From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 11 Aug 2026 07:56:19 -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 1wtnto-0008EA-Ea for bitcoindev@gnusha.org; Tue, 11 Aug 2026 07:56:19 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-45952ce9ee0sf3450475fac.1 for ; Tue, 11 Aug 2026 07:56:16 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1786460170; cv=pass; d=google.com; s=arc-20260327; b=cKuMdGbj+rx931QHOmBGyig/dipVu0OvAaDbEaf4h5s9nlkJ9pSsS1HcsrqwbICLgV WBs36jYP3gx1AmNO30dPGLtLEzfBItmVe63n4trdgWJXR9abJq+NX1PDZwf61gZ2giPS KbzZYpaun//L7RDZtGyIB2teYF7QT3wBiU0N0l5kBSJ6yLBW8x9wIKqtIln8ckyCnQ2M 86gjv70XsNejbmb08EUswn7DkbPCVs+zRhMLa7TyPnZ6hk4mCj4rdX8c4WAs0FyQQHaX YTByTiwk5i8WBVlMHFn6XZNT0yK1go1mAvRGo2o67zC/ncxYMwR9oHt7YdGQySjluZZ/ B7hQ== 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=pcvEbwxZdiGL7vibbvVc65O5uR0YO/QAXHWduCyILmM=; fh=YA91pT//e1T4FP1TSw7DjkvrMizBYEPkzRsATGpWflI=; b=NzfG3ZNKG6gicTzBZJWmhS+IEerYsvxHVs3se831pUIBcl5QQ+90J655lhoFqllBJD dpSeh6AWkUdZpoFJ6InkLeYmOlK3u6MJeY/QTVm3XLYOsyss4AchjXgWS+n484L6zKrc JHWKXaWQQm8jaDsb4JPTTv76CI9eBqClDqThnkWN4w4IzOpYtXfBaWL217krszpUrPET L8Fzs2Wdt47qbn6Cugg0sd93AyeRCaw0dJdyIUPn/J+y/GL4bjcRB99IPFIsRjLfBVlJ ecxhQBmRfkA5ebWfrEgStMh/myL10L06XDugm31VSGUy40K54ziEZfiOXwC8gf1UmEND 2tpQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=G2sk5Icp; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.102 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=1786460170; x=1787064970; 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=pcvEbwxZdiGL7vibbvVc65O5uR0YO/QAXHWduCyILmM=; b=wO+D8kpOuyNlk13qbovd8O6ny+II3mznH6sUQCacDrRYbREqj3XOUYzcB0q5QuN7bw MxthygMjE9oEaxf1c04kd5zNbWb1WOnT0iLFOkX1xt97fqfQSHUW/eqQ4W8Ao1e8qJtw jr3Bhm6O6GyWfng/3T2YH6W7FmBUShAq27rzu90SL/cC+muzrBNh9USKZ3e1prXT63Ve C6jCdClLZwiTLWi6G9nAYcG5ySHPEnAGFs+SrqMj/81/CPLJ7L0s8XuQdVoFiYsBGDC9 5fE5cXFpHzWv9OA0pLh7eJL0vvADDus9wWsM12WhcdoF69K+5crgktu8r17GviuPK2Yf LuTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786460170; x=1787064970; 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=pcvEbwxZdiGL7vibbvVc65O5uR0YO/QAXHWduCyILmM=; b=kSpqB/I5TCJMaxFRKoK/FhObQP1il1UD4rQ4e4RfoLThzarMcnx61VhYiFQ5YXF8V8 WMMBHjwbileirJsVu3tUWuwJIMn/6ZUxYNTSCrCgf9Q4OPP8yIqT/P/nik5SYBb4pGJi KHL2Nxa74XBOkV0YKgnhe5/PjBl34qnL8fnEI0mlo7kUPxXNhdKdP6YrOXLOWLpMBe0E aln6Drx0Ger/aTrFH6EguLlf1iYLCn8g/w70FVbYl40+2a/3cLrOy2hXVeVzVIfOuP6Q zI7lVqhHqQHqWY2DhCeUC3JAqpPUOt89ye/3gsitLbB4ayo4X1iZZAA5lqVAMZZSIFbe GUeA== X-Forwarded-Encrypted: i=2; AHgh+RpLvI0F9u2NjiRwj6UJ0u7AalD72zMa9a2t9DCRJpMxgq2WY4yDjDzX3UB5wnk+GfTfLkt8u/LRIZVb@gnusha.org X-Gm-Message-State: AOJu0Yzm7e4XP1lJgm3sVDReSYvLrxVepxH1WSN7EyZI+pDR+f4M8q7h mMdfRECBAVhG2rnv8Ep9GVCCJo0tu/xAF2hsgudEs2YXiSwuSkobUDKD X-Received: by 2002:a05:6870:d364:b0:457:70b0:b286 with SMTP id 586e51a60fabf-45e21843737mr2484647fac.18.1786460169938; Tue, 11 Aug 2026 07:56:09 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPSqQYIIp5JYrkLBwIp/c5ltUfW4DZL/Wjw2+mo/DMO4dA==" Received: by 2002:a05:6870:96a4:b0:456:6589:b64f with SMTP id 586e51a60fabf-459cda7d975ls3469365fac.2.-pod-prod-05-us; Tue, 11 Aug 2026 07:56:04 -0700 (PDT) X-Received: by 2002:a05:6808:3189:b0:4ab:2c58:4514 with SMTP id 5614622812f47-4b1fd21ff35mr2930443b6e.0.1786460164798; Tue, 11 Aug 2026 07:56:04 -0700 (PDT) Received: by 2002:a05:6402:2ca:b0:69c:20b8:fa6f with SMTP id 4fb4d7f45d1cf-6a1cafa2be5msa12; Tue, 11 Aug 2026 07:08:59 -0700 (PDT) X-Received: by 2002:a05:6402:2402:b0:69f:d4b7:9476 with SMTP id 4fb4d7f45d1cf-6a3644817b3mr2135853a12.4.1786457338177; Tue, 11 Aug 2026 07:08:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1786457338; cv=none; d=google.com; s=arc-20260327; b=ZisKHQ/Qa8vVnsVLXW/g46z56YGgAiMwjZxRBznvsCfW0X04rEh1FeUw9xF/tFi5jq QId2w+eTaRu/j0lBuhT2mKH0/B9ExcJmRj3pm30IiUr1q33J2Stt2zgvJbyTeh8EAkoU XPEKskNXlBF9Yw0mlEpw14Bcd/q+Cwa4GUlBIIDl+ggeSGs+47w8UCdwJ5vxITDWSkeP Dwej+1mTo8ZJplFh7nT0pTqpv55aFX0x9zny5bE811R34d88Lqz6dJXc7oNYYi4+A6y+ z66NCMmFzmnsfTT7wRTmKfuG3z4nfYZa+mfNNJRH/8hoayNti2BBEz6Gq5bz5HwStx7K DSgg== 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=JbyBk8bXq6c3K3mWQhkW7fOatnlgV1MSJgYH0M8dfyQ=; fh=l0aQaLwe4UFBxTQIXrRRpVb3fgkbJqXdfIHFRFgqA/I=; b=XBCoGkBM1zHYXJUmy1cvgp/6kF7WBtpK7Pu6wdg9kxyPK8O4rk0IuL4oKL+MvF9UXK 1ziTq3c4JDsxiwNG5D0pxpDmoj6/Wod0YwBg+Sw8cLVi6SwnKbcYb2myQj2NSFTVnLlI SBhyPRQ931ezs/BGv1ye3RsT5qVgeTZExc9tjwcRoMm0FJnAnrlRtLH51LXe+tQluAJE l4ogvbaua6VCOPlJ4FOsR8DL3IzFsR15C5Ks34x/2fBJv79No0tTCDoAS1kwgbCulDu9 X6ShX7Sg21vzn/xBJkrQkOHOD3N21lllei6siWVyR9Ep4kz2z2MFgGNUTObAnaQ5s8pc 6FlQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=G2sk5Icp; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.102 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-106102.protonmail.ch (mail-106102.protonmail.ch. [79.135.106.102]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-6a362e70902si32290a12.6.2026.08.11.07.08.57 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 07:08:58 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.102 as permitted sender) client-ip=79.135.106.102; Date: Tue, 11 Aug 2026 14:08:51 +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: <9phSoKtu5X4YzlMjNwSDXsmozBcMS7FL3C56xbVMSqd88Rf38Yjv4-mDKRexx8mnpnWGdfsfAUgSQqyYQWz5UeTWymp1M-lU_auC59sARJQ=@protonmail.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 22ae4d5ac386c915d929e3ae74d1df3a7a685a51 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------5851853c409e409f4d66d4c4068b38371cac3752896f7d696b682bcfc60fcd6d"; 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=G2sk5Icp; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.102 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) --------5851853c409e409f4d66d4c4068b38371cac3752896f7d696b682bcfc60fcd6d Content-Type: multipart/mixed;boundary=---------------------47ce053bc22caddebf390baedb9ba79d -----------------------47ce053bc22caddebf390baedb9ba79d Content-Type: multipart/alternative;boundary=---------------------b202aea95a1c7b6130c0826694f6b9a8 -----------------------b202aea95a1c7b6130c0826694f6b9a8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Re-sending this (Aug 4), because I forgot to hit reply-all :P Hey Shinobi, thanks for clarifying your OP.=C2=A0 > To deal with the xpub problem, a new set of derivation paths can be defin= ed for each address type which is specced to only use the Electrum protocol= for balancing fetching. By only using individual address queries, you avoi= d the disclosure of the xpub for these sets of addresses and create a path = where for end users a transition can happen potentially even without their = awareness. New wallet updates can simply start generating addresses using t= he new derivation paths and new protocol for balance fetching. Interesting idea, and maybe it would reduce harm if adopted at scale today,= but unfortunately this is only a forward-secure solution. It does not help= users whose pubkeys are already exposed unless they take proactive action = and move their coins, in which case why not move the coins to a PQ secure a= ddress (once those are available)? > They do require proactive action, but in the event of failing to do so or= losing the proofs after the deadline, the possibility of HD recovery and c= ommit-reveal migration would cover users in that case. As i said earlier, the issue with pre-registration protocols is: If proacti= ve action is required, why not just move coins to a PQ-secure address, or l= acking that, to one which has a decidable knowledge asymmetry, like P2TR or= a hashed address? The juice doesn't seem worth the squeeze to me. > I believe this combination of these recovery mechanisms can achieve 100% = recovery coverage for every address type live on the network except P2PK ou= tputs and custom bare scripts with the singular new security assumption of = maintaining the secrecy of public keys I want to be clear about the qualification on your primary claim here: We c= an't go back in time and assume people never reused addresses. Any changes = we make to wallet standards, code, or to consensus are only forward-facing.= Existing information cannot be un-leaked. At best we can hope users move c= oins to PQ secure addresses or at least to addresses which are recoverable = via rescue protocols (i.e. hashed addresses, P2TR). Technically you're correct, but it's important to be clear that your assump= tion excludes a huge (1/3)=C2=A0fraction of today's UTXO set from the set o= f "covered" coins. That remaining 1/3 does still stand a chance to be rescu= ed, but just not with 100% coverage. To summarize, we have the UTXO set we have, not the one we want, and we sha= ll have to deal with it as it exists on Q-day: some coins will have exposed= public keys and some won't. When that time rolls around, the community sha= ll have to decide what matters more: Preserving as much of that remaining 1= /3 of the UTXO set as possible, or avoiding all confiscation. regards, conduition On Thursday, July 23rd, 2026 at 5:46 PM, 'shinobimonkey' via Bitcoin Develo= pment Mailing List wrote: > This is just a rewrite of the original message to address some of conduit= ion=E2=80=99s remarks in his reply, and more concisely state the implicit a= ssumptions of the overall idea. I just belted out the original post in a fe= w minutes while I was buried under work, so hopefully this gets across the = scope and assumptions more clearly. >=20 > There are a number of proposed mechanisms for facilitating the recovery o= f coins by their legitimate owner by applying new additive encumbrances spe= cifying a new proof of secret knowledge in addition to a signature by a pri= vate key, as well as commit-reveal schemes to allow for committing to a tra= nsaction spending vulnerable coins and requiring such a commitment to attai= n a certain number of blocks built upon it before the committed transaction= is consensus valid. >=20 > None of these schemes is capable of providing complete recovery coverage = for all coins whose owners still possess a private key if applied blanketly= to a given address type. I believe that by layering multiple recovery sche= mes together additively, and allowing any single one of them to meet the th= reshold required for spending, 100% coverage can be achieved by taking on o= nly one new security assumption: the requirement to keep your public key/in= ternal script paths secret. >=20 > It should also be possible to account for the fact that most users not ru= nning their own full node are leaking master public keys to a third party b= ackend server for balance querying. >=20 > To deal with the xpub problem, a new set of derivation paths can be defin= ed for each address type which is specced to only use the Electrum protocol= for balancing fetching. By only using individual address queries, you avoi= d the disclosure of the xpub for these sets of addresses and create a path = where for end users a transition can happen potentially even without their = awareness. New wallet updates can simply start generating addresses using t= he new derivation paths and new protocol for balance fetching. >=20 > The only complications I can see with this is out-of-box middle-ware that= is being used to connect wallets to users=E2=80=99 nodes are built around = the assumption of xpubs and using Core=E2=80=99s internal wallet. This is a= lmost certain to be a non-issue in the vast majority of cases as it will be= a user connecting to their own node, but even in the small number of cases= where a user is connecting to a third party node with such software, it ca= n be adapted to use something like Electrum protocol. I don=E2=80=99t see t= his being a major show stopper. >=20 > The xpub issue mitigated, now the interaction of the of different recover= y mechanisms. >=20 > Xpub derivation based recovery: > ------------------------------- >=20 > This will cover any BIP 32 based wallet, regardless of what derivation pa= th (?) is used. So this recovery path should encompass both any address gen= erated using legacy derivation paths with exposed public keys, as well as n= ewer derivation paths securing them through the use of the Electrum protoco= l. >=20 > For any hashed-address type (P2PKH, P2SH, P2WPKH, P2WSH) the derivation p= roof alone is sufficient, and as conduition pointed out in response to my i= nitial post the internal key can additively be used to make this workable f= or P2TR addresses that do not use the NUMS point. >=20 > This specifically ensures that any user with coins using these address ty= pes can produce a recovery proof without having to take any kind of proacti= ve action before the activation of a fork implementing additive encumbrance= s on address types. (It=E2=80=99s worth noting however these proofs will be= pretty big, which is relevant for stateful proofs). >=20 > Stateful timestamped proofs > --------------------------- >=20 > This has been pitched multiple times before I can recall but never really= described in detail. Simply the basic components of a signature from the e= xisting encumbrance condition over a new authentication mechanism (a public= key for a quantum safe scheme), and a timestamp to prove that this attesta= tion was produced before some pre-defined deadline chosen to expire before = a viable quantum computer exists. >=20 > This could be pretty simply boiled down to the 1) the signature over the = new public key/authentication commitment, 2) the timestamp. Given the poten= tial size of ZKPs, and the fact that hash-based signatures can be optimized= to ~580 bytes, I think these are still worth considering looking at how mu= ch smaller and more efficient with blockspace stateful proofs can be compar= ed to ZKPs. >=20 > They do require proactive action, but in the event of failing to do so or= losing the proofs after the deadline, the possibility of HD recovery and c= ommit-reveal migration would cover users in that case. >=20 > Commit-reveal migration > ----------------------- >=20 > For any hashed address type, the old commit-reveal migration scheme requi= ring an encrypted commitment to a transaction be confirmed in the blockchai= n for a pre-defined number of blocks before the plain-text transaction can = be considered consensus valid. The secrecy of public keys can be maintained= using the new derivation specification, but this will still be consensus v= alid for coins in legacy derived addresses. >=20 > Again, as conduition pointed out in his reply to my original post, the in= ternal key forms the basis for a secret inaccessible to an attacker, and ca= n be applied as a requirement for P2TR keyspends as an additional validity = requirement while using commit-reveal migration. Any tapscript spends using= commit-reveal should work as long as those tapscript paths have never been= reused with the same internal variables like public keys. >=20 > Wrap up > ------- >=20 > So I think I=E2=80=99ve covered all my bases in terms of implicit assumpt= ions and responding to conduitions comments. >=20 > Unless I am fundamentally missing something, or have overlooked important= implementation details like those conduition corrected in his replies from= my initial post, I believe this combination of these recovery mechanisms c= an achieve 100% recovery coverage for every address type live on the networ= k except P2PK outputs and custom bare scripts with the singular new securit= y assumption of maintaining the secrecy of public keys (which as noted abov= e can be accomplished with a rather painless migration behind the scenes fo= r users and without the need to go through the process of generating a new = master key and migrating funds across seeds). >=20 > So I guess, yeah=E2=80=A6what am I overlooking here? >=20 >=20 >=20 >=20 > Shinobi >=20 > Sent with Proton Mail secure email. >=20 > On Wednesday, July 15th, 2026 at 12:58 AM, 'conduition' via Bitcoin Devel= opment Mailing List wrote: >=20 > > > I don't see what the point of your response is here, given I specific= ally and explicitly state in the original post that address types revealing= public keys on-chain are out of scope here, uncoverable in this way due to= the proposal involving commit-reveal as an allowed mechanism. > >=20 > >=20 > >=20 > > The words you quoted were written as a counterpoint to your claim that = "by layering them, and allowing any single one of them=C2=A0to be used, com= plete coverage of any conceivable key generation method can be achieved for= hashed address types." My point was that your claim is not true because so= me coins don't have KA's (because of how their address was generated and us= ed previously) and thus can't be rescued. I used satoshi's coins as an exam= ple but the same is true of some coins on hashed address types (see my reus= ed paper wallet example). > >=20 > >=20 > > Any UTXO which does=C2=A0have a KA is perfectly rescuable, regardless o= f the type of address it sits on. It just so happens that some address type= s encourage more KA's than others (e.g. hashed addresses), but not all coin= s on such addresses will have a KA and be recoverable after Q-day rolls aro= und. Often it's impossible to identify those cases with certainty. > >=20 > >=20 > > > Again, I don't see the point of the reply here, as this would be a co= mpletely separate recovery mechanism than the combination of these two/thre= e specific things. These specific mechanisms layered together, and applied = as an additional encumbrance only on hashed address types, ignoring P2TR an= d P2PK, would achieve complete coverage of any feasible key generation sche= me. > >=20 > > You said in your OP that "Coverage of non-hashed address types is funda= mentally impossible", and so you focus mostly on hashed addresses in your p= roposal. My point is that your claim there was wrong, that P2TR coins can= =C2=A0be rescued because they have one or more KA's, and the text you quote= d shows an example of a KA in P2TR which can be used for rescue. > >=20 > > I point this out because any rescue protocol proposal should seek to co= ver as many UTXOs as possible (within reason), so we ought to cover P2TR co= ins as well if it's feasible to do so, which it clearly is. > >=20 > >=20 > > > Whether it was generated with BIP 32 or not is irrelevant if the addr= ess is reused, obviously in a quantum threat scenario address reuse is a fa= tal mistake. > >=20 > >=20 > > That's not true, it is highly relevant. If a hashed address has an EC p= ublic key exposed on-chain prior to the activation height of the rescue pro= tocol fork, then we can mark that address as having no "hashed address know= ledge asymmetry", and disallow the use of that specific KA for coins on tha= t specific address. Other KA's like BIP32 derivation would remain completel= y usable for rescue. > >=20 > >=20 > > > The same thing is true of revealing your xpubs, which is just as wide= spread (if not moreso) of a practice. That completely undermines the KA tha= t HD recovery proofs depend on. > >=20 > >=20 > > Also not true. Revealing your account-level (i.e. `m/44'/0'/0'`) xpub d= oes not give a quantum adversary any information about the extended key at = the coin-level (i.e. `m/44'/0'`). Wallets typically never share these keys,= even in complex multisig setups. The hardened derivation of the account-le= vel xpriv key (at `m/44'/0'/0'`) is exactly the quantum hard relation that = the BIP32 KA relies upon, and knowing the account-level xpriv doesn't give = you any help in deriving it from the coin-level parent key. I'd encourage y= ou to revisit Laolu's thread on the ML and you'll see this is exactly what = his best ZKP benchmark does. > >=20 > > However, revealing your xpub does=C2=A0give a CRQC the ability to forge= the hashed-address KA proof, because they can re-derive the hidden public = key, crack it, and forge a signature + KA-proof to steal the coins. Since x= pubs are shared off-chain, validator nodes won't know that they should disa= ble the hashed-address KA for children of the exposed xpub. So there is som= e meat to the argument that we ought not to allow hashed address KA's at al= l, because they would encourage selling of xpubs to CRQCs and enable more t= heft than would otherwise be possible. I'm personally still undecided on th= is problem. > >=20 > >=20 > > > I don't see how this is a useful response or criticism, unless you al= so want to apply the same degree of criticism to HD recovery proofs in gene= ral as well. > >=20 > >=20 > > I'm not trying to criticize you or your proposal, other than by correct= ing false statements. I'm sorry if my prior reply was confusing, I can writ= e a bit indirectly at times. > >=20 > > The general idea of layering different KA's is excellent, and I fully s= upport it. But it's also important we be accurate about which coins can and= can't be rescued, as this is a very important factor which ML readers will= use to weigh the pros/cons of supporting or rejecting a rescue protocol so= ft-fork, and as i said earlier, misconceptions abound here. > >=20 > > The most common misconception I see in this field of research is that p= eople think too much about the proving mechanism and not enough about the k= nowledge asymmetries and hard relations. The exact tooling used to prove & = authenticate KA's (ZKPs, commit/reveal, etc) should IMO be decoupled from t= he discussion of which coins can/can't be rescued. Pretty much any KA you c= an authenticate with a ZKP can be authenticated with commit/reveal, and vic= e-versa. > >=20 > > So there should really be two discussions: > >=20 > >=20 > > 1. Which knowledge asymmetries should be allowed for rescue? > > 2. Which proving system should we use to authenticate knowledge asymme= tries? > >=20 > >=20 > > On the subject of (1), I parsed the point of your OP roughly as "more i= s better" when it comes to KA's, and mostly I agree. Unfortunately we can't= recover every UTXO, even if you scope it strictly to certain address types= as you do. There will always be confiscation with rescue protocols, unless= you limit yourself only to KA's whose existence can be checked on-chain, l= ike the hashed address KA, leaving all other addresses untouched, which IMO= is a bad plan because we'll have poor practical results (1/3 of the supply= remains to be siezed or frozen). > >=20 > > On (2), I think you may have some misunderstandings about how commit/re= veal works, because you claimed commit/reveal is not useful for proving KA'= s in non-hashed address types, which is incorrect: Commit/reveal can prove = any KA for any UTXO just as well as ZKPs, no matter what address type the c= oins sit on. > >=20 > >=20 > > regards, > > conduition > >=20 > >=20 > >=20 > > On Tuesday, July 14th, 2026 at 6:29 PM, shinobimonkey wrote: > >=20 > > > - No matter what tool we use to authenticate KA's, there will exist= some UTXOs which have no knowledge asymmetries on Q-day.=C2=A0I suspect Sa= toshi's coins are chief among them, since they are stored on P2PK addresses= generated by Bitcoin Core's old JBOK wallet system. > > > =20 > > >=20 > > >=20 > > >=20 > > > I don't see what the point of your response is here, given I specific= ally and explicitly state in the original post that address types revealing= public keys on-chain are out of scope here, uncoverable in this way due to= the proposal involving commit-reveal as an allowed mechanism. The whole po= int of this proposal of these three=C2=A0(or as you pointed out validly, ju= st the ZKP + commit/reveal would achieve the same coverage and the stateful= proofs is redundant)=C2=A0specific mechanisms is that they can be applied = only to hashed address types, leaving P2TR and P2PK as a separate matter.= =C2=A0=C2=A0 > > >=20 > > > - Not true. P2TR UTXOs can be rescued using internal keys as a KA, = which are essentially preimages hidden to the quantum attacker. Pick an int= ernal pubkey=C2=A0`P` with output key=C2=A0`P' =3D P + H(P) * G`, and give= =C2=A0`P'` to the CRQC. Though they can factor=C2=A0`P'`, they cannot guess= =C2=A0`P`=C2=A0other than by brute-force (or Grover's search). > > > =20 > > >=20 > > >=20 > > >=20 > > > Again, I don't see the point of the reply here, as this would be a co= mpletely separate recovery mechanism than the combination of these two/thre= e specific things. These specific mechanisms layered together, and applied = as an additional encumbrance only on hashed address types, ignoring P2TR an= d P2PK, would achieve complete coverage of any feasible key generation sche= me.=C2=A0 > > >=20 > > >=20 > > > - It is still possible to have a UTXO on a hashed address which con= tains no KA.=C2=A0Consider a paper wallet, generated randomly (not from BIP= 32), which has already been spent from previously and so has an EC pubkey e= xposed on chain. > > > =20 > > >=20 > > >=20 > > >=20 > > > Whether it was generated with BIP 32 or not is irrelevant if the addr= ess is reused, obviously in a quantum threat scenario address reuse is a fa= tal mistake. The same thing is true of revealing your xpubs, which is just = as widespread (if not moreso) of a practice. That completely undermines the= KA that HD recovery proofs depend on. I don't see how this is a useful res= ponse or criticism, unless you also want to apply the same degree of critic= ism to HD recovery proofs in general as well.=C2=A0 > > >=20 > > >=20 > > > Preparing for a post quantum Bitcoin will require lots of ancillary h= ygiene practice changes and tightening up when it comes to managing data li= ke that if we don't want these type of preparatory schemes to be undermined= by poor practices.=C2=A0=C2=A0 > > >=20 > > >=20 > > > Accepting this reality, and only applying these three (or I guess two= ) additional recovery encumbrances to hashed address types (i.e. not P2PK a= nd P2TR), any user should be able to recover all of their hashed address se= cured coins in all situations except key loss or address reuse (and this is= ultimately not special to this proposal, any recovery or preparatory schem= e to deal with quantum short of just giving users a new address type and th= em outright migrating will require that users begin to treat and handle pub= lic key material differently for it to work). > > >=20 > > > Shinobi > > >=20 > > > Sent with Proton Mail secure email. > > >=20 > > > On Tuesday, July 14th, 2026 at 4:38 PM, conduition wrote: > > >=20 > > > > Hi Shinobi,=C2=A0 > > > >=20 > > > > Thanks for raising this item. It's a heavily contentious subject wi= th a lot of misinformation flying around. > > > >=20 > > > > Before we even think about rescue protocols like ZKPs, pre-registra= tion, or commit/reveal, it is important to understand what a rescue protoco= l even does. So let me first define another term: Knowledge Asymmetry.=C2= =A0 > > > >=20 > > > > In this context, a knowledge asymmetry (or KA for short) is a witne= ss 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 information which an h= onest coin-holder knows, but which a future CRQC will not know and cannot e= asily compute or guess. > > > >=20 > > > > Examples of knowledge asymmetries include: > > > >=20 > > > > - BIP32 parent keys and chain codes (this is what Lalu used in hi= s RISC0 benchmarks) > > > > - EC keys hidden behind a hash, e.g. > > > >=20 > > > > - Hashed address types which haven't been spent from > > > > - MuSig peer keys > > > > - Taproot internal keys > > > >=20 > > > > - Pre-registered commitments=C2=A0 > > > >=20 > > > >=20 > > > > KA's are distinct from private keys because currently there exists = no standardized means to authenticate oneself using these KA's in consensus= , and because KA's are not always perfectly private (e.g. hashed public key= s).=C2=A0 > > > >=20 > > > > 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 onto explicitly quantum-safe addresses in time. > > > >=20 > > > >=20 > > > > - Lalu's ZK-STARK benchmarks show how to authenticate a BIP32 KA = using the RISC0 STARK prover, but generally a ZKP can prove any computation= , and allows fast verification.=C2=A0 > > > > - Commit/reveal strategies can prove 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 assumption= we will introduce a way to authenticate those KA's later. > > > >=20 > > > >=20 > > > >=20 > > > > Pre-registration is a bit of a red-herring in my view. If a user ca= n pre-register to create a new KA, why not simply move to a quantum-safe ad= dress? Or move to any standard BIP32 wallet or hashed address, where known = KA's abound?=C2=A0So i will discount pre-registration as a rescue scheme fo= r now because it seems excessively complex and redundant. > > > >=20 > > > > 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 BI= P32 keys or hashed addresses. Both have their trade-offs.=C2=A0 > > > >=20 > > > > The more relevant fact to consider in regards to your OP is: No mat= ter what tool we use to authenticate KA's, there will exist some UTXOs whic= h have no knowledge asymmetries on Q-day. I suspect Satoshi's coins are chi= ef among them, since they are stored on P2PK addresses generated by Bitcoin= Core's old JBOK wallet system. > > > >=20 > > > > We could theoretically partition the set of all Bitcoin UTXOs into = two subsets: Those with KA's, and those without. I like to call these the "= recoverable" and "unrecoverable" sets of UTXOs.=C2=A0 > > > >=20 > > > > The unrecoverable set unfortunately cannot be rescued from a QC, no= matter what rescue protocol we devise, because there exists no provable ma= thematical distinction between the honest user and the future CRQC. The onl= y route left there is KYC or "trusted salvage" by a CRQC. > > > >=20 > > > > 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 multi= ple KA's.=C2=A0 > > > >=20 > > > > 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 K= A's to prioritize authenticating, so we kinda just have to go by dead-recko= ning. > > > >=20 > > > > With this in mind, I would like to correct a few statements in your= OP: > > > >=20 > > > >=20 > > > > > However, by layering them, and allowing any single one of them=C2= =A0to be used, complete coverage of any conceivable key generation method c= an be achieved for hashed address types. > > > >=20 > > > >=20 > > > > It is still possible to have a UTXO on a hashed address which conta= ins no KA. Consider a paper wallet, generated randomly (not from BIP32), wh= ich 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-registratio= n), no rescue protocol can save this UTXO: it will either be stolen or froz= en. > > > >=20 > > > >=20 > > > > > Coverage of non-hashed address types is fundamentally impossible,= because the requirement to allow use of commit-reveal migration would inhe= rently leave such address types still exposed to a quantum attacker. > > > >=20 > > > >=20 > > > > Not true. P2TR UTXOs can be rescued using internal keys as a KA, wh= ich are essentially preimages hidden to the quantum attacker. Pick an inter= nal pubkey `P` with output key `P' =3D P + H(P) * G`, and give `P'` to the = CRQC. Though they can factor `P'`, they cannot guess `P`=C2=A0other than by= brute-force (or Grover's search). > > > >=20 > > > > By default most P2TR software generates the output key with a hidde= n internal key in this way even if no scripts are present (example), and th= is 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 wal= let.=C2=A0 > > > >=20 > > > > The same would apply to any P2PK key generated using hashes, though= I think these would be very rare. > > > >=20 > > > >=20 > > > >=20 > > > > regards, > > > > conduition > > > >=20 > > > > On Tuesday, July 14th, 2026 at 9:44 AM, 'shinobimonkey' via Bitcoin= Development Mailing List wrote: > > > >=20 > > > > > Currently the discussion around how to address the potential risk= of a viable quantum computer centers around two primary issues: the quantu= m-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 remai= n secured by vulnerable ECC based scripts, specifically should these coins = be frozen, and what mechanisms are available to allow legitimate owners to = recover those coins if possible without an attacker having the ability to d= o so.=C2=A0 > > > > >=20 > > > > > This second issue is (and always has been) a very socially conten= tious one, as the common understanding is it is impossible to guarantee wit= h certainty that no user is being left in a position where they are incapab= le of generating a recovery proof, and therefore are forever prevented from= accessing their coins.=C2=A0 > > > > >=20 > > > > > My motivation for writing this is to solve this contention (at le= ast partially) in a manner that can hopefully move discussions forward in a= productive direction rather than lead to two opposing plans of action even= tually colliding in the real world with live implementations of conflicting= rules.=C2=A0 > > > > >=20 > > > > > The current solution landscape as it stands to my understanding i= s:=C2=A0 > > > > >=20 > > > > >=20 > > > > > - BIP 32 hierarchical proofs, as proposed a decade or so ago by= Adam Back 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-s= afe authentication mechanism to be used for spending after a post-quantum s= pending 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 sc= heme where a transaction spending vulnerable ECC inputs must=C2=A0have an e= ncrypted commitment to that exact transaction confirmed in a block with a p= re-determined number of confirmations prior to the decrypted plaintext tran= saction's confirmation, or the decrypted transaction is invalid.=C2=A0 > > > > >=20 > > > > >=20 > > > > > All three of these proposals leave some subset of coins uncovered= . HD proofs are useless for users who generated their keys any other way th= an BIP 32, stateful timestamped proofs are useless for any inactive user or= someone who for any reason does not create them before the creation deadli= ne, and the commit-reveal migration is useless for anyone with an address t= ype that isn't hashed because any attacker would have access to the materia= l 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 c= an be achieved for hashed address types. Coverage of non-hashed address typ= es is fundamentally impossible, because the requirement to allow use of com= mit-reveal migration would inherently leave such address types still expose= d to a quantum attacker.=C2=A0 > > > > >=20 > > > > >=20 > > > > > - Hierarchical proofs cover any BIP 32 user > > > > > - Stateful timestamped proofs cover any active/observant non-BI= P 32 user > > > > > - Commit-reveal covers any non-BIP 32 user who is inactive/not = observant=C2=A0 > > > > >=20 > > > > >=20 > > > > > 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 unab= le to recover 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, a= nd inherently 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 Googl= e 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/b= itcoindev/sdGGYMMWowlFff6Yh8usMel61HVYmV8KPMqT9np2kK7GxPbVaogJ2aJSFe4v16VNL= ef4eDwNgfReiK-7j-sYn1jlXHPoAPWAwNBbSJxEz3M%3D%40protonmail.com. > >=20 > > -- > > You received this message because you are subscribed to the Google Grou= ps "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/bitcoin= dev/XeI-rNO4AO9UCO-CL4K8scZ8VZjc_5ctaY4sw98wepKsOgEQkpExB8eagrO_TqplOUpt9WE= RYxitzsoCaIjoz99M9mfrrIYMKkdMij1_Pls%3D%40proton.me. >=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/gJnvMBYdwA6pJzPtnsuBLrymr9Vs1xQ_xejRrEvET1Tz-FJZ6B_b5z0gaT25Fz2RG1N--cVZi= kyUclGDoLouOTRNVocOTn-fuBuwiyMCs54%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/= EYz75GQ2aP5QVHF_l9zLm8T11xH8jU4w0WfCwzWkB1H0XTSfhdLRF0_Bb4lb7pfsIE3HrX_f9cm= Dpfk-tCcnAjTrKP8DoO2Pk8Bh4JFlQAs%3D%40proton.me. -----------------------b202aea95a1c7b6130c0826694f6b9a8 Content-Type: multipart/related;boundary=---------------------265e4d88ca4151a96ff23dc5ea9fbdf2 -----------------------265e4d88ca4151a96ff23dc5ea9fbdf2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Re-sending this (Aug 4), b= ecause I forgot to hit reply-all :P

