BIP-322: add clarifications and more test vectors #2136

guggero commented at 3:43 PM on April 9, 2026: contributor

While implementing a Golang implementation of BIP-322, I noticed a couple of things that weren't super clear.

I also added more test vectors for both the "simple" and "full" variants.

in bip-0322.mediawiki:40 in 675040175d

  35 | +! Full
  36 | +! Full (PoF)
  37 | +|-
  38 | +| Compatible script types
  39 | +| <code>P2PKH, P2SH-P2WPKH, P2WPKH</code>
  40 | +| <code>P2WPKH, P2WSH&#42;, P2TR&#42;</code> (&#42; excluding time lock scripts)

murchandamus commented at 5:23 PM on April 9, 2026:

I don’t think that’s what you were going for:

The Unicode Decimal Code is rendered as written, due to the code formatting. In Mediawiki, asterisks are only semantically relevant as the symbol for starting an unordered list item. So, if I’m not mistaken, the following should render as intended:

| <code>P2WPKH, P2WSH*, P2TR*</code> (* excluding time lock scripts)

guggero commented at 6:59 PM on April 9, 2026:

Yeah, fixed in a later commit but now also fixed in the transposed version.

in bip-0322.mediawiki:49 in 675040175d outdated

  44 | +| Signature format
  45 | +| compact, public key recoverable ECDSA signature, base64-encoded
  46 | +| witness stack, consensus encoded and base64-encoded
  47 | +| full <code>to_sign</code> transaction, consensus and base64-encoded
  48 | +| full <code>to_sign</code> transaction, consensus and base64-encoded
  49 | +|}

murchandamus commented at 5:32 PM on April 9, 2026:

I found this table hard to read as presented and it would make more sense to me if it were transposed:

{| class="wikitable"
|- style="font-weight:bold;"
!
! Compatible script types
! Signature format
|-
| Legacy
| <code>P2PKH, P2SH-P2WPKH, P2WPKH</code>
| compact, public key recoverable ECDSA signature, base64-encoded
|-
| Simple
| <code>P2WPKH, P2WSH*, P2TR*</code> (* excluding time lock scripts)
| witness stack, consensus encoded and base64-encoded
|-
| Full
| <code>all</code>
| full <code>to_sign</code> transaction, consensus and base64-encoded
|-
| Full (PoF)
| <code>all</code>
| full <code>to_sign</code> transaction, consensus and base64-encoded
|}

guggero commented at 6:59 PM on April 9, 2026:

Yeah, you're right. Looks better this way, thanks a lot for the transposition!

in bip-0322.mediawiki:183 in 675040175d outdated

 203 | -
 204 | -to_spend:
 205 | -
 206 | -* Message = "" (empty string): <code>c5680aa69bb8d860bf82d4e9cd3504b55dde018de765a91bb566283c545a99a7</code>
 207 | -* Message = "Hello World": <code>b79d196740ad5217771c1098fc4a4b51e0535c32236c71f1ea4d61a2d603352b</code>
 208 | +Basic test vectors for message hashing, transaction hashes and "simple" variant test cases can be found [[bip-0322/bip322.json|here]].

murchandamus commented at 5:39 PM on April 9, 2026:

Please use a meaningful content in the link texts to improve readability, e.g.:

