BIP-341: Explain the 64-byte signature format

david-bakin commented at 5:37 pm on June 6, 2022: none

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.

bitcoin deleted a comment on Jun 7, 2022

luke-jr commented at 9:14 pm on July 25, 2022: member

@sipa @jonasnick @ajtowns

luke-jr added the label Proposed BIP modification on Jul 25, 2022

in bip-0341.mediawiki:139 in 1911a9be08 outdated

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>.

sipa commented at 9:24 pm on July 25, 2022:

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.

david-bakin commented at 10:50 pm on July 25, 2022:

I will look elsewhere in the BIPs for a proper reference.

jonasnick commented at 3:28 pm on July 26, 2022:

How about s/is the 64-byte/is a 64-byte/ ?

sipa commented at 0:24 am on July 27, 2022:

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.

david-bakin commented at 5:46 pm on July 27, 2022:

ok.

david-bakin commented at 5:47 pm on July 27, 2022:

Changed to “A Taproot signature is a 64-byte Schnorr signature, as defined in …” - ?

in bip-0341.mediawiki:140 in 1911a9be08 outdated

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.

jonasnick commented at 3:29 pm on July 26, 2022:

For consistency you should replace ''' with <code> and </code>.

david-bakin commented at 5:47 pm on July 27, 2022:

Done. (I had looked in the mediawiki markup docs rather than look around in this file.)

jonasnick commented at 3:34 pm on July 26, 2022: contributor

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.

david-bakin force-pushed on Jul 27, 2022

jonasnick commented at 9:09 pm on July 28, 2022: contributor

Looks good to me. Feel free to squash the “address PR comments” commit.

BIP-341: Explain the 64-byte signature format

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

5c85131cff

david-bakin force-pushed on Aug 7, 2022

david-bakin commented at 2:02 am on August 7, 2022: none

Looks good to me. Feel free to squash the “address PR comments” commit.

Squash done.

jonasnick commented at 3:12 pm on August 16, 2022: contributor

ACK 5c85131cfff22f7116eec6a93b9cfb5567373bf9 (conditional on another coauthor’s ACK).

jackromo888 approved

scgbckbone approved

scgbckbone commented at 12:57 pm on January 12, 2023: contributor

very helpful addition!!

in bip-0341.mediawiki:140 in 5c85131cff

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.

ajtowns commented at 1:08 pm on January 12, 2023:

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 (SIGHASH_DEFAULT, encoded as ‘‘0x00’’) the sighash byte is omitted from the encoding entirely, resulting in a 64-byte signature.

?

scgbckbone commented at 1:13 pm on January 12, 2023:

or just replace can with must?

Can confirm that 65bytes sig with 0x00 appended is considered invalid for bitcoind (v24.0)

sipa commented at 3:13 pm on January 12, 2023:

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.

david-bakin commented at 8:33 pm on April 26, 2024:

I will make it explicit, give me a minute.

murchandamus commented at 8:27 pm on April 26, 2024: contributor

What’s the status of this PR? I see one ACK conditional on another author agreeing, all authors have commented, but it’s not clear to me whether they are supportive of this change. Can you please clarify @sipa, @ajtowns?

sipa commented at 8:31 pm on April 26, 2024: member

I’d like to see #1330 (review) addressed. The text still seems to imply that the omission is optional for SIGHASH_DEFAULT.

vostrnad commented at 8:38 pm on April 26, 2024: contributor

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.

david-bakin commented at 9:13 pm on April 26, 2024: none

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 (and SIGHASH_DEFAULT assumed). (This ensures that there are not two valid formats for the same SIGHASH_DEFAULT signature: with and without the 0x00 sighash byte.)

sipa commented at 9:20 pm on April 26, 2024: member

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_DEFAULT mode is implied.

david-bakin commented at 9:29 pm on April 26, 2024: none

@david-bakin What about just:

This sighash byte is optional. If omitted the resulting signatures are 64 bytes, and a SIGHASH_DEFAULT mode is implied.

OK by me.

murchandamus commented at 1:37 pm on April 29, 2024: contributor

Do I understand right, that the next step is that @david-bakin will update the PR to adopt the phrasing suggested by @sipa?

murchandamus added the label PR Author action required on May 8, 2024

5twelve approved

murchandamus commented at 8:24 pm on November 14, 2024: contributor

Is anyone still working on this?

BIP-341: Explain the 64-byte signature format #1330