From: "'duncan0k' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: bitcoindev@googlegroups.com
Cc: 2099999997690000@proton.me
Subject: Re: [bitcoindev] [BIP draft] Unspendable Internal Keys for Wallet Policies
Date: Fri, 11 Sep 2026 04:16:47 +0000 [thread overview]
Message-ID: <010001a08eaeac21-65cd8340-8efe-45da-9a59-9bf2af00f538-000000@email.amazonses.com> (raw)
In-Reply-To: <ToQA7AIlDQoaVhHUgpy0MjUEy5FYvYQL1d1Lr_xgmIpEcjYBhuT2JkEDNddmPa-qgIziEzHcGS9bHreVXUHLaSqDTjQtREHXkchtjphDbxQ=@proton.me>
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.
prev parent reply other threads:[~2026-09-14 20:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=010001a08eaeac21-65cd8340-8efe-45da-9a59-9bf2af00f538-000000@email.amazonses.com \
--to=bitcoindev@googlegroups.com \
--cc=2099999997690000@proton.me \
--cc=duncan0k@cipherscope.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox