š
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>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 23:18:27
in reply to nevent1qā¦9z9e
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 23:18:27Event JSON
{
"id": "025db9b7918d16a970198a2af0e250ad6884abb8738b9d201dd17f423d38964a",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686179907,
"kind": 1,
"tags": [
[
"e",
"93af7b1be8797d2a1683551105f962f360fcab88fd5768c2fa8ac19d93416ad2",
"",
"root"
],
[
"e",
"8450370cfb3ef6b42b4038e640f1032de84b1e97d71895332993a0ce194ee7fb",
"",
"reply"
],
[
"p",
"d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2"
]
],
"content": "š
Original date posted:2023-01-10\nšļø 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.\nš Original message:On Mon, Jan 09, 2023 at 09:11:46PM -1000, David A. Harding wrote:\n\u003e On 2023-01-09 12:18, Peter Todd via bitcoin-dev wrote:\n\u003e \u003e [The quote:]\n\u003e \u003e \n\u003e \u003e \"Does fullrbf offer any benefits other than breaking zeroconf\n\u003e \u003e business\n\u003e \u003e practices?\"\n\u003e \u003e \n\u003e \u003e ...has caused a lot of confusion by implying that there were no\n\u003e \u003e benefits. [...]\n\u003e \u003e \n\u003e \u003e tl;dr: without full-rbf people can intentionally and unintentionally DoS\n\u003e \u003e attack\n\u003e \u003e multi-party protocols by double-spending their inputs with low-fee txs,\n\u003e \u003e holding\n\u003e \u003e up progress until that low-fee tx gets mined.\n\u003e \n\u003e Hi Peter,\n\u003e \n\u003e I'm confused. Isn't this an easily solvable issue without full-RBF?\n\u003e Let's say Alice, Bob, Carol, and Mallory create a coinjoin transaction.\n\u003e Mallory either intentionally or unintentionally creates a conflicting\n\u003e transaction that does not opt-in to RBF.\n\u003e \n\u003e You seem to be proposing that the other participants force the coinjoin\n\u003e to complete by having the coinjoin transaction replace Mallory's\n\u003e conflicting transaction, which requires a full-RBF world.\n\u003e \n\u003e But isn't it also possible in a non-full-RBF world for Alice, Bob, and\n\u003e Carol to simply create a new coinjoin transaction which does not include\n\u003e any of Mallory's inputs so it doesn't conflict with Mallory's\n\u003e transaction? That way their second coinjoin transaction can confirm\n\u003e independently of Mallory's transaction.\n\nHow do you propose that the participants learn about the double-spend? Without\nknowing that it happened, they can't respond as you suggested.\n\n\u003e Likewise, if Alice and Mallory attempt an LN dual funding and Mallory\n\u003e creates a conflict, Alice can just create an alternative dual funding\n\u003e with Bob rather than try to use full-RBF to force Mallory's earlier dual\n\u003e funding to confirm.\n\nSame issue.\n\nAnd of course, in both cases full-rbf makes Mallory have to actually pay full\nprice for the attack. Either because the intended transaction goes through. Or\nbecause their double-spending DoS attack had to be much more expensive in the\nfirst place.\n\n\u003e \u003e ## Transaction Pinning\n\u003e \u003e \n\u003e \u003e Exploiting either rule is expensive.\n\u003e \n\u003e I think this transaction pinning attack against coinjoins and dual\n\u003e fundings is also solved in a non-full-RBF world by the honest\n\u003e participants just creating a non-conflicting transaction.\n\u003e \n\u003e That said, if I'm missing something and these attacks do actually apply,\n\u003e then it might be worth putting price figures on the attack in terms most\n\u003e people will understand. The conflicting inputs attack you described in\n\u003e the beginning as being solved by full-RBF costs about $0.05 USD at\n\u003e $17,000/BTC. The transaction pinning attack you imply is unsolved by\n\u003e full-RBF costs about $17.00. If both attacks apply, any protocol which\n\u003e is vulnerable to a $17.00 attack still seems highly vulnerable to me, so\n\u003e it doesn't feel like a stretch to say that full-RBF lacks significant\n\u003e benefits for those protocols.\n\nCoinjoins are an automated process that happens constantly. As I described in\nmy email, it's totally normal for them to fail constantly - I was told by\nWasabi that only ~25% of coinjoin rounds succeed right now, a figure that\nfrankly was much higher than I expected. Being forced to spend $17/round rather\nthan $0.05/round is a huge improvement that adds up to serious money at the\nscale at which Wasabi and similar protocols operate at.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230110/9e0a6645/attachment.sig\u003e",
"sig": "d05573baa72845ad4e320f985117652a10943c689ae7ce68adc5ff79ac13ab1b9816c7a9a84eb4565d9ce692125aeafdc152924787c0468f616791ef0ef408c7"
}