Hey Shinobi, thanks for = clarifying your OP. 

To de= al with the xpub problem, a new set of derivation paths can be defined for = each address type which is specced to only use the Electrum protocol for ba= lancing fetching. By only using individual address queries, you avoid the d= isclosure of the xpub for these sets of addresses and create a path where f= or end users a transition can happen potentially even without their awarene= ss. New wallet updates can simply start generating addresses using the new = derivation paths and new protocol for balance fetching.

Interesting idea, and mayb= e it would reduce harm if adopted at scale today, but unfortunately this is= only a forward-secure solution. It does not help users whose pubkeys are a= lready exposed unless they take proactive action and move their coins, in w= hich case why not move the coins to a PQ secure address (once those are ava= ilable)?

They do require proact= ive action, but in the event of failing to do so or losing the proofs after= the deadline, the possibility of HD recovery and commit-reveal migration w= ould cover users in that case.
As i said earlier, th= e issue with pre-registration protocols is: If proactive action is required= , why not just move coins to a PQ-secure address, or lacking that, to one w= hich has a decidable knowledge asymmetry, like P2TR or a hashed address? Th= e juice doesn't seem worth the squeeze to me.

I believe this combination of these recovery mechanisms can achieve 100% recovery coverage for every address type live on the network except P2PK outputs and custom bare scripts with the singular new security assumption of maintaining the secrecy of public keys

