From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 14 Jul 2026 14:40:10 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wjkrI-0003kH-RE for bitcoindev@gnusha.org; Tue, 14 Jul 2026 14:40:10 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-44d2204d393sf1901035fac.0 for ; Tue, 14 Jul 2026 14:40:08 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1784065202; cv=pass; d=google.com; s=arc-20260327; b=Btk/jvPgEMT9SCS1TvFCfpIZMkGf1Ez6xPtb9VoqiyNy/j8IQM9vuD5Bdfg8WqV7st RePD7sA/wD5vgRwt+mkUL3hJoC0GhrChWsQ4HUrOQgIAp+wbdqhmkdK7/EExz/W4wgft Cg47nAnrF507/cdK0YB/ihlPnPINWUnQ9XBtnMPNae9gIjSlscSJDUVWexLGNL4vzIj6 5CoYWrKoUpgMuoo+3ubzuI9ctcO8Ist1yPccsRRwjmABHeozA5bM5W8yIkUC0BicT5hL QIFo4CQwMTi+KIwlKUmY5c44DNjP6AXDR8iYAzK9c0WQyUiAnhmvFWEWQ18GS1B4buCs hqIQ== 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=f57WPdURpy+VouVhqbmLEoTTgKyGnrLzwX5ZVikW3bo=; fh=8f7iWJTc0jJB45X9vMyZR8h5rvH0e4xyOzGbRabV9Xs=; b=Z5ToWu6nabjUi4bVPxm5ushMEH/BbXIZBha90ny/f/EqZFf22K1Y0aonOGDmtQPVs4 tgwUsrc6xRmmHohDrzP+/AeS0BUxGWIIGEmSIXPCnn/E9NrOeF1t/x1qcZc5/Dplh56i EJyv+FpZCDg472KGmGyt9lmizlAgxLgr6oMbN/PLOSDq04zWdthOiQ5boxuBpX0jLqVd 63jCHBBH1ZuECHMLri85HdUhGMrPY6KJ3FrGFTWl4SLFZtikyZTtwtlDcBqt/hBlhjA+ nAlMWc8kQbOo0jE1xVWzHMlFrt3ONBguireKWs1i2orcY8ew8eFPZk2JImRdoyyJ/RIh vtaw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=BUXMGA5s; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.103 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=1784065202; x=1784670002; 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=f57WPdURpy+VouVhqbmLEoTTgKyGnrLzwX5ZVikW3bo=; b=sgkdWHonCAt1y22qVjBNW8jSWPduB00cd1RN1BRCw0CroCY3tzFwsOUONVduQktoJ+ qOC50C4izd01BrtMPQrHsh4LN5mldw9YozaKeRIu02LLZqgOw0zm3yOZN0MFnQeKsj/O A2SyhWLi/3KXSH0huayEb/8VdM52MK7ZvzdKAjtsHfuBDQ5EPdB9pYzDdmfGacGW2oX2 1YfDFlpwJAGTHfblCGGIidjl//WjcAe52VDqw3mX8+iCr7XUXt267DQlcbz6L5s6Dnel ntOnkI3W5XWQ64Bo3PQRCdkJQtvFq/IJQE6mjBYYIZOjhQJI5QYGCAXyj9TS63xa0kRz nAgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784065202; x=1784670002; 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=f57WPdURpy+VouVhqbmLEoTTgKyGnrLzwX5ZVikW3bo=; b=lfE1beZtbO6RzL6sFkxUt+WbIhK3fAEPFlVwPKoDHl/E9gyyoqdTqDnhIe6iLUU2wP Syp5QGL2aM7eD27jJKrKcRI2Hb7/hbyeZeUQ50+dv+KwlV4D3DQGp/aurYcL20seJ/hq KlLzCHlq06DVezRN8UywdduhJNv7lENDXPJ/HCqjHZhQABbiWaoQGImZB95F/GqyX/19 yzl0bDxsufrOqofQF4Kg22do7x5PSDabMg40eQq7V4gTv0URFjoy+0NmVqH0QDllimOE 3tVnOuImCKymrqs09l1xsY4eeFoDSEHkt6aYAdlWMrNDUvo5qYPfCaF3jot0Lw9zBz2E CTfQ== X-Forwarded-Encrypted: i=2; AHgh+RpXWX3hSX//edxJ7U2qBOWHKYx+3J077YXIOTEHphN8ZUB3KmIiZWYfEDraDnyiaTSS7i1xfZTvGk+Y@gnusha.org X-Gm-Message-State: AOJu0YzsmunBAFG3Eh6p5wr4CxWtOJcUuyZ+cp6Ev6CW0TGm3ylNyp9H THaLqiHOTuu7jZr/Sl8kZ76sj5YunCS3uxbNa193yak6uE5/TLymC5Lo X-Received: by 2002:a05:6870:970b:b0:44c:9008:21b0 with SMTP id 586e51a60fabf-451f1035fb6mr8568323fac.2.1784065202263; Tue, 14 Jul 2026 14:40:02 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUehGTdtxTmNn8Ir99KWNZDt7drH5oTG9N6RHzPPmNXymw==" Received: by 2002:a05:6870:b01d:b0:43b:4306:c32b with SMTP id 586e51a60fabf-45628adfbcbls146424fac.2.-pod-prod-09-us; Tue, 14 Jul 2026 14:39:58 -0700 (PDT) X-Received: by 2002:a05:6808:3503:b0:495:d6b7:6004 with SMTP id 5614622812f47-4a42af9514bmr9568504b6e.26.1784065197923; Tue, 14 Jul 2026 14:39:57 -0700 (PDT) Received: by 2002:a05:6504:6194:10b0:308:ee47:a2d9 with SMTP id a1c4a302cd1d6-308ffcba7a0msc7a; Tue, 14 Jul 2026 14:38:40 -0700 (PDT) X-Received: by 2002:ac2:5689:0:b0:5ae:b486:2ef5 with SMTP id 2adb3069b0e04-5b15d7c4ad3mr22066e87.65.1784065118144; Tue, 14 Jul 2026 14:38:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784065118; cv=none; d=google.com; s=arc-20260327; b=b3hWr4wf+26BAED1CFY0DFynLSccNBwZE4yj8qrE8zE9qJyKwnNXARe+byMt3KWQgL HQW8d5qBjPel7hGOJSS9L4LV+HI8YVro1Bx2aX7wRXDKDZsjSW1/1eR38OYN1AjIWdbt OqQzheYrDwJUTakuyQuIO+IU7rGYsfBfauXpUPT3XPqnfjm/4pw7ZufhM51+rSEEg8cq FeTZJhWaGDaXwrNPhkJ6xabboTM9HHsfWhVT900gAcJzKB/WNxQ4QxlQpJYWLGf+TRPr s0+tn4nRlUZ86PbcINuaOgVi8iVXwBgtwOxwe7ToVKOt5rhbX8Wz/2wHggwrD79yPi96 MTew== 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=Jx+8vCC6OL1p1OIoDCmQNvV8/17V8eRCMDT2KRYyhg4=; fh=l0aQaLwe4UFBxTQIXrRRpVb3fgkbJqXdfIHFRFgqA/I=; b=N/h52ubYVtyfauy+c08rnVDW+3c/KR5/n6Nm6e9HrjV/2EB0uqaNR15XwzAU2py3pq X8BMOlosVQKG5i2Bo0m9/exfrMGMe3xo187m+0oqTr+QMY276aCzZgvIBzt8RU1Pp7H1 nmBAg4jOvbjDBl0Q7Gh+XXJhPnBU3SXkut1Q6oliZWK3JCd/B1vBKUI6PgNHERu6jv5/ OOJ3n+sQgw76RDWclICpJXCSdvQNYJ6/C10ieYzlCv6+WIx3/k67AHayXA2xD2S+JFOC 1QK9WPaBiB3U8TKAtg1W2dhZOHgCkUE33b+OmAossCI+kobugCisANt63AapXUx9tYz+ ZfxA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=BUXMGA5s; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.103 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-106103.protonmail.ch (mail-106103.protonmail.ch. [79.135.106.103]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5b01ca8cfbcsi249536e87.6.2026.07.14.14.38.38 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2026 14:38:38 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.103 as permitted sender) client-ip=79.135.106.103; Date: Tue, 14 Jul 2026 21:38:29 +0000 To: shinobimonkey From: "'conduition' via Bitcoin Development Mailing List" Cc: "bitcoindev@googlegroups.com" Subject: Re: [bitcoindev] Quantum Recovery Of Hashed Address Secured Coins With No Confiscatory Risk Message-ID: In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 28afb8076bf5b5a3e5c89ce113c672625ccf59c1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------d3ecdaad5c3574054c003daed8acd551c8267fd33e59642176d68efeae02c502"; 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=BUXMGA5s; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.103 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) --------d3ecdaad5c3574054c003daed8acd551c8267fd33e59642176d68efeae02c502 Content-Type: multipart/mixed;boundary=---------------------e299757deff43d32465d9f2d10a59697 -----------------------e299757deff43d32465d9f2d10a59697 Content-Type: multipart/alternative;boundary=---------------------6ab0e3cc1437c6e7f2188a72589b340d -----------------------6ab0e3cc1437c6e7f2188a72589b340d Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Shinobi,=C2=A0 Thanks for raising this item. It's a heavily contentious subject with a lot= of misinformation flying around. Before we even think about rescue protocols like ZKPs, pre-registration, or= commit/reveal, it is important to understand what a rescue protocol even d= oes. So let me first define another term: Knowledge Asymmetry.=C2=A0 In this context, a knowledge asymmetry (or KA for short) is a witness to a = quantum-hard relation that has been committed on-chain before Q-day. In pla= in words, a KA is some piece of high-entropy information which an honest co= in-holder knows, but which a future CRQC will not know and cannot easily co= mpute or guess. Examples of knowledge asymmetries include: - BIP32 parent keys and chain codes (this is what Lalu used in his RISC0 = benchmarks) - EC keys hidden behind a hash, e.g. - Hashed address types which haven't been spent from - MuSig peer keys - Taproot internal keys - Pre-registered commitments=C2=A0 KA's are distinct from private keys because currently there exists no stand= ardized means to authenticate oneself using these KA's in consensus, and be= cause KA's are not always perfectly private (e.g. hashed public keys).=C2= =A0 The rescue protocols you cite as examples are all merely different ways to = modify consensus so that KA's can be used to rescue coins that don't move o= nto explicitly quantum-safe addresses in time. - Lalu's ZK-STARK benchmarks show how to authenticate a BIP32 KA using th= e RISC0 STARK prover, but generally a ZKP can prove any computation, and al= lows fast verification.=C2=A0 - Commit/reveal strategies can prove any KA that can be verified by publi= shing a witness (e.g. by publishing a preimage and recomputing its hash, in= the case of hashed addresses, but it's more general than that). - Pre-registration is a way to create new KA's where they may not already= exist (e.g. for exposed-pubkey JBOK wallets), under the assumption we will= introduce a way to authenticate those KA's later. Pre-registration is a bit of a red-herring in my view. If a user can pre-re= gister to create a new KA, why not simply move to a quantum-safe address? O= r move to any standard BIP32 wallet or hashed address, where known KA's abo= und?=C2=A0So i will discount pre-registration as a rescue scheme for now be= cause it seems excessively complex and redundant. The other two, ZKPs and commit/reveal, are far more interesting as they let= us authenticate existing KA's present on Bitcoin UTXOs, such as BIP32 keys= or hashed addresses. Both have their trade-offs.=C2=A0 The more relevant fact to consider in regards to your OP is: No matter what= tool we use to authenticate KA's, there will exist some UTXOs which have n= o knowledge asymmetries on Q-day. I suspect Satoshi's coins are chief among= them, since they are stored on P2PK addresses generated by Bitcoin Core's = old JBOK wallet system. We could theoretically partition the set of all Bitcoin UTXOs into two subs= ets: Those with KA's, and those without. I like to call these the "recovera= ble" and "unrecoverable" sets of UTXOs.=C2=A0 The unrecoverable set unfortunately cannot be rescued from a QC, no matter = what rescue protocol we devise, because there exists no provable mathematic= al distinction between the honest user and the future CRQC. The only route = left there is KYC or "trusted salvage" by a CRQC. For the recoverable set (those with KA's), we can further classify them bas= ed on the types of KA available to each UTXO: some UTXOs have multiple KA's= .=C2=A0 However, these sets all have unknown size and volume because - with the exc= eption of hashed addresses - it's hard to tell at a glance which KA's a par= ticular address has available. This makes it hard to justify what KA's to p= rioritize authenticating, so we kinda just have to go by dead-reckoning. With this in mind, I would like to correct a few statements in your OP: > However, by layering them, and allowing any single one of them=C2=A0to be= used, complete coverage of any conceivable key generation method can be ac= hieved for hashed address types. It is still possible to have a UTXO on a hashed address which contains no K= A. Consider a paper wallet, generated randomly (not from BIP32), which has = already been spent from previously and so has an EC pubkey exposed on chain= . Unless a new KA is introduced (by moving coins or pre-registration), no r= escue protocol can save this UTXO: it will either be stolen or frozen. > Coverage of non-hashed address types is fundamentally impossible, because= the requirement to allow use of commit-reveal migration would inherently l= eave such address types still exposed to a quantum attacker. Not true. P2TR UTXOs can be rescued using internal keys as a KA, which are = essentially preimages hidden to the quantum attacker. Pick an internal pubk= ey `P` with output key `P' =3D P + H(P) * G`, and give `P'` to the CRQC. Th= ough they can factor `P'`, they cannot guess `P`=C2=A0other than by brute-f= orce (or Grover's search). By default most P2TR software generates the output key with a hidden intern= al key in this way even if no scripts are present (example), and this is st= andardized in BIP86 so I believe most P2TR wallets have a KA and so can be = rescued. Even if they didn't have an internal key, any P2TR address can use= BIP32 as a KA since most P2TR addresses are derived from an HD wallet.=C2= =A0 The same would apply to any P2PK key generated using hashes, though I think= these would be very rare. regards, conduition On Tuesday, July 14th, 2026 at 9:44 AM, 'shinobimonkey' via Bitcoin Develop= ment Mailing List wrote: > Currently the discussion around how to address the potential risk of a vi= able quantum computer centers around two primary issues: the quantum-safe s= ignature schemes (or schemes) to integrate for users to migrate to and use = if need be, and what (if anything) to do about any coins that remain secure= d by vulnerable ECC based scripts, specifically should these coins be froze= n, and what mechanisms are available to allow legitimate owners to recover = those coins if possible without an attacker having the ability to do so.=C2= =A0 >=20 > This second issue is (and always has been) a very socially contentious on= e, as the common understanding is it is impossible to guarantee with certai= nty that no user is being left in a position where they are incapable of ge= nerating a recovery proof, and therefore are forever prevented from accessi= ng their coins.=C2=A0 >=20 > My motivation for writing this is to solve this contention (at least part= ially) in a manner that can hopefully move discussions forward in a product= ive direction rather than lead to two opposing plans of action eventually c= olliding in the real world with live implementations of conflicting rules.= =C2=A0 >=20 > The current solution landscape as it stands to my understanding is:=C2=A0 >=20 >=20 > - BIP 32 hierarchical proofs, as proposed a decade or so ago by Adam Ba= ck and recently implemented as a proof-of-concept by roasbeef.=C2=A0 > - Non-deterministic stateful proofs constructed and timestamped before = a deadline, showing a vulnerable ECC key signing off on a quantum-safe auth= entication mechanism to be used for spending after a post-quantum spending = restriction is activated > - Tim Ruffing/Tadge Dryja's idea (I apologize, but I forget who was the= actual originator of the proposal) of a commit-reveal migration scheme whe= re a transaction spending vulnerable ECC inputs must=C2=A0have an encrypted= commitment to that exact transaction confirmed in a block with a pre-deter= mined number of confirmations prior to the decrypted plaintext transaction'= s confirmation, or the decrypted transaction is invalid.=C2=A0 >=20 >=20 > All three of these proposals leave some subset of coins uncovered. HD pro= ofs are useless for users who generated their keys any other way than BIP 3= 2, stateful timestamped proofs are useless for any inactive user or someone= who for any reason does not create them before the creation deadline, and = the commit-reveal migration is useless for anyone with an address type that= isn't hashed because any attacker would have access to the material needed= to create a valid pre-commitment for a spend.=C2=A0 >=20 > However, by layering them, and allowing any single one of them=C2=A0to be= used, complete coverage of any conceivable key generation method can be ac= hieved for hashed address types. Coverage of non-hashed address types is fu= ndamentally impossible, because the requirement to allow use of commit-reve= al migration would inherently leave such address types still exposed to a q= uantum attacker.=C2=A0 >=20 >=20 > - Hierarchical proofs cover any BIP 32 user > - Stateful timestamped proofs cover any active/observant non-BIP 32 use= r > - Commit-reveal covers any non-BIP 32 user who is inactive/not observan= t=C2=A0 >=20 >=20 > The only case in which I can see a restriction of hashed address type spe= nds using this layered approach of recovery would leave a user unable to re= cover their coins is if they have lost access to their private keys. That c= ase is completely outside of the scope of any of these proposals, and inher= ently impossible to cover.=C2=A0 >=20 > Shinobi >=20 > Sent with Proton Mail secure email. >=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/sdGGYMMWowlFff6Yh8usMel61HVYmV8KPMqT9np2kK7GxPbVaogJ2aJSFe4v16VNLef4eDwNg= fReiK-7j-sYn1jlXHPoAPWAwNBbSJxEz3M%3D%40protonmail.com. --=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/= gchRDYHoK2N2rCf0m6qNLWUkR0_rJkO_zL8dvPr7IDCY7FO_iPyzk0hP9L0Y3kwJtvCxnNNc4Ik= CpNpG5M5Uxa5BR_psT8KR15HtVTeeyQg%3D%40proton.me. -----------------------6ab0e3cc1437c6e7f2188a72589b340d Content-Type: multipart/related;boundary=---------------------618c38de2571bd413c779b8bcadf342c -----------------------618c38de2571bd413c779b8bcadf342c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Shinobi,=  

