From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 07 Sep 2026 14:04:28 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x3gVv-0008AC-H0 for bitcoindev@gnusha.org; Mon, 07 Sep 2026 14:04:28 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-44aeefa1c36sf2289895fac.3 for ; Mon, 07 Sep 2026 14:04:26 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1788815061; cv=pass; d=google.com; s=arc-20260327; b=AzZjapz2XmZobpah2cLD39VV8DowCppPMkZNns/XCvMsF5D87wT10a2q1Y4oyNmnx7 Q6tTzau7ejE07OuqJ5RP9y3MLn52TLLj3i0+0g7i8zsr2nB5Rb5iYqKVPFClOaeYFVAr kDWrbnB5cmXgS5dr7idLK4LjxjSqMcidVMCh6fgHB2QgzaIDhGxf6pE5S/YQ347BytcN ZPUd2XAT3Zvhn1zPakFaG2Ksdkq2qsoHZFJYeh1qyW83R7rhkqFuny8SOfbWNHV/7tAO L0uZWAOScRlokjZbV1OAr3x3ot4/lhN88mXYELeVuuNUUpZNI9k+YQGtBluocIQvTiJD ikDA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=jgsjBYEdcHbEST/CaynZJYKXv1kh/9LUpOQ3kZdn2A4=; fh=7Bk1PEIZuyQTYCX9LJ0oaML/8lhr7IDo6lwRi4t8NJ0=; b=bqVpOFvc1T2ENyp7jktHm1nMW3mpS6MsNkvPmNVtcnzJItNTvYpJ6M+NwAYtOooatq tE49vZO2TfYVWEqZtELfr9ppIzmq/374kpsN6igmDiY+KaHkaEweJDb0lgVFO7kMRjgx ZCMM2QC3fGHtuh19GrSHj6LMEindwq3/lYHN0srCMJdblhM5q7h5jybmAb/KHx5rePcS zSWl6zDWfaZEoRJ35YvBjw4ZV8+zQD6OumwjsyGr1HV4CCwsPOV5vIAZq5l7y/fszCjT p2v2LkHPmgQ16ZNWacgiGoie4O4fcjLAakDJ3dut11mALzQ68IYF0vVWBg+QrKHSVulb V4fg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=U0LvPCJi; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.24 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1788815061; x=1789419861; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=jgsjBYEdcHbEST/CaynZJYKXv1kh/9LUpOQ3kZdn2A4=; b=wc/AU64HvaFaiPWJ4vOpKRaTemiWcfsaCRwqVcpf3M8HyvcbgA+capVDUFps5r+JJP Urt8BCFESU+RyePb97+rwmmvdrguEHeu551WKePd8rJkXYeLUKeB6Ihrs6xc/aSi4yFR 79yHO+jj0XSv6hDNXztPgWRbp/SDCXP19lXiVxNQ0BnlO+uDRrMcSzsjxdsu5hOkT4RJ 8swUrKsyyuiC3QOkGw4COEmIaEWsc/yCEOpDM5w2FymmUMyRDaSxAD2rdNCNkilYNxP9 wUGIPMcTmQ7C3tyLydkmwtDN/WYR+4GY/EPUdv+QnzYaU+N26FekEpQa1LdmALDJ516c 4PMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788815061; x=1789419861; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:x-beenthere:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=jgsjBYEdcHbEST/CaynZJYKXv1kh/9LUpOQ3kZdn2A4=; b=q6CPOwlu+yUEjg/975SvQr4Rr3a2H/f8ZTAlGeJ0xtpd2mHDf6fV9suwvW/64xAmcH Dts6ulGfEjx7kF/oQP8Wzcpur1LaNHADZZxqNkYBadAlrbBMADiGogd18AqdYIh80TBV xuL2PWAALG5Sgpvmo5bDNC7+M+8ZQhxjvwF54IwCcpB3z/ozZ97QV5JutD13/4lZkiFd tdxF74tApdeOXF8XA3vUCLDH5ExqbjWL4h6Uox+uG/KN6gwdyPobNn8F5Z0+B/Gmpdle 7yL9IrBZcRObLyBqop5BZfBzvgFQGOLDbZQ8XDsPa3kCj06lCJIdJhSV7ahz0XVa9SzR LMQQ== X-Forwarded-Encrypted: i=2; AKwUvBxZluv38DEvP5g59PZCj4CILN8ypLh4C9cK9u7linD/QT0sWySE8EgicB1XkRb+cF1WRPB5c3ga/7WO@gnusha.org X-Gm-Message-State: AFuF++lIn2zuRkytqcukCFtTkP/gx55F6l579nICbg99j+Dy3l7F6zPi iNSiSvzp+64VlG8lKQHUtcYyGKV9t1UkkduBg4+xMCxYWtl9bSX+pq18 X-Received: by 2002:a05:6870:3908:b0:475:a112:126c with SMTP id 586e51a60fabf-475a1124b1dmr13185745fac.25.1788815060949; Mon, 07 Sep 2026 14:04:20 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLde/ziMAtVqSe9GkkMLs5XpJVuMLDapjAXlW98uZzAaIOw==" Received: by 2002:a05:6870:1752:b0:475:98a9:d32a with SMTP id 586e51a60fabf-47598b96de0ls3830326fac.2.-pod-prod-04-us; Mon, 07 Sep 2026 14:04:16 -0700 (PDT) X-Received: by 2002:a05:6808:4f67:b0:4b3:89ae:df60 with SMTP id 5614622812f47-4b967b42b3amr15402744b6e.16.1788815056122; Mon, 07 Sep 2026 14:04:16 -0700 (PDT) Received: by 2002:a05:6808:2009:20b0:495:e116:a399 with SMTP id 5614622812f47-4bbef95ceabmsb6e; Mon, 7 Sep 2026 13:53:20 -0700 (PDT) X-Received: by 2002:a05:6a00:32c4:b0:857:73e2:9107 with SMTP id d2e1a72fcca58-8616c8498dfmr33251102b3a.23.1788814399534; Mon, 07 Sep 2026 13:53:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1788814399; cv=none; d=google.com; s=arc-20260327; b=QRe08QEW6YKY01fiG0/buYgQpcmME4q8Zu2ZhIs1OEa5B8jlx5s48YBjQ/kHyRUYia AGACktS2nMccrGttKxhpgCFrOw/YSHEV/stH1Nf8bokZFQQXi8b+FtzvR8nthgLYNzan XX+chXyN8aVKhjM80xD8/ibT9+/L/aqBrZOW9PehxHnvDxcF6Wnu52IqNEX1C44bV5CQ lYBQMHSWW+OhglfIhGoH9lx8A9I38dr3GVpNgYPKRKjhNMEGnetfjZjf+m7T2HGwjC2q 89Y6fgB86fzjAQyOmqcieix2z8xLHoMmqv+0QgAdMmifaI+By88WTVIlVzzJYHNliymr GxUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=P2RFqKC8QqCwaLfoOOlLg9ctvXcXtr6NMSYbK5nlgxs=; fh=e0V9/H+STYFstLTxFr2LPVeeTQvaqDxWADqw2ZbVVZQ=; b=W07nGzehSzSQVHhLLfQcSi4pGqwc7dLdPsgI1m//215lFbGmF7EpVQaNx7fX3V1CUP LqWvjM96BMPjxNP2OngGBcVeNmB0afNJdAgV3Yt9S7SyXGjTgQfYhDD+LNBKKhHo9pHx tzUmSkY1e4v3bEUNmHd+bJCVayTpFpX5IXpzHrucUusHaHlxHW56vHivx1xz4+Ia6W/r RAc/MeC2xdr/wVotHbyjtmhl2OwvlR6tCPUUqhwKJ6UdY8uX9J+T43BwQ7WTo4hI8E5B 9j5zMg9MgEVbtwp3Fq5zPwJg+MLum+zcxKTDTwL/OYESqVhuK1usStU9PhZjTwr+OM25 jlbQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=U0LvPCJi; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.24 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24424.protonmail.ch (mail-24424.protonmail.ch. [109.224.244.24]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-8644c5ce1a2si179486b3a.7.2026.09.07.13.53.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Sep 2026 13:53:19 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.24 as permitted sender) client-ip=109.224.244.24; Date: Mon, 07 Sep 2026 20:53:13 +0000 To: duncan0k From: "'conduition' via Bitcoin Development Mailing List" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] Standardizing public key exposure classification for existing outputs Message-ID: <9QUT0_vQUMszAr1ZQw9EsjX9S-gnVFJDD7g4eYgeovhYaOu84nmqJUs8vuDtaPSexGIKkiG3xNpo_jEnVMeJPSnxARXvcOah5jujNBBOdeU=@proton.me> In-Reply-To: <010001a06dd4cdd9-b8082042-8750-4e9a-917e-2053c919e4c4-000000@email.amazonses.com> References: <010001a06dd4cdd9-b8082042-8750-4e9a-917e-2053c919e4c4-000000@email.amazonses.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: f5ccc70294e162373a579948d6e7b95549de57f3 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------3959f7ac95b2b2f8fdaa80483e30c29c2371594f0c3bf429a06a4c6191df8917"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=U0LvPCJi; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.24 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------3959f7ac95b2b2f8fdaa80483e30c29c2371594f0c3bf429a06a4c6191df8917 Content-Type: multipart/mixed;boundary=---------------------824569e9f8af76ff50077d31d3f1a75b -----------------------824569e9f8af76ff50077d31d3f1a75b Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Duncan, Disclaimer: I haven't read the draft BIP; it appears to be AI-generated. If= you don't have time to write your own BIP, you should not expect others to= have time to read it. > Before I invest further: is this something the list considers worth > specifying, or is it better left to each implementation?=20 I think it is an important question to answer. A deterministic standardized= way to index what "exposed pubkey" means is beneficial to everyone involve= d in the PQ conversation. My work on DropKick and Tadge Dryja's work on Lifeboat are both contingent = on this source of truth, but nobody has yet spent the cycles to figure out = how that would work. Methodology is still an open problem too. Would every full node go back and= reindex the entire chain to collect a list of exposed pubkeys/addresses? T= hat seems expensive, but at least an upgraded node could start preparing ea= rly, before any fork is activated. Perhaps this is an excuse for bitcoind to finally include an address index?= This would basically solve the engineering problem as a drive-by. > I am also interested in whether anyone has prior art I have missed -- I c= ould > not find a canonical definition, but this is the kind of thing that > gets rediscovered. I would check out Project Eleven's dashboard [2] if you haven't already.=20 > Is a P2TR output exposed at rest? If you consider the internal key + MAST root to be a preimage, then no: P2T= R is actually usable without exposing that preimage, unless you do a script= spend.=20 However, not every P2TR address is guaranteed to HAVE an internal key. Some= non-standard implementations might have disregarded BIP341's recommendatio= ns, and put a bare untweaked pubkey on chain. It's impossible to know for s= ure.=20 Personally I doubt this is a significant share of the P2TR supply - Every c= odebase i've ever seen that implements P2TR does so with an empty tweak, as= recommended by the spec. Still, it means when considering rescue protocols that locking P2TR coins u= nder a new encumbrance that says "you can only spend by proving knowledge o= f the internal key" will confiscate some unknown (probably tiny) fraction o= f P2TR coins. > Is a spent-from P2PKH address that still holds a balance "exposed at rest= " or "exposed on spend"? Exposed at rest, i.e. vulnerable to 'long exposure' attacks. > What should a classifier report for a P2SH/P2WSH output whose script has = never been revealed? I would say "unexposed" for this. The signer definitely knows something (a = script) that the CRQC doesn't. > What about keys disclosed off-chain -- xpubs handed to service > providers, or spends of the corresponding output on a 2017 fork? I strongly doubt we can do much about off-chain exposure. regards, conduition [1]: https://github.com/bitcoin/bips/pull/1895#pullrequestreview-4110112784 [2]: https://www.projecteleven.com/bitcoin-risq-list On Friday, September 4th, 2026 at 12:25 PM, 'duncan0k' via Bitcoin Developm= ent Mailing List wrote: > Hi all, >=20 > I would like to gauge interest in a specification that defines how to > classify an existing Bitcoin output by whether the public key needed to > spend it has already been published on-chain. >=20 > The gap: BIP 360 gives us an output type whose key stays off-chain > until a script-path spend, and BIP 361 proposes a phased sunset of > legacy signature verification. Both assume the ecosystem can answer > "which existing outputs are exposed?" -- but no BIP specifies how that > question is answered. >=20 > Why this is a practical problem: published estimates of the exposed > supply currently range from roughly 25% to over 34%. As far as I can > tell the spread is definitional, not measurement error. Recurring > disagreements: >=20 > - Is a P2TR output exposed at rest? Its 32-byte output key is a public > key, and solving its discrete log yields a working key-path spend > regardless of how the internal key was chosen -- a NUMS internal key > does not help, since consensus never checks how Q was constructed. >=20 > - Is a spent-from P2PKH address that still holds a balance "exposed at > rest" or "exposed on spend"? To an adversary these are the same > situation, but tools label them differently. >=20 > - What should a classifier report for a P2SH/P2WSH output whose script > has never been revealed? >=20 > - What about keys disclosed off-chain -- xpubs handed to service > providers, or spends of the corresponding output on a 2017 fork? >=20 > If BIP 361 or something like it advances, "is this output > legacy-vulnerable" becomes a question asked at scale by wallets, > explorers and custodians, with money attached. Users consulting two > tools should not get two answers about the same coins. >=20 > What the draft does: it specifies four levels -- EXPOSED_AT_REST, > EXPOSED_ON_SPEND, NOT_EXPOSED, UNDETERMINED -- a per-output-type > assignment table, and a fail-closed rule: where data is insufficient > to distinguish two levels, the more-exposed level must be assigned. > Two points I would particularly like feedback on: >=20 > 1. Disclosure mechanism does not change the level. A reused, > spent-from script that retains a balance is EXPOSED_AT_REST, the > same as P2PK. I think separating these invites the reading that > reused addresses are safer than P2PK, which is false. Some existing > tools (including an earlier iteration of my own) do separate them. >=20 > 2. UNDETERMINED is mandatory for unrecognized output types, rather > than defaulting them to unexposed. Any classifier predating a > future output type will encounter outputs it cannot reason about, > and reporting those as safe asserts a property it has not > established. >=20 > The draft also specifies a constant-time floor: if a script's > confirmed spent-output count is greater than zero, a spend has > occurred, and for every type except P2MR that publishes the material > the script commits to. This is what prevents a truncated history scan > from producing a false NOT_EXPOSED -- without it, every implementation > independently decides what to report when it runs out of scan budget, > and the divergence reappears at the engineering layer. (The one > over-approximation -- a revealed script that requires no signature -- > errs in the conservative direction, which the fail-closed rule > permits; see the v0.2.0 changelog.) >=20 > Explicitly out of scope: risk scoring. Turning exposure into a number > requires weighing balance, dormancy and CRQC timelines, none of which > are observable on-chain and all of which are contested. The draft > stops at the observable so that the numbers people compute on top of > it are at least computed over the same facts. >=20 > Draft, reference implementation and test vectors: > https://github.com/duncan0k/pubkey-exposure-classification >=20 > I posted this to Delving Bitcoin a couple of days ago and am > cross-posting here for wider review: > https://delvingbitcoin.org/t/standardizing-an-exposure-classification-for= -existing-outputs-pre-bip/2866 >=20 > Before I invest further: is this something the list considers worth > specifying, or is it better left to each implementation? I am also > interested in whether anyone has prior art I have missed -- I could > not find a canonical definition, but this is the kind of thing that > gets rediscovered. >=20 > duncan0k >=20 > -- > 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/bitcoinde= v/010001a06dd4cdd9-b8082042-8750-4e9a-917e-2053c919e4c4-000000%40email.amaz= onses.com. >=20 --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 9QUT0_vQUMszAr1ZQw9EsjX9S-gnVFJDD7g4eYgeovhYaOu84nmqJUs8vuDtaPSexGIKkiG3xNp= o_jEnVMeJPSnxARXvcOah5jujNBBOdeU%3D%40proton.me. -----------------------824569e9f8af76ff50077d31d3f1a75b Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------824569e9f8af76ff50077d31d3f1a75b-- --------3959f7ac95b2b2f8fdaa80483e30c29c2371594f0c3bf429a06a4c6191df8917 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmqfJCsJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmdmxKhO7KrNr9dzbsEQdQWeHlyz9rHtEcQY7R8p Mw5AKBYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAC25gEAmrnXmLmyLscQ7+3V JOvYjBRnBCWKJvQfOyMb1bjMTDEA/AxTYOBjlwquUqKdHGf9A6WL1iU55W54 zVXxyTwqtNoH =39iI -----END PGP SIGNATURE----- --------3959f7ac95b2b2f8fdaa80483e30c29c2371594f0c3bf429a06a4c6191df8917--