<= /div>
I want to be clear about the qualification on your primary claim = here: We can't go back in time and assume people never reused addresses. An= y changes we make to wallet standards, code, or to consensus are only forwa= rd-facing. Existing information cannot be un-leaked. At best we can hope us= ers move coins to PQ secure addresses or at least to addresses which are re= coverable via rescue protocols (i.e. hashed addresses, P2TR).
Technically you're correct, but it's important to be clear that= your assumption excludes a huge (1/3) fraction of today's UTXO= set from the set of "covered" coins. That remaining 1/3 does still stand a= chance to be rescued, but just not with 100% coverage.

To summarize, we have the UTXO set we have, not the one we want, and = we shall have to deal with it as it exists on Q-day: some coins will have e= xposed public keys and some won't. When that time rolls around, the communi= ty shall have to decide what matters more: Preserving as much of that remai= ning 1/3 of the UTXO set as possible, or avoiding all confiscation.
<= div>
regards,
conduition

On Thursday, July 23rd, 2026 at 5:46 PM, 'shinobimonkey' via Bitcoi= n Development Mailing List <bitcoindev@googlegroups.com> wrote:

This is just a rewrite of the original message to address some of conduition=E2=80=99s remarks in his reply, and more concisely state the implicit assumptions of the overall idea. I just belted out the original post in a few minutes while I was buried under work, so hopefully this gets across the scope and assumptions more clearly.

