* [bitcoindev] Keyless Anchors Are Vulnerable To Replacement Cycling Attacks
@ 2024-08-02 7:54 Peter Todd
2024-08-02 21:58 ` Keagan McClelland
0 siblings, 1 reply; 3+ messages in thread
From: Peter Todd @ 2024-08-02 7:54 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 3135 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoindev] Keyless Anchors Are Vulnerable To Replacement Cycling Attacks
2024-08-02 7:54 [bitcoindev] Keyless Anchors Are Vulnerable To Replacement Cycling Attacks Peter Todd
@ 2024-08-02 21:58 ` Keagan McClelland
2024-08-27 19:39 ` Antoine Riard
0 siblings, 1 reply; 3+ messages in thread
From: Keagan McClelland @ 2024-08-02 21:58 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoindev] Keyless Anchors Are Vulnerable To Replacement Cycling Attacks
2024-08-02 21:58 ` Keagan McClelland
@ 2024-08-27 19:39 ` Antoine Riard
0 siblings, 0 replies; 3+ messages in thread
From: Antoine Riard @ 2024-08-27 19:39 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 10843 bytes --]
Hello,
> 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.
Same, I cannot remember about an earlier citation in doucmentation around
keyless
ephemeral anchors, and while this is a concern I was aware of I was
expecting
that some reviewer of ephemeral anchors would figure it out earlier (or at
least
praying for that...).
> 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.
Yes, about the second observation, see the section 5.2 about high-fee
collaboration
transactions advantage in the write-up which was initially released at the
disclosure of replacement cycling attacks [0].
[0]
https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf
In my belief, the simple fact that any bitcoin economical actor originating
transaction traffic at regular interval (e.g LSP or exchange batching) can
leverage that position to engage in replacement cycling attacks is a real
worry.
> # 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.
Yes, in my understanding this scenario works. I think can even maliciously
batch
B3 to replace a N number of keyless spending B2 transactions at the same
time.
> ## SIGHASH_ANYONECANPAY
>
> Obviously, a similar attack is possible against SIGHASH_ANYONECANPAY-using
> transactions, provided that _all_ signatures sign with
SIGHASH_ANYONECANPAY.
Yes, a single SIGHASH_ALL locks-in the spent input, and as such avoid a
third-party
to adds a higher-fee / feerate input, then to be ulteriorly conflited with.
There
might be some data carriage style transactions using this pattern...
> # 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!
I still think altruistic rebroadcasting is a very limited mitigation as
even beefy
nodes have computationally-limited memory and/or disk spaces. They would
need to have
some ordering of the dropped transactions e.g caches by tiers of feerate
group and
a replacement cycling attacker would just have to spam the top cache.
I believe it was already discussed there and in the previous email (I might
be
missing something ?) [1].
[1] https://groups.google.com/g/bitcoindev/c/qEx4K8lGnLk/m/AMPqDi6MBwAJ
> # 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.
Yes...On the other hand third parties rebroadcasting transactions are now
exposing themselves to be injected DoS traffic. Having full-nodes offering a
threshold of their memory / CPU cyles to process anonymizing traffic is
great,
especially for the marginal lighnting user. When it's a lightning hub with
a lot of channel funds, I believe it's naive to expect those additional
memory /
CPU cyles cannot be spammed for exploitation purposes.
> 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.
I did, and effectively you're running into hierarchy of caches management
styles of issues [2]
[2] https://github.com/bitcoin/bitcoin/issues/28699
Best,
Antoine
ots hash: eba1b16753146707a07dcd1aee1ca066fcb323e18222be7282088c49d9f44266
Le vendredi 2 août 2024 à 23:00:16 UTC+1, Keagan McClelland a écrit :
> > 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 <pe...@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+...@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/57c52a0c-c390-4b7b-8247-8612a489cb98n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 13296 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-08-27 19:41 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-08-02 7:54 [bitcoindev] Keyless Anchors Are Vulnerable To Replacement Cycling Attacks Peter Todd
2024-08-02 21:58 ` Keagan McClelland
2024-08-27 19:39 ` Antoine Riard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox