From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 14 Jul 2026 15:29:47 -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 1wjldJ-0008SS-Tp for bitcoindev@gnusha.org; Tue, 14 Jul 2026 15:29:47 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-43cce86b0c4sf3655968fac.3 for ; Tue, 14 Jul 2026 15:29:45 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1784068180; cv=pass; d=google.com; s=arc-20260327; b=GdEHNoHK+sOqSELPsgRbwf5dl2CTfwNOfrHy5vBJW32jKlYsKJvonW+Q2xq58RaRS4 LqzJi3sydZmI0VGyu6nZDHe0A83phogm1PgpLptrXzy/QYRIhOQVybJrvfrzRNc8mgcd V9JA0+70ZuizlAPRfJEt3ub9NBM4VjS9N88fmox3unGbPT7RwTUI5PygZ0gseMgHwiUc ncZimA3wkdGIDahQh5Joltfb9KhFRYCTfmK+/pfKPj3nILRp6TYjfjdGhuY5/bopam0S E9shpMuFIknVnSE244mDILjr0Do1SKFM4tAmaVYeD4Tsqjugm32o6BIn3Rzdi8ankuJ7 D4Vg== 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=zficc1cbG0RSAHV+EVBuZ0KuGz2pGENuhJDLlugtPLc=; fh=qtnoS9zBccNjKgGsJTUQ6xa1Em2P5760ikn1IW5UZKc=; b=TzDEU7WMjBpWW9I551GdI0j4lGNJkHGP/kCzz36mZI9Perj369lfws8t4jBNaNq8/c 63DvxOwYJa9P2wDt/q/hUfND+HSM4OaoxH1uUp8CAAcHm7iG7qrtnGwQ9mMPsHjl3zZf JE60eTaGMR/yGDAqzVFi1ZR7yWD4dTN5pVJa8UPt3v6pQujWpGX+WjB73QcfXd5lFkHx CiGHDHtRUovF1fglZXSCQkPTIAKgHjGr3mWjRdZo0oVLRWY4KuLfmOrdJBUwZUccawdL s2XYr7QyWTdikWNjw2n7ikPhedSCkG8hDFnUTcdwWiOf+6V6y6iOh1Whf2k51VQI1cc9 4laA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="mywNtHV/"; spf=pass (google.com: domain of shinobius_monk@protonmail.com designates 79.135.106.104 as permitted sender) smtp.mailfrom=shinobius_monk@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1784068180; x=1784672980; 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=zficc1cbG0RSAHV+EVBuZ0KuGz2pGENuhJDLlugtPLc=; b=FJAUu0Agv0eapkKjK3KKtHikvN5AR6BaF2kGmLY/un180/DzePv8Sj0q+hpNW0SFDG NaSod8LYzAKlzyxeJAs3QtM08Lx5Cbw2Hapg3UiqHoh962HMeT1rdv/eDb16KvcOL8cM GhHP/sEB4mJiYouVVGwlJ4P8hwP9CBgqCFAZD0MG/G0uR02PoqDjvdGbL7dcy+ZAV4Ud aBa0YYYIloJnnYk1tRILuEOurWcOaPkFfXIzPVBEKdxUkUtj9ynUjZOrMWfUM8divSKg dKyZKOTGddgH+/9sEGoGSf/bm0q+nzVPRQ4qwDfdPmwXOXIDZ/vn3Yet0NXjRdl5XVUy IJuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784068180; x=1784672980; 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=zficc1cbG0RSAHV+EVBuZ0KuGz2pGENuhJDLlugtPLc=; b=LfJ7VS+F/81a+f71xOL5vkC5hs4DUI10HYTuBe8CUDJ+tWWz58ihGMCkd7+SPWIQLI 4EbLWr6njkytMCxhyB0Vb7tD1Jag1g+lzKghYM5xeiSstbg1r1acmt08pqeseFn7k0RB lB6esbXPCgU/h3MEajrCWe+dHAlai+/N1rGCRRGXKFvdNUD9sgVdsrB49Cywa/IafPPX 5of1bFEn/o6z1oP5o2fY0ThtoOp0vta807d47Yw/Spls5DuKrOirEs3qye0xz2Olgd63 MbaENYfjwkdU9HhdniZ60CkR844V8IFZ1IY5czPl5+BpPRro0Pn9vs6VTEBjWmnkAbiG xV/w== X-Forwarded-Encrypted: i=2; AHgh+Rq5IA1Ffcy/bNrLGheiWuUidpIOrowmOTcPqcY/FJsbpzLrGPPOQij08eOMgZilJSrHbeGmrDn0GpWx@gnusha.org X-Gm-Message-State: AOJu0Yz4JcmBe8h9jlvPHnX2TNE1TELsplks1fv7Fa4DjjYGBishG9dt H4Fej/mjj1edF/i9MQD5t8XEaykpc2QUCaH2OFRnRCsPCJ+HL3Du85cf X-Received: by 2002:a05:6870:a08d:b0:447:1746:f3c8 with SMTP id 586e51a60fabf-455f8023b8dmr3352274fac.28.1784068179698; Tue, 14 Jul 2026 15:29:39 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPQNYqMXeI79PNhUQcMQhWqRABYlLNJ2H1sdDZgFBuumxg==" Received: by 2002:a05:6870:a115:b0:454:e0fd:42f0 with SMTP id 586e51a60fabf-456290f838cls239601fac.2.-pod-prod-01-us; Tue, 14 Jul 2026 15:29:35 -0700 (PDT) X-Received: by 2002:a05:6808:1308:b0:494:e494:8c38 with SMTP id 5614622812f47-4a4725f6028mr3189119b6e.7.1784068175798; Tue, 14 Jul 2026 15:29:35 -0700 (PDT) Received: by 2002:a05:600c:5896:b0:488:963a:630a with SMTP id 5b1f17b1804b1-493f2d460ffms5e9; Tue, 14 Jul 2026 15:29:12 -0700 (PDT) X-Received: by 2002:a05:6000:2005:b0:475:f100:360c with SMTP id ffacd0b85a97d-47f4fcfadd7mr228670f8f.59.1784068151006; Tue, 14 Jul 2026 15:29:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784068151; cv=none; d=google.com; s=arc-20260327; b=Nt4syL9VY9vo+05OIZlZkzsql0lxuga4attq1gRRMDcxRfzVXqmsujelt0heiM2up7 lBIjQzVacVPxLPTBm76rkrpbKxdbqYQhdh2ojd7YmKQl12qSWWsrzwsZttHSD8MT1OY5 fg5EJldtyMV1aXdjQl5B9UqEK8uqrjXmROuWCui9X7+sn8DHtPL1FZ3Tv8e93h7Y97A3 kYnkxf+rAmMbuC0twS++EIkaP2TneGEOV6yjUoqu6vst7O82KrtkCO+5Wg3jG3wrbooS D3q1TSFpNr6RYZ4a6tYWW+dXew9zHCul6SkzpGBCj2HHlkNjsl+3TQMZ4uLhBnb4UXw7 dGlQ== 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=TaY9My6xkXufdK3fMU0JMVcGiu+M4g9/KEpZus7vPCQ=; fh=NdMtxlgcB7XMNm7RkllsTejKYwjjd2EPyy2sAVEi5wE=; b=rsVs3OgqCudWbhOushgSZKpBUT6Tw+j5OhghZJy2jQd7mP6hEiH1HKCLIPsLAPKXkK yV/BwkHZNPOP1udsr7jGrljkWrZEzjVnCOyudc3dkHYWxBGZN3CmhW9YBQpy98hsiF2V pOAqepW6M5sOp2Jn3ZCP2oCj7sOaRCvMGDcBcrB/dNygr+6w16MKDCmeBWTvtckPuzQx QZVFm01DT49P9anVhGlUmGX/Gdw+EXhFd4DKvJnKH3eo46KBQVnAHTb7KrnG2K2mwpxH 2vzlggJlxh8NTyDFqNlwl/k/otElgqd8Kho3zoyDAcjz6suGTBV4+uC/p1QoT4Uwkg0I +E6w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="mywNtHV/"; spf=pass (google.com: domain of shinobius_monk@protonmail.com designates 79.135.106.104 as permitted sender) smtp.mailfrom=shinobius_monk@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-106104.protonmail.ch (mail-106104.protonmail.ch. [79.135.106.104]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-47f465174a9si76533f8f.7.2026.07.14.15.29.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2026 15:29:10 -0700 (PDT) Received-SPF: pass (google.com: domain of shinobius_monk@protonmail.com designates 79.135.106.104 as permitted sender) client-ip=79.135.106.104; Date: Tue, 14 Jul 2026 22:28:59 +0000 To: conduition From: "'shinobimonkey' 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: <9phSoKtu5X4YzlMjNwSDXsmozBcMS7FL3C56xbVMSqd88Rf38Yjv4-mDKRexx8mnpnWGdfsfAUgSQqyYQWz5UeTWymp1M-lU_auC59sARJQ=@protonmail.com> In-Reply-To: References: Feedback-ID: 119200758:user:proton X-Pm-Message-ID: c8065d168c137c133c25f5ab58b0c184e0620fde MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_5rVBkbIYtSXzryjupkP6IVy8vzS9lzYcHmo4ErvXE" X-Original-Sender: shinobius_monk@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="mywNtHV/"; spf=pass (google.com: domain of shinobius_monk@protonmail.com designates 79.135.106.104 as permitted sender) smtp.mailfrom=shinobius_monk@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: shinobimonkey Reply-To: shinobimonkey 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 (-) --b1=_5rVBkbIYtSXzryjupkP6IVy8vzS9lzYcHmo4ErvXE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable - No matter what tool we use to authenticate KA's, there will exist some UT= XOs which have no 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. I don't see what the point of your response is here, given I specifically a= nd explicitly state in the original post that address types revealing publi= c keys on-chain are out of scope here, uncoverable in this way due to the p= roposal involving commit-reveal as an allowed mechanism. The whole point of= this proposal of these three (or as you pointed out validly, just the ZKP = + commit/reveal would achieve the same coverage and the stateful proofs is = redundant)specific mechanisms is that they can be applied only to hashed ad= dress types, leaving P2TR and P2PK as a separate matter. - Not true. P2TR UTXOs can be rescued using internal keys as a KA, which ar= e essentially preimages hidden to the quantum attacker. Pick an internal pu= bkeyP=E2=80=8B with output keyP' =3D P + H(P) * G=E2=80=8B, and giveP'=E2= =80=8B to the CRQC. Though they can factorP'=E2=80=8B, they cannot guessP o= ther than by brute-force (or Grover's search). Again, I don't see the point of the reply here, as this would be a complete= ly separate recovery mechanism than the combination of these two/three spec= ific things. These specific mechanisms layered together, and applied as an = additional encumbrance only on hashed address types, ignoring P2TR and P2PK= , would achieve complete coverage of any feasible key generation scheme. - It is still possible to have a UTXO on a hashed address which contains no= KA. Consider a paper wallet, generated randomly (not from BIP32), which ha= s already been spent from previously and so has an EC pubkey exposed on cha= in. Whether it was generated with BIP 32 or not is irrelevant if the address is= reused, obviously in a quantum threat scenario address reuse is a fatal mi= stake. The same thing is true of revealing your xpubs, which is just as wid= espread (if not moreso) of a practice. That completely undermines the KA th= at HD recovery proofs depend on. I don't see how this is a useful response = or criticism, unless you also want to apply the same degree of criticism to= HD recovery proofs in general as well. Preparing for a post quantum Bitcoin will require lots of ancillary hygiene= practice changes and tightening up when it comes to managing data like tha= t if we don't want these type of preparatory schemes to be undermined by po= or practices. Accepting this reality, and only applying these three (or I guess two) addi= tional recovery encumbrances to hashed address types (i.e. not P2PK and P2T= R), any user should be able to recover all of their hashed address secured = coins in all situations except key loss or address reuse (and this is ultim= ately not special to this proposal, any recovery or preparatory scheme to d= eal with quantum short of just giving users a new address type and them out= right migrating will require that users begin to treat and handle public ke= y material differently for it to work). Shinobi Sent with [Proton Mail](https://proton.me/mail/home) secure email. On Tuesday, July 14th, 2026 at 4:38 PM, conduition w= rote: > Hi Shinobi, > > Thanks for raising this item. It's a heavily contentious subject with a l= ot 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= does. So let me first define another term: Knowledge Asymmetry. > > 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 p= lain words, a KA is some piece of high-entropy information 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 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 > > KA's are distinct from private keys because currently there exists no sta= ndardized means to authenticate oneself using these 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 t= o modify consensus so that KA's can be used to rescue coins that don't move= onto 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. > - 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-= register to create a new KA, why not simply move to a quantum-safe address?= Or move to any standard BIP32 wallet or hashed address, where known KA's a= bound? So i will discount pre-registration as a rescue scheme for now becau= se it seems excessively complex and redundant. > > The other two, ZKPs and commit/reveal, are far more interesting as they l= et us authenticate existing KA's present on Bitcoin UTXOs, such as BIP32 ke= ys or hashed addresses. Both have their trade-offs. > > The more relevant fact to consider in regards to your OP is: No matter wh= at tool we use to authenticate KA's, there will exist some UTXOs which have= no knowledge asymmetries on Q-day. I suspect Satoshi's coins are chief amo= ng 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 su= bsets: Those with KA's, and those without. I like to call these the "recove= rable" and "unrecoverable" sets of UTXOs. > > The unrecoverable set unfortunately cannot be rescued from a QC, no matte= r what rescue protocol we devise, because there exists no provable mathemat= ical distinction between the honest user and the future CRQC. The only rout= e left there is KYC or "trusted salvage" by a CRQC. > > For the recoverable set (those with KA's), we can further classify them b= ased on the types of KA available to each UTXO: some UTXOs have multiple KA= 's. > > However, these sets all have unknown size and volume because - with the e= xception of hashed addresses - it's hard to tell at a glance which KA's a p= articular address has available. This makes it hard to justify what KA's to= prioritize 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 to be use= d, complete coverage of any conceivable key generation method can be achiev= ed for hashed address types. > > It is still possible to have a UTXO on a hashed address which contains no= KA. Consider a paper wallet, generated randomly (not from BIP32), which ha= s already been spent from previously and so has an EC pubkey exposed on cha= in. 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 impossible, becaus= e the requirement to allow use of commit-reveal migration would 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 ar= e essentially preimages hidden to the quantum attacker. Pick an internal pu= bkey 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 gues= s P other than by brute-force (or Grover's search). > > By default most P2TR software generates the output key with a hidden inte= rnal key in this way even if no scripts are present ([example](https://gith= ub.com/rust-bitcoin/rust-bitcoin/blob/3812750b6824eb0374504d7e2fddd8e8528a2= cda/bitcoin/src/taproot/mod.rs#L193-L195)), and [this is standardized in BI= P86](https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki#address= -derivation) 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. > > The same would apply to any P2PK key generated using hashes, though I thi= nk these would be very rare. > > regards, > conduition > > On Tuesday, July 14th, 2026 at 9:44 AM, 'shinobimonkey' via Bitcoin Devel= opment Mailing List wrote: > >> Currently the discussion around how to address the potential risk of a v= iable quantum computer centers around two primary issues: the quantum-safe = signature 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 secur= ed by vulnerable ECC based scripts, specifically should these coins be froz= en, and what mechanisms are available to allow legitimate owners to recover= those coins if possible without an attacker having the ability to do so. >> >> This second issue is (and always has been) a very socially contentious o= ne, as the common understanding is it is impossible to guarantee with certa= inty that no user is being left in a position where they are incapable of g= enerating a recovery proof, and therefore are forever prevented from access= ing their coins. >> >> My motivation for writing this is to solve this contention (at least par= tially) in a manner that can hopefully move discussions forward in a produc= tive direction rather than lead to two opposing plans of action eventually = colliding in the real world with live implementations of conflicting rules. >> >> The current solution landscape as it stands to my understanding is: >> >> - BIP 32 hierarchical proofs, as proposed a decade or so ago by Adam Bac= k and recently implemented as a proof-of-concept by roasbeef. >> - Non-deterministic stateful proofs constructed and timestamped before a= deadline, showing a vulnerable ECC key signing off on a quantum-safe authe= ntication mechanism to be used for spending after a post-quantum spending r= estriction 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 wher= e a transaction spending vulnerable ECC inputs must have an encrypted commi= tment to that exact transaction confirmed in a block with a pre-determined = number of confirmations prior to the decrypted plaintext transaction's conf= irmation, or the decrypted transaction is invalid. >> >> All three of these proposals leave some subset of coins uncovered. HD pr= oofs are useless for users who generated their keys any other way than BIP = 32, stateful timestamped proofs are useless for any inactive user or someon= e 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 tha= t isn't hashed because any attacker would have access to the material neede= d to create a valid pre-commitment for a spend. >> >> However, by layering them, and allowing any single one of them to be use= d, complete coverage of any conceivable key generation method can be achiev= ed for hashed address types. Coverage of non-hashed address types is fundam= entally impossible, because the requirement to allow use of commit-reveal m= igration would inherently leave such address types still exposed to a quant= um attacker. >> >> - Hierarchical proofs cover any BIP 32 user >> - Stateful timestamped proofs cover any active/observant non-BIP 32 user >> - Commit-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 sp= ends using this layered approach of recovery would leave a user unable to r= ecover their coins is if they have lost access to their private keys. That = case is completely outside of the scope of any of these proposals, and inhe= rently impossible to cover. >> >> Shinobi >> >> Sent with [Proton Mail](https://proton.me/mail/home) secure email. >> >> -- >> You received this message because you are subscribed to the Google Group= s "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/sdGGYMMWowlFff6Yh8usMel61HVYmV8KPMqT9np2kK7GxPbVaogJ2aJSFe4v16VNLef4eDwN= gfReiK-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/= 9phSoKtu5X4YzlMjNwSDXsmozBcMS7FL3C56xbVMSqd88Rf38Yjv4-mDKRexx8mnpnWGdfsfAUg= SQqyYQWz5UeTWymp1M-lU_auC59sARJQ%3D%40protonmail.com. --b1=_5rVBkbIYtSXzryjupkP6IVy8vzS9lzYcHmo4ErvXE Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
  • = No matter what tool we use to authenticate KA's, there will exist some UTXO= s which have no knowledge asymmetries on Q-day. I sus= pect Satoshi's coins are chief among them, since they are stored on P2PK ad= dresses generated by Bitcoin Core's old JBOK wallet system.

I don't see what the point of your response= is here, given I specifically and explicitly state in the original post th= at address types revealing public keys on-chain are out of scope here, unco= verable in this way due to the proposal involving commit-reveal as an allow= ed mechanism. The whole point of this proposal of these three 
  • Not true. P2TR UTXOs can be rescued using int= ernal keys as a KA, which are essentially preimages hidden to the quantum a= ttacker. 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).

<= div style=3D"scrollbar-width: thin; scrollbar-color: rgba(0, 0, 0, 0.35) rg= ba(0, 0, 0, 0); background-color: rgb(255, 255, 255);">Again= , I don't see the point of the reply here, as this would be a completely se= parate recovery mechanism than the combination of these two/three specific = things. These specific mechanisms layered together, and applied as an addit= ional encumbrance only on hashed address types, ignoring P2TR and P2PK, wou= ld achieve complete coverage of any feasible key generation scheme. 

  • It is still possible t= o have a UTXO on a hashed address which contains no KA. Consider a pap= er wallet, generated randomly (not from BIP32), which has already been spen= t from previously and so has an EC pubkey exposed on chain.

Whether it was generated with BIP = 32 or not is irrelevant if the address is reused, obviously in a quantum th= reat scenario address reuse is a fatal mistake. The same thing is true of r= evealing your xpubs, which is just as widespread (if not moreso) of a pract= ice. That completely undermines the KA that HD recovery proofs depend on. I= don't see how this is a useful response or criticism, unless you also want= to apply the same degree of criticism to HD recovery proofs in general as = well. 

