Delivery-date: Fri, 02 Aug 2024 05:31:05 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.158 as permitted sender) client-ip=103.168.172.158;
Feedback-ID: i525146e8:Fastmail
Date: Fri, 2 Aug 2024 07:54:28 +0000
From: Peter Todd <pete@petertodd.org>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] Keyless Anchors Are Vulnerable To Replacement Cycling Attacks
Message-ID: <ZqyQtNEOZVgTRw2N@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="vRkTbBrP6olNI+nv"
Content-Disposition: inline
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--vRkTbBrP6olNI+nv
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

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.

--vRkTbBrP6olNI+nv
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmaskLMACgkQLly11TVR
LzfreA//WnWPNqDyHOnqdilxmWyXLLpuzh8qoYOSkuBoZYODk9U8rcuQUqg3mpct
GWyYvwH8+jAAH47of6nTa3CLrRi5RG1jI0icCihWxfElC3+7U+WnUOk7pN2cDwGX
W4pdeyf8FCjJVJgDFPOhWymmeUYtjEXDw+FFYcjNjKBBpwcW+/SHXClqrWIhFaD7
RRMbFJ/F7K3tAT6OIfooeoLxMAwGmj/P01qg6OR/X1SDrbZqv5AhVRyK4ZX4u2nn
UiYX3WeugedJXOR2RWdRBKVnHnMBNdkPS9JJYCIocDvdRW2gCznZkTmQNd4Rn5d8
Mpj8i2vcw+qyBdoMl3bxpj7vIn3JjuQPhpANFLM4aYhZLLnS4ugiXSxujlmXZO9S
7ft8E3ZDInwhmmma3CMK60GmbYfoPTe44siPA0Gqlxm/QBWTXEII2Ig8ipgN3f9j
ocw2vwTNnySwb7eHQCuwwsaTuJXSjaA5MzT+E+cRlwgoUSCdak+qSCFtrBRsubjO
ACbz+jRL36I28TwgQ7RwUl6Yz7uH7nkoPzDtikoHFTcC7DEV7RXiK2zlaCbFwFSd
DfhDhdlEX8i8Jzgl+eJ0s8wQ2ods/Oh1cbnT17P0+xhppK10NsBdUe4Xk25DINV0
mDCYCgatFdep7+UeTkEolB9MYfqYU2Rt+ZF1TPJEZN5zmJq7A1I=
=LR7g
-----END PGP SIGNATURE-----

--vRkTbBrP6olNI+nv--