Published on: 2021-07-12T00:02:12+00:00
In a recent Bitcoin-dev mailing list discussion, there was a proposal to introduce a new SIGHASH_GROUP flag to improve transaction processing efficiency and avoid O(n^2) behavior. The proposal suggests grouping transactions together using the annex field "sig_group_count" and hashing only the relevant outputs when evaluating an input. This optimization aims to reduce overhead and improve transaction signing. The proposal provides an example of combining transactions in the Lightning network to illustrate how the SIGHASH_GROUP flag would work. However, it notes that there may be limitations when certain outputs collide on the absolute output position.Another topic discussed in the email thread is the possibility of introducing more advanced sighash malleability flags, such as SIGHASH_IOMAP, which would allow transaction signers to commit to a map of inputs and outputs. However, concerns were raised about theft possibilities, heaviness of range specification, and quadratic behavior.The discussion also explores a single-party managed fee-bumping system that could solve fee-bumping requirements in the Lightning network without external utxos or additional interaction between parties. This system would allow for fee adjustment by reducing the balance of a transaction or draining an output with HTLC or PTLC. The proposal suggests that this idea could be applied to all Bitcoin transactions, enabling efficient fee adjustments in various scenarios. The benefits and drawbacks of a sponsor-like mechanism for fee-bumping are also discussed.The conversation touches on fee-bumping techniques for second-layer protocols and proposes solutions such as the SIGHASH_ANYPREVOUT softfork proposal or tx mutation schemes. These approaches aim to address security issues and optimize fee-bumping in contract protocols with distrusting counterparties.Overall, the discussions revolve around proposals and ideas to improve transaction processing efficiency, optimize fee-bumping mechanisms, and address security concerns in various Bitcoin-related contexts, including Lightning network transactions and second-layer protocols.Another aspect discussed is input-based fee-bumping as a primitive for Layer 2 solutions. The use of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability flags is one variant of input-based fee-bumping, but ACP | SINGLE is easily pinable, so ACP | ALL is used for Revault. This requires a pool of fee-bumping UTXOs to be consumed entirely. The author suggests broadcasting a single fan-out transaction creating the entire UTXO pool in advance to overcome this limitation. However, sometimes the cost of many small additional inputs must be incurred. The discussion also explores the possibility of attaching the bumping input at the tail of the chain rather than targeting the root and suggests using smarter tx-relay techniques such as "attach-on-contract-utxo-root" CPFP or blinded CPFP.The post compares input-based fee-bumping and CPFP techniques for second-layer protocols in terms of onchain footprint, tx-relay bandwidth rebroadcast, batching opportunity, and mempool flexibility. CPFP requires one anchor output per participant, while input-based fee-bumping only requires one input if the bumping utxo offers an adequate feerate point. If a preliminary fan-out transaction must be broadcasted first, one input and two outputs more must be accounted for. CPFP's efficiency in tx-relay bandwidth rebroadcast relies on the assumption of bounded rationality of the participants, while input-based fee-bumping (today) breaks the chain validity and requires updating and rebroadcasting the remaining transactions beyond the updated root. However, input-based fee-bumping with SIGHASH_ANYPREVOUT+SIGHASH_IOMAP doesn't break the chain validity and could preserve the rest of the chain. For fee-bumping batching, CPFP requires one input/one output per aggregated chain, even if the child transaction fields can be shared. Input-based fee-bumping (today) requires one bumping input per chain, but transaction fields can be shared if a preliminary fan-out transaction is used. Input-based fee-bumping with SIGHASH_ANYPREVOUT+SIGHASH_IOMAP can attach one bumping input and outgoing output to the aggregated root. Regarding fee-bumping mempool flexibility, CPFP has limitations and doesn't scale beyond two contract participants, while input-based fee-bumping's acceptance is not restrained by package limits.The post concludes by mentioning future soft forks that allow significant onchain footprint savings, especially in batching, and future package relay bandwidth efficiency that should consider the rebroadcast frequency of CPFPing multi-party protocols.Overall, the conversation delves into various fee-bumping techniques, their advantages, limitations, and potential future improvements. It provides insights into the complexities and trade-offs involved in securing transactions in multi-party protocols.
Updated on: 2023-08-02T03:56:08.130121+00:00