Published on: 2019-02-09T00:39:54+00:00
In recent discussions among Bitcoin developers, several proposals and considerations were raised regarding the Bitcoin protocol. Pieter Wuille raised concerns about the reuse of OP_MASK and SIGHASH_NOINPUT, with the latter posing a greater risk. Realistic risks associated with NOINPUT were discussed, and output tagging was suggested as an alternative. A proposed script involving CODESEPARATOR was presented, which could eliminate the need for certain cases under taproot. The use of CODESEPARATOR for Scriptless Script without Schnorr was also mentioned.There were debates on the usefulness of OP_CODESEPARATOR under Taproot. Some argued that committing to the masked script is not necessary if best practices are followed, while others believed that using IF+CODESEP approach could be cheaper for certain scripts. The usability and security of OP_CODESEPARATOR with NOINPUT were questioned, but its usefulness in some cases was acknowledged.The discussions also touched upon witness weight malleability in Bitcoin Script and the proposal to use a 64-byte signature for the default "signing all" sighash. There were concerns about estimating witness weight in multisig cases. The discussion explored the possibility of transforming any script into an equivalent one that avoids witness weight malleability.The role of scriptmask in a taproot world and its tradeoff with security were discussed. Opcodes like IF, NOTIF, VERIFY, DROP, and arithmetic opcodes accepting CScriptNum inputs posed challenges. Suggestions were made to eliminate witness weight malleability in practice through policies and consensus enforcement.The discussions also covered topics such as the implementation of covenants/vaults using NOINPUT, changes to Bitcoin script, the efficiency of the sighash cache, and the removal of OP_CODESEPARATOR.In summary, the discussions revolved around various proposals and considerations related to Bitcoin Script, including mask complexity, witness weight malleability, sighash flags, opcodes, and their impact on security and functionality. The ongoing efforts of the Bitcoin development community to improve the efficiency, security, and flexibility of the Bitcoin protocol were reflected in these discussions.The Bitcoin development community is currently exploring options for replacing OP_CODESEPARATOR, which takes a significant amount of time to execute. One suggestion is to add an internal counter that increments with every control flow operator, allowing signatures to cover the value of this counter or the index of the block within the Bitcoin Script program. The community is open to any solution that can replace the functionality of OP_CODESEPARATOR.Anthony Towns, a member of the Bitcoin development community, has raised concerns about the implementation of NOINPUT in the BIP 118 specification. He suggests that implementing NOINPUT implies the ANYONECANPAY feature, but removing the blanking of the 'hashSequence' field may affect this implication. Christian, another community member, agrees that there may not be a good use case for keeping the number of inputs with NOINPUT.Pieter Wuille, a Bitcoin Core developer, has proposed additions to the sighash for future segwit versions. These additions include committing to the absolute transaction fee and scriptPubKey in addition to the scriptCode. To prevent lying about the type of output being spent, these additions are made optional. Wuille's proposal introduces three new sighash flags: SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK. He also suggests adding a new opcode, OP_MASK, which acts as a NOP during execution.The computation of the sighash would follow the BIP143 method, with modifications based on the presence of the new flags. If SIGHASH_SCRIPTMASK is present, every subsequent opcode/push after an OP_MASK in scriptCode is removed. The scriptPubKey being spent is added to the sighash unless SIGHASH_SCRIPTMASK is set. The transaction fee is added to the sighash unless SIGHASH_NOFEE is set. Additionally, when SIGHASH_NOINPUT is set, hashPrevouts, hashSequence, and outpoint are set to null.Christian expresses concern about introducing a new opcode to mask things in the sighash, but considers it a minor issue. He also notes that Wuille's proposal may address some downsides of BIP118 by committing to the script when possible. Wuille seeks feedback on whether his proposal introduces redundant flexibility or overlooks any obvious use cases.In summary, Pieter Wuille proposes three new sighash flags, namely SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK, along with the addition of a new opcode called OP_MASK. These additions aim to enhance the functionality of the sighash in future segwit versions. The proposal suggests specific modifications to the sighash computation process, including the addition of transaction fee and scriptPubKey commitment. The community is encouraged to provide feedback on these proposals and identify any potential issues or use cases that may have been overlooked.
Updated on: 2023-08-02T00:02:39.338876+00:00