T= here are a number of proposed mechanisms for facilitating the recovery of coins by their legitimate owner by applying new additive encumbrances specifying a new proof of secret knowledge in addition to a signature by a private key, as well as commit-reveal schemes to allow for committing to a transaction spending vulnerable coins and requiring such a commitment to attain a certain number of blocks built upon it before the committed transaction is consensus valid.

N= one of these schemes is capable of providing complete recovery coverage for all coins whose owners still possess a private key if applied blanketly to a given address type. I believe that by layering multiple recovery schemes together additively, and allowing any single one of them to meet the threshold required for spending, 100% coverage can be achieved by taking on only one new security assumption: the requirement to keep your public key/internal script paths secret.

It should also be possible to account for the fact tha= t most users not running their own full node are leaking master public keys to a third party backend server for balance querying.

To deal with the xp= ub problem, a new set of derivation paths can be defined for each address type which is specced to only use the Electrum protocol for balancing fetching. By only using individual address queries, you avoid the disclosure of the xpub for these sets of addresses and create a path where for end users a transition can happen potentially even without their awareness. New wallet updates can simply start generating addresses using the new derivation paths and new protocol for balance fetching.

The only complications I can = see with this is out-of-box middle-ware that is being used to connect wallets to users=E2=80=99 nodes are built around the assumption of xpubs and using Core=E2=80=99s internal wallet. This is almost certain to be a non-issue in the vast majority of cases as it will be a user connecting to their own node, but even in the small number of cases where a user is connecting to a third party node with such software, it can be adapted to use something like Electrum protocol. I don=E2=80=99t see this being a major show stopper.

