[BIP draft] Unspendable Internal Keys for Wallet Policies

[2099999997690000]

Hi all,

Resending with the correct subject; the proposal is unchanged. Apologies for the duplicate.

Pursuant to the discussions about standardizing an unspendable NUMS key for an script path only taproot policy https://delvingbitcoin.org/t/unspendable-keys-in-descriptors/304 and https://github.com/bitcoin/bips/pull/1746 ; we undertook the issue with these guiding principles:

1. We don't police adherence to other bips except when they directly affect the issue at hand.
2. We use the already in place mechanisms in other bips.
3. We don't claim semantic canonicalization of the script and only normalize the policy to some opinionated extent.
   
   

The gist is, we define _​ as a placeholder for the unspendable NUMS key. We sort keys inside musig(...) and sortedmulti_a. We sort sibling pairs of the tree. If there is multipath extension, we add the same length tuple to the _​ so that we don't fall to reuse. Then we pull the keys out and us @i​ placeholders and hash the whole thing consisting of the normalized descriptor and the keys. That would be the chain code for the H​ defined in BIP 341.

The details can be found here:

https://github.com/bitryonix/bips/blob/bip-xxxx-unspendable-internal-keys/bip-xxxx-unspendable-internal-keys.mediawiki

Best,

NTL

[duncan0k]

Hi NTL,

One property of this construction that isn't in the Motivation or
Security sections, and which I think is worth stating: it makes
script-path-only Taproot outputs *provably* so after the fact, to
anyone handed the policy -- and that has a post-quantum use.

Under current rules a CRQC that solves Q can key-path spend any P2TR
output regardless of how Q was built; on-chain, a tweaked NUMS key
and a bare untweaked key are indistinguishable. So for rescue
mechanisms of the shape "prove the key path was never spendable,
then recover via script path", the question is whether the holder
can produce evidence the attacker cannot. With an ad-hoc r the
holder can show r, but a rescue rule can't specify one uniform
verification, and r is one more thing to have kept. With this BIP
the evidence is the policy itself: recompute the chain code, derive
the internal key from H, rebuild Q. The attacker holds q but not the
policy, so cannot produce it. Your Security section already notes
that anyone can verify derivation from H; the PQ angle is that the
*policy* becomes the secret whose knowledge a rescue rule can demand.

The versioned tag leaves room for such a rule to pin a version. It
may be worth a sentence in Motivation, since it is a reason to adopt
beyond interoperability.

This came up in the exposure-classification thread [1], where
conduition raised holder-provability for P2TR; the two pieces of
work look complementary.

duncan0k

[1] https://gnusha.org/pi/bitcoindev/010001a06dd4cdd9-b8082042-8750...@email.amazonses.com/