BIP: 118 Layer: Consensus (soft fork) Title: SIGHASH_NOINPUT Author: Christian Decker <[email protected]> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0118 Status: Draft Type: Standards Track Created: 2017-02-28 License: BSD-3-Clause
This BIP describes a new signature hash flag (sighash-flag) for segwit transactions. It removes any commitment to the output being spent from the signature verification mechanism. This enables dynamic binding of transactions to outputs, predicated solely on the compatibility of output scripts to input scripts.
Off-chain protocols make use of transactions that are not yet broadcast to the Bitcoin network in order to renegotiate the final state that should be settled on-chain. In a number of cases it is desirable to react to a given transaction being seen on-chain with a predetermined reaction in the form of another transaction. Often the reaction is identical, no matter which transaction is seen on-chain, but the application still needs to create many identical transactions. This is because signatures in the input of a transaction uniquely commit to the hash of the transaction that created the output being spent.
This proposal introduces a new sighash flag that modifies the behavior of the transaction digest algorithm used in the signature creation and verification, to exclude the previous output commitment. By removing the commitment we enable dynamic rebinding of a signed transaction to outputs whose witnessProgram and value match the ones in the witness of the spending transaction.
The dynamic binding is opt-in and can further be restricted by using unique witnessProgram scripts that are specific to the application instance, e.g., using public keys that are specific to the off-chain protocol instance.
SIGHASH_NOINPUT is a flag with value 0x40 appended to a signature so that the signature does not commit to any of the inputs, and therefore to the outputs being spent. The flag applies solely to the verification of that single signature.
The SIGHASH_NOINPUT flag is only active for segwit scripts with version 1 or higher. Should the flag be used in a non-segwit script or a segwit script of version 0, the current behavior is maintained and the script execution MUST abort with a failure.
The transaction digest algorithm from BIP 143 is used when verifying a SIGHASH_NOINPUT signature, with the following modifications:
2. hashPrevouts (32-byte hash) is 32 0x00 bytes
3. hashSequence (32-byte hash) is 32 0x00 bytes
4. outpoint (32-byte hash + 4-byte little endian) is
set to 36 0x00 bytes
5. scriptCode of the input is set to an empty script
0x00
The value of the previous output remains part of the transaction digest and is therefore also committed to in the signature.
The NOINPUT flag MAY be combined with the SINGLE flag in which case the hashOutputs is modified as per BIP 143[1]: it only commits to the output with the matching index, if such output exists, and is a uint256 0x0000......0000 otherwise.
Being a change in the digest algorithm, the NOINPUT flag applies to all segwit signature verification opcodes, specifically it applies to:
- OP_CHECKSIG
- OP_CHECKSIGVERIFY
- OP_CHECKMULTISIG
- OP_CHECKMULTISIGVERIFY
Using NOINPUT the input containing the signature no longer references a specific output. Any participant can take a transaction and rewrite it by changing the hash reference to the previous output, without invalidating the signatures. This allows transactions to be bound to any output that matches the value committed to in the witness and whose witnessProgram, combined with the spending transaction's witness returns true.
Previously, all information in the transaction was committed in the signature itself, while now the relationship between the spending transaction and the output being spent is solely based on the compatibility of the witnessProgram and the witness.
This also means that particular care has to be taken in order to avoid unintentionally enabling this rebinding mechanism. NOINPUT MUST NOT be used, unless it is explicitly needed for the application, e.g., it MUST NOT be a default signing flag in a wallet implementation. Rebinding is only possible when the outputs the transaction may bind to all use the same public keys. Any public key that is used in a NOINPUT signature MUST only be used for outputs that the input may bind to, and they MUST NOT be used for transactions that the input may not bind to. For example an application SHOULD generate a new key-pair for the application instance using NOINPUT signatures and MUST NOT reuse them afterwards.
The NOINPUT sighash flag is to be deployed during a regular segwit script update.
As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not verify the validity of the new sighash flag and will consider the transaction valid by default. Being only applicable to segwit transactions, non-segwit nodes will see an anyone-can-spend script and will consider it valid.
The NOINPUT sighash flag was first proposed by Joseph Poon in February 2016[2], after being mentioned in the original Lightning paper[3]. A formal proposal was however deferred until after the activation of segwit. This proposal is a continuation of this discussion and attempts to formalize it in such a way that it can be included in the Bitcoin protocol. As such we'd like acknowledge Joseph Poon and Thaddeus Dryja as the original inventors of the NOINPUT sighash flag, and its uses in off-chain protocols.
- ^ https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki
- ^ https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html
- ^ http://lightning.network/lightning-network.pdf
This document is licensed under the BSD 3 Clause license.