Bitcoin draft proposes reproducible Taproot internal keys derived from wallet policies

An open submission, with no adoption announced

A pull request opened November 1, 2026 in Bitcoin's improvement-proposal repository presents a convention for wallet Taproot internal keys. Numbered 2340 on GitHub, it remains open and unmerged when checked. That number identifies the pull request, not an assigned BIP number. The document is marked Draft and seeks to make a construction reproducible by different software from the same wallet policy.

The proposed placeholder is an underscore, used instead of an internal key with no known signing key. This concerns a particular Taproot spending path, rather than preventing all bitcoin in the wallet from being spent. The other conditions specified in scripts remain decisive. The draft explicitly says constructing this key does not exempt software from separately checking the surrounding policy's validity and requirements.

Recreating the construction without another random secret

The stated problem concerns wallets that want to make this internal path unusable while avoiding a fixed key recognizable when a spend reveals the corresponding data. Some approaches use a random value that must then be retained. The draft instead proposes deriving public parameters from a normalized form of the policy. Two implementations could then reproduce the internal key from that policy and the derivation path, without backing up that additional secret.

The construction uses existing mechanisms, including BIP 32 extended keys and a point described in BIP 341 with an unknown discrete logarithm. Its cryptographic commitment covers both keys and policy structure: thresholds, timelocks, roles and tree arrangement. The aim is to distinguish policies using the same keys under different conditions. It does not claim every set of rules producing equivalent results would automatically be recognized as identical.

Backups still require the policy

That reproducibility has limits. The document says a seed backup alone does not reconstruct the wallet policy. It also explains that an observer knowing or guessing the complete policy could reconstruct public parameters and enumerate some internal keys. The proposal therefore guarantees no absolute privacy. Its security depends in particular on the cryptographic assumption concerning the starting point and exact compliance with derivation rules.

Adopting this convention would change an existing policy's addresses. The draft consequently requires treating the result as a separate descriptor and retaining the original to watch and spend funds received earlier. A Python implementation and test vectors accompany the request, but their stated purpose is demonstration and interoperability, not production use. Today's submission opens a technical review; it establishes neither collective approval, universal compatibility nor deployment in wallets.