diff options
Diffstat (limited to 'bip-0118.mediawiki')
| -rw-r--r-- | bip-0118.mediawiki | 311 |
1 files changed, 190 insertions, 121 deletions
diff --git a/bip-0118.mediawiki b/bip-0118.mediawiki index 1b2f27c..a3a690b 100644 --- a/bip-0118.mediawiki +++ b/bip-0118.mediawiki @@ -1,144 +1,213 @@ <pre> BIP: 118 Layer: Consensus (soft fork) - Title: SIGHASH_NOINPUT + Title: SIGHASH_ANYPREVOUT for Taproot Scripts Author: Christian Decker <decker.christian@gmail.com> + Anthony Towns <aj@erisian.com.au> 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 + Requires: 340, 341, 342 </pre> -== Abstract == -This BIP describes a new signature hash flag (<tt>sighash</tt>-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. - -== Motivation == -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 <tt>witnessProgram</tt> and value match the ones -in the <tt>witness</tt> of the spending transaction. - -The dynamic binding is opt-in and can further be restricted by using -unique <tt>witnessProgram</tt> scripts that are specific to the application -instance, e.g., using public keys that are specific to the off-chain -protocol instance. +== Introduction == + +=== Abstract === + +This BIP describes a new type of public key for tapscript ([[bip-0342.mediawiki|BIP 342]]) transactions. +It allows signatures for these public keys to not commit to the exact UTXO being spent. +This enables dynamic binding of transactions to different UTXOs, provided they have compatible scripts. + +=== Copyright === + +This document is licensed under the 3-clause BSD license. + +=== Motivation === + +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 respond to a given transaction being seen on-chain with a predetermined reaction in the form of another transaction. +Often the same reaction is desired for a variety of different transactions that may be seen on-chain, but because the input signatures in the response transaction commit to the exact transaction that is being reacted to, this means a new signature must be created for every possible transaction one wishes to be able to react to. + +This proposal introduces a new public key type<ref>'''Why a new public key type?''' +New public key types for tapscript can be introduced in a soft fork by specifying new rules for ''unknown public key types'' as specified in [[bip-0342.mediawiki|BIP 342]], as this only requires adding restrictions to the pre-existing signature opcodes. +Possible alternative approaches would be to define new script opcodes, to use a different taproot leaf version, or to use a different set of SegWit outputs than those specified by [[bip-0341.mediawiki|BIP 341]]; however all of these approaches are more complicated, and are better reserved for other upgrades where the additional flexibility is actually needed. +In this case, we specify a new transaction digest, but retain the same elliptic curve and signature algorithm (ie, secp256k1 and [[bip-0340.mediawiki|BIP 340]]).</ref> +that modifies the behavior of the transaction digest algorithm used in the signature creation and verification, by excluding the commitment to the previous output (and, optionally, the witness script<ref>'''Why (and why not) commit to the witness script?''' +The [https://blockstream.com/eltoo.pdf eltoo] paper provides an example of why committing to the witness script is not always appropriate. +It uses script and the transaction <code>nLockTime</code> to make signatures asymmetric, so that a transaction with an earlier signature can be spent by a transaction with a later signature, but a transaction with a later signature cannot be spent by a transaction with an earlier signature. +As a result, a single signature for a third, even later transaction must be able to spend both the prior transactions, even though they have a different tapscript. +On the other hand, these cases also provide a good reason to have the option to commit to the script: because each transaction has a new script, committing to the script allows you to produce a signature that applies to precisely one of these transactions. +In the eltoo case, this allows you to have a signature for an update transaction that can be applied to any prior update, and a signature for a settlement transaction that applies only to the corresponding update transaction, while using the same key for both, which in turn allows for a more compact script. +</ref> and value <ref>'''Why (and why not) commit to the input value?''' +Committing to the input value may provide additional safety that a signature can't be maliciously reused to claim funds that the signer does not intend to spend, so by default it seems sensible to commit to it. However, doing so prevents being able to use a single signature to consolidate a group of UTXOs with the same spending condition into a single UTXO which may be useful for some protocols, such as the proposal for [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html layered commitments with eltoo].</ref>). +Removing this commitment allows dynamic rebinding of a signed transaction to another previous output that requires authorisation by the same key. + +The dynamic rebinding is opt-in due to using a separate public key type, and the breadth of transactions the signature can be rebound to can be further restricted by using different keys, committing to the script being spent in the signature, using different amounts between UTXOs, using different nSequence values in the spending transaction, or using the codeseparator opcode to commit to the position in the script. == Specification == -<tt>SIGHASH_NOINPUT</tt> is a flag with value <tt>0x40</tt> 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 <tt>SIGHASH_NOINPUT</tt> 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 -<tt>SIGHASH_NOINPUT</tt> 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 <tt>value</tt> of the previous output remains part of the transaction -digest and is therefore also committed to in the signature. - -The <tt>NOINPUT</tt> flag MAY be combined with the <tt>SINGLE</tt> flag in which -case the <tt>hashOutputs</tt> is modified as per BIP -143<ref>https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki</ref>: it -only commits to the output with the matching index, if such output exists, and -is a <tt>uint256</tt> <tt>0x0000......0000</tt> otherwise. - -Being a change in the digest algorithm, the <tt>NOINPUT</tt> flag applies to -all segwit signature verification opcodes, specifically it applies to: - -* <tt>OP_CHECKSIG</tt> - -* <tt>OP_CHECKSIGVERIFY</tt> - -* <tt>OP_CHECKMULTISIG</tt> - -* <tt>OP_CHECKMULTISIGVERIFY</tt> - -== Binding through scripts == -Using <tt>NOINPUT</tt> 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 <tt>witness</tt> and whose <tt>witnessProgram</tt>, -combined with the spending transaction's <tt>witness</tt> returns <tt>true</tt>. - -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 <tt>witnessProgram</tt> and the <tt>witness</tt>. - -This also means that particular care has to be taken in order to avoid -unintentionally enabling this rebinding mechanism. <tt>NOINPUT</tt> 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 <tt>NOINPUT</tt> 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 <tt>NOINPUT</tt> -signatures and MUST NOT reuse them afterwards. + +This BIP modifies the behaviour of the [[bip-0342.mediawiki|BIP 342]] signature opcodes<ref>'''What about key path spends?''' +This proposal only supports ANYPREVOUT signatures via script path spends, and does not support ANYPREVOUT signatures for key path spends. +This is for two reasons: first, not supporting key path spends allows this proposal to be independent of the core changes included in [[bip-0341.mediawiki|BIP 341]] and [[bip-0342.mediawiki|BIP 342]]; second, it allows addresses to opt-in or opt-out of ANYPREVOUT support while remaining indistinguishable prior to being spent. +</ref> (<code>CHECKSIG</code>, <code>CHECKSIGVERIFY</code>, and <code>CHECKSIGADD</code>) for public keys that have a length of 33 bytes and a first byte of <code>0x01</code> or the public key which is precisely the single byte vector <code>0x01</code><ref>'''Use of 0x01 public key type''' +Because <code>OP_0</code> leaves an empty vector on the stack it would not satisfy [[bip-0342.mediawiki|BIP 342]]'s rules for unknown public key types. As such, it is convenient to use one of <code>OP_1..OP_16</code> or <code>OP_1NEGATE</code> as a way to reference the taproot internal key. +To keep things as simple as possible, we use the first of these, and add the same byte as a prefix to allow ANYPREVOUT signatures for explicitly specified keys. +</ref>. +These keys are termed '''BIP 118 public keys'''. + +==== Rules for signature opcodes ==== + +The [[bip-0342.mediawiki|BIP 342]] rules for signature opcodes are modified by removing keys with the first byte <code>0x01</code> and length of either 1-byte or 33-bytes from the list of unknown public key types, and adding the following rule prior to the handling of unknown public key types: + +* If the public key is the single byte <code>0x01</code>, or if the public key is 33 bytes and the first byte of the public key is <code>0x01</code>, it is considered to be a BIP 118 public key: +** If the signature is not the empty vector, the signature is validated according to the [[bip-0341.mediawiki|BIP 341]] signing validation rules with the public key, allowable <code>hash_type</code> values, and transaction digest modified as defined below. + +==== Public key ==== + +To convert the 1-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], use the 32-byte taproot internal key, <code>p</code>, as defined in [[bip-0341.mediawiki|BIP 341]]. + +To convert a 33-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], remove the <code>0x01</code> prefix and use the remaining 32 bytes. + +==== Signature message ==== + +The function ''SigMsg118(hash_type, ext_flag)'' computes the message being signed as a byte array, analogously to ''SigMsg(hash_type, ext_flag)'' defined in [[bip-0341.mediawiki|BIP 341]], ''SigExt118(hash_type,key_version)'' computes the extension, similarly to [[bip-0342.mediawiki|BIP 342]]. + +The parameter ''hash_type'' is an 8-bit unsigned value, reusing values defined in [[bip-0341.mediawiki|BIP 341]], with the addition that the values <code>0x41</code>, <code>0x42</code>, <code>0x43</code>, <code>0xc1</code>, <code>0xc2</code>, and <code>0xc3</code> are also valid for BIP 118 public keys. + +We define the following constants using bits 6 and 7 of <code>hash_type</code>: + +* <code>SIGHASH_ANYPREVOUT = 0x40</code> +* <code>SIGHASH_ANYPREVOUTANYSCRIPT = 0xc0</code> + +As per [[bip-0341.mediawiki|BIP 341]], the parameter ''ext_flag'' is an integer in the range 0-127, used for indicating that extensions are added at the end of the message. The parameter ''key_version'' is an 8-bit unsigned value (an integer in the range 0-255) used for committing to the public key version. + +The following restrictions apply and cause validation failure if violated: +* Using any undefined ''hash_type'' (not ''0x00'', ''0x01'', ''0x02'', ''0x03'', ''0x41'', ''0x42'', ''0x43'', ''0x81'', ''0x82'', ''0x83'', ''0xc1'', ''0xc2'', or ''0xc3''). +* Using <code>SIGHASH_SINGLE</code> without a "corresponding output" (an output with the same index as the input being verified). + +If these restrictions aren't violated, ''SigMsg118(hash_type,ext_flag)'' evaluates to the concatenation of the following data, in order (with byte size of each item listed in parentheses). Numerical values in 2, 4, or 8-byte items are encoded in little-endian. + +* Control: +** ''hash_type'' (1). +* Transaction data: +** ''nVersion'' (4): the ''nVersion'' of the transaction. +** ''nLockTime'' (4): the ''nLockTime'' of the transaction. +** If ''hash_type & 0xc0'' is zero: +*** ''sha_prevouts'' (32): the SHA256 of the serialization of all input outpoints. +*** ''sha_amounts'' (32): the SHA256 of the serialization of all spent output amounts. +*** ''sha_scriptpubkeys'' (32): the SHA256 of the serialization of all spent output ''scriptPubKey''s. +*** ''sha_sequences'' (32): the SHA256 of the serialization of all input ''nSequence''. +** If ''hash_type & 3'' does not equal <code>SIGHASH_NONE</code> or <code>SIGHASH_SINGLE</code>: +*** ''sha_outputs'' (32): the SHA256 of the serialization of all outputs in <code>CTxOut</code> format. +* Data about this input: +** ''spend_type'' (1): equal to ''(ext_flag * 2) + annex_present'', where ''annex_present'' is 0 if no annex is present, or 1 otherwise (the original witness stack has two or more witness elements, and the first byte of the last element is ''0x50'') +** If ''hash_type & 0xc0'' is non-zero: +*** If ''hash_type & 0xc0'' is <code>SIGHASH_ANYONECANPAY</code>: +**** ''outpoint'' (36): the <code>COutPoint</code> of this input (32-byte hash + 4-byte little-endian). +*** If ''hash_type & 0xc0'' is <code>SIGHASH_ANYONECANPAY</code> or <code>SIGHASH_ANYPREVOUT</code>: +**** ''amount'' (8): value of the previous output spent by this input. +**** ''scriptPubKey'' (35): ''scriptPubKey'' of the previous output spent by this input, serialized as script inside <code>CTxOut</code>. Its size is always 35 bytes. +*** ''nSequence'' (4): ''nSequence'' of this input. +** If ''hash_type & 0xc0'' is zero: +*** ''input_index'' (4): index of this input in the transaction input vector. Index of the first input is 0. +** If an annex is present (the lowest bit of ''spend_type'' is set): +*** ''sha_annex'' (32): the SHA256 of ''(compact_size(size of annex) || annex)'', where ''annex'' includes the mandatory ''0x50'' prefix. +* Data about this output: +** If ''hash_type & 3'' equals <code>SIGHASH_SINGLE</code>: +*** ''sha_single_output'' (32): the SHA256 of the corresponding output in <code>CTxOut</code> format. + +Similarly, ''SigExt118(hash_type,key_version)'' evaluates to the concatenation of: + +* Extension: +** If ''hash_type & 0xc0'' is not <code>SIGHASH_ANYPREVOUTANYSCRIPT</codE>: +*** ''tapleaf_hash'' (32): the tapleaf hash as defined in [[bip-0341.mediawiki|BIP 341]] +** ''key_version'' (1). +** ''codesep_pos'' (4): the opcode position of the last executed <code>OP_CODESEPARATOR</code> before the currently executed signature opcode, with the value in little endian (or ''0xffffffff'' if none executed). The first opcode in a script has a position of 0. A multi-byte push opcode is counted as one opcode, regardless of the size of data being pushed. + +Note that if ''hash_type & 0x40'' is zero, ''SigMsg118(hash_type,ext_flag) == SigMsg(hash_type,ext_flag)'', and ''SigExt118(hash_type,0x00) == ext'' (where ''ext'' is the message extension as defined in [[bip-0342.mediawiki|BIP 342]]). + +To verify a signature ''sig'' for a BIP 118 public key ''p'': + +* If the ''sig'' is 64 bytes long, return ''Verify(p, hash<sub>TapSigHash</sub>(0x00 || SigMsg118(0x00, 1) || SigExt118(0x00, 0x01), sig)'', where ''Verify'' is defined in [[bip-0340.mediawiki|BIP 340]]. +* If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00 and Verify(p, hash<sub>TapSighash</sub>(0x00 || SigMsg118(sig[64], 1) || SigExt118(sig[64], 0x01), sig[0:64])''. +* Otherwise, fail. + +The key differences from [[bip-0342.mediawiki|BIP 342]] signature verification are: + +* In all cases, <code>key_version</code> is set to the constant value <code>0x01</code> instead of <code>0x00</code>.<ref>'''Why change key_version?''' Changing <code>key_version</code> ensures that if the same private key is used to generate both a [[bip-0342.mediawiki|BIP 342]] key and a BIP 118 public key, that a signature for the [[bip-0342.mediawiki|BIP 342]] key is not also valid for the BIP 118 public key (and vice-versa).</ref> +* If <code>SIGHASH_ANYPREVOUT</code> is set, the digest is calculated as if <code>SIGHASH_ANYONECANPAY</code> was set, except <code>outpoint</code> is not included in the digest. +* If <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> is set, the digest is calculated as if <code>SIGHASH_ANYONECANPAY</code> was set, except <code>outpoint</code>, <code>scriptPubKey</code> and <code>tapleaf_hash</code> are not included in the digest. + +== Security == + +==== Signature replay ==== + +By design, <code>SIGHASH_ANYPREVOUT</code> and <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> introduce additional potential for signature replay (that is they allow the same signature to be reused on a different transaction) when compared to <code>SIGHASH_ALL</code> and <code>SIGHASH_ANYONECANPAY</code> signatures. + +Both <code>SIGHASH_ALL</code> and <code>SIGHASH_ANYONECANPAY</code> signatures prevent signature replay by committing to one or more inputs, so replay of the signature is only possible if the same input can be spent multiple times, which is not possible on the Bitcoin blockchain (due to enforcement of [[bip-0030.mediawiki|BIP 30]]). +With <code>SIGHASH_ANYPREVOUT</code> signature replay is possible for different UTXOs with the same <code>scriptPubKey</code> and the same value, while with <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> signature replay is possible for any UTXOs that reuse the same BIP 118 public key in one of their potential scripts. + +As a consequence, implementors MUST ensure that BIP 118 public keys are only reused when signature replay cannot cause loss of funds (eg due to other features of the protocol or other constraints on the transaction), or when such a loss of funds is acceptable. + +==== Malleability ==== + +Use of <code>SIGHASH_ANYPREVOUT</code> or <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> may introduce additional malleability vectors. + +In particular, a transaction authenticated using only ANYPREVOUT signatures is malleable to anyone able to provide an alternate input satisfied by the signature -- an input changed in this way would produce a new, valid transaction paying the same recipient, but with a different txid. +Depending on the changes to the inputs, this might conflict with the original transaction (if some inputs remain shared) or might result in a double-payment to the recipient (if they do not). + +Further, for a chain of transactions using the same <code>scriptPubKey</code> and value, and only authenticated via ANYPREVOUT signatures (as envisioned in eltoo for failure cases), it may be possible for any third party to malleate the transactions (and their txids) without having access to any of the private keys, particularly by omitting intermediate transactions. + +This form of malleation can be dealt with by the child transactions also using ANYPREVOUT signatures -- when a parent transaction is malleated, its children can be adjusted to reference the new txid as the input and the ANYPREVOUT signatures remain valid. + +However child transactions that are authorised by a <code>SIGHASH_ALL</code> or <code>SIGHASH_ANYONECANPAY</code> signature will need new signatures if their inputs are malleated in this way. +This risk may be mitigated somewhat by using [[bip-0068.mediawiki|BIP 68]]/[[bip-0112.mediawiki|BIP 112]] relative time locks before spending a UTXO that had been authorised via an ANYPREVOUT signature with <code>SIGHASH_ALL</code> or <code>SIGHASH_ANYONECANPAY</code>: a relative timelock can ensure that the inputs have enough confirmations that they can only be replaced in the event of a large block reorg. +Note that this approach has drawbacks: relative timelocks prevent fee-bumping via child-pays-for-parent, and have the obvious drawback of making the funds temporarily unusable until the timelock expires. + +==== Privacy considerations ==== + +It is expected that ANYPREVOUT signatures will only be rarely used in practice. +Protocol and wallet designers should aim to have their transactions use Taproot key path spends whenever possible, both for efficiency reasons due to the lower transaction weight, but also for privacy reasons to avoid third parties being able to distinguish their transactions from those of other protocols. + +Transactions that do use ANYPREVOUT signatures will therefore reveal information about the transaction, potentially including that cooperation was impossible, or what protocol or software was used (due to the details of the script). + +In order to maximise privacy, it is therefore recommended that protocol designers only use BIP 118 public keys in scripts that will be spent using at least one ANYPREVOUT signature, and either use key path spends or alternate scripts in the taproot merkle tree for any spends that can be authorised without ANYPREVOUT signatures. +Following this recommendation may require additional script branches, which may mean disregarding this recommendation may result in a better tradeoff between cost and privacy in some circumstances. + +== Rationale == + +<references /> == Deployment == -The <tt>NOINPUT</tt> sighash flag is to be deployed during a regular segwit -script update. -== Backward compatibility == -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. +TODO + +This may be deployed as a soft-fork either concurrent with, or subsequent to the deployment of [[bip-0340.mediawiki|BIP 340]], [[bip-0341.mediawiki|BIP 341]] and [[bip-0342.mediawiki|BIP 342]]. + +== Backwards compatibility == + +As a soft fork, older software will continue to operate without modification. +Nodes that have not upgraded to support [[bip-0341.mediawiki|BIP 341]] will see all taproot witness programs as anyone-can-spend scripts, and nodes that have upgraded to support [[bip-0341.mediawiki|BIP 341]] and [[bip-0342.mediawiki|BIP 342]] but not BIP 118 will simply treat any non-empty signature against a BIP 118 public key as valid. +As such, nodes are strongly encourage to upgrade in order to fully validate signatures for the new public key type. + +Non-upgraded wallets can receive and send bitcoin from non-upgraded and upgraded wallets using SegWit version 0 programs, traditional pay-to-pubkey-hash, etc. +Depending on the implementation, non-upgraded wallets may be able to send to SegWit version 1 programs if they support sending to [[bip-0350.mediawiki|BIP350]] Bech32m addresses and do not prevent the transaction from being broadcast due to considering the outputs non-standard. -== Acknowledgments == +== Revisions == -The <tt>NOINPUT</tt> sighash flag was first proposed by Joseph Poon in -February 2016<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html</ref>, after being mentioned in the original -Lightning paper<ref>http://lightning.network/lightning-network.pdf</ref>. 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 <tt>NOINPUT</tt> sighash flag, and its uses in off-chain protocols. +Apart from being based on Taproot rather than SegWit v0, the main differences to prior revisions of this BIP are: -== References == +* The sighash flag has been renamed from "NOINPUT" to "ANYPREVOUT" to reflect that while any prevout may potentially be used with the signature, some aspects of the input are still committed to, namely the input nSequence value, and (optionally) the spending conditions and amount. +* Previously NOINPUT would have worked for direct public key spends (assuming deployment was fleshed out in a way similar to BIP 141 P2WPKH and P2WSH), however this proposal only applies to signatures via tapscript, and not direct key path spends. This means that addresses must opt-in to the ability to be spent by a <code>SIGHASH_ANYPREVOUT</code> or <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> signature by including an appropriate tapscript path when the address is created. +* NOINPUT signatures do not commit to the output's spending conditions either via <code>scriptPubKey</code> or the redeem/witness script. This behaviour is preserved when <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> is used, but when <code>SIGHASH_ANYPREVOUT</code> is used, the signature now commits to <code>scriptPubKey</code> and the tapscript. +* NOINPUT signatures did commit to the input's amount. This behaviour is preserved when <code>SIGHASH_ANYPREVOUT</code> is used, but not when <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> is used. +* <code>OP_CODESEPARATOR</code> in script will affect both <code>SIGHASH_ANYPREVOUT</code> and <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> signatures, whereas it would not have in the previous draft. -<references/> +== Acknowledgements == -== Copyright == +The <code>SIGHASH_NOINPUT</code> flag was first proposed by Joseph Poon in [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html February 2016], after being mentioned in the original [http://lightning.network/lightning-network-paper.pdf Lightning paper] by Joseph Poon and Thaddeus Dryja. +This document is the result of discussions with many people and had direct input from Greg Maxwell, Jonas Nick, Pieter Wuille and others. -This document is licensed under the BSD 3 Clause license. |