Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2018-06-26 📝 Original message:On Tue, Jun 26, 2018 at ...
📅 Original date posted:2018-06-26
📝 Original message:On Tue, Jun 26, 2018 at 12:12 AM, Bradley Denby via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> That's right, the idea is to choose Dandelion relays independently from
> whether they support Dandelion. If the chosen nodes do not support
> Dandelion, then the transactions are fluffed. Otherwise, the transactions
> are relayed along a stem.
I don't see any problem with doing that... Although an additional
countermeasure we're likely to take against attacks on partial
deployment is that we'd likely make the wallet's use of stem
forwarding be a configuration option which is initially hidden and set
to off. In a subsistent release after dandelion propagation is widely
deployed we'd unhide the option and default it to on. This way users
don't begin using it until the deployment is relatively dense.
I believe this approach is a is sufficient such that it could always
select out-peers that were dandelion capable without harm, but at the
same time I also don't see a reason that we can't do both.
(in fact, for privacy reasons we might want to three-stage the
deployment, with the use of dandelion by wallets having a setting of
off, sometimes, or always so that attackers can't so easily correlate
the use of dandelion with upgrades.)
📝 Original message:On Tue, Jun 26, 2018 at 12:12 AM, Bradley Denby via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> That's right, the idea is to choose Dandelion relays independently from
> whether they support Dandelion. If the chosen nodes do not support
> Dandelion, then the transactions are fluffed. Otherwise, the transactions
> are relayed along a stem.
I don't see any problem with doing that... Although an additional
countermeasure we're likely to take against attacks on partial
deployment is that we'd likely make the wallet's use of stem
forwarding be a configuration option which is initially hidden and set
to off. In a subsistent release after dandelion propagation is widely
deployed we'd unhide the option and default it to on. This way users
don't begin using it until the deployment is relatively dense.
I believe this approach is a is sufficient such that it could always
select out-peers that were dandelion capable without harm, but at the
same time I also don't see a reason that we can't do both.
(in fact, for privacy reasons we might want to three-stage the
deployment, with the use of dandelion by wallets having a setting of
off, sometimes, or always so that attackers can't so easily correlate
the use of dandelion with upgrades.)