From 5767f444995df378ad772887b739e84bd9002d95 Mon Sep 17 00:00:00 2001 From: David Bakin Date: Mon, 6 Jun 2022 10:35:53 -0700 Subject: [PATCH] BIP-341: Explain the 64-byte signature format Co-authored-by: Pieter Wuille Co-authored-by: Anthony Towns --- bip-0341.mediawiki | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index bd45f3d92c..a367d36ed1 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -136,6 +136,8 @@ In summary, the semantics of the [[bip-0143.mediawiki|BIP143]] sighash types rem ==== Taproot key path spending signature validation ==== +A Taproot signature is a 64-byte Schnorr signature, as defined in [[bip-0340.mediawiki|BIP340]], with the sighash byte appended in the usual Bitcoin fashion. This sighash byte is optional. If omitted, the resulting signatures are 64 bytes, and a SIGHASH_DEFAULT mode is implied. + To validate a signature ''sig'' with public key ''q'': * If the ''sig'' is 64 bytes long, return ''Verify(q, hashTapSighash(0x00 || SigMsg(0x00, 0)), sig)'''''Why is the input to ''hashTapSighash'' prefixed with 0x00?''' This prefix is called the sighash epoch, and allows reusing the ''hashTapSighash'' 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., where ''Verify'' is defined in [[bip-0340.mediawiki#design|BIP340]]. * If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00'''Why can the hash_type not be 0x00 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. and Verify(q, hashTapSighash(0x00 || SigMsg(sig[64], 0)), sig[0:64])''.