Unspendable keys in descriptors

The need for robust spending policies—often necessitated by requirements like timelocks or complex conditions not expressible via standard keypaths—drives the exploration of unspendable keys that are indistinguishable from ordinary keys, unique per usage, easily recognizable within descriptors, and require minimal additional entropy for usability with signing devices.

Multiple strategies for generating such keys have been proposed and evaluated. A straightforward but limited solution involves using a fixed, well-known unspendable xpub, which meets some functional criteria but fails to prevent fingerprinting and may expose the unspendable nature to external observers. More sophisticated approaches leverage root xpubs with random chaincodes, aligning more closely with desired properties at the cost of introducing extra entropy into user workflows. BIP-0341 suggests constructing public keys from NUMS (Nothing-Up-My-Sleeve) points, furthering the goal of indistinguishability and by extension, privacy. An innovative direction recycles entropy from descriptor contents or taptree structures, proposing deterministic derivation of unspendable xpubs via hashing schemes over involved public keys—a concept that can be integrated into both wallet policies and output descriptors to different degrees depending on their explicitness and flexibility.

The debate over standardizing a public NUMS is particularly pronounced, given its implications for protocols like BIP352 (silent payments), where provably unspendable keypaths enhance privacy and interoperability. Standardization simplifies protocol design and implementation, providing a common reference point for verification across platforms. However, it also raises nuanced privacy concerns. If revealing an internal key as part of a script-only Taproot spend immediately signals the presence of a script path, privacy could be compromised. Therefore, the adoption of a standard NUMS must be carefully considered against potential scenarios where predictability might expose transaction participants or reduce fungibility.

Technical discussions have highlighted the importance of maintaining order independence when deriving chaincodes from xpubs, especially in multi-signature arrangements. Solutions include sorting xpubs prior to concatenation and hash, or combining individually hashed xpubs via XOR or modular addition, with safeguards to prevent repeated xpubs from nullifying each other’s contribution. These methods aim to secure the process against malicious manipulation without sacrificing efficiency. Further, there is consensus that only xpubs following the xpub//* pattern should be permitted in wallet policies for Taproot, streamlining implementation and reducing ambiguity, though this restriction impacts legacy wallet workflows relying on optional derivation paths.

Wallet policies and output descriptors, while related, serve distinct roles and thus demand tailored handling of entropy and key representation. Output descriptors benefit from explicitly stated entropy sources, ensuring determinism and transparency, whereas wallet policies can infer such data from their content, promoting a leaner structure. The evolving standardization efforts, such as those encapsulated in BIP-0388 and recent proposals (GitHub BIP Draft), reflect the ongoing refinement of these distinctions and the pursuit of greater security and ease of use.

A notable cryptographic innovation is the NUMS key generator and validator adhering to BIP-0341 methods, which enables keys constructed as H + r*G to be proven as NUMS-based by disclosing the scalar r. This allows for verifiability without compromising secrecy and could further evolve to permit signature generation without revealing underlying secrets, as discussed by Pieter Wuille (@sipa). Practical demonstrations, including a working key path and live transaction records, are accessible via Jaonoctus's NUMS-secp256k1 and Mempool's Signet transaction detail page, respectively.

Recent developments toward standardizing the use of a dedicated placeholder (_) for unspendable NUMS keys in script-only Taproot policies aim to prevent accidental key reuse and clarify transaction construction. Keys are systematically organized within functions like musig(.) and `