Re: [bitcoindev] Keyless Anchors Are Vulnerable To Replacement Cycling Attacks

[Keagan McClelland <keagan.mcclelland@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4751 bytes --]

>  I think the existence of this additional type of replacement cycling
attack suggests that adding an optional rebroadcasting module to Bitcoin
Core
that would keep track of dropped transactions and re-add them to mempools
when
they are again valid would make sense. This fixes all replacement cycling
attacks and there's probably lots of nodes who have the memory and/or disk
space to keep track of dropped transactions like this.

It kinda seems like this might introduce a DOS vector to the nodes running
this
module since you can keep cycling B3, B4 etc. and force the mempool to house
all of these until one of them gets mined. Further, it would cause the
mempool
to have to decide which of these dead transactions gets priority upon the
eviction
of the conflicting one. Is this something you've given thought to?
Admittedly I
haven't dived deep into it.

Keags

On Fri, Aug 2, 2024 at 5:30 AM Peter Todd <pete@petertodd.org> wrote:

> This feels like someone should have published it before. But I can't find
> an
> obvious citation (eg in any of the documentation around keyless ephemeral
> anchors), so I'll publish one here. Maybe I'm the first to point this out
> explicitly? Probably not; I'd appreciate an earlier citation if one exists.
>
>
> tl;dr: _Anyone_ can do a replacement cycling attack on transactions where
> fees
> are paid via CPFP via keyless anchors and similar outputs that a
> third-party
> can double-spend. Secondly, for attackers who were already planning on
> making a
> transaction with a higher total fee and total fee-rate than the target,
> this
> attack is almost free.
>
>
> # The Attack
>
> Suppose that Alice has created a 2 transaction package consisting of
> low-fee or
> zero-fee transaction A, whose fees are CPFP paid via a keyless ephemeral
> anchor
> spent by transaction B. For B to pay fees, obviously it must spend a second
> transaction output.
>
> Mallory can cycle A and B out of mempools by broadcasting transaction B2,
> spending his own output and the keyless ephemeral anchor of A, at a higher
> fee/fee-rate than B. Next, Mallory broadcasts B3, double-spending B2 by
> spending Mallory's input but not the ephemeral anchor of A. Assuming
> Mallory
> needed to mine B3 anyway, the only cost to this attack is the small chance
> that
> B2 will in fact be mined between the time that B2 is replaced by B3.
>
> At this point A is no longer economical to mine as B has been cycled out,
> and A
> may be dropped from mempools depending on the circumstances.
>
>
> ## SIGHASH_ANYONECANPAY
>
> Obviously, a similar attack is possible against SIGHASH_ANYONECANPAY-using
> transactions, provided that _all_ signatures sign with
> SIGHASH_ANYONECANPAY.
>
>
> # Countermeasures
>
> As with other replacement cycling attacks, rebroadcasting A and B fixes the
> issue. I think the existence of this additional type of replacement cycling
> attack suggests that adding an optional rebroadcasting module to Bitcoin
> Core
> that would keep track of dropped transactions and re-add them to mempools
> when
> they are again valid would make sense. This fixes all replacement cycling
> attacks and there's probably lots of nodes who have the memory and/or disk
> space to keep track of dropped transactions like this.
>
> Preventing the replacement of B2 with B3 is _not_ a viable countermeasure:
> if
> that replacement was prohibited, attackers could in turn exploit that rule
> as a
> new form of transaction pinning!
>
>
> # Privacy
>
> The fact that rebroadcasting is a countermeasure is a privacy concern. Each
> time a transaction is rebroadcast by the sender is a potential opportunity
> to
> track the origin of a transaction. Again, having third parties
> rebroadcasting
> transactions altruistically would mitigate this privacy concern.
>
> --
> 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/ZqyQtNEOZVgTRw2N%40petertodd.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/CALeFGL1dLhdvdePzt5xdZxskcU6WJDJL_PSmO2u2Z1nKZCKMag%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 5877 bytes --]