From: Peter Todd <pete@petertodd•org>
To: "David A. Harding" <dave@dtrt•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive
Date: Tue, 10 Jan 2023 03:47:48 -0500 [thread overview]
Message-ID: <Y70mNHsX4JcKYZyi@petertodd.org> (raw)
In-Reply-To: <aaaeda2950e61127a3218c523927a0d8@dtrt.org>
[-- Attachment #1: Type: text/plain, Size: 3490 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-01-10 8:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-09 22:18 Peter Todd
2023-01-10 7:11 ` David A. Harding
2023-01-10 8:47 ` Peter Todd [this message]
2023-01-10 10:02 ` David A. Harding
2023-01-10 10:06 ` Peter Todd
2023-01-10 20:14 ` David A. Harding
2023-01-13 23:37 ` Peter Todd
2023-01-10 9:19 ` alicexbt
2023-01-10 10:03 ` Peter Todd
2023-01-10 17:10 ` alicexbt
2023-01-13 23:46 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y70mNHsX4JcKYZyi@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox