From: Antoine Riard <antoine.riard@gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>,
security@ariard.me
Subject: Re: [bitcoindev] [FULL DISCLOSURE]: Replacement Cycling Attacks on Attacks on Bitcoin Miners Block Templates
Date: Mon, 27 Jan 2025 23:01:02 +0000 [thread overview]
Message-ID: <CALZpt+HyQyj6EUf39JX3nuD3izsmBSG9XUcV-EVrC05o2T=u7A@mail.gmail.com> (raw)
In-Reply-To: <7aa8b4bd7c2d475ad07efb90d770fbd8@dtrt.org>
[-- Attachment #1: Type: text/plain, Size: 2506 bytes --]
> Do I understand correctly that this attack only applies if Alice
> attempts to fee bump her batch transaction? In short, is this the
> attack:
Fundamentally, yes. This attack is primarily targeting all transaction
flows with a fee bump.
See section 6.4 of the joined paper for more characterization of the
"Transaction Traffic Hijack", while no quantitative analysis of the average
% txn affected has been done so far.
There could also be UTXO-sharing flows that are affected, where the
attacker is propagating first, and preventing the other tx to propagate,
before evicting his own package.
However no test and no thoughts has been given to this
"block-first-at-the-UTXO-root" alternative, the fee bump is more concerning.
Best,
Antoine
Le lun. 27 janv. 2025 à 22:17, David A. Harding <dave@dtrt.org> a écrit :
> On 2025-01-27 05:22, Antoine Riard wrote:
> > As soon as Alice's batch transaction starts to propagate, Mallet
> > consumes its 2 outputs with 2 chain of junk transactions to reach max
> > package limits (25 descendants) and block the carve-out. The junk
> > transactions are of size 150 bytes and feerates 2 satoshis per virtual
> > byte and they have 2 parents: one Alice's payout UTXO and one Mallet's
> > UTXO.
> >
> > Starting from this point, Alice's exchange server logic should either
> > (a) attempts a CPFP or (b) attempts a RBF on the batch transaction. As
> > there is no global mempool, Alice is uncertain on the explanation for
> > the lack of propagation of her batch transaction [...]
>
> Do I understand correctly that this attack only applies if Alice
> attempts to fee bump her batch transaction? In short, is this the
> attack:
>
> - Alice broadcasts a transaction.
> - Mallet pins Alice.
> - Alice doesn't realize she's been pinned and bumps the fees.
> - The bump doesn't propagate due to the pin, but Mallet receives it
> anyway somehow.
> - Mallet mines the fee bump, but nobody else mines it because it didn't
> propagate. Mallet thus makes more money than other miners.
>
> Thanks,
>
> -Dave
>
--
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 visit https://groups.google.com/d/msgid/bitcoindev/CALZpt%2BHyQyj6EUf39JX3nuD3izsmBSG9XUcV-EVrC05o2T%3Du7A%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 3393 bytes --]
prev parent reply other threads:[~2025-01-27 23:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-27 15:22 [bitcoindev] [FULL DISCLOSURE]: Replacement Cycling Attacks on Attacks on Bitcoin Miners Block Templates Antoine Riard
2025-01-27 22:17 ` David A. Harding
2025-01-27 23:01 ` Antoine Riard [this message]
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='CALZpt+HyQyj6EUf39JX3nuD3izsmBSG9XUcV-EVrC05o2T=u7A@mail.gmail.com' \
--to=antoine.riard@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=dave@dtrt.org \
--cc=security@ariard.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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