From: "'duncan0k' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: bitcoindev@googlegroups.com
Cc: conduition@proton.me
Subject: Re: [bitcoindev] Standardizing public key exposure classification for existing outputs
Date: Tue, 8 Sep 2026 03:53:47 +0000 [thread overview]
Message-ID: <010001a07f268952-f2dff00c-20e0-4c9f-8a8b-344a35df0c6b-000000@email.amazonses.com> (raw)
In-Reply-To: <9QUT0_vQUMszAr1ZQw9EsjX9S-gnVFJDD7g4eYgeovhYaOu84nmqJUs8vuDtaPSexGIKkiG3xNpo_jEnVMeJPSnxARXvcOah5jujNBBOdeU=@proton.me>
Hi conduition,
Thanks for engaging with the substance despite your reservations.
Answering the disclaimer straight first:
> Disclaimer: I haven't read the draft BIP; it appears to be
> AI-generated.
Partially fair, so I'll be precise about it: I used an LLM to help
draft the English text, and I won't pretend otherwise. What I'd push
back on is the implication that the content is machine-generated.
The classification was extracted from a scanner running in
production against mainnet; the fail-closed rules each correspond to
a failure mode we actually hit (truncated indexer history, the P2PK
blind spot of address-indexed APIs); the v0.2.0 revisions came from
review finding real holes. The test vectors are independently
verifiable either way. If the prose style gets in the way of review,
I'll rewrite it plainer -- the semantics are what I'm asking people
to check.
> My work on DropKick and Tadge Dryja's work on Lifeboat are both
> contingent on this source of truth
This is the kind of consumer I hoped existed. I'd like to understand
what shape DropKick needs: per-output levels at a given height? A
committed set? That determines whether script-level classification
is sufficient or an outpoint-level profile is needed.
> Would every full node go back and reindex the entire chain to
> collect a list of exposed pubkeys/addresses?
The draft deliberately stops at semantics -- what conclusion is
sound given what data -- so it doesn't presuppose any index. The
constant-time floor exists for implementations that only have
aggregate spent-counts. A node-level exposure index (or the
address-index drive-by) would be the natural next layer, and worth
its own thread; the semantics shouldn't depend on it.
> I would check out Project Eleven's dashboard
I have -- the RISQ list is the closest prior art I know of. The gap
it leaves is that a dashboard applies a methodology; it doesn't
specify one that implementations can be checked against. Different
tools citing 25%-34% is the symptom.
> If you consider the internal key + MAST root to be a preimage,
> then no: P2TR is actually usable without exposing that preimage
I think we're answering two different questions, and the draft
should name both. Mine: can a CRQC spend it under current consensus
rules? For P2TR yes -- solving the dlog of Q yields a key-path
spend; the attacker never needs P or the MAST root. Yours: does the
holder retain a secret a CRQC lacks, usable under a future rescue
encumbrance ("prove knowledge of the internal key")? For
BIP341-conformant outputs yes -- and your own point that some
outputs may be bare untweaked keys, indistinguishable on-chain, is
exactly why any such rescue confiscates an unknown fraction, and why
the draft classifies by attacker-spendability (observable) rather
than rescue-provability (not). I'll add a note distinguishing the
two, crediting this exchange.
> I would say "unexposed" for this. The signer definitely knows
> something (a script) that the CRQC doesn't.
I believe we agree on substance and my naming misled you -- useful
signal in itself. That case is EXPOSED_ON_SPEND in the draft,
defined as "not disclosed; spending will necessarily publish key
material" -- safe at rest, your reasoning exactly. NOT_EXPOSED is
reserved for outputs whose spend reveals nothing reusable (P2MR
script paths). If EXPOSED_ON_SPEND reads as "already exposed", the
label is doing harm; EXPOSED_WHEN_SPENT may be better. Open to
suggestions.
> I strongly doubt we can do much about off-chain exposure.
Agreed -- the draft scopes it out for that reason. The levels state
what the chain shows, nothing more.
I'll fold the P2TR note and the naming question into v0.3.0.
duncan0k
--
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/010001a07f268952-f2dff00c-20e0-4c9f-8a8b-344a35df0c6b-000000%40email.amazonses.com.
next prev parent reply other threads:[~2026-09-08 4:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 19:10 [bitcoindev] Standardizing public key exposure classification for existing outputs 'duncan0k' via Bitcoin Development Mailing List
2026-09-07 20:53 ` 'conduition' via Bitcoin Development Mailing List
2026-09-08 3:53 ` 'duncan0k' via Bitcoin Development Mailing List [this message]
2026-09-14 21:04 ` 'duncan0k' via Bitcoin Development Mailing List
2026-09-18 10:38 ` 'duncan0k' via Bitcoin Development Mailing List
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=010001a07f268952-f2dff00c-20e0-4c9f-8a8b-344a35df0c6b-000000@email.amazonses.com \
--to=bitcoindev@googlegroups.com \
--cc=conduition@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