Published on: 2022-02-18T09:01:07+00:00
The discussion on the bitcoin-dev mailing list revolves around the validity of transactions in Bitcoin and the use of transaction sponsors as a fee-bumping primitive. Currently, there is a consensus threshold for transactions to become invalid after a 100 block reorg. However, concerns have been raised about the risks involved for those not waiting for standard finalization.One concern is the difficulty of knowing if a target transaction has been dropped from the majority of network nodes since the last broadcast. However, it is possible to specify a sponsorship transaction that points to a specific transaction ID without rebroadcasting the original transaction data. Pre-committing to a fee-bumping key in CPFP outputs could also become problematic if the key is compromised later on.Transaction sponsors and fee-bumping primitives have benefits for fee management in certain use cases, but there are potential risks to consider, such as data availability and redundancy issues. Further analysis is necessary before deploying new fee-bumping primitives.The use of transaction sponsors in fee bumping has limitations, including transaction topology fluctuations and pre-specifying fee-bumping keys in CPFP outputs. Broadcasting sponsor and target transactions together is suggested as a measure of caution. While transaction sponsors have advantages like targeted replacement policy and ease of migration, they are not a solution to L2-related mempool issues due to replace-by-fee bottleneck and dust limit issues. The proposal of SIGHASH_{NONE,SINGLE}|ANYONECANPAY for the fee-management use case is made.There is a disagreement about the impact of decreasing the miner's reward on fee-bumping. Some argue that increasing feerate may not always be economically rational, as miners with a limited number of transactions may prioritize maximizing absolute fees over feerate. However, this argument may not align with the current reality where a large backlog of transactions is not necessary. The complexity of prioritizing transactions in the mempool is discussed, considering both fee rates and transaction sizes.A simplified approach to fee-bumping is needed to minimize network costs and blockspace waste. Special consideration is given to design principles that ensure feerate bumps are not impossible and minimize bandwidth and chain space consumption. Broadcasting the "diff" instead of rebroadcasting the original transaction is suggested as a more efficient approach. Transaction sponsors are proposed as a way to simplify fee management, although concerns about pinning attacks and wasted block space are raised.The complexity of fee-bumping and dynamic fee management in Bitcoin has sparked significant discussion. Design principles that prioritize the end-user experience while ensuring incentive compatibility are introduced. Additive feerate bumps should always be possible without extensive bandwidth or chain space. Special transaction structures should not be necessary, and feerate increases should be feasible from any source. The transaction sponsors design is supported as a means to achieve these goals, allowing for feerate bumps after a transaction has been broadcasted.Critics have raised objections, citing potential pinning-like attacks and compromise of the classic invariant. However, ways to address these concerns are suggested. Implementing this approach would require a soft-fork, but it is considered worth considering to streamline the fee management process.Given the increasing importance of fees within the Bitcoin system, the current complexity of fee management is deemed unsustainable. Exploring alternative approaches that enhance user experience and simplify fee management is crucial. While further considerations and discussions are needed, an approach that allows for fee-bumping after transaction broadcast is advocated for its flexibility and promised benefits.
Updated on: 2023-08-02T05:35:26.714069+00:00