The xpub issue mitigated, now the interaction of the of dif= ferent recovery mechanisms.

Xpub derivati= on based recovery:

This will cover any BIP 32 based wallet, regardl= ess of what derivation path (?) is used. So this recovery path should encompass both any address generated using legacy derivation paths with exposed public keys, as well as newer derivation paths securing them through the use of the Electrum protocol.

For any hashed-address type (P2PKH= , P2SH, P2WPKH, P2WSH) the derivation proof alone is sufficient, and as conduition pointed out in response to my initial post the internal key can additively be used to make this workable for P2TR addresses that do not use the NUMS point.

This specifically ensures that any user with coins using= these address types can produce a recovery proof without having to take any kind of proactive action before the activation of a fork implementing additive encumbrances on address types. (It=E2=80=99s worth noting however these proofs will be pretty big, which is relevant for stateful proofs).

Stateful timestamped proo= fs

This has been pitched multiple times before I can recall but nev= er really described in detail. Simply the basic components of a signature from the existing encumbrance condition over a new authentication mechanism (a public key for a quantum safe scheme), and a timestamp to prove that this attestation was produced before some pre-defined deadline chosen to expire before a viable quantum computer exists.

This could be pretty simply boiled down to the 1) t= he signature over the new public key/authentication commitment, 2) the timestamp. Given the potential size of ZKPs, and the fact that hash-based signatures can be optimized to ~580 bytes, I think these are still worth considering looking at how much smaller and more efficient with blockspace stateful proofs can be compared to ZKPs.

