V3 transaction policy for anti-pinning

V3 transaction policy for anti-pinning

Original Postby instagibbs

Posted on: January 8, 2024 16:26 UTC

The recent discussion in the programming community has highlighted a critical issue known as the "cycle attack" within the context of Bitcoin transactions.

This complex technical problem occurs when a child transaction is replaced by fee-bidding (RBF), and consequently, the new child no longer references the original ephemeral anchor. This results in both the parent transaction and the originally referenced fee bump being expelled from the mempool. The suggested mitigation strategy involves persistent re-broadcasting of the transaction. The rationale behind this approach is that each attempt to execute the cycle attack incurs a cost on the attacker in terms of fees, thus making it an expensive endeavor to maintain the attack over time.

Furthermore, this situation can be perceived from a strategic standpoint where an entity is attempting to censor a particular transaction. Such an entity would need to continuously outbid others to prevent the transaction from being included in a block — needing to do so for every block and even between blocks if the defense is executed correctly under the assumption of mempool synchrony. In contrast, the victim of this censorship only needs to pay once, either at the conclusion of the "game" or at their anticipated rate. Despite the importance of this issue, there is an expressed desire to avoid delving too deeply into the cycle attack debate as it has been extensively discussed within the development community. For more detailed technical insights, interested parties can reference the discussions on the Linux Foundation mailing list: