* [bitcoindev] [BIP draft] Unspendable Internal Keys for Wallet Policies
@ 2026-09-09 18:41 '2099999997690000' via Bitcoin Development Mailing List
2026-09-11 4:16 ` 'duncan0k' via Bitcoin Development Mailing List
0 siblings, 1 reply; 2+ messages in thread
From: '2099999997690000' via Bitcoin Development Mailing List @ 2026-09-09 18:41 UTC (permalink / raw)
To: bitcoindev@googlegroups.com
[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]
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:
- We don't police adherence to other bips except when they directly affect the issue at hand.
- We use the already in place mechanisms in other bips.
- 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
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ToQA7AIlDQoaVhHUgpy0MjUEy5FYvYQL1d1Lr_xgmIpEcjYBhuT2JkEDNddmPa-qgIziEzHcGS9bHreVXUHLaSqDTjQtREHXkchtjphDbxQ%3D%40proton.me.
[-- Attachment #2: Type: text/html, Size: 3578 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [bitcoindev] [BIP draft] Unspendable Internal Keys for Wallet Policies
2026-09-09 18:41 [bitcoindev] [BIP draft] Unspendable Internal Keys for Wallet Policies '2099999997690000' via Bitcoin Development Mailing List
@ 2026-09-11 4:16 ` 'duncan0k' via Bitcoin Development Mailing List
0 siblings, 0 replies; 2+ messages in thread
From: 'duncan0k' via Bitcoin Development Mailing List @ 2026-09-11 4:16 UTC (permalink / raw)
To: bitcoindev; +Cc: 2099999997690000
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-4e9a-917e-2053c919e4c4-000000@email.amazonses.com/
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/010001a08eaeac21-65cd8340-8efe-45da-9a59-9bf2af00f538-000000%40email.amazonses.com.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-09-14 20:54 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-09 18:41 [bitcoindev] [BIP draft] Unspendable Internal Keys for Wallet Policies '2099999997690000' via Bitcoin Development Mailing List
2026-09-11 4:16 ` 'duncan0k' via Bitcoin Development Mailing List
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox