Published on: 2022-08-11T16:56:29+00:00
The Bitcoin community is currently exploring a way for the initial signer to delegate to another scriptPubKey in order to improve privacy and compatibility with CoinJoin/Lightning. One suggestion that has been proposed is to use MAST (two Merkle branches) to achieve this. The first branch would contain the original signer's scriptPubKey, while the second branch would contain the delegated signer's scriptPubKey. It appears that all parties involved can make signatures on both the delegating and delegated keys. However, more documentation is needed to fully understand the motivation behind this requirement.In relation to OP_CHECKDATASIG, it has been discovered that this opcode already exists in Bitcoin Cash. However, proponents of BIP322 do not prioritize BCH script compatibility. In order to create an opcode called OP_CHECKDATASIG for the internal purposes of BIP322, a lengthy soft-fork would be required to modify the consensus rules. This raises the question of how Script should verify a single signature on the stack without affecting any inputs or outputs. Several suggestions have been made, including performing key recovery for legacy ECDSA and using specific output scripts to require valid signatures and public keys. Additionally, backward compatibility with Bitcoin Message and the use of opcodes like OP_RESERVED have been discussed, although introducing new opcodes may add unnecessary complexity to the Script.To address these issues, it has been proposed to introduce a hypothetical OP_CHECKDATASIG opcode that can perform ECDSA public key recovery for legacy P2PKH signing. This could be done safely within the BIP. However, in order to ensure compatibility with existing schemes, the opcode would need to be assigned a specific byte, such as OP_CHECKDATASIG. Backward compatibility is crucial, and one possible approach is to use OP_RESERVED to maintain compatibility with "Bitcoin Message". The draft of BIP322 also includes TODO items such as Silent Transactions, limiting eligible opcodes in scriptPubKeys for signing, and delegation to another scriptPubKey. Suggestions have been made, such as placing a NOP at the beginning of the script to activate proof parsing mode and using MAST for delegation.During the discussion on the bitcoin-dev mailing list, user Ali Sherief brought up several TODO items from an older version of the BIP322 draft. These items included addressing the interaction with Silent Transactions, considering whether to introduce an invalid opcode for specific proof types, and finding a solution for delegating to another scriptPubKey. Suggestions were made to limit which opcodes scriptPubKeys can use for signing by placing a NOP at the beginning of the script to activate proof parsing mode. Additionally, a subsection for Silent Transactions could be created to operate using its scriptPubKey. It was also proposed to use MAST with two Merkle branches to specify the original signer's scriptPubKey and delegated signer's scriptPubKey for delegation.BIP322 is still a work in progress, with several TODO items that need to be addressed. The Github issue/PR at https://github.com/bitcoin/bips/pull/1347 has been created to address these items. Ali shared the TODO items from an older version of the draft and suggested limiting the opcodes that scriptPubKeys can sign from, potentially by using a NOP at the beginning of the script. However, it is important to note that an opcode may not be necessary if the program can infer the source of the proof from context. For silent transactions, a suggestion has been made to create a subsection that operates using its scriptPubKey. As for the delegation to another scriptPubKey, the proposal suggests using MAST with two Merkle branches to contain both scriptPubKeys.Overall, the Bitcoin community is actively discussing various solutions to ensure backward compatibility in Bitcoin Scripting language. The lack of certain opcodes, such as OP_CHECKDATASIG, and the need for delegation to another scriptPubKey are being addressed through proposals like MAST and limited opcode usage. However, more documentation and clarification are required to fully understand the motivations behind these requirements and how they will be implemented.
Updated on: 2023-08-02T07:16:13.437912+00:00