summaryrefslogtreecommitdiff
path: root/bip-0341.mediawiki
diff options
context:
space:
mode:
authorPieter Wuille <pieter@wuille.net>2020-07-28 13:50:50 -0700
committerPieter Wuille <pieter@wuille.net>2020-07-28 13:50:50 -0700
commitb9ea863727c8e53d69afc1a816feed8944cc1e58 (patch)
tree43fe81ce0f20b5cc5b0e036450102a4b955d5d46 /bip-0341.mediawiki
parent5cc0c6fb498efdc35debc17c044ee9ccaa13f0ce (diff)
downloadbips-b9ea863727c8e53d69afc1a816feed8944cc1e58.tar.xz
Use consistent capitalization of tag TapSighash
Diffstat (limited to 'bip-0341.mediawiki')
-rw-r--r--bip-0341.mediawiki2
1 files changed, 1 insertions, 1 deletions
diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki
index 6c71b8d..b767ea5 100644
--- a/bip-0341.mediawiki
+++ b/bip-0341.mediawiki
@@ -137,7 +137,7 @@ In summary, the semantics of the [[bip-0143.mediawiki|BIP143]] sighash types rem
==== Taproot key path spending signature validation ====
To validate a signature ''sig'' with public key ''q'':
-* If the ''sig'' is 64 bytes long, return ''Verify(q, hash<sub>TapSigHash</sub>(0x00 || SigMsg(0x00, 0)), sig)''<ref>'''Why is the input to ''hash<sub>TapSigHash</sub>'' prefixed with 0x00?''' This prefix is called the sighash epoch, and allows reusing the ''hash<sub>TapSigHash</sub>'' tagged hash in future signature algorithms that make invasive changes to how hashing is performed (as opposed to the ''ext_flag'' mechanism that is used for incremental extensions). An alternative is having them use a different tag, but supporting a growing number of tags may become undesirable.</ref>, where ''Verify'' is defined in [[bip-0340.mediawiki#design|BIP340]].
+* If the ''sig'' is 64 bytes long, return ''Verify(q, hash<sub>TapSighash</sub>(0x00 || SigMsg(0x00, 0)), sig)''<ref>'''Why is the input to ''hash<sub>TapSighash</sub>'' prefixed with 0x00?''' This prefix is called the sighash epoch, and allows reusing the ''hash<sub>TapSighash</sub>'' tagged hash in future signature algorithms that make invasive changes to how hashing is performed (as opposed to the ''ext_flag'' mechanism that is used for incremental extensions). An alternative is having them use a different tag, but supporting a growing number of tags may become undesirable.</ref>, where ''Verify'' is defined in [[bip-0340.mediawiki#design|BIP340]].
* If the ''sig'' is 65 bytes long, return ''sig[64] &ne; 0x00<ref>'''Why can the <code>hash_type</code> not be <code>0x00</code> in 65-byte signatures?''' Permitting that would enable malleating (by third parties, including miners) 64-byte signatures into 65-byte ones, resulting in a different `wtxid` and a different fee rate than the creator intended</ref> and Verify(q, hash<sub>TapSighash</sub>(0x00 || SigMsg(sig[64], 0)), sig[0:64])''.
* Otherwise, fail<ref>'''Why permit two signature lengths?''' By making the most common type of <code>hash_type</code> implicit, a byte can often be saved.</ref>.