public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "David A. Harding" <dave@dtrt•org>
To: Peter Todd <pete@petertodd•org>,
	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: Mon, 09 Jan 2023 21:11:46 -1000	[thread overview]
Message-ID: <aaaeda2950e61127a3218c523927a0d8@dtrt.org> (raw)
In-Reply-To: <Y7ySzDjzx5eDjOH9@petertodd.org>

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.

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.

> ## 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.

Thanks,

-Dave


  reply	other threads:[~2023-01-10  7:11 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 [this message]
2023-01-10  8:47   ` Peter Todd
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=aaaeda2950e61127a3218c523927a0d8@dtrt.org \
    --to=dave@dtrt$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=pete@petertodd$(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