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: Sun, 21 Jul 2024 20:25:25 +0000 [thread overview]
Message-ID: <Zp1utYduhnWf4oA4@petertodd.org> (raw)
In-Reply-To: <d57a02a84e756dbda03161c9034b9231@dtrt.org>
[-- Attachment #1: Type: text/plain, Size: 8772 bytes --]
On Sun, Jul 21, 2024 at 05:35:31AM -1000, David A. Harding wrote:
> 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.
Right. So in the entire history of Core, we have two quite ridiculous free
relay attacks that got fixed, and we *added* a significant free-relay
vulnerability by adding mempool expiration. We also added a free-relay
vulnerability, and a fill-and-dump vulnerability, with the mempool size limit.
That's not evidence that Core actually cares much about "free" relay.
> > 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.
Good. So you basically agree with me that RBFR does _not_ significantly change
the status quo.
I'll respond to the specifics of your RBFR analysis separately; it does *not*
apply to one-shot RBFR.
> > 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.
Yes, "minutes to hours". Transactions relay on the order of seconds to tens of
seconds. Weak blocks simply aren't relevant.
Also, the attacks I've described are ones that can be pulled off by having a
tiny minority of hash power mine a double spend. Weak blocks don't help you
there, as that tiny minority isn't likely to even find a weak block.
> 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.
For weak blocks to be a solution, you at minimum need to take away the ability
of miners to choose what transactions they mine. For example, consider the
scenario where you do a "free" relay attack by broadcasting transactions that
OCEAN rejects, and then double-spending them via OCEAN _after_ the transactions
have been broadcast. Equally, you'd need to take away the ability of RBFR
miners to do the revenue maximizing thing: mining RBFR replacements.
I'll also second Antoine Riard's objections to this class of idea in general:
you're really proposing a secondary pseudo-consensus mechanism to solve the
problems in your first pseud-consensus mechanism.
> > 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.
The irony here is you've almost described a _good_ mitigation to "free" relay
attacks: just reduce the size of the default mempool. A big reason why we have
"free" relay attacks right now is because we allow transactions to be broadcast
that are uneconomical to mine; if you limit transaction broadcast to
transactions that are economical to mine in the near future, relay is more
expensive.
For miners, you can make a decent argument that they want to have on-hand a big
backlog of transactions in case mempools empty out; in my conversations with
miners almost all of them claim they run with much larger than default mempools
(eg >1GB). I've even discussed mempool emptying attacks and RBFR in this
context with miners: they didn't think they were an issue as replacing their
mempools was absurdly expensive.
Fee estimation of course can make use of knowing what backlog of transactions
exist. But I'm sure only a small minority of nodes do fee estimation.
A variant of this solution would be to just pick the minimum relay fee to be
some number N blocks worth of transactions "back" from the highest fee-rate tip
of the mempool. Obviously, this will be easier to implement with a cluster
mempool, and requires package relay for the CPFP case.
> 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
Erlay (and transaction set reconciliation in general) does not help you
reconcile conflicting transactions. It simply lets you efficiently learn about
the total set of known transactions. Notice how the Erlay is based on WTXIDs,
and the BIP doesn't even talk about dealing with conflicts.
> independent nodes to come to consistent conclusions about the best
> revenue set of transactions (~cluster mempool),
That's quite irrelevant as RBFR _is_ the highest revenue policy in lots of
situations. That's one reason why in my discussions with miners/pools, they're
interested in implementing it (mining pools have very low profit margins, so
every cent counts, and RBFR replacements are reasonably common already). Mining
pools implemented full-RBF against the wishes of Core for the same reason:
full-RBF earns you more revenue, and I made it easy to implement.
Implementing one-shot RBFR is probably going to be quite a bit cleaner with
cluster mempools, as it'll provide a nice way to rapidly determine what the
minimum economic fee-rate is to get into the next (N) blocks. (though you can
do this in a less clean way by just periodically assembling a trial block and
recording the value, or using the fee estimation code)
Finally, why are clusters even relevant to "free" relay? Most "free" relay
attacks don't even need transaction packages. The really boring and unsolvable
"free" relay attack of simply broadcasting large transactions that conflict
with small ones is done with single transaction packages.
> 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.
As I explained above, weak blocks is not a "free" relay solution.
> 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.
I could also argue that magic ponies will solve "free" relay. We have to weight
that hope with the likelyhood it will happen; none of the technical
advancements you have mentioned even come close.
Anyway, I'll reply to the rest of your other email separately.
--
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/Zp1utYduhnWf4oA4%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-07-21 20:48 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
2024-07-21 20:25 ` Peter Todd [this message]
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=Zp1utYduhnWf4oA4@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