From: "David A. Harding" <dave@dtrt•org>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
Date: Sun, 21 Jul 2024 05:35:31 -1000 [thread overview]
Message-ID: <d57a02a84e756dbda03161c9034b9231@dtrt.org> (raw)
In-Reply-To: <ZpvRvRybauFFnhQV@petertodd.org>
On 2024-07-20 05:03, Peter Todd wrote:
> What other "free" relay attacks can you think of that were fixed?
The two you mention were the two I had in mind.
> Did you actually read my One-Shot RBFR proposal?
Yes. It didn't provide any examples of RBFr free relay and I wanted to
see whether a basic RBFr free relay attack would use significantly more,
significantly less, or about the same amount of bandwidth per dollar
spent as other free relay attacks. My conclusion is that it's about the
same.
> Weak blocks are not a solution to any of the "free" relay attacks I've
> disclosed and your source does not claim that they are a "free" relay
> solution.
It does not explicitly say that, but it does say: "bonus use-cases:
“Forcible insertion” of transactions that are incentive-compatible but
violate anti-DoS rules".
For example, in some of the scenarios you describe, the attacker sends
an appealing transaction to miners and then sends less appealing
versions of that transaction to relay nodes. If the appealing
transaction enters the top mempool and gets included in a weak block,
relay nodes will stop relaying less appealing variations minutes to
hours before they otherwise would.
Weak blocks also provide a decentralized DoS-resistant mechanism for
voluntarily communicating all sorts of information from miners to other
miners and relay nodes. That makes them an excellent tool for resolving
any attack that depends on miners and relay nodes having a divergent set
of transactions.
> 1) Have you've read my One Shot RBFR proposal? In particular, my
> analysis of DoS attacks *including* existing DoS attacks like
> simultaneous broadcast.
>
> 2) Do you agree or disagree with me that these existing DoS attacks
> are real?
Yes, I've read your proposal, and I agree those attacks are plausible.
In my mind, the major difference between those free relay attacks
and RBFR free relay attacks is how solvable they are.
I think it's easy to sketch a significant mitigation to all free relay
attacks (including RBFR):
- Reduce the maximum size of both relayable transactions and in-mempool
packages, e.g. from 100,000 vbytes to 1,000 vbytes.
- Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB.
- Increase the default mempool feerate floor, e.g. from e.g. from 1
sat/vb to 100 sat/vb.
That would break relay of many existing presigned transactions,
potentially leading to money loss, and would break other existing
usecases, not to mention introduce other problems. However, I think
it's sufficient to prove that a mitigation to free relay is possible
without rendering the network unusable.
Of course, an ideal solution wouldn't require placing any additional
constraints on mempool policy. For the case of free relay due to
divergent mempool policies, maybe it's something that could be done with
transaction set reconciliation (~erlay), functions for allowing
independent nodes to come to consistent conclusions about the best
revenue set of transactions (~cluster mempool), P2P relay of non-obvious
cluster linearizations[1], and miners voluntarily committing to their
mempool contents in candidate blocks and P2P relaying those commitments
in weak blocks.
Innovations like that don't work for RBFR. If mempool policy is kept
the same, free relay attacks with RBFR remain equally effective no
matter what mechanisms we implement to improve preconsensus consistency.
If pure RBFR is added and clever protocol developers find ways to
largely fix other free relay attacks, then devs will either need to
significantly restrict mempool policy anyway or will need to restrict or
remove RBFR to make Bitcoin Core safe. Given that, it seems to me like
a very reasonable decision not to add pure RBFR and to wait until better
tools like cluster mempool become available before evaluating
significant changes to RBF policy (like one-shot RBFR).
Thanks,
-Dave
[1]
https://github.com/bitcoinops/bitcoinops.github.io/pull/1421#discussion_r1415834695
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/d57a02a84e756dbda03161c9034b9231%40dtrt.org.
next prev parent reply other threads:[~2024-07-21 18:04 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 15:56 Peter Todd
2024-07-18 23:04 ` [bitcoindev] " Antoine Riard
2024-07-19 1:05 ` Peter Todd
2024-07-19 13:52 ` Antoine Riard
2024-07-19 14:38 ` Peter Todd
2024-07-19 23:58 ` Antoine Riard
2024-07-20 0:46 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-07-21 2:06 ` Antoine Riard
2024-07-21 20:17 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-07-22 1:59 ` 'Anonymous User' via Bitcoin Development Mailing List
2024-07-24 0:44 ` Antoine Riard
2024-07-24 0:35 ` Antoine Riard
2024-07-19 12:41 ` /dev /fd0
2024-07-19 23:56 ` Antoine Riard
2024-07-20 5:57 ` /dev /fd0
2024-07-20 15:08 ` Peter Todd
2024-07-21 2:13 ` Antoine Riard
2024-07-21 6:16 ` /dev /fd0
2024-07-21 2:12 ` Antoine Riard
2024-07-19 18:26 ` [bitcoindev] " Murch
2024-07-20 14:10 ` Peter Todd
2024-07-20 6:41 ` David A. Harding
2024-07-20 15:03 ` Peter Todd
2024-07-20 15:30 ` Peter Todd
2024-07-21 15:35 ` David A. Harding [this message]
2024-07-21 20:25 ` Peter Todd
2024-07-24 0:38 ` Antoine Riard
2024-07-21 2:10 ` Antoine Riard
2024-07-22 15:10 ` Peter Todd
2024-07-24 0:41 ` Antoine Riard
2024-07-22 11:45 ` [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not Peter Todd
2024-07-22 16:43 ` David A. Harding
2024-07-22 20:06 ` Peter Todd
2024-07-22 22:08 ` David A. Harding
2024-07-23 11:29 ` Peter Todd
2024-07-24 0:42 ` Antoine Riard
2024-07-22 17:13 ` [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core 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=d57a02a84e756dbda03161c9034b9231@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=bitcoindev@googlegroups.com \
--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