Posted on: February 28, 2024 22:34 UTC

The discussion revolves around a proposal for a new SIGHASH_DOUBLE flag to enhance the functionality of signing Bitcoin transactions.

This proposed flag aims to allow the signing of transactions for two outputs, facilitating the creation of Partially Signed Bitcoin Transactions (PSBTs) that can be combined non-interactively. The concept is similar to the existing SIGHASH_SINGLE, but it includes both a payout and a change output. The verification process for transactions containing this flag would involve scanning all signature flags to identify the presence of SIGHASH_DOUBLE and then counting two indices in the output index—one starting at 0 and another starting at the vin_count + 1. This method would pair each SIGHASH_DOUBLE input with its adjacent output as well as with an output indexed at vin_count + 1, thus achieving consensus on the designated outputs.

Further elaboration on organizing transactions suggests that inputs and outputs should be arranged based on their sighash flag. This organization would prioritize pairs of SIGHASH_DOUBLE inputs and outputs, followed by SIGHASH_SINGLE pairs and the remaining inputs and outputs, to avoid transaction rejection from the mempool due to improper arrangement. However, there are limitations to this approach, especially concerning transactions that contribute inputs without outputs or that consolidate inputs, potentially affecting compatibility with SIGHASH_DOUBLE.

The possibility of soft-forking this feature into Bitcoin was also discussed, suggesting the extension of the SIGHASH_NONE flag for backward compatibility with older nodes. The introduction of Taproot provides several methods for extending signature validation, which could be explored for implementing SIGHASH_DOUBLE. Additionally, the combination of SIGHASH_DOUBLE with ANYONECANPAY is highlighted as an interesting use case, allowing for a mempool of single-spend PSBTs. This could reduce transaction overhead and facilitate miner consolidation of transactions into blocks, presenting a novel approach to optimizing Bitcoin's transaction efficiency. The proposal is open to feedback, acknowledging that further thought and community input are essential for refining the concept.