A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

Summary:

The Bitcoin Improvement Proposal (BIP) by Jeremy Rubin proposes a mechanism for arbitrary unconnected third parties to attach fees to an arbitrary transaction. The proposal allows for inter-transaction dependencies and is restricted to ensure a subset of behavior sufficient to replace Child Pays for Parent (CPFP) and Replace-by-Fee (RBF) for fee bumping.The policy specification involves defining a sponsor vector with specific rules, including not having any child spends or unconfirmed parents, having exactly one entry present in the mempool, and allowing one sponsor to replace another subject to normal replacement policies. The proposal aims to provide a minimal mechanism that tightly bounds how much extra work the mempool might have to do to account for new sponsors in the worst-case scenario, while providing an "it always works" API for end-users that is not subject to traditional issues around pinning.The lack of global mempool means you can creatively combine mempools limits or mempools absolute-fee/feerate/conflicts logic to provoke mempools-partitions. However, this proposal aims to solve class a) of pinnings by allowing fee-bumping with a new definition of dependencies. It won't solve class b) of pinnings for multi-party time-sensitive protocols without further modifications.Antoine Riard mentions that the proposal won't solve class b) of pinnings for multi-party time-sensitive protocols without further modifications. He suggests that a per-input future Taproot annex might be used, and even apply a witness discount as this mechanism could be argued to be less blockspace expensive than a CPFP for the same semantic. An alternative could be a new transaction field like a new `stxid`.The final output of a transaction is an unambiguous location to attach metadata to a transaction, such that the data must be committed to as part of the signature hash. The proposal would reduce costs compared to N-Parent-1-CPFP as the CPFP must include an input for each bumped parent, here we only have the Sponsor output. In terms of attack analysis, the worst-case scenario could lead to a 1/2 reduction in the number of children allowed and a 2x increase in maximum children, but even in the latter attack scenario, the denial-of-service surface is not significant because sponsor transactions have no children nor parents.Future policy work might insert sponsors into a special sponsor pool with an eviction policy that would enable sponsors to be queried and tracked for transactions that have too low fee to enter the mempool in the first place. A reference implementation demonstrating these rules is available, but it has not been carefully audited for correctness and likely diverges from this document in ways that should either be reflected in this document or amended in the code.Overall, the proposed mechanism provides a general specification for inter-transaction dependencies that restricts the mempool policy to replace CPFP and RBF for fee bumping while ensuring a minimal mechanism that allows arbitrary unconnected third parties to attach fees to an arbitrary transaction.

Updated on: 2023-06-14T15:25:28.478683+00:00