bitcoin-dev

Combined summary - Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation

Combined summary - Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation

The discourse on Bitcoin Improvement Proposal (BIP) 157 and its effectiveness highlights that the protocol operates well based on practical experiences.

Rebroadcasting transactions is considered an additional security layer where even a single node's participation suffices for functionality. Consistency in mempool minimum fees across nodes has been observed, with deviations within 1%, despite differences in their mempool sizes. This reflects a steady supply/demand curve for transaction fees.

Replacement attacks, where attackers use the same unspent transaction outputs (UTXOs) to displace multiple victim transactions, are addressed by BIP125 rules. These rules require incremental fees for each transaction replacement, thus financially burdening the attacker. The effectiveness of such attacks is further diminished when targeting multiple victims simultaneously, as it reduces the attack's impact due to the distribution of information across nodes. For instance, if an attacker targets two different victim transactions, the likelihood of both being cycled out by half of the altruistic rebroadcasting nodes is low, rendering the attack ineffective.

Concerns have been raised about the security model for time-sensitive second-layer networks, particularly regarding the determination of global mempool minimum fees and adversaries exploiting this system. The conversation also discussed the potential for adversaries to broadcast the same UTXO amount under various transaction IDs, consuming all altruistic bandwidth. Although rate-limitation per UTXO was considered, it brings the risk of impacting legitimate transactions. A long-term solution involves fixing replacement cycling through techniques such as eliminating package malleability and adopting self-contained fee-bumping reserve UTXOs, as detailed in a Linux Foundation mailing list post.

The discussion around local replacement caches suggests that such mechanisms might not be necessary since altruistic entities could provide caching services, managing transaction broadcasts based on minimum fee thresholds. BIP-133 feefilter is highlighted as a tool enabling nodes to set fee rate thresholds to avoid receiving low-fee transactions. Even with significant financial resources, an attacker's impact may be limited due to P2P bandwidth constraints and the cost-effectiveness of storing a replacement database in RAM.

A proposal from a GitHub issue suggests implementing a local replacement cache to maintain transactions meeting current fee requirements, highlighting concerns for full-nodes with limited storage facing moderate liquidity attacks. Periodic altruistic rebroadcasting could become vulnerable to sybil attacks or malicious squatting. Furthermore, discrepancies in rebroadcast traffic and minimum fee rates could result in bandwidth wastage. In cases involving medium- to high-liquidity attackers, existing mitigation efforts might fall short, leading to concurrent spending issues and compromising the integrity of multi-party time-sensitive protocols.

Finally, to counter replacement cycling attacks, a method for third parties to monitor and rebroadcast original transactions replaced in the attack cycle is suggested. While this approach requires development work and coordination among interested parties, it remains feasible and potentially cost-effective. Miners could be incentivized to participate in rebroadcasting to capture profitable transactions. However, limitations exist in Bitcoin Core's transaction propagation which can be improved by the Transaction Announcements Reconciliation BIP, enhancing synchronization of mempools across the network.

For further exploration of these topics, readers are directed to Peter Todd's domain and the provided references, including the BIP-133 feefilter mechanism on GitHub and the GitHub issue discussing local replacement caches.

Discussion History

0
Peter ToddOriginal Post
December 9, 2023 10:08 UTC
1
December 15, 2023 22:29 UTC
2
December 17, 2023 10:57 UTC
3
December 21, 2023 21:59 UTC
4
December 22, 2023 14:01 UTC