=
Preparing for a post quantum Bitcoin will require lots of ancill= ary hygiene practice changes and tightening up when it comes to managing da= ta like that if we don't want these type of preparatory schemes to be under= mined by poor practices.  

Accepting this reality, and only apply= ing these three (or I guess two) additional recovery encumbrances to hashed= address types (i.e. not P2PK and P2TR), any user should be able to recover= all of their hashed address secured coins in all situations except key los= s or address reuse (and this is ultimately not special to this proposal, an= y recovery or preparatory scheme to deal with quantum short of just giving = users a new address type and them outright migrating will require that user= s begin to treat and handle public key material differently for it to work)= .

Shinobi

Sent with Proton Mail secure email.

<= div class=3D"protonmail_quote"> On Tuesday, July 14th, 2026 at 4:38 PM, conduition <conduition@p= roton.me> wrote:
Hi Shinobi, 

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

Before we even think about rescue pr= otocols like ZKPs, pre-registration, or commit/reveal, it is important to u= nderstand what a rescue protocol even does. So let me first define another = term: Knowledge Asymmetry. 

In this context, a knowledge asymmetry (or= KA for short) is a witness to a quantum-hard relation that has been commit= ted on-chain before Q-day. In plain words, a KA is some piece of high-entro= py information which an honest coin-holder knows, but which a future CRQC w= ill not know and cannot easily compute or guess.

