Peter Todd [ARCHIVE] on Nostr: š Original date posted:2023-01-10 šļø Summary of this message: Full-RBF is ...
š
Original date posted:2023-01-10
šļø Summary of this message: Full-RBF is proposed to prevent intentional and unintentional DoS attacks on multi-party protocols by double-spending inputs with low-fee transactions. The cost of such attacks is expensive, but the issue can also be solved in a non-full-RBF world by creating non-conflicting transactions.
š Original message:On Mon, Jan 09, 2023 at 09:11:46PM -1000, David A. Harding wrote:
> On 2023-01-09 12:18, Peter Todd via bitcoin-dev wrote:
> > [The quote:]
> >
> > "Does fullrbf offer any benefits other than breaking zeroconf
> > business
> > practices?"
> >
> > ...has caused a lot of confusion by implying that there were no
> > benefits. [...]
> >
> > tl;dr: without full-rbf people can intentionally and unintentionally DoS
> > attack
> > multi-party protocols by double-spending their inputs with low-fee txs,
> > holding
> > up progress until that low-fee tx gets mined.
>
> Hi Peter,
>
> I'm confused. Isn't this an easily solvable issue without full-RBF?
> Let's say Alice, Bob, Carol, and Mallory create a coinjoin transaction.
> Mallory either intentionally or unintentionally creates a conflicting
> transaction that does not opt-in to RBF.
>
> You seem to be proposing that the other participants force the coinjoin
> to complete by having the coinjoin transaction replace Mallory's
> conflicting transaction, which requires a full-RBF world.
>
> But isn't it also possible in a non-full-RBF world for Alice, Bob, and
> Carol to simply create a new coinjoin transaction which does not include
> any of Mallory's inputs so it doesn't conflict with Mallory's
> transaction? That way their second coinjoin transaction can confirm
> independently of Mallory's transaction.
How do you propose that the participants learn about the double-spend? Without
knowing that it happened, they can't respond as you suggested.
> Likewise, if Alice and Mallory attempt an LN dual funding and Mallory
> creates a conflict, Alice can just create an alternative dual funding
> with Bob rather than try to use full-RBF to force Mallory's earlier dual
> funding to confirm.
Same issue.
And of course, in both cases full-rbf makes Mallory have to actually pay full
price for the attack. Either because the intended transaction goes through. Or
because their double-spending DoS attack had to be much more expensive in the
first place.
> > ## Transaction Pinning
> >
> > Exploiting either rule is expensive.
>
> I think this transaction pinning attack against coinjoins and dual
> fundings is also solved in a non-full-RBF world by the honest
> participants just creating a non-conflicting transaction.
>
> That said, if I'm missing something and these attacks do actually apply,
> then it might be worth putting price figures on the attack in terms most
> people will understand. The conflicting inputs attack you described in
> the beginning as being solved by full-RBF costs about $0.05 USD at
> $17,000/BTC. The transaction pinning attack you imply is unsolved by
> full-RBF costs about $17.00. If both attacks apply, any protocol which
> is vulnerable to a $17.00 attack still seems highly vulnerable to me, so
> it doesn't feel like a stretch to say that full-RBF lacks significant
> benefits for those protocols.
Coinjoins are an automated process that happens constantly. As I described in
my email, it's totally normal for them to fail constantly - I was told by
Wasabi that only ~25% of coinjoin rounds succeed right now, a figure that
frankly was much higher than I expected. Being forced to spend $17/round rather
than $0.05/round is a huge improvement that adds up to serious money at the
scale at which Wasabi and similar protocols operate at.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230110/9e0a6645/attachment.sig>;
šļø Summary of this message: Full-RBF is proposed to prevent intentional and unintentional DoS attacks on multi-party protocols by double-spending inputs with low-fee transactions. The cost of such attacks is expensive, but the issue can also be solved in a non-full-RBF world by creating non-conflicting transactions.
š Original message:On Mon, Jan 09, 2023 at 09:11:46PM -1000, David A. Harding wrote:
> On 2023-01-09 12:18, Peter Todd via bitcoin-dev wrote:
> > [The quote:]
> >
> > "Does fullrbf offer any benefits other than breaking zeroconf
> > business
> > practices?"
> >
> > ...has caused a lot of confusion by implying that there were no
> > benefits. [...]
> >
> > tl;dr: without full-rbf people can intentionally and unintentionally DoS
> > attack
> > multi-party protocols by double-spending their inputs with low-fee txs,
> > holding
> > up progress until that low-fee tx gets mined.
>
> Hi Peter,
>
> I'm confused. Isn't this an easily solvable issue without full-RBF?
> Let's say Alice, Bob, Carol, and Mallory create a coinjoin transaction.
> Mallory either intentionally or unintentionally creates a conflicting
> transaction that does not opt-in to RBF.
>
> You seem to be proposing that the other participants force the coinjoin
> to complete by having the coinjoin transaction replace Mallory's
> conflicting transaction, which requires a full-RBF world.
>
> But isn't it also possible in a non-full-RBF world for Alice, Bob, and
> Carol to simply create a new coinjoin transaction which does not include
> any of Mallory's inputs so it doesn't conflict with Mallory's
> transaction? That way their second coinjoin transaction can confirm
> independently of Mallory's transaction.
How do you propose that the participants learn about the double-spend? Without
knowing that it happened, they can't respond as you suggested.
> Likewise, if Alice and Mallory attempt an LN dual funding and Mallory
> creates a conflict, Alice can just create an alternative dual funding
> with Bob rather than try to use full-RBF to force Mallory's earlier dual
> funding to confirm.
Same issue.
And of course, in both cases full-rbf makes Mallory have to actually pay full
price for the attack. Either because the intended transaction goes through. Or
because their double-spending DoS attack had to be much more expensive in the
first place.
> > ## Transaction Pinning
> >
> > Exploiting either rule is expensive.
>
> I think this transaction pinning attack against coinjoins and dual
> fundings is also solved in a non-full-RBF world by the honest
> participants just creating a non-conflicting transaction.
>
> That said, if I'm missing something and these attacks do actually apply,
> then it might be worth putting price figures on the attack in terms most
> people will understand. The conflicting inputs attack you described in
> the beginning as being solved by full-RBF costs about $0.05 USD at
> $17,000/BTC. The transaction pinning attack you imply is unsolved by
> full-RBF costs about $17.00. If both attacks apply, any protocol which
> is vulnerable to a $17.00 attack still seems highly vulnerable to me, so
> it doesn't feel like a stretch to say that full-RBF lacks significant
> benefits for those protocols.
Coinjoins are an automated process that happens constantly. As I described in
my email, it's totally normal for them to fail constantly - I was told by
Wasabi that only ~25% of coinjoin rounds succeed right now, a figure that
frankly was much higher than I expected. Being forced to spend $17/round rather
than $0.05/round is a huge improvement that adds up to serious money at the
scale at which Wasabi and similar protocols operate at.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230110/9e0a6645/attachment.sig>;