> 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