Basic test vectors for message hashing, transaction hashes and "simple" variant test cases can be found in [[bip-0322/bip322.json|bip322.json].

or

Basic test vectors for message hashing, transaction hashes and "simple" variant test cases can be found in the [[bip-0322/bip322.json|test vector file]].

Perhaps file names based on the content rather than the creation method such as basic-test-vectors.json and full-signing-test-vectors.json would be more meaningful than just repeating the BIP number.

guggero commented at 7:00 PM on April 9, 2026:

Makes sense, fixed.

guggero force-pushed on Apr 9, 2026

in bip-0322.mediawiki:185 in 675040175d

 206 | -* Message = "" (empty string): <code>c5680aa69bb8d860bf82d4e9cd3504b55dde018de765a91bb566283c545a99a7</code>
 207 | -* Message = "Hello World": <code>b79d196740ad5217771c1098fc4a4b51e0535c32236c71f1ea4d61a2d603352b</code>
 208 | +Basic test vectors for message hashing, transaction hashes and "simple" variant test cases can be found [[bip-0322/bip322.json|here]].
 209 |  
 210 | -to_sign:
 211 | +Generated test vectors for "full" variant test cases can be found [[bip-0322/bip322-generated.json|here]].

murchandamus commented at 5:40 PM on April 9, 2026:

Generated test vectors for the "full" signing variant can be found in [[bip-0322/bip322-generated.json|bip322-generated.json]].

guggero force-pushed on Apr 9, 2026

murchandamus commented at 5:44 PM on April 9, 2026: member

cc: @kallewoof for sign-off

murchandamus added the label Proposed BIP modification on Apr 9, 2026

murchandamus added the label Pending acceptance on Apr 9, 2026

guggero force-pushed on Apr 9, 2026

guggero requested review from murchandamus on Apr 9, 2026

guggero commented at 7:07 PM on April 9, 2026: contributor

I think we might be able to change the test vectors to just a single signature if we get clarity on https://github.com/bitcoin/bitcoin/pull/24058#discussion_r3059008676. I suspect that buidl-python either derives a sub-key from a WIF (what does it use as the chain code in that case?) or just interprets the private key in a WIF differently. IMO there shouldn't be the need for two different valid signatures being defined in a BIP.

in bip-0322.mediawiki:37 in 2b051e285c

  32 | +!
  33 | +! Compatible script types
  34 | +! Signature format
  35 | +|-
  36 | +| Legacy
  37 | +| <code>P2PKH, P2SH-P2WPKH, P2WPKH</code>

kallewoof commented at 5:48 AM on April 10, 2026:

This should only list P2PKH, I think. See "Legacy" section below in which it states

The legacy format MAY be used, but must be restricted to the legacy P2PKH invoice address format.

guggero commented at 7:09 AM on April 10, 2026:

Yes, I see what you mean. My intention was to show what's possible with the different variants. But we should discourage using the legacy format, I agree. I added a clarification hint, I hope that makes it clearer and also more readable.

in bip-0322/generated-test-vectors.json:2 in 2b051e285c

   0 | @@ -0,0 +1,181 @@
   1 | +{
   2 | +  "tx_hashes": null,

kallewoof commented at 5:51 AM on April 10, 2026:

Can this be removed since it's null? Or is this here to demonstrate that the tx hash is not forgotten but intentionally not set?

guggero commented at 7:09 AM on April 10, 2026:

Just an artifact of the JSON serialization. Removed.

kallewoof commented at 5:53 AM on April 10, 2026: contributor

LGTM. Two nits, feel free to disregard.

guggero force-pushed on Apr 10, 2026

BIP-0322: add format clarification table

This commit adds a table that clarifies what script types are compatible
with what signing variant and also makes more clear what the exact
format for the signatures of the different variants are.

4d36f73e7b

BIP-0322: clarify scriptSig on to_sign for legacy transactions

Before this commit it was not clear that non-native SegWit outputs
(e.g. P2PKH or P2SH-P2WPKH) only work if the correct scriptSig is
provided.
This then also makes it more clear why P2SH-P2WPKH outputs are NOT
supported by the "simple" variant.

805bb0b6fc

BIP-0322: turn test vectors into JSON, add more

This commit turns the existing test vectors into a JSON and then adds
more test cases covering the most common script types.

3ab70c98a7

guggero force-pushed on Apr 10, 2026

guggero commented at 7:09 AM on April 10, 2026: contributor

I added some negative test cases as well.

kallewoof commented at 8:17 AM on April 10, 2026: contributor

I didn't look at the test cases, but LGTM otherwise.

murchandamus removed the label Pending acceptance on Apr 10, 2026

murchandamus commented at 11:46 PM on April 10, 2026: member

Text looks good to me. Per cursory glance a lot of the same strings make an appearance in the basic test vectors. Seems fine for Draft. Any potential issues with the test vectors would presumably be found when other people use them. @kallewoof, @guggero: With the renewed interest in BIP 322 recently, is either of you interested in working on moving this proposal toward Deployment? I seem to remember there were potentially a couple open questions raised either on the Bitcoin Core PR or in a PR here. If either of you is going to work more on this, and you are not aware of what I mean, I could dig around to find it again.

murchandamus merged this on Apr 10, 2026

murchandamus closed this on Apr 10, 2026

guggero commented at 5:57 AM on April 11, 2026: contributor

With the renewed interest in BIP 322 recently, is either of you interested in working on moving this proposal toward Deployment?

Yes, definitely. I don't have any experience with the BIP process yet, but I'm going to read up on it to find out what the required steps for getting a BIP finalized are.

I'll also go through the Bitcoin Core PR to see what the open questions were.

My plan is also to add a section to the BIP that describes how PSBTs can/should be used in a multisig scenario to collaboratively create a valid full signature. Currently it looks like we'd require a new global or per-input PSBT field that contains the message to sign, so signers can present it to the user when co-signing (which IMO is very important for hardware wallets, otherwise they would just show you the "sign transaction" UI with very confusing inputs and outputs).

I'll create another PR soon, unless you think this is the wrong approach, then please let me know now.

guggero deleted the branch on Apr 11, 2026

murchandamus commented at 5:58 PM on April 11, 2026: member

No, that sounds great, @guggero. Please check out BIP 3 for more information on the BIP Process. And yeah, check out the Bitcoin Core PR. You may also find these conversations interesting: