Published on: 2018-04-04T23:11:52+00:00
In the bitcoin-dev mailing list, a discussion took place regarding the potential problems of combining transactions with varying fee amounts. The issue arises when one bundle overpays and another underpays, as they can only be safely combined if a SIGHASH_ALL signature is included in the overpaying bundle. Otherwise, miners could create their own transaction using only the overpaying bundle. One solution suggested was to commit to a set of keys that are allowed to bundle, but this would limit the generality of outsourcing.Another problem discussed was the difficulty of guessing future fees for commitment transactions in lightning. Pre-signing HTLC-Success/HTLC-Timeout transactions by channel partners is necessary to ensure the correct output address. However, if the commitment transaction gets bundled, its txid will change, making pre-signing impossible without SIGHASH_NOINPUT. To solve this, a proposal was made to add a zero-value anyone-can-spend output to commitment transactions that can be used with CPFP (Child Pays For Parent) to bump the fees. However, this would lead to UTXO bloat and may not pass the dust threshold.A potential solution suggested was to have after-the-fact fee-bumping via special sighash flags at the block level. This involves providing a third transaction whose witness includes the txids and a signature committing to them. This transaction can only be included in a block if the referenced transactions (X and Y) are also in the same block. However, it raises the question of what the new transaction would spend since an existing output cannot be used. It was suggested that an unspendable zero-amount output script, such as 'OP_NOP4', could be used instead.Anthony Towns raised concerns about combining bundles with different fees and proposed using a SIGHASH_ALL sig in the overpaying bundle to prevent miners from creating their own transactions. He also suggested replacing SINGLE|ANYONECANPAY with additional witness bytes. In response, the discussion revolved around guessing future fees for commitment transactions and using parent-pays-for-child. However, due to timelocked outputs, this approach cannot work with HTLC-Success/HTLC-Timeout transactions as they spend outputs from the commitment transaction and need to be pre-signed. The proposed solutions included adding a zero-value anyone-can-spend output to commitment transactions for CPFP or after-the-fact fee-bumping via special sighash flags at the block level.The bitcoin-dev community proposed a new way to bundle transactions in order to address the issue of guessing future fees for commitment transactions. This proposal involves indicating that a signature only applies to part of a transaction, or a "bundle". Bundles can be combined into larger transactions and non-bundled signature inputs/outputs can be appended. The proposed bundling method includes SIGHASH_BUNDLESTART and SIGHASH_INBUNDLE flags, which indicate the number of inputs and outputs in a bundle and that a signature applies to the current bundle. Additionally, two per-tx counters track the number of inputs and outputs used in each bundle. This bundling method could replace SINGLE|ANYONECANPAY but requires an extra couple of witness bytes. BIP-69 style ordering rules can also be established within a bundle. While the bundling does not offer privacy benefits, it allows for dealing with discrepancies in fees.A suggested solution for pre-signing HTLC-Success/HTLC-Timeout transactions, which require the correct output address, is to add a zero-value anyone-can-spend output to commitment transactions. Another idea is after-the-fact fee-bumping via special sighash flags at the block level. However, implementing this is not straightforward. Rusty proposed a more flexible alternative to SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, including SIGHASH_BUNDLESTART and SIGHASH_INBUNDLE bits. This proposed signature indicates that it only signs part of a transaction's inputs and outputs, allowing for the combination of multiple bundles into larger transactions. Two counters track the inputs and outputs used in each bundle. This approach could be useful for guessing future fees and allows public aggregators to provide throughput promises and add additional fees. Feedback on this proposal is welcome.
Updated on: 2023-08-01T22:51:54.298404+00:00