= Thanks for raising this item. It's a heavily contentious subject with a lot= of misinformation flying around.

Before we even think about rescue protocols like= ZKPs, pre-registration, or commit/reveal, it is important to understand wh= at a rescue protocol even does. So let me first define another term: Kno= wledge Asymmetry. 

In this context, a knowledge asymmetry (or KA for shor= t) is a witness to a quantum-hard relation that has been committed on-chain= before Q-day. In plain words, a KA is some piece of high-entropy informati= on which an honest coin-holder knows, but which a future CRQC will not know= and cannot easily compute or guess.

Examples of knowledge asymmetries include:
  • BIP32 parent keys and chain codes (this i= s what Lalu used in his RISC0 benchmarks)
  • EC keys hidden behind a hash, e.g.
    • Hashed address types which haven't been spent from
    • MuSig peer keys
    • Taproot internal keys
  • Pre-registered commitments 

KA's are distinct from private keys because curr= ently there exists no standardized means to authenticate oneself using thes= e KA's in consensus, and because KA's are not always perfectly private (e.g= . hashed public keys). 

The rescue protocols = you cite as examples are all merely different ways to modify consensus so t= hat KA's can be used to rescue coins that don't move onto explicitly quantu= m-safe addresses in time.

  • Lalu's ZK-STARK benchmarks show how to authenticate a B= IP32 KA using the RISC0 STARK prover, but generally a ZKP can prove any com= putation, and allows fast verification. 
  • Commit/reveal strategies can prove any K= A that can be verified by publishing a witness (e.g. by publishing a preima= ge and recomputing its hash, in the case of hashed addresses, but it's more= general than that).
  • Pre-registration is a way to create new KA's where they may not a= lready exist (e.g. for exposed-pubkey JBOK wallets), under the assumption w= e will introduce a way to authenticate those KA's later.

Pre-registration is a bit of a r= ed-herring in my view. If a user can pre-register to create a new KA, why n= ot simply move to a quantum-safe address? Or move to any standard BIP32 wal= let or hashed address, where known KA's abound? So i will disco= unt pre-registration as a rescue scheme for now because it seems excessivel= y complex and redundant.

The other two, ZKPs and c= ommit/reveal, are far more interesting as they let us authenticate existing= KA's present on Bitcoin UTXOs, such as BIP32 keys or hashed addresses. Bot= h have their trade-offs. 

The more relevant f= act to consider in regards to your OP is: No matter what tool we use to = authenticate KA's, there will exist some UTXOs which have no knowledge asym= metries on Q-day. I suspect Satoshi's coins are chief among them, since= they are stored on P2PK addresses generated by Bitcoin Core's old JBOK wal= let system.

We could theoretically partition the s= et of all Bitcoin UTXOs into two subsets: Those with KA's, and those withou= t. I like to call these the "recoverable" and "unrecoverable" sets of UTXOs= . 

The unrecoverable set unfortunately cannot= be rescued from a QC, no matter what rescue protocol we devise, because th= ere exists no provable mathematical distinction between the honest user and= the future CRQC. The only route left there is KYC or "trusted salvage" by = a CRQC.

For the recoverable set (those with KA's), we can further classify them based on the types of KA available to = each UTXO: some UTXOs have multiple KA's. 

Ho= wever, these sets all have unknown size and volume because - with the excep= tion of hashed addresses - it's hard to tell at a glance which KA's a parti= cular address has available. This makes it hard to justify what KA's to pri= oritize authenticating, so we kinda just have to go by dead-reckoning.

With this in mind, I would like to correct a few state= ments in your OP:

However, by layering= them, and allowing any single one of them to be used, complete covera= ge of any conceivable key generation method can be achieved for hashed addr= ess types.

It is still pos= sible to have a UTXO on a hashed address which contains no KA. Consider a p= aper wallet, generated randomly (not from BIP32), which has already been sp= ent from previously and so has an EC pubkey exposed on chain. Unless a new = KA is introduced (by moving coins or pre-registration), no rescue protocol = can save this UTXO: it will either be stolen or frozen.

Coverage of non-hashed address types is fundamentally imp= ossible, because the requirement to allow use of commit-reveal migration wo= uld inherently leave such address types still exposed to a quantum attacker= .

Not true. P2TR UTXOs can= be rescued using internal keys as a KA, which are essentially preimages hi= dden to the quantum attacker. Pick an internal pubkey P=E2=80= =8B with output key P' =3D P + H(P) * G=E2=80=8B, and give P'=E2=80=8B to the CRQC. Though they can factor P'= =E2=80=8B, they cannot guess P other than by brute-force = (or Grover's search).

By default most P2TR softwar= e generates the output key with a hidden internal key in this way even if n= o scripts are present (example), and this is standardized in= BIP86 so I believe most P2TR wallets have a KA and so can be rescued. = Even if they didn't have an internal key, any P2TR address can use BIP32 as= a KA since most P2TR addresses are derived from an HD wallet. 
<= div>
The same would apply to any P2PK key generated using has= hes, though I think these would be very rare.


=

regards,
conduition
On Tuesday, July 14th, 2026 at 9:44 AM, 'shinobimonkey' via Bitcoin= Development Mailing List <bitcoindev@googlegroups.com> = wrote:
Currently the discussion around how to address the potential risk of a via= ble quantum computer centers around two primary issues: the quantum-safe si= gnature schemes (or schemes) to integrate for users to migrate to and use i= f need be, and what (if anything) to do about any coins that remain secured= by vulnerable ECC based scripts, specifically should these coins be frozen= , and what mechanisms are available to allow legitimate owners to recover t= hose coins if possible without an attacker having the ability to do so.&nbs= p;
This= second issue is (and always has been) a very socially contentious one, as = the common understanding is it is impossible to guarantee with certainty th= at no user is being left in a position where they are incapable of generati= ng a recovery proof, and therefore are forever prevented from accessing the= ir coins. 

My motivation for writing this is to solve this contention (at lea= st partially) in a manner that can hopefully move discussions forward in a = productive direction rather than lead to two opposing plans of action event= ually colliding in the real world with live implementations of conflicting = rules. 

The current solution landscape as it stands to my understanding is:&n= bsp;
<= br>
  • BIP 32 hierarchical proofs, as proposed a dec= ade or so ago by Adam Back and recently implemented as a proof-of-concept b= y roasbeef. 
  • Non= -deterministic stateful proofs constructed and timestamped before a deadlin= e, showing a vulnerable ECC key signing off on a quantum-safe authenticatio= n mechanism to be used for spending after a post-quantum spending restricti= on is activated
  • Tim Ruffing= /Tadge Dryja's idea (I apologize, but I forget who was the actual originato= r of the proposal) of a commit-reveal migration scheme where a transaction = spending vulnerable ECC inputs must have an encrypted commitmen= t to that exact transaction confirmed in a block with a pre-determined numb= er of confirmations prior to the decrypted plaintext transaction's confirma= tion, or the decrypted transaction is invalid. 

    • All three of these = proposals leave some subset of coins uncovered. HD proofs are useless for u= sers who generated their keys any other way than BIP 32, stateful timestamp= ed proofs are useless for any inactive user or someone who for any reason d= oes not create them before the creation deadline, and the commit-reveal mig= ration is useless for anyone with an address type that isn't hashed because= any attacker would have access to the material needed to create a valid pr= e-commitment for a spend. 

    However, by layering them, and allowing any sin= gle one of them to be used, complete coverage of any conceivable k= ey generation method can be achieved for hashed address types. Coverage of = non-hashed address types is fundamentally impossible, because the requireme= nt to allow use of commit-reveal migration would inherently leave such addr= ess types still exposed to a quantum attacker. 

    • Hierarchical proofs cover any BIP 32 user
    • Stateful timestamped proofs cover any active/observ= ant non-BIP 32 user
    • C= ommit-reveal covers any non-BIP 32 user who is inactive/not observant 

    The only case in which I can see a restriction of hashed address= type spends using this layered approach of recovery would leave a user una= ble to recover their coins is if they have lost access to their private key= s. That case is completely outside of the scope of any of these proposals, = and inherently impossible to cover. 

    Shinobi

    Sent with Proton Mail secure email.

    --
    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+u= nsubscribe@googlegroups.com.
    To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/sdGGYMMWowlFff6Yh8usMel61H= VYmV8KPMqT9np2kK7GxPbVaogJ2aJSFe4v16VNLef4eDwNgfReiK-7j-sYn1jlXHPoAPWAwNBbS= JxEz3M%3D%40protonmail.com.

    --
    You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
    To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
    To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/gchRDY= HoK2N2rCf0m6qNLWUkR0_rJkO_zL8dvPr7IDCY7FO_iPyzk0hP9L0Y3kwJtvCxnNNc4IkCpNpG5= M5Uxa5BR_psT8KR15HtVTeeyQg%3D%40proton.me.
    -----------------------618c38de2571bd413c779b8bcadf342c-- -----------------------6ab0e3cc1437c6e7f2188a72589b340d-- -----------------------e299757deff43d32465d9f2d10a59697 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== -----------------------e299757deff43d32465d9f2d10a59697-- --------d3ecdaad5c3574054c003daed8acd551c8267fd33e59642176d68efeae02c502 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmpWrEQJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmeDVVo/9fb5g+Hn2aFL0PPd45lQDCCxwJ/YHpKB dI5FQhYhBEdIka0CMtrLdg13a3gpbO2E9rPFAACsPgD/b+PvB0/p4iLqpiPP jAV9BXLb5XBlyaWMdqqhy+JyMQoBAJBjSo+WW69Zhhk2XKdWhfneKc0Iyyyx /hdw2KNNAsMI =QcJe -----END PGP SIGNATURE----- --------d3ecdaad5c3574054c003daed8acd551c8267fd33e59642176d68efeae02c502--