They do require = proactive action, but in the event of failing to do so or losing the proofs after the deadline, the possibility of HD recovery and commit-reveal migration would cover users in that case.

Commit-reveal migration

For any = hashed address type, the old commit-reveal migration scheme requiring an encrypted commitment to a transaction be confirmed in the blockchain for a pre-defined number of blocks before the plain-text transaction can be considered consensus valid. The secrecy of public keys can be maintained using the new derivation specification, but this will still be consensus valid for coins in legacy derived addresses.

Again, as conduition pointed out in his re= ply to my original post, the internal key forms the basis for a secret inaccessible to an attacker, and can be applied as a requirement for P2TR keyspends as an additional validity requirement while using commit-reveal migration. Any tapscript spends using commit-reveal should work as long as those tapscript paths have never been reused with the same internal variables like public keys.

Wrap up

So I think I=E2=80=99ve covered all my bases in terms of= implicit assumptions and responding to conduitions comments.

Unless I am fund= amentally missing something, or have overlooked important implementation details like those conduition corrected in his replies from my initial post, I believe this combination of these recovery mechanisms can achieve 100% recovery coverage for every address type live on the network except P2PK outputs and custom bare scripts with the singular new security assumption of maintaining the secrecy of public keys (which as noted above can be accomplished with a rather painless migration behind the scenes for users and without the need to go through the process of generating a new master key and migrating funds across seeds).