Examples of knowledge asymmetries= include:
  • BIP32 parent keys and chain c= odes (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
      • <= /ul>
    • Pre-registered commitmen= ts 

    KA's are distinct from private keys b= ecause currently there exists no standardized means to authenticate oneself= using these KA's in consensus, and because KA's are not always perfectly p= rivate (e.g. hashed public keys). 

    The rescue= protocols you cite as examples are all merely different ways to modify con= sensus so that KA's can be used to rescue coins that don't move onto explic= itly quantum-safe addresses in time.

    • Lalu's ZK-STARK benchmarks show how to authent= icate a BIP32 KA using the RISC0 STARK prover, but generally a ZKP can prov= e any computation, and allows fast verification. 
    • Commit/reveal strategies can pr= ove any KA that can be verified by publishing 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 ass= umption we will introduce a way to authenticate those KA's later.

    Pre-registration is a b= it of a red-herring in my view. If a user can pre-register to create a new = KA, why not simply move to a quantum-safe address? Or move to any standard = BIP32 wallet or hashed address, where known KA's abound? So i w= ill discount pre-registration as a rescue scheme for now because it seems e= xcessively complex and redundant.

    The other two, Z= KPs 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 addre= sses. Both have their trade-offs. 

    The more r= elevant fact to consider in regards to your OP is: No matter what tool w= e use to authenticate KA's, there will exist some UTXOs which have no knowl= edge asymmetries on Q-day. I suspect Satoshi's coins are chief among th= em, since they are stored on P2PK addresses generated by Bitcoin Core's old= JBOK wallet system.

    We could theoretically partit= ion the set of all Bitcoin UTXOs into two subsets: Those with KA's, and tho= se without. I like to call these the "recoverable" and "unrecoverable" sets= of UTXOs. 

    The unrecoverable set unfortunate= ly cannot be rescued from a QC, no matter what rescue protocol we devise, b= ecause there exists no provable mathematical distinction between the honest= user and the future CRQC. The only route left there is KYC or "trusted sal= vage" by a CRQC.

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

    However, these sets all have unknown size and volume because - with = the exception of hashed addresses - it's hard to tell at a glance which KA'= s a particular address has available. This makes it hard to justify what KA= 's to prioritize authenticating, so we kinda just have to go by dead-reckon= ing.

    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 to be used, comple= te coverage of any conceivable key generation method can be achieved for ha= shed address types.

    It is = still possible to have a UTXO on a hashed address which contains no KA. Con= sider a paper wallet, generated randomly (not from BIP32), which has alread= y been spent from previously and so has an EC pubkey exposed on chain. Unle= ss 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 fundamen= tally impossible, because the requirement to allow use of commit-reveal mig= ration would 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 pre= images hidden 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'<= /code>=E2=80=8B, they cannot guess P other than by brute-= force (or Grover's search).

    By default most P2TR s= oftware generates the output key with a hidden internal key in this way eve= n if no scripts are present (example), and this is standardized in BIP86 so I believe most P2TR wa= llets 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. 

    The same would ap= ply to any P2PK key generated using hashes, though I think these would be v= ery 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/= 9phSoKtu5X4YzlMjNwSDXsmozBcMS7FL3C56xbVMSqd88Rf38Yjv4-mDKRexx8mnpnWGdfsfAUg= SQqyYQWz5UeTWymp1M-lU_auC59sARJQ%3D%40protonmail.com.
--b1=_5rVBkbIYtSXzryjupkP6IVy8vzS9lzYcHmo4ErvXE--