From 5b9b44cc79a8f9e6370f8f533920d68a50015390 Mon Sep 17 00:00:00 2001 From: Brandon Black Date: Fri, 29 Oct 2021 14:48:52 -0700 Subject: [PATCH 1/4] BIP341: SigHash: Clarify SIGHASH_DEFAULT --- bip-0341.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index ba3310f5..13767ebe 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -90,7 +90,7 @@ We first define a reusable common signature message calculation function, follow The function ''SigMsg(hash_type, ext_flag)'' computes the message being signed as a byte array. It is implicitly also a function of the spending transaction and the outputs it spends, but these are not listed to keep notation simple. -The parameter ''hash_type'' is an 8-bit unsigned value. The SIGHASH encodings from the legacy script system are reused, including SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, and SIGHASH_ANYONECANPAY, plus the default ''hash_type'' value ''0x00'' which results in signing over the whole transaction just as for SIGHASH_ALL. The following restrictions apply, which cause validation failure if violated: +The parameter ''hash_type'' is an 8-bit unsigned value. The SIGHASH encodings from the legacy script system are reused, including SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, and SIGHASH_ANYONECANPAY. We define a new ''hashtype'' SIGHASH_DEFAULT (value ''0x00'') which results in signing over the whole transaction just as for SIGHASH_ALL. The following restrictions apply, which cause validation failure if violated: * Using any undefined ''hash_type'' (not ''0x00'', ''0x01'', ''0x02'', ''0x03'', ''0x81'', ''0x82'', or ''0x83'''''Why reject unknown ''hash_type'' values?''' By doing so, it is easier to reason about the worst case amount of signature hashing an implementation with adequate caching must perform.). * Using SIGHASH_SINGLE without a "corresponding output" (an output with the same index as the input being verified). From 736e79c938f75272717d0f3f44d985036c53f5fe Mon Sep 17 00:00:00 2001 From: Brandon Black Date: Fri, 29 Oct 2021 14:49:28 -0700 Subject: [PATCH 2/4] BIP341: SigHash: Clarify encoding of script pub keys --- bip-0341.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index 13767ebe..e856aa5e 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -106,7 +106,7 @@ If the parameters take acceptable values, the message is the concatenation of th ** If the ''hash_type & 0x80'' does not equal SIGHASH_ANYONECANPAY: *** ''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_scriptpubkeys'' (32): the SHA256 of all spent outputs' ''scriptPubKeys'', serialized as script inside CTxOut. *** ''sha_sequences'' (32): the SHA256 of the serialization of all input ''nSequence''. ** If ''hash_type & 3'' does not equal SIGHASH_NONE or SIGHASH_SINGLE: *** ''sha_outputs'' (32): the SHA256 of the serialization of all outputs in CTxOut format. From d690408080bbf9c2442502abac9ac0a21db5a378 Mon Sep 17 00:00:00 2001 From: Brandon Black Date: Fri, 29 Oct 2021 14:49:58 -0700 Subject: [PATCH 3/4] BIP341/342: Clarify SigHash extensions * Pull the definition of the extension in BIP342 to its own section * Add a section to BIP341 on validating script path signatures * Clarify that SigMsg does not produce the message being signed, but a common portion of it --- bip-0341.mediawiki | 4 ++-- bip-0342.mediawiki | 12 ++++++++---- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index e856aa5e..8af9c559 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -88,13 +88,13 @@ We first define a reusable common signature message calculation function, follow ==== Common signature message ==== -The function ''SigMsg(hash_type, ext_flag)'' computes the message being signed as a byte array. It is implicitly also a function of the spending transaction and the outputs it spends, but these are not listed to keep notation simple. +The function ''SigMsg(hash_type, ext_flag)'' computes the common portion of the message being signed as a byte array. It is implicitly also a function of the spending transaction and the outputs it spends, but these are not listed to keep notation simple. The parameter ''hash_type'' is an 8-bit unsigned value. The SIGHASH encodings from the legacy script system are reused, including SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, and SIGHASH_ANYONECANPAY. We define a new ''hashtype'' SIGHASH_DEFAULT (value ''0x00'') which results in signing over the whole transaction just as for SIGHASH_ALL. The following restrictions apply, which cause validation failure if violated: * Using any undefined ''hash_type'' (not ''0x00'', ''0x01'', ''0x02'', ''0x03'', ''0x81'', ''0x82'', or ''0x83'''''Why reject unknown ''hash_type'' values?''' By doing so, it is easier to reason about the worst case amount of signature hashing an implementation with adequate caching must perform.). * Using SIGHASH_SINGLE without a "corresponding output" (an output with the same index as the input being verified). -The parameter ''ext_flag'' is an integer in range 0-127, and is used for indicating (in the message) that extensions are added at the end of the message'''What extensions use the ''ext_flag'' mechanism?''' [[bip-0342.mediawiki|BIP342]] reuses the same common signature message algorithm, but adds BIP342-specific data at the end, which is indicated using ''ext_flag = 1''.. +The parameter ''ext_flag'' is an integer in range 0-127, and is used for indicating (in the message) that extensions are appended to the output of ''SigMsg()'''''What extensions use the ''ext_flag'' mechanism?''' [[bip-0342.mediawiki#common-signature-message-extension|BIP342]] reuses the same common signature message algorithm, but adds BIP342-specific data at the end, which is indicated using ''ext_flag = 1''.. If the parameters take acceptable values, the message is 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 are encoded in little-endian. diff --git a/bip-0342.mediawiki b/bip-0342.mediawiki index 87e07ae8..bbefcaaa 100644 --- a/bip-0342.mediawiki +++ b/bip-0342.mediawiki @@ -104,13 +104,17 @@ The following rules apply to OP_CHECKSIG, OP_CHECKSIGVERIFYOP_CHECKSIG, a 1-byte value 0x01 is pushed onto the stack. *** For OP_CHECKSIGADD, a CScriptNum with value of n + 1 is pushed onto the stack. +===Common Signature Message Extension=== + +We define the tapscript message extension ''ext'' to [[bip-0341.mediawiki#common-signature-message|BIP341 Common Signature Message]], indicated by ''ext_flag = 1'': +* ''tapleaf_hash'' (32): the tapleaf hash as defined in [[bip-0341.mediawiki#design|BIP341]] +* ''key_version'' (1): a constant value ''0x00'' representing the current version of public keys in the tapscript signature opcode execution. +* ''codesep_pos'' (4): the opcode position of the last executed OP_CODESEPARATOR 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. Opcodes in parsed but unexecuted branches count towards this value as well. + ===Signature validation=== To validate a signature ''sig'' with public key ''p'': -* Compute the tapscript message extension ''ext'', consisting of the concatenation of: -** ''tapleaf_hash'' (32): the tapleaf hash as defined in [[bip-0341.mediawiki#design|BIP341]] -** ''key_version'' (1): a constant value ''0x00'' representing the current version of public keys in the tapscript signature opcode execution. -** ''codesep_pos'' (4): the opcode position of the last executed OP_CODESEPARATOR 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. Opcodes in parsed but unexecuted branches count towards this value as well. +* Compute the tapscript message extension ''ext'' described above. * If the ''sig'' is 64 bytes long, return ''Verify(p, hashTapSighash(0x00 || SigMsg(0x00, 1) || ext), sig)'', where ''Verify'' is defined in [[bip-0340.mediawiki#design|BIP340]]. * If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00 and Verify(p, hashTapSighash(0x00 || SigMsg(sig[64], 1) || ext), sig[0:64])''. * Otherwise, fail. From 6222dc45a301c9b7d83536e2cd97d42899f5cb85 Mon Sep 17 00:00:00 2001 From: Brandon Black Date: Fri, 29 Oct 2021 15:01:39 -0700 Subject: [PATCH 4/4] BIP341: Clarify tweaking of secret keys --- bip-0341.mediawiki | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index 8af9c559..400b466e 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -175,6 +175,8 @@ The parity bit will be required for spending the output with a script path. In order to allow spending with the key path, we define taproot_tweak_seckey to compute the secret key for a tweaked public key. For any byte string h it holds that taproot_tweak_pubkey(pubkey_gen(seckey), h)[1] == pubkey_gen(taproot_tweak_seckey(seckey, h)). +Note that because tweaks are applied to 32-byte public keys, `taproot_tweak_seckey` may need to negate the secret key before applying the tweak. + def taproot_tweak_pubkey(pubkey, h): t = int_from_bytes(tagged_hash("TapTweak", pubkey + h))