Author: Antoine Riard 2022-01-30 22:53:32
Published on: 2022-01-30T22:53:32+00:00
The current Bitcoin Core RBF policy has three main goals: allowing opting out, incentive compatibility, and DoS protection. However, pinning attacks have become a pressing concern as SIGHASH_ANYONECANPAY pinning can be bypassed by creating intermediary transactions to be replaced together. The restriction of requiring replacement transactions to increase the absolute fee of the mempool has been criticized. In Package RBF, applying the same rules is problematic, especially with the absolute fee pinning attack. To solve LN pinning attacks, fair feerate bidding between counterparties must be enabled.If the replace-by-feerate rule is adopted, there shouldn't be an incentive for Bob to pick up the first option. The deployment of Taproot opens interesting possibilities in the vaults/payment channels design space, where the tapscripts can commit to different set of timelocks/quorum of keys. Improving Core's rate-limiting transaction strategy is a whole discussion in itself. One solution could be to associate per-user "tag" to the LN transactions, where each "tag" would have its own replacement slots, but privacy must be considered. There are concerns about a too-much complex interface easing the way for an attacker to trigger an L2 node to issue policy-invalid chain of transactions. Rate-limiting how many replacements we allow per prevout introduces a new pinning vector in the context of shared-utxo. In a recent post on the Bitcoin-dev mailing list, developer Jeremy Rubin proposed some improvements to the Replace-by-Fee (RBF) feature in bitcoin transactions. Rubin suggests several changes, including removing rules requiring higher absolute fees and allowing new unconfirmed inputs while preventing a so-called "anyone-can-pay" pinning attack. He also proposes creating a more user-friendly interface for fee bumping transactions. Additionally, Rubin discusses various models for calculating transaction validation rate-limiting and improving the mining score of mempool transactions. Finally, he presents some improvement proposals for RBF, including a fee-rate-only rule and limiting the number of replacements per prevout.The author of this document proposes a new rule for replacing transactions in Bitcoin's mempool, called the "feerate-based" rule. This approach aims to address issues associated with the current replacement policy while also preventing potential attacks. The feerate-based rule involves calculating conflicting transactions and their descendants, finding original transactions that would be included in the next block, and ensuring that replacements pay at least this amount plus a certain percentage in absolute fees. Additionally, replacements must have a higher feerate than the maximum mining score of remaining transactions in the mempool after the next block.The proposal suggests using TBD constants to limit the number of replacements allowed with some set of fees. The document discusses various options for implementing the feerate-based replacement rule, including calculating block templates on the fly, caching a block template, or dividing the mempool into "high feerate" and "low feerate" layers. The author acknowledges contributions from various individuals in developing this proposal. Links to relevant pull requests, issues, and discussions are provided throughout the document for further context. Overall, more discussion is needed to improve RBF policy.
Updated on: 2023-06-15T16:00:22.804211+00:00