BIP-0322: name taproot upgrade mechanisms in the upgradeable rules #2336

pull fametrano wants to merge 1 commits into bitcoin:master from fametrano:bip322-taproot-upgradeable changing 1 files +5 −2

fametrano commented at 4:33 AM on October 23, 2026: contributor

BIP322's upgradeable rules do not name four taproot upgrade mechanisms, so a verifier that follows the text calls a signature using one of them valid. This adds one rule naming them: an unknown leaf version and the annex (BIP341), OP_SUCCESSx and an unknown public key type (BIP342). Such a signature then gets the inconclusive state, as reserved NOPs and segwit versions above 1 already do. The version becomes 3.0.0: as with 2.0.0 in #2188, some signatures that were valid no longer are.

The BIP322 library in btcd#2521 already returns inconclusive for all four, and the gap was raised in its review. I ran its test vectors through btclib-wallet, a verifier I maintain: it agreed on three of the four and called the annex case valid, as the current text says.

cc @guggero @kallewoof

BIP-0322: name taproot upgrade mechanisms in the upgradeable rules

The upgradeable rules list the to_sign version, NOPs reserved for
upgrades and segwit versions above 1. BIP341 and BIP342 also reserve
unknown leaf versions, OP_SUCCESSx, unknown public key types and the
annex for upgrades. A verifier that follows the BIP322 text calls a
signature using any of them valid. Name them, so that these give the
inconclusive state like the other upgrade mechanisms.

Some signatures that were valid become inconclusive, so bump the
version to 3.0.0, as #2188 did for 2.0.0, and add a changelog entry.
Add 342 to Requires.

c86595ba9b

saeidas582-lab commented at 5:28 AM on October 23, 2026: none
سلام من یک ایرانی هستم میتونی کمکم کنی بیت کوین گیرم بیاد

در تاریخ جمعه ۲۳ اکتبر ۲۰۲۶،‏ ۸:۰۶ Ferdinando Ametrano < @.***> نوشت:
BIP322's upgradeable rules do not name four taproot upgrade mechanisms, so a verifier that follows the text calls a signature using one of them valid. This adds one rule naming them: an unknown leaf version and the annex (BIP341), OP_SUCCESSx and an unknown public key type (BIP342). Such a signature then gets the inconclusive state, as reserved NOPs and segwit versions above 1 already do. The version becomes 3.0.0: as with 2.0.0 in #2188 https://github.com/bitcoin/bips/pull/2188, some signatures that were valid no longer are.

The BIP322 library in btcd#2521 https://github.com/btcsuite/btcd/pull/2521 already returns inconclusive for all four, and the gap was raised in its review https://github.com/btcsuite/btcd/pull/2521#discussion_r3343915648. I ran its test vectors through btclib-wallet, a verifier I maintain: it agreed on three of the four and called the annex case valid, as the current text says.

cc @guggero https://github.com/guggero @kallewoof https://github.com/kallewoof

You can view, comment on, or merge this pull request online at:

#2336 Commit Summary

c86595b https://github.com/bitcoin/bips/pull/2336/commits/c86595ba9b94779a37ca4ae8a9a78111bee6de88 BIP-0322: name taproot upgrade mechanisms in the upgradeable rules

File Changes

(1 file https://github.com/bitcoin/bips/pull/2336/files)

M bip-0322.mediawiki https://github.com/bitcoin/bips/pull/2336/files#diff-4faedf051c0baabc4ce61929f0baa82db49ecbf9a3ad5d07eef98fcf05ae09f3 (7)

Patch Links:

#2336.patch

#2336.diff

— Reply to this email directly, view it on GitHub https://github.com/bitcoin/bips/pull/2336?email_source=notifications&email_token=CRIRNT66CIU6QXS377ZAFB35VLN3FA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF42DSNZXHA2TIMRXGOTHEZLBONXW5KTTOVRHGY3SNFRGKZFFMV3GK3TUVRTG633UMVZF6Y3MNFRWW, or unsubscribe https://github.com/notifications/unsubscribe-auth/CRIRNT6LXSOV2XO3HQDILRL5VLN3FAVCNFSNUABEKJSXA33TNF2G64TZHMYTINJTGE3TGNZ3JFZXG5LFHM2TSOJRHEZTSNRQGSQXMAQ . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS https://github.com/notifications/mobile/ios/CRIRNT6CEPR22GIH7IZJLHT5VLN3FA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF42DSNZXHA2TIMRXGOTHEZLBONXW5KTTOVRHGY3SNFRGKZFFMV3GK3TUVJTG633UMVZF62LPOM and Android https://github.com/notifications/mobile/android/CRIRNT6OXLDU454L6J7YIIL5VLN3FA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF42DSNZXHA2TIMRXGOTHEZLBONXW5KTTOVRHGY3SNFRGKZFFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE. Download it today! You are receiving this because you are subscribed to this thread.Message ID: @.***>
jonatack added the label Proposed BIP modification on Oct 23, 2026
jonatack added the label Pending acceptance on Oct 23, 2026
in bip-0322.mediawiki:495 in c86595ba9b
```
 491 | @@ -491,6 +492,8 @@ and many others for their feedback on the specification.
 492 |  
 493 |  == Changelog ==
 494 |  
 495 | +* '''3.0.0''' (2026-10-23):
```
guggero commented at 6:05 AM on October 23, 2026:

IMHO we could go with a minor version change here. From BIP3:

The MINOR version is incremented whenever the specification of the BIP is changed or extended in a backward-compatible way.

The clarified taproot rules are themselves called "upgrade mechanisms", which, in the spirit of the spec as written, would implicitly fall into the upgradeable rules category. This clarification just makes the rules explicit to avoid confusion.

I will add/update the test vectors of BIP322 once the Golang implementation is finalized/merged. That implementation and vectors also share the current interpretation that this change turns into explicit rules.

But, since this is more about the BIP process that the content, I'm deferring to the maintainers' opinion (cc @murchandamus, @jonatack) here.
guggero commented at 6:09 AM on October 23, 2026: contributor

ACK c86595ba9b94779a37ca4ae8a9a78111bee6de88, subject to possibly changing the version bump to minor.
kallewoof commented at 6:59 AM on October 23, 2026: contributor

ACK. Agree on this being a minor version bump.

Contributors

Labels

Proposed BIP modification Pending acceptance

Linked (view graph)

#2188 BIP-0322: remove address optionality for PoF

BIP-0322: name taproot upgrade mechanisms in the upgradeable rules #2336

cc @guggero https://github.com/guggero @kallewoof https://github.com/kallewoof