bitcoin-dev

A Free-Relay Attack Exploiting RBF Rule #6

A Free-Relay Attack Exploiting RBF Rule #6

Original Postby Antoine Riard

Posted on: March 28, 2024 19:13 UTC

The discussion delves into the intricacies of transaction-relay bandwidth DoS (Denial of Service) risks within the Bitcoin network, acknowledging that these concerns have been recognized by senior developers for some time.

Specific attention is given to the dust_limit_satoshis setting in Bitcoin's Lightning Network, which, once set during the initial negotiation phase, remains unchangeable. This setting plays a critical role in the construction of commitment transactions as outlined in BOLT3, where dust HTLCs (Hashed Time-Locked Contracts) are trimmed and their value is added to the transaction's absolute fee. This mechanism allows for the generation of a series of commitment transactions with progressively increasing fee rates, demonstrating how the size and number of trimmed HTLCs affect the overall transaction fee.

Further exploration is given to the scalability and efficiency of Bitcoin's transaction relay process, especially concerning the evolving dynamics of network mempools. The narrative highlights a growing disparity between Bitcoin clients based on their time-value preferences, noting that those with higher time-value preferences are essentially outbidding those with lower ones for space in network mempools. This leads to a discussion on the sustainability of a common-sized mempool, particularly for hobbyist full-nodes, in an environment where transaction issuers increasingly determine rebroadcasting and pricing strategies.

The dialogue also touches upon the concept of proof-of-UTXO as an economic measure against Sybil attacks in the context of transaction relay. Although imperfect, it is suggested that the same proof-of-UTXO can be reused across different subsets of transaction-relay peers, leveraging the network topology and peer relationships as amplification factors for mitigating such attacks. The balance between the effectiveness of these measures and the value of the transaction-relay traffic they protect is considered.

Lastly, the discussion acknowledges the complexity of liquidity management within the Lightning Network's channel dynamics. It hints at the existence of asymmetries in current implementations that could potentially be exploited as vectors for "free-relay" bandwidth attacks at the network level. This point underscores the ongoing challenges in designing systems that effectively balance security, efficiency, and fairness in decentralized networks.