The signature would be expected to be 65-bytes: the 64-byte Schnorr
signature plus the appended sighash byte. But the new sighash value
SIGHASH_DEFAULT, encoded as 0x00, allows the space optimization of
omitting the sighash byte, allowing for a 64-byte signature.
This is now explained explicitly in the text.
135 | @@ -136,6 +136,9 @@ In summary, the semantics of the [[bip-0143.mediawiki|BIP143]] sighash types rem 136 | 137 | ==== Taproot key path spending signature validation ==== 138 | 139 | +A Taproot signature is the 64-byte Schnorr signature defined in [[bip-0340.mediawiki|BIP340]] with the sighash byte appended in the usual Bitcoin fashion<ref>See [https://en.bitcoin.it/wiki/OP_CHECKSIG#How_it_works '''OP_CHECKSIG''' "How it works"].</ref>.
I'm not very keen on linking to the bitcoin.it wiki, especially not without a fixed timestamp. It's hard to say the OP_CHECKSIG article there will forever include an explanation of this concept.
I will look elsewhere in the BIPs for a proper reference.
How about s/is the 64-byte/is a 64-byte/ ?
I don't think you'll find any, since the "append a byte to the ECDSA signature to indicate the sighash type" dates back to the original release, long before the BIP process. I'd just leave the text without a reference.
ok.
Changed to "A Taproot signature is a 64-byte Schnorr signature, as defined in ..." - ?
135 | @@ -136,6 +136,9 @@ In summary, the semantics of the [[bip-0143.mediawiki|BIP143]] sighash types rem 136 | 137 | ==== Taproot key path spending signature validation ==== 138 | 139 | +A Taproot signature is the 64-byte Schnorr signature defined in [[bip-0340.mediawiki|BIP340]] with the sighash byte appended in the usual Bitcoin fashion<ref>See [https://en.bitcoin.it/wiki/OP_CHECKSIG#How_it_works '''OP_CHECKSIG''' "How it works"].</ref>. 140 | +However, in the common case of '''SIGHASH_DEFAULT''', encoded as ''0x00'', a space optimization can be made by ''omitting'' the sighash byte, resulting in a 64-byte signature with '''SIGHASH_DEFAULT''' assumed.
For consistency you should replace ''' with <code> and </code>.
Done. (I had looked in the mediawiki markup docs rather than look around in this file.)
I'd be ok with adding this explanatory paragraph. Note that this defines a new term, "Taproot signature". But as far as I can see that doesn't hurt.
Looks good to me. Feel free to squash the "address PR comments" commit.
The signature would be expected to be 65-bytes: the 64-byte Schnorr
signature plus the appended sighash byte. But the new sighash value
SIGHASH_DEFAULT, encoded as 0x00, allows the space optimization of
omitting the sighash byte, allowing for a 64-byte signature.
This is now explained explicitly in the text.
Address PR comments
- remove ref to `bitcoin.it` wiki - may change or disappear in future (just don't
refer to a definition)
- Slight wording change to sentence
- Make markup consistent with rest of file
Looks good to me. Feel free to squash the "address PR comments" commit.
Squash done.
ACK 5c85131cfff22f7116eec6a93b9cfb5567373bf9 (conditional on another coauthor's ACK).
very helpful addition!!
135 | @@ -136,6 +136,9 @@ In summary, the semantics of the [[bip-0143.mediawiki|BIP143]] sighash types rem 136 | 137 | ==== Taproot key path spending signature validation ==== 138 | 139 | +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. 140 | +However, in the common case of <code>SIGHASH_DEFAULT</code>, encoded as ''0x00'', a space optimization can be made by ''omitting'' the sighash byte, resulting in a 64-byte signature with <code>SIGHASH_DEFAULT</code> assumed.
I read "a space optimization can be made" as suggesting that you could have a 65 byte SIGHASH_DEFAULT signature, as omitting the sighash byte would just be optional.
Perhaps
However, in the common case when the default sighash flags being used (<code>SIGHASH_DEFAULT</code>, encoded as ''0x00'') the sighash byte is omitted from the encoding entirely, resulting in a 64-byte signature.
?
or just replace can with must?
Can confirm that 65bytes sig with 0x00 appended is considered invalid for bitcoind (v24.0)
Can confirm that 65bytes sig with 0x00 appended is considered invalid for
bitcoind (v24.0)
Hopefully, it's explicitly spelled out in footnote 21 that that is not allowed.
I will make it explicit, give me a minute.
I'd like to see #1330 (review) addressed. The text still seems to imply that the omission is optional for SIGHASH_DEFAULT.
To be honest, I think the (consensus-critical) specification section should be as short as possible, as long as it's unambiguous, which seems to be the case here. There's even a footnote about the two permitted signature lengths, so it really doesn't seem necessary to reiterate that in the document body.
What would you think of the following text as a replacement for line 140:
However, in the common case of
SIGHASH_DEFAULT, encoded as 0x00, the sighash byte is omitted, resulting in a 64-byte signature (andSIGHASH_DEFAULTassumed). (This ensures that there are not two valid formats for the sameSIGHASH_DEFAULTsignature: with and without the 0x00 sighash byte.)
I don't think this paragraph needs to go into too much detail; the full specification follows in the lines below, which already includes a footnote about avoiding malleation between 64 and 64-byte signatures. @vostrnad In abstract I agree with you, but we often follow a structure where there is first an informal description of what is going on, followed by a more formal specification with the exact rules. I think of this as this informal description. @david-bakin What about just:
This sighash byte is optional. If omitted the resulting signatures are 64 bytes, and a
SIGHASH_DEFAULTmode is implied.
@david-bakin What about just:
This sighash byte is optional. If omitted the resulting signatures are 64 bytes, and a
SIGHASH_DEFAULTmode is implied.
OK by me.
Do I understand right, that the next step is that @david-bakin will update the PR to adopt the phrasing suggested by @sipa?
Is anyone still working on this?
