From: Peter Todd <pete@petertodd•org>
To: "David A. Harding" <dave@dtrt•org>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
Date: Sat, 20 Jul 2024 15:03:25 +0000 [thread overview]
Message-ID: <ZpvRvRybauFFnhQV@petertodd.org> (raw)
In-Reply-To: <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
[-- Attachment #1: Type: text/plain, Size: 5133 bytes --]
On Fri, Jul 19, 2024 at 08:41:07PM -1000, David A. Harding wrote:
> On 2024-07-18 05:56, Peter Todd wrote:
> > I disclosed it to the bitcoin-security mailing list as a test: does
> > Bitcoin Core actually care about free relay attacks?
>
> They do. Several free relay attacks that were present in earlier
> versions of Bitcoin were eliminated in later versions.
I can think of two such eliminated attacks, both significantly more "free" than
anything we're discussing here, and interestingly, both attacks that I
participated in discovering or fixing:
1) The fact that non-final transactions were accepted into the mempool, even if
they wouldn't be valid for thousands of years (IIRC I exploited the
mempool.space mixer with this).
2) nSequence replacement, which replace-by-fee ultimately fixed.
What other "free" relay attacks can you think of that were fixed?
> New proposals
> are evaluated for their potential to create new permanent free relay
> vectors. The discovery of free relay is almost always reason enough to
> reject a proposal.
Yet even though Murch (I think quite accurately) said that the full-rbf "free"
relay attack was a fairly obvious attack, my pull-req to enable it sat for over
a year without any comment from Core... Surely, if Core was genuinely concerned
about these attacks, Core would rush to quietly fix them; we could have shipped
full-RBF by default something like six months ago.
And in spite of this apparent concern about "free" relay, I don't see anyone
trying to mitigate the "free" relay attack that the introduction of TRUC/V3
transactions will cause.
It's also notable that Core *introduced* a new form of "free" relay a few years
back with mempool expiration.
> The free relay attack you describe in your email and the type of free
> relay enabled by your replace-by-feerate (RBFr) proposal can allow an
> attacker to 10x to 100x the amount of bandwidth used network wide by
> relay nodes for a cost of $10,000 to $50,000 a day (or, as you mention,
> effectively for free if they were going to send a bunch of transactions
> anyway).
Did you actually read my One-Shot RBFR proposal? I covered DoS attacks:
https://petertodd.org/2024/one-shot-replace-by-fee-rate#denial-of-service-attacks
The *status quo* is that free relay attacks are unavoidable, because, at
minimum, you can always pull them off by simultaneous broadcast of
contradictory transactions (especially if you, eg, need to do consolidation
transactions anyway). RBFR does not change that.
> I cannot imagine what would make you think that protocol developers are
> not concerned about attacks that could drive large numbers of relay
> nodes off the network for a cost easily affordable to any well-funded
> adversary.
>
> In this case, you've found a specific instance (full-RBF vs signaled
> RBF) of a well-known general problem (optional policies leading to
> mempool inconsistencies, allowing free relay) and appear to be arguing
> that devs don't care about free relay because they refused to reverse a
> previous decision (to not change the RBF configuration default) that has
> been hotly debated multiple times.
...and your point is? Are you saying that Core developers put politics above
security, by refusing to fix a known "free" relay attack simply because it was
"hotly debated"?
> > I believe the authors of that BIP are fully aware of the fact that
> > "free" relay is an unavoidable problem, making their rational for
> > TRUC/V3 bogus
>
> Differences in node policy leading to mempool inconsistencies (which
> allows free relay) is a well known problem that's the result of Bitcoin
> being an open protocol based on free/libre software (two things I think
> we all want). Many protocol developers have attempted to address the
> problem over the years, most recently just a few months ago with an
> updated proposal for using weak blocks as a first step to address
> "diverging mempool policies".[1]
Weak blocks are not a solution to any of the "free" relay attacks I've
disclosed, and your source, https://delvingbitcoin.org/t/second-look-at-weak-blocks/805,
does not claim that they are a "free" relay solution.
Weak blocks simply aren't relevant until a miner has received a transaction and
found a weak block. By that point the "free" relay has already happened.
Anyway, before I spend time replying to the rest of your email, I think it'd be
helpful if you confirm two things to make sure we're actually on the same page:
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?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
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/ZpvRvRybauFFnhQV%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-07-20 15:12 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 [this message]
2024-07-20 15:30 ` Peter Todd
2024-07-21 15:35 ` David A. Harding
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=ZpvRvRybauFFnhQV@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoindev@googlegroups.com \
--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