Published on: 2018-07-13T00:04:14+00:00
The ongoing discussion among Bitcoin developers revolves around the potential risks and vulnerabilities of the proposed SIGHASH_NOINPUT feature. One concern is the risk for individuals who regularly reuse addresses, as signing one input with NOINPUT could inadvertently spend all inputs associated with that key. To address this issue, suggestions have been made to use a new opcode, such as OP_CHECK_SIG_FOR_SINGLE_USE_KEY, or opcodes like OP_CHECKSIG_1USE or OP_CHECKMULTISIG_1USE, which would ensure that a NOINPUT signature is only valid for intended single-use keys.While these alternatives may result in slightly larger witness sizes, they are not worse than the normal taproot tradeoff. Additionally, it has been noted that a different opcode at a philosophical level could differentiate between signatures that authorize spending of a particular coin and those that sign a spend of an entire wallet. This differentiation could be reflected in different addresses by introducing a new opcode for NOINPUT.The proposal itself, called SIGHASH_NOINPUT, has generated positive enthusiasm among developers. Christian Decker, a Bitcoin Core developer, has requested the assignment of a BIP number for the proposal from the benevolent BIP editors (BBEs). Although he has implemented hashing in Bitcoin Core, he believes it is unlikely to pass review due to the lack of groundwork on witness V1 scripts, preventing current testing. It has been noted that some fork coins have used sighash 0x40 as FORKID, but this does not conflict with the NOINPUT proposal as it only applies to segwit transactions disabled by the fork coins.The implementation of SIGHASH_NOINPUT is expected to enhance the efficiency of the Lightning Network by allowing the creation of lightning channels without broadcasting to the network. This will lead to cost savings for users and reduce the load on the blockchain. The proposal aims to address transaction malleability issues and improve privacy.Christian Decker's proposal for a new sighash flag, SIGHASH_NOINPUT, has garnered interest for its potential applications. By removing the commitment to the previous output, this flag enables rebinding of inputs to any matching outpoint through script compatibility. The proposal is meant to facilitate off-chain use-cases, such as lightning channels and watch-towers.Some concerns have been raised about confusion with existing wallets, but given that existing wallets do not sign things with unknown flags, it was decided to proceed with the sighash approach. The proposal is minimalistic and simple, although input from the wider community is still sought, particularly regarding committing to the amount of the outpoint being spent.It is believed that the deployment of SIGHASH_NOINPUT can be introduced by bumping the segwit script version and adding the new behavior. Christian hopes that the proposal will be well-received and looks forward to discussing variants and tradeoffs. The potential applications enabled by this change are considered interesting, with the belief that there are many more possibilities to explore.
Updated on: 2023-07-31T20:12:58.887731+00:00