diff --git a/bip-taproot.mediawiki b/bip-taproot.mediawiki index 76c23dc8..0823c6bb 100644 --- a/bip-taproot.mediawiki +++ b/bip-taproot.mediawiki @@ -54,10 +54,10 @@ The notation below follows that of bip-schnorr. === Script validation rules === -A Taproot output is a SegWit output (native or P2SH-nested, see [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) with version number 1, and a 32-byte witness program. -The following rules only apply when such an output is being spent. Any other outputs, including version 1 outputs with lengths other than 32 bytes, remain unencumbered. +A Taproot output is a native SegWit output (see [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) with version number 1, and a 32-byte witness program. +The following rules only apply when such an output is being spent. Any other outputs, including version 1 outputs with lengths other than 32 bytes, or P2SH-wrapped version 1 outputs, remain unencumbered. -* Let ''q'' be the 32-byte array containing the witness program (second push in scriptPubKey or P2SH redeemScript) which represents a public key according to bip-schnorr. +* Let ''q'' be the 32-byte array containing the witness program (the second push in the scriptPubKey) which represents a public key according to bip-schnorr. * Fail if the witness stack has 0 elements. * If there are at least two witness elements, and the first byte of the last element is 0x50'''Why is the first byte of the annex 0x50?''' Like the 0xc0-0xc1 constants, 0x50 is chosen as it could not be confused with a valid P2WPKH or P2WSH spending. As the control block's initial byte's lowest bit is used to indicate the public key's Y quadratic residuosity, each script version needs two subsequence byte values that are both not yet used in P2WPKH or P2WSH spending. To indicate the annex, only an "unpaired" available byte is necessary like 0x50. This choice maximizes the available options for future script versions., this last element is called ''annex'' ''a'''''What is the purpose of the annex?''' The annex is a reserved space for future extensions, such as indicating the validation costs of computationally expensive new opcodes in a way that is recognizable without knowing the outputs being spent. Until the meaning of this field is defined by another softfork, users SHOULD NOT include annex in transactions, or it may lead to PERMANENT FUND LOSS. and is removed from the witness stack. The annex (or the lack of thereof) is always covered by the transaction digest and contributes to transaction weight, but is otherwise ignored during taproot validation. * If there is exactly one element left in the witness stack, key path spending is used: @@ -126,10 +126,9 @@ As the message for signature verification, transaction digest is ''hashTapS *** sha_outputs (32): the SHA256 of the serialization of all outputs in CTxOut format. * Data about this input: ** spend_type (1): -*** Bit-0 is set if the scriptPubKey being spent is P2SH (opposed to "native segwit"). -*** Bit-1 is set if an annex is present (the original witness stack has two or more witness elements, and the first byte of the last element is 0x50). +*** Bit 0 is set if an annex is present (the original witness stack has two or more witness elements, and the first byte of the last element is 0x50). *** The other bits are unset. -** scriptPubKey (24 or 35): scriptPubKey of the previous output spent by this input, serialized as script inside CTxOut. The size is 24-byte for P2SH-embedded segwit, or 35-byte for native segwit. +** scriptPubKey (35): scriptPubKey of the previous output spent by this input, serialized as script inside CTxOut. Its size is always 35 bytes. ** If the SIGHASH_ANYONECANPAY flag is set: *** outpoint (36): the COutPoint of this input (32-byte hash + 4-byte little-endian). *** amount (8): value of the previous output spent by this input. @@ -142,11 +141,11 @@ As the message for signature verification, transaction digest is ''hashTapS ** If the SIGHASH_SINGLE flag is set: *** sha_single_output (32): the SHA256 of the corresponding output in CTxOut format. -The total number of bytes hashed is at most ''209'''''What is the number of bytes hashed for the signature hash?''' The total size of the input to ''hashTapSighash'' (excluding the initial 64-byte hash tag) can be computed using the following formula: ''176 - is_anyonecanpay * 50 - is_none * 32 - is_p2sh_spending * 11 + has_annex * 32''.. +The total number of bytes hashed is at most ''209'''''What is the number of bytes hashed for the signature hash?''' The total size of the input to ''hashTapSighash'' (excluding the initial 64-byte hash tag) can be computed using the following formula: ''176 - is_anyonecanpay * 50 - is_none * 32 + has_annex * 32''.. In summary, the semantics of the BIP143 sighash types remain unchanged, except the following: # The way and order of serialization is changed.'''Why is the serialization in the transaction digest changed?''' Hashes that go into the digest and the digest itself are now computed with a single SHA256 invocation instead of double SHA256. There is no expected security improvement by doubling SHA256 because this only protects against length-extension attacks against SHA256 which are not a concern for transaction digests because there is no secret data. Therefore doubling SHA256 is a waste of resources. The digest computation now follows a logical order with transaction level data first, then input data and output data. This allows to efficiently cache the transaction part of the digest across different inputs using the SHA256 midstate. Additionally, digest computation avoids unnecessary hashing as opposed to BIP143 digests in which parts may be set zero and before hashing them. Despite that, collisions are made impossible by committing to the length of the data (implicit in hash_type and spend_type) before the variable length data. -# The digest commits to the scriptPubKey'''Why does the transaction digest commit to the scriptPubKey?''' This prevents lying to offline signing devices about the type of output being spent, even when the actually executed script (scriptCode in BIP143) is correct. Without committing to the scriptPubKey an attacker can fool the device into overpaying fees by asking it to sign for a P2SH wrapped segwit output but actually using it to spend a native segwit output.. +# The digest commits to the scriptPubKey'''Why does the transaction digest commit to the scriptPubKey?''' This prevents lying to offline signing devices about output being spent, even when the actually executed script (scriptCode in BIP143) is correct. This means it's possible to compactly prove to a hardware wallet what (unused) execution paths existed.. # If the SIGHASH_ANYONECANPAY flag is not set, the digest commits to the amounts of ''all'' transaction inputs.'''Why does the transaction digest commit to the amounts of all transaction inputs?''' This eliminates the possibility to lie to offline signing devices about the fee of a transaction. # The digest commits to all input nSequence if SIGHASH_NONE or SIGHASH_SINGLE are set (unless SIGHASH_ANYONECANPAY is set as well).'''Why does the transaction digest commit to all input nSequence if SIGHASH_SINGLE or SIGHASH_NONE are set?''' Because setting them already makes the digest commit to the prevouts part of all transaction inputs, it is not useful to treat the nSequence any different. Moreover, this change makes nSequence consistent with the view that SIGHASH_SINGLE and SIGHASH_NONE only modify the digest with respect to transaction outputs and not inputs. # The digest commits to taproot-specific data epoch, spend_type and annex (if present). @@ -208,7 +207,7 @@ def taproot_output_script(internal_pubkey, script_tree): return bytes([0x51, 0x20]) + output_pubkey.get_bytes() -The function taproot_output_script returns a byte array with the scriptPubKey. It can be P2SH wrapped if desired (see BIP141). +The function taproot_output_script returns a byte array with the scriptPubKey (see BIP141). [[File:bip-taproot/tree.png|frame|This diagram shows the hashing structure to obtain the tweak from an internal key ''P'' and a Merkle tree consisting of 5 script leaves. ''A'', ''B'', ''C'' and ''E'' are ''TapLeaf'' hashes similar to ''D'' and ''AB'' is a ''TapBranch'' hash. Note that when ''CDE'' is computed ''E'' is hashed first because ''E'' is less than ''CD''.]] @@ -229,7 +228,7 @@ def taproot_sign_key(script_tree, internal_privkey, hash_type): return [sig] -This function returns the witness stack necessary, and assumes a tweak_add method on private keys, and a sighash function to compute the signature hash as defined above (for simplicity, the snippet above ignores passing information like the transaction, the input position, P2SH or not, ... to the sighashing code). +This function returns the witness stack necessary, and assumes a tweak_add method on private keys, and a sighash function to compute the signature hash as defined above (for simplicity, the snippet above ignores passing information like the transaction, the input position, ... to the sighashing code). '''Spending using one of the scripts''' A Taproot output can be spent by satisfying any of the scripts used in its construction. To do so, a witness stack consisting of the script's inputs, plus the script itself and the control block are necessary. See the code below: @@ -282,8 +281,7 @@ Non-upgraded nodes, however, will consider all SegWit version 1 witness programs They are strongly encouraged to upgrade in order to fully validate the new programs. 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 BIP173 Bech32 addresses and non-standardness of these outputs does not prevent transaction broadcasting. -Non-upgraded wallets can send bitcoin to upgraded wallets using Segwit version 1 programs nested in BIP16 P2SH. +Depending on the implementation non-upgraded wallets may be able to send to Segwit version 1 programs if they support sending to BIP173 Bech32 addresses. == Acknowledgements == diff --git a/bip-tapscript.mediawiki b/bip-tapscript.mediawiki index 603990e0..0f4fdf53 100644 --- a/bip-tapscript.mediawiki +++ b/bip-tapscript.mediawiki @@ -44,8 +44,8 @@ Additionally, the new tapscript OP_SUCCESS opcodes allow introducin ==Specification== The rules below only apply when validating a transaction input for which all of the conditions below are true: -* The transaction output is a '''segregated witness spend''' (i.e., either the scriptPubKey or BIP16 redeemScript is a witness program as defined in BIP141). -* It is a '''taproot spend''' as defined in bip-taproot (i.e., the witness version is 1, the witness program is 32 bytes). +* The transaction output is a '''segregated witness spend''' (i.e., the scriptPubKey is a witness program as defined in BIP141). +* It is a '''taproot spend''' as defined in bip-taproot (i.e., the witness version is 1, the witness program is 32 bytes, and it is not P2SH wrapped). * It is a '''script path spend''' as defined in bip-taproot (i.e., after removing the optional annex from the witness stack, two or more stack elements remain). * The leaf version is ''0xc0'' (i.e. the first byte of the last witness element after removing the optional annex is ''0xc0'')'''How is the ''0xc0'' constant chosen?''' Following the guidelines in bip-taproot, by choosing a value having the two top bits set, tapscript spends are identifiable even without access to the UTXO being spent., marking it as a '''tapscript spend'''. @@ -103,10 +103,9 @@ These opcodes count toward the 201 non-push opcodes limit. As the message for signature opcodes signature verification, transaction digest has the same definition as in bip-taproot, except the following: -The one-byte spend_type has a different value, specificially at bit-2: -* Bit-0 is set if the scriptPubKey being spent is P2SH (opposed to "native segwit"). -* Bit-1 is set if an annex is present (the original witness stack has at least two witness elements, and the first byte of the last element is 0x50). -* Bit-2 is set. +The one-byte spend_type has a different value, specificially at bit 1: +* Bit 0 is set if an annex is present (the original witness stack has at least two witness elements, and the first byte of the last element is 0x50). +* Bit 1 is set. * The other bits are unset. As additional pieces of data, added at the end of the input to the ''hashTapSighash'' function: @@ -114,7 +113,7 @@ As additional pieces of data, added at the end of the input to the ''hashTa * key_version (1): a constant value 0x00 representing the current version of public keys in the tapscript signature opcode execution. * codeseparator_position (2): the opcode position of the last executed OP_CODESEPARATOR before the currently executed signature opcode, with the value in little endian (or 0xffff 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. -The total number of bytes hashed is at most ''244'''''What is the number of bytes hashed for the signature hash?''' The total size of the input to ''hashTapSighash'' (excluding the initial 64-byte hash tag) can be computed using the following formula: ''211 - is_anyonecanpay * 50 - is_none * 32 - is_p2sh_spending * 11 + has_annex * 32''.. +The total number of bytes hashed is at most ''244'''''What is the number of bytes hashed for the signature hash?''' The total size of the input to ''hashTapSighash'' (excluding the initial 64-byte hash tag) can be computed using the following formula: ''211 - is_anyonecanpay * 50 - is_none * 32 + has_annex * 32''.. In summary, the semantics of the BIP143 sighash types remain unchanged, except the following: # The exceptions mentioned in bip-taproot.