So I guess, yeah=E2=80=A6what am I ov= erlooking here?




Shinobi

Sent with Proton Mail secure email.

<= div class=3D"protonmail_quote"> On Wednesday, July 15th, 2026 at 12:58 AM, 'conduition' via Bitcoin= Development Mailing List <bitcoindev@googlegroups.com> = wrote:
I don't see what the point of your response is here, given I s= pecifically and explicitly state in the original post that address types re= vealing public keys on-chain are out of scope here, uncoverable in this way= due to the proposal involving commit-reveal as an allowed mechanism.

The words you quoted were written as a counterpoin= t to your claim that "by layering them, and allowing any single one of t= hem to be used, complete coverage of any conceivable key generation me= thod can be achieved for hashed address types." My point was that your = claim is not true because some coins don't have KA's (because of how their = address was generated and used previously) and thus can't be rescued. I use= d satoshi's coins as an example but the same is true of some coins on hashe= d address types (see my reused paper wallet example).

Any UTXO which does have a KA is perfectly rescuable, reg= ardless of the type of address it sits on. It just so happens that some add= ress types encourage more KA's than others (e.g. hashed addresses), but not= all coins on such addresses will have a KA and be recoverable after Q-day = rolls around. Often it's impossible to identify those cases with certainty.=

Again, I don't see the point of the = reply here, as this would be a completely separate recovery mechanism than = the combination of these two/three specific things. These specific mechanis= ms layered together, and applied as an additional encumbrance only on hashe= d address types, ignoring P2TR and P2PK, would achieve complete coverage of= any feasible key generation scheme.
=
You said in your OP that "Coverage of non-hashed addr= ess types is fundamentally impossible", and so you focus mostly on hash= ed addresses in your proposal. My point is that your claim there was= wrong, that P2TR coins can be rescued because they have one or= more KA's, and the text you quoted shows an example of a KA in P2TR which = can be used for rescue.

I point this out because any rescue protocol proposal shou= ld seek to cover as many UTXOs as possible (within reason), so we ought to = cover P2TR coins as well if it's feasible to do so, which it clearly is.

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= mistake.

That's not true, it is highly relevant. If a has= hed address has an EC public key exposed on-chain prior to the activation h= eight of the rescue protocol fork, then we can mark that address as having = no "hashed address knowledge asymmetry", and disallow the use of that sp= ecific KA for coins on that specific address. Other KA's like BI= P32 derivation would remain completely usable for rescue.

The same t= hing is true of revealing your xpubs, which is just as widespread (if not m= oreso) of a practice. That completely undermines the KA that HD recovery pr= oofs depend on.

Also not true. Revealing your account-leve= l (i.e. m/44'/0'/0'=E2=80=8B) xpub does not give a quantum adv= ersary any information about the extended key at the coin-level (i.e. m/44'/0'=E2=80=8B). Wallets typically never share these keys, even = in complex multisig setups. The hardened derivation of the account-level xp= riv key (at m/44'/0'/0') is exactly the quantum hard relation = that the BIP32 KA relies upon, and knowing the account-level xpriv doesn't = give you any help in deriving it from the coin-level parent key. I'd encour= age you to revisit Laolu's thread on the ML and you'= ll see this is exactly what his best ZKP be= nchmark does.

