bitcoin-dev

OP_Expire mempool behavior

OP_Expire mempool behavior

Original Postby Peter Todd

Posted on: March 19, 2024 15:04 UTC

In a detailed discussion concerning Bitcoin development, Antoine Riard addresses several technical nuances related to Bitcoin Improvement Proposals (BIP), specifically focusing on the mechanisms of transaction replacement and the potential for denial-of-service (DoS) attacks within these frameworks.

Riard explains that under BIP125 rules, a Hash Time-Locked Contract (HTLC)-timeout transaction replacing an HTLC-preimage transaction in a mempool would incur a higher fee, effectively compensating for the bandwidth used. This scenario aligns with the replace-by-fee-rate (RBFR) strategy, where transactions offer higher fees to prioritize their confirmation over others. The crux of Riard's argument is that these mechanisms ensure that something always confirms, thus maintaining network integrity.

Riard further elaborates on the OP_Expire case, highlighting a scenario where transactions become invalid after a certain timeframe. If such transactions are not mined with a reasonably high probability (for example, greater than 10%), it opens up a vulnerability for attackers to consume network bandwidth indefinitely at minimal cost. However, Riard reassures that current RBF and RBFR rules are sufficient to prevent DoS attacks by ensuring that attackers must still pay fees for the transactions they cycle through, thereby not unduly burdening the network.

The discussion also touches upon concerns raised in a GitHub issue, where unusual behavior from certain nodes was noted. Speculation around these observations suggests possible explanations such as non-standard mempool size limits set by pre-made node distributions or the presence of fake spy nodes exhibiting abnormal activity.

Lastly, Riard identifies a potential flaw in version 3 (V3) transactions, where a child transaction can be replaced without adequately compensating for the bandwidth of the evicted parent transaction. He suggests that this issue constitutes a straightforward design bug in V3 transactions that needs to be addressed. Once rectified, the system would require attackers to "fairly" compensate for their network usage through appropriate fees for each cycle of replaced transactions, thereby reinforcing the principle that users must pay for the resources they consume on the network.