From: Peter Todd <pete@petertodd•org>
To: Antoine Riard <antoine.riard@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
Date: Fri, 19 Jul 2024 14:38:11 +0000 [thread overview]
Message-ID: <Zpp6U00Mp7Z/bOej@petertodd.org> (raw)
In-Reply-To: <CALZpt+HJvBXM_geK7JC8umrt1goq8bc+pnY0mk+o+r_+bjrtew@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6279 bytes --]
On Fri, Jul 19, 2024 at 02:52:29PM +0100, Antoine Riard wrote:
> Hi Peter,
>
> > I think you need to re-read the attack carefully before we discuss this
> > further. The % of hash power mining full-rbf does not significantly
> change the
> > cost efficiency of the attack as long as the fee-rate of the B
> transaction(s)
> > is below the minimum economic fee-rate necessary for miners to mine a
> > transaction. Above the minimum economic fee-rate, the cost efficiency is
> an
> > essentially linear function of % of full-rbf miners.
>
> This is not the % of hash power mining _full-rbf_ I was pointing to, just
> the indistinct
> total % of hash power mining.
>
> In my understanding, this is the scenario:
> - Alice broadcasts small size, low-feerate transaction opt-in disabled A to
> 99% of the miners+network nodes mempools
> - Alice broadcasts a double-spend of A, a high-feerate transaction A2 to
> Mark, a single miner
> - Network nodes does not relay transaction A to Mark and vice-versa Mark
> does not relay transaction A2 to network nodes
Here I think you've misunderstood the attack.
A is a low fee-rate transaction with opt-in disabled. When it is broadcast, it
reaches 100% of nodes.
A2 is a full-RBF double-spend of A. When it is broadcast, it reaches all
nodes/miners with full-RBF enabled, replacing A. Full-RBF nodes do in fact
relay A2 to non-full-rbf nodes they're peered with. But those nodes reject A2
as it is a full-RBF replacement.
We are *not* trying to limit A2 to a single miner, or do any kind of
simultaneous broadcast. We don't need to.
> - Alice broadcasts a child B of transaction A to 99% of the miners+network
> nodes mempools
The % of miners/nodes that accept B isn't particularly relevant; this is an
attack primarily against nodes that have full-RBF disabled (though those nodes
will waste the bandwidth of their full-RBF peers).
> - Mark, the single miner confirms in a block A2, rendering as a waste A+B
> network bandwidth
Again, the attack does not depend on a single miner receiving A2. Indeed, it
works fine even if 100% of hash power is mining A2.
Also, A2 isn't necessarily what gets mined. A2 can be broadcast with a fee-rate
only slightly higher than A that is still below the minimum economic fee-rate,
and then replaced later with an even higher fee-rate double-spend that is a
high enough fee-rate to get mined. Remember that RBF Rule #6 prohibits a
replacement if the fee-rate of the replacement is lower than the directly
replaced transaction.
> Correct if I'm wrong with this scenario and if it does not match the attack
> vector you're describing.
You're not far off. But I believe you are still misunderstanding details, as
described above.
> The child B can be extended with a full chain of useless children within
> max mempool limits.
Correct. Although it's probably simplest to just pick a B that is large enough
to max out the mempool limits on its own.
> The attack efficiency (i.e the total vB of bandwidth network waste) is
> dependent on the delay
> by which transaction A2 is included in Mark's block template and
> subsequently mined. Back to
> my observation, higher are Mark hashrate ressources, less there is latency
> to let transaction B
> spontaneously propagate on the network, or for Alice to (re)-broadcast in
> cycle.
Again, A2 does not need to pay a high enough fee-rate to be economical to mine.
So there are no particular latency requirements between when A, B, and A2 are
broadcast.
All that is necessary for this class of attack is there be at least one miner
willing to mine A2 (or a further double-spend), who rejects A.
> All that said, I think my open question to you at the beginning of my
> answer is still there,
> i.e how much time has been left between the private report of this issue to
> the sec mailing
> list and the public disclosure of your email.
This attack is simply a variant of attacks that were publicly disclosed months
ago, that Core has chosen not to respond to at all, so the exact timeframe
isn't very relevant. This is not actually a new class of attack; the whole
point of my disclosure is to show that Core does not actually care about this
class of attack by showing they won't even bother to fix the simplest possible
version, even when the fix is trivial.
But anyway, I disclosed on Jul 7th giving a 7 day deadline before I'd publish
if I couldn't get any response. I publicly verified that achow (and others) had
received my email on Jul 10th, with achow promising a response. On Jul 12th
rather than replying, Core closed my full-RBF pull-req that fixes this issue.
On Jul 15th I reached out again, and after someone else pointed out that
failing to reply to me was degrading the value of the security mailing list,
and finally got achow and glozow to respond in a perfunctory fashion (glozow
recommended that I open a new full-RBF pull-req). So I published this on Jul
18th after my replies to achow and glozow didn't get any response. This whole
time no-one has asked me to not publish this attack; asking me to keep this
fact about mempools a secret would be rather duplicitous given that a key
argument for TRUC/V3 relies on "free" relay attacks not being possible.
Core could have *easily* responded by simply merging my pull-req to enable
full-RBF by default, a trivial change that has had lots of ACKs from technical
reviewers, which ~100% of hash power has adopted. No-one reasonable would have
questioned merging that pull-req. They chose not to do so, proving my point
that none of this has anything to do with a genuine technical concern.
I was previously on the bitcoin-security mailing list for years, and almost
every disclosed attack has gotten a response within 24 hours, with the longest
about 72 hours (I just skimmed through my archives to double check). Failing to
respond at all is very unusual.
--
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/Zpp6U00Mp7Z/bOej%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-07-19 18:27 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 15:56 [bitcoindev] " 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 [this message]
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
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=Zpp6U00Mp7Z/bOej@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/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