However, revealing your xpub does give a CRQC the ab= ility to forge the hashed-address KA proof, because they can re-derive the = hidden public key, crack it, and forge a signature + KA-proof to steal the = coins. Since xpubs are shared off-chain, validator nodes won't know that th= ey should disable the hashed-address KA for children of the exposed xpub. S= o there is some meat to the argument that we ought not to allow hashed addr= ess KA's at all, because they would encourage selling of xpubs to CRQCs and= enable more theft than would otherwise be possible. I'm personally still u= ndecided on this problem.

I don't see how this is a useful response or= criticism, unless you also want to apply the same degree of criticism to H= D recovery proofs in general as well.

I'm not trying to cr= iticize you or your proposal, other than by correcting false statements. I'= m sorry if my prior reply was confusing, I can write a bit indirectly at ti= mes.
<= br>
Th= e general idea of layering different KA's is excellent, and I fully support= it. But it's also important we be accurate about which coins can and can't= be rescued, as this is a very important factor which ML readers will use t= o weigh the pros/cons of supporting or rejecting a rescue protocol soft-for= k, and as i said earlier, misconceptions abound here.

The most common misconceptio= n I see in this field of research is that people think too much about the p= roving mechanism and not enough about the knowledge asymmetries and hard re= lations. The exact tooling used to prove & authenticate KA's (ZKPs, com= mit/reveal, etc) should IMO be decoupled from the discussion of which coins= can/can't be rescued. Pretty much any KA you can authenticate with a ZKP c= an be authenticated with commit/reveal, and vice-versa.

So there should really be = two discussions:

  1. Which knowledge asymmetries should be allowed for rescu= e?
  2. Which p= roving system should we use to authenticate knowledge asymmetries?

On the subject of (1), I parsed the point of your OP roughly as "mo= re is better" when it comes to KA's, and mostly I agree. Unfortunately we c= an't recover every UTXO, even if you scope it strictly to certain address t= ypes as you do. There will always be confiscation with rescue protocols, un= less you limit yourself only to KA's whose existence can be checked on-chai= n, like the hashed address KA, leaving all other addresses untouched, which= IMO is a bad plan because we'll have poor practical results (1/3 of the su= pply remains to be siezed or frozen).

On (2), I think you may have some misunderst= andings about how commit/reveal works, because you claimed commit/reveal is= not useful for proving KA's in non-hashed address types, which is incorrec= t: Commit/reveal can prove any KA for any UTXO just as well as ZKPs, no mat= ter what address type the coins sit on.

regards,
conduition



On Tuesday, July 14th, 2026 at 6:29 PM, shinobimonkey <shinobius_monk@protonmail.com> wrote:
  • = No matter what tool we use to authenticate KA's, there will exi= st some UTXOs which have no knowledge asymmetries on Q-day. = I suspect Satoshi's coins are chief among them, since they are store= d on P2PK addresses generated by Bitcoin Core's old JBOK wallet system.

I don't see what the point of y= our response is here, given I specifically and explicitly state in the orig= inal post that address types revealing public keys on-chain are out of scop= e here, uncoverable in this way due to the proposal involving commit-reveal= as an allowed mechanism. The whole point of this proposal of these three&n= bsp;(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 address types, leaving P2TR and P2PK as a separate matter. 
  • Not true. P2TR UTXOs can be rescue= d using internal keys as a KA, which are essentially preimages hidden to th= e 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 <= code style=3D"scrollbar-width:thin;scrollbar-color:rgba(0, 0, 0, 0.35) rgba= (0, 0, 0, 0)">P'=E2=80=8B, they cannot guess P other than by brute-force (or Grover's search).

=
Again, I don't see the point of the reply here, as this would be a = completely separate recovery mechanism than the combination of these two/th= ree specific things. These specific mechanisms layered together, and applie= d as an additional encumbrance only on hashed address types, ignoring P2TR = and P2PK, would achieve complete coverage of any feasible key generation sc= heme. 

  • It is sti= ll possible to have a UTXO on a hashed address which contains no KA. C= onsider a paper wallet, generated randomly (not from BIP32), which has alre= ady been spent from previously and so has an EC pubkey exposed on chain.

Whether it was genera= ted with BIP 32 or not is irrelevant if the address is reused, obviously in= a quantum threat scenario address reuse is a fatal mistake. The same thing= is true of revealing your xpubs, which is just as widespread (if not mores= o) of a practice. 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 i= n general as well. 

=
Preparing for a post quantum Bitcoin will require l= ots of ancillary hygiene practice changes and tightening up when it comes t= o managing data like that if we don't want these type of preparatory scheme= s to be undermined by poor practices.  

Accepting this reality, a= nd only applying these three (or I guess two) additional recovery encumbran= ces to hashed address types (i.e. not P2PK and P2TR), any user should be ab= le to recover all of their hashed address secured coins in all situations e= xcept key loss or address reuse (and this is ultimately not special to this= proposal, any recovery or preparatory scheme to deal with quantum short of= just giving users a new address type and them outright migrating will requ= ire that users begin to treat and handle public key material differently fo= r 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= @proton.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 "= 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 h= ttps://groups.google.com/d/msgid/bitcoindev/XeI-rNO4AO9UCO-CL4K8scZ8VZjc_5c= taY4sw98wepKsOgEQkpExB8eagrO_TqplOUpt9WERYxitzsoCaIjoz99M9mfrrIYMKkdMij1_Pl= s%3D%40proton.me.

--
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/gJnvMBYdwA6pJzPtnsuBLrymr9= Vs1xQ_xejRrEvET1Tz-FJZ6B_b5z0gaT25Fz2RG1N--cVZikyUclGDoLouOTRNVocOTn-fuBuwi= yMCs54%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/EYz75G= Q2aP5QVHF_l9zLm8T11xH8jU4w0WfCwzWkB1H0XTSfhdLRF0_Bb4lb7pfsIE3HrX_f9cmDpfk-t= CcnAjTrKP8DoO2Pk8Bh4JFlQAs%3D%40proton.me.
-----------------------265e4d88ca4151a96ff23dc5ea9fbdf2-- -----------------------b202aea95a1c7b6130c0826694f6b9a8-- -----------------------47ce053bc22caddebf390baedb9ba79d 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== -----------------------47ce053bc22caddebf390baedb9ba79d-- --------5851853c409e409f4d66d4c4068b38371cac3752896f7d696b682bcfc60fcd6d Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0Fgmp7LNEJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmdnLJLBYrvnBp853rcqG5XvV7mu764qUK97zAHB xN3/khYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAAqgQD/W1wY20jcjNvxlwHm swTTwEBFWRgagvxU7QOU2kRwJ7cBAL8RG61K9R38kjtXbztFw4gLaHKGHQvU 6uVPDt4OYesF =FZV0 -----END PGP SIGNATURE----- --------5851853c409e409f4d66d4c4068b38371cac3752896f7d696b682bcfc60fcd6d--