From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 14 Jul 2026 22:58:42 -0700 Received: from mail-oo1-f56.google.com ([209.85.161.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wjsdk-0001MH-67 for bitcoindev@gnusha.org; Tue, 14 Jul 2026 22:58:42 -0700 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-6a18f3aba30sf7118681eaf.1 for ; Tue, 14 Jul 2026 22:58:39 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1784095114; cv=pass; d=google.com; s=arc-20260327; b=afnReWr1XP/1AhZIoqfEU6tHuMiXwiqT6N4xuB6MBBzYp+6dwKhSGiywVnL8d6PMs9 Y0iibdjZbUyX3THKUPYxoRO+/Rm9rUQgVawJ9/EbYF8nknglwg+U+5vbYlbVP21qnXsI qx2oI1bdIN6H3rby//aa0gBxszrxfKYpJqdMqkHQkrBnnsmi96o/EFYMdYq5HfrCOJF8 ws7gQ5IFmILwfLjsuauCZ0Z8TX8ojstbh0QoPmXUU0t5yOKGL6O65JbrrRCrOUwwlDse aQ2Eue2dKOrwi8ACEvwADMXDhmNIc00/WFqGHxO6peE1p9Mq++4BMGFDdaVl5M6/t1WU 31WQ== 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=YHGWaQY43eA39koTOwv3dKUE9obkc20t6pbKuCLp34Y=; fh=+AB8yltwj7YkD003BKOpXDLknoJv5xtxA6bCWQZw56k=; b=CzQ0JG6vRdwD0+J7ic0/asiZA7VMrc5JdcH7mbcTWpACj3ou2R4Wj7Ss3U42gi6kHE bfi2arJu/Nj+Rt3POgFSP7EyzkEyh7XSybHH21mXz6+x4Iz1w8reejVNQ7z1f4FLVM0Q r8b8htX4XN1+JcM9McEfGIGOIpFU7UjgSrdCrd205QlHP+DWqapDfXI8s3HQJHTxPE8A eyxWcb0qNjZCO48cO/KnSh1TwS8cuMEUzJxNP70cup1A+lln8P+v5bqA1Ha1KFEQ0MIS EJ/UKHdjUDuDJXjvX5e9DM9H/rmEyGklRQXJBOTV5rXFomPvHo+5CVasqXv6X7twCelc LHPw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=dA3eKVZx; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.19 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=1784095114; x=1784699914; 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=YHGWaQY43eA39koTOwv3dKUE9obkc20t6pbKuCLp34Y=; b=YrWQHAhQKg4MRxep7srvQMAYUPXtq7cB3NHM67QOfukiS5AEl25eSWHz3/yxS2E6xm GJAvWaBexB72WEZvfi3Kq7hGwsWXjIKUQ2qIC9IBfo0lT/ePkQHG8jxJ1OXTV0BlqXvZ lsLTvTJEwonJQwUlI9svdaF6PUgRT4B+BhcLP7vprkPEge5mKXnGjTDNKeS1WoTfSWyi QiCgw2m9QF2KwFM332Kjuc7uZRYLyHICq8zMxQoJ8xy/Jw4UJ+hytJjzalJ32ESrFMIX oSoAT3QuLUTTSiSAYYnutaMQvVb9J7XoFk7IQnMIf9J24Aaa+ks9OvNhXXvw9BWSi4nl qRKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784095114; x=1784699914; 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=YHGWaQY43eA39koTOwv3dKUE9obkc20t6pbKuCLp34Y=; b=KJQ9I/TCFP46Y/Sppnkp4h1ZhAn3w7BRo6qRDKqOHDrMlK+dCd6PfcKCtV1nrAWbXj j9sngVtb14YZ5mkaT5xxb0KW6sVonkThX/OXA8fpRUyTRhhNhRVCD52r8eoeCagxBP6d UphZEdHZWqXn5xUjP+FrwHZ1RUrcdwIUG0B8u794pd5SBFvs2SyRUICQbEA8ELkijcR6 m3Zl7+dP2/uf4sfEC+AyfUcCahbpPZTwLKKzZfz2uCbG0KCigFR0/gFSvZ2IcJJIo5JN r/YmxwyVRb5w1g25GByOT/+ubvRcDx3gBH4tWh/vknzex/OeU0z8wLUtYoQP3AH5CdqP qBiA== X-Forwarded-Encrypted: i=2; AHgh+RowNLUXNZ7KbETIZbjZXQlFompxoGqs1ixws5N0PjLEnc0Kt/kLN4dxtiMCdsvcPPSXiALFQ8VCNbIo@gnusha.org X-Gm-Message-State: AOJu0YwI2lLLO8yhcUeaohfg5DfrgmGon0sq2H7d4Ldhy5vFEip5j8St OWdbxQpnWTei9yCM90oxHTkKB/zWL2QCmhfV6pdg8XkkGLYhOBvDk6gB X-Received: by 2002:a05:6820:80c5:b0:6a3:7722:2e28 with SMTP id 006d021491bc7-6a3d9e6f68fmr1149189eaf.13.1784095113690; Tue, 14 Jul 2026 22:58:33 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPSPGbuVC02EL6rPPTv0hbR7RSGDMS//ZYH7pocivDlTtw==" Received: by 2002:a05:6820:2907:b0:6a3:d777:c4ef with SMTP id 006d021491bc7-6a3d9d31573ls327636eaf.2.-pod-prod-05-us; Tue, 14 Jul 2026 22:58:29 -0700 (PDT) X-Received: by 2002:a05:6808:4d16:b0:4a4:9e18:607a with SMTP id 5614622812f47-4a49e1861bemr55787b6e.21.1784095109039; Tue, 14 Jul 2026 22:58:29 -0700 (PDT) Received: by 2002:a05:6402:5044:b0:670:416a:5ab4 with SMTP id 4fb4d7f45d1cf-69c25337cb2msa12; Tue, 14 Jul 2026 21:17:26 -0700 (PDT) X-Received: by 2002:a05:6402:538b:b0:698:7485:3f12 with SMTP id 4fb4d7f45d1cf-69e19ae48e0mr577351a12.24.1784089044873; Tue, 14 Jul 2026 21:17:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784089044; cv=none; d=google.com; s=arc-20260327; b=dIFJLpkdLwTYrpDVesauNFskERD+MWI4TYSIiWUG2Lse/a67Jc3CJLWbcvbVmY62uH gwXCaY4OG1WH8Sh2daTkLIAsI+hRPiCjJF/C6shK/2i3mm3brc2NPCmd5XeVAGFQLpSn zoUwtiOP/PNUu2eyLSNqaOizSNOLaxZhcNa04BVlR6HXd3FhO3ryD31gKTp38qUhr0ck qSDUZw4EsCvDs77IbXFVRy1+jGXawBxIGrCGmfNpwv7YIcMavCrSW/nrMZ3Rl3zJSqo+ ulxBqzFCrXaCQX7pN1UoVijn2FYpqhXBTenxZzJqIFi1+LNzmOIF8ng7Q9pcXpJ8cy+0 HFnQ== 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=74o28PHkXmrbJi1Ed8roKPQaTi6mIcQ4KHGkg5wJ+8o=; fh=l0aQaLwe4UFBxTQIXrRRpVb3fgkbJqXdfIHFRFgqA/I=; b=rIn69t3Y4SkVgMF8DJb1lJE3taEgHh0MCkXGp7/dxknIToh70EZCE/LlD+j89Q8/Hg Obvze3Q5F6F9e1/gXInIaFh68bJSEdpmwmBOIziDaRY0HOK0G/Wk/m4/spUc9xZp58U4 x/GuTAwhf/7GVYvIaSQJV09N9vQU5FaYIJmmXrKaSJItTcYkTTraHXUNOWoA2KNtheRb 0fAmXMCYle2QliAs9a/XsE8Y3MQmzxcm8EAyA0+I9W+eU/PLcucYcCXvhv4INVPkUIXw iDaljMyVHB2ABdLigvqD1K1DpIkUmTWGmZMxjRJO18ldMFQqWt4SkxKG8AxnHvSI/XE6 9bjQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=dA3eKVZx; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.19 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch. [185.70.43.19]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-69cd29a2726si100834a12.7.2026.07.14.21.17.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2026 21:17:24 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.19 as permitted sender) client-ip=185.70.43.19; Date: Wed, 15 Jul 2026 04:17:17 +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: <9phSoKtu5X4YzlMjNwSDXsmozBcMS7FL3C56xbVMSqd88Rf38Yjv4-mDKRexx8mnpnWGdfsfAUgSQqyYQWz5UeTWymp1M-lU_auC59sARJQ=@protonmail.com> References: <9phSoKtu5X4YzlMjNwSDXsmozBcMS7FL3C56xbVMSqd88Rf38Yjv4-mDKRexx8mnpnWGdfsfAUgSQqyYQWz5UeTWymp1M-lU_auC59sARJQ=@protonmail.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: ea66bd904ac48ce11e91e196a663f81ea9894efb MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------f4eaf692b48ad53afc105149fe6d4600ccee6eba290c3afe0ad033886d1cfa7b"; 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=dA3eKVZx; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.19 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) --------f4eaf692b48ad53afc105149fe6d4600ccee6eba290c3afe0ad033886d1cfa7b Content-Type: multipart/mixed;boundary=---------------------40ca733e194f82972ba539db593de9f4 -----------------------40ca733e194f82972ba539db593de9f4 Content-Type: multipart/alternative;boundary=---------------------bdf78a96de122f1b4d59fc018a796e68 -----------------------bdf78a96de122f1b4d59fc018a796e68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > I don't see what the point of your response is here, given I specifically= and explicitly state in the original post that address types revealing pub= lic 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 counterpoint to your claim that "by = layering them, and allowing any single one of them=C2=A0to be used, complet= e coverage of any conceivable key generation method can be achieved for has= hed address types." My point was that your claim is not true because some c= oins don't have KA's (because of how their address was generated and used p= reviously) and thus can't be rescued. I used satoshi's coins as an example = but the same is true of some coins on hashed address types (see my reused p= aper wallet example). Any UTXO which does=C2=A0have a KA is perfectly rescuable, regardless of th= e type of address it sits on. It just so happens that some address types en= courage 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 comple= tely separate recovery mechanism than the combination of these two/three sp= ecific things. These specific mechanisms layered together, and applied as a= n additional encumbrance only on hashed address types, ignoring P2TR and P2= PK, would achieve complete coverage of any feasible key generation scheme. You said in your OP that "Coverage of non-hashed address types is fundament= ally impossible", and so you focus mostly on hashed addresses in your propo= sal. My point is that your claim there was wrong, that P2TR coins can=C2=A0= be rescued because they have one or more KA's, and the text you quoted show= s an example of a KA in P2TR which can be used for rescue. I point this out because any rescue protocol proposal should 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 hashed address has an EC publi= c key exposed on-chain prior to the activation height of the rescue protoco= l fork, then we can mark that address as having no "hashed address knowledg= e asymmetry", and disallow the use of that specific KA for coins on that sp= ecific address. Other KA's like BIP32 derivation would remain completely us= able for rescue. > The same thing is true of revealing your xpubs, which is just as widespre= ad (if not moreso) of a practice. That completely undermines the KA that HD= recovery proofs depend on. Also not true. Revealing your account-level (i.e. `m/44'/0'/0'`) xpub does = 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, eve= n in complex multisig setups. The hardened derivation of the account-level = 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 you t= o revisit Laolu's thread on the ML and you'll see this is exactly what his = best ZKP benchmark does. 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 xpubs= are shared off-chain, validator nodes won't know that they should disable = the hashed-address KA for children of the exposed xpub. So there is some me= at to the argument that we ought not to allow hashed address KA's at all, b= ecause they would encourage selling of xpubs to CRQCs and enable more theft= than would otherwise be possible. I'm personally still undecided on this p= roblem. > I don't see how this is a useful response or criticism, unless you also w= ant to apply the same degree of criticism to HD recovery proofs in general = as well. I'm not trying to criticize 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 times. The general idea of layering different KA's is excellent, and I fully suppo= rt 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 soft-f= ork, and as i said earlier, misconceptions abound here. The most common misconception I see in this field of research is that peopl= e think too much about the proving mechanism and not enough about the knowl= edge asymmetries and hard relations. The exact tooling used to prove & auth= enticate KA's (ZKPs, commit/reveal, etc) should IMO be decoupled from the d= iscussion of which coins can/can't be rescued. Pretty much any KA you can a= uthenticate with a ZKP can be authenticated with commit/reveal, and vice-ve= rsa. So there should really be two discussions: 1. Which knowledge asymmetries should be allowed for rescue? 2. Which proving system should we use to authenticate knowledge asymmetrie= s? On the subject of (1), I parsed the point of your OP roughly as "more is be= tter" when it comes to KA's, and mostly I agree. Unfortunately we can't rec= over 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, 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 supply rem= ains to be siezed or frozen). On (2), I think you may have some misunderstandings about how commit/reveal= 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 coins= sit on. regards, conduition On Tuesday, July 14th, 2026 at 6:29 PM, shinobimonkey wrote: > - No matter what tool we use to authenticate KA's, there will exist som= e UTXOs which have no knowledge asymmetries on Q-day.=C2=A0I suspect Satosh= i's coins are chief among them, since they are stored on P2PK addresses gen= erated 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 specifically= and explicitly state in the original post that address types revealing pub= lic 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 point = of this proposal of these three=C2=A0(or as you pointed out validly, just t= he ZKP + commit/reveal would achieve the same coverage and the stateful pro= ofs 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, whic= h are essentially preimages hidden to the quantum attacker. Pick an interna= l 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 comple= tely separate recovery mechanism than the combination of these two/three sp= ecific things. These specific mechanisms layered together, and applied as a= n additional encumbrance only on hashed address types, ignoring P2TR and P2= PK, would achieve complete coverage of any feasible key generation scheme.= =C2=A0 >=20 >=20 > - It is still possible to have a UTXO on a hashed address which contain= s no KA.=C2=A0Consider a paper wallet, generated randomly (not from BIP32),= which has already been spent from previously and so has an EC pubkey expos= ed on chain. > =20 >=20 >=20 >=20 > 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. The same thing is true of revealing your xpubs, which is just as w= idespread (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 respons= e or criticism, unless you also want to apply the same degree of criticism = to HD recovery proofs in general as well.=C2=A0 >=20 >=20 > Preparing for a post quantum Bitcoin will require lots of ancillary hygie= ne practice changes and tightening up when it comes to managing data like t= hat 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) ad= ditional recovery encumbrances to hashed address types (i.e. not P2PK and P= 2TR), any user should be able to recover all of their hashed address secure= d coins in all situations except key loss or address reuse (and this is ult= imately 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 o= utright migrating will require that users begin to treat and handle public = 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 with a= lot of misinformation flying around. > >=20 > > Before we even think about rescue protocols like ZKPs, pre-registration= , or commit/reveal, it is important to understand what a rescue protocol ev= en 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 witness t= o 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 hones= t coin-holder knows, but which a future CRQC will not know and cannot easil= y compute or guess. > >=20 > > Examples of knowledge asymmetries include: > >=20 > > - BIP32 parent keys and chain codes (this is what Lalu used in his RI= SC0 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 s= tandardized means to authenticate oneself using these KA's in consensus, an= d because KA's are not always perfectly private (e.g. hashed public keys).= =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 mo= ve onto explicitly quantum-safe addresses in time. > >=20 > >=20 > > - Lalu's ZK-STARK benchmarks show how to authenticate a BIP32 KA usin= g the RISC0 STARK prover, but generally a ZKP can prove any computation, an= d allows fast verification.=C2=A0 > > - Commit/reveal strategies can prove any KA that can be verified by p= ublishing 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 alr= eady 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 can pr= e-register to create a new KA, why not simply move to a quantum-safe addres= s? 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 for no= w 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 BIP32 = 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 matter = what tool we use to authenticate KA's, there will exist some UTXOs which ha= ve no knowledge asymmetries on Q-day. I suspect Satoshi's coins are chief a= mong them, since they are stored on P2PK addresses generated by Bitcoin Cor= e'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 "reco= verable" and "unrecoverable" sets of UTXOs.=C2=A0 > >=20 > > The unrecoverable set unfortunately cannot be rescued from a QC, no mat= ter what rescue protocol we devise, because there exists no provable mathem= atical distinction between the honest user and the future CRQC. The only ro= ute 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 multiple = 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 KA's = to prioritize authenticating, so we kinda just have to go by dead-reckoning= . > >=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=A0t= o be used, complete coverage of any conceivable key generation method can b= e achieved for hashed address types. > >=20 > >=20 > > 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 = has already been spent from previously and so has an EC pubkey exposed on c= hain. 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. > >=20 > >=20 > > > Coverage of non-hashed address types is fundamentally impossible, bec= ause the requirement to allow use of commit-reveal migration would inherent= ly 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, which = are essentially preimages hidden to the quantum attacker. Pick an internal = 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 bru= te-force (or Grover's search). > >=20 > > By default most P2TR software generates the output key with a hidden in= ternal key in this way even if no scripts are present (example), and this i= s standardized in BIP86 so I believe most P2TR wallets have a KA and so can= be rescued. Even if they didn't have an internal key, any P2TR address can= use BIP32 as a KA since most P2TR addresses are derived from an HD wallet.= =C2=A0 > >=20 > > The same would apply to any P2PK key generated using hashes, though I t= hink these would be very rare. > >=20 > >=20 > >=20 > > regards, > > conduition > >=20 > > On Tuesday, July 14th, 2026 at 9:44 AM, 'shinobimonkey' via Bitcoin Dev= elopment 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 quantum-sa= fe 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 se= cured by vulnerable ECC based scripts, specifically should these coins be f= rozen, and what mechanisms are available to allow legitimate owners to reco= ver those coins if possible without an attacker having the ability to do so= .=C2=A0 > > >=20 > > > This second issue is (and always has been) a very socially contentiou= s one, as the common understanding is it is impossible to guarantee with ce= rtainty that no user is being left in a position where they are incapable o= f generating a recovery proof, and therefore are forever prevented from acc= essing their coins.=C2=A0 > > >=20 > > > My motivation for writing this is to solve this contention (at least = partially) in a manner that can hopefully move discussions forward in a pro= ductive direction rather than lead to two opposing plans of action eventual= ly colliding in the real world with live implementations of conflicting rul= es.=C2=A0 > > >=20 > > > The current solution landscape as it stands to my understanding is:= =C2=A0 > > >=20 > > >=20 > > > - BIP 32 hierarchical proofs, as proposed a decade or so ago by Ada= m Back and recently implemented as a proof-of-concept by roasbeef.=C2=A0 > > > - Non-deterministic stateful proofs constructed and timestamped bef= ore a deadline, showing a vulnerable ECC key signing off on a quantum-safe = authentication mechanism to be used for spending after a post-quantum spend= ing restriction is activated > > > - Tim Ruffing/Tadge Dryja's idea (I apologize, but I forget who was= the actual originator of the proposal) of a commit-reveal migration scheme= where a transaction spending vulnerable ECC inputs must=C2=A0have an encry= pted commitment to that exact transaction confirmed in a block with a pre-d= etermined number of confirmations prior to the decrypted plaintext transact= ion'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 than B= IP 32, stateful timestamped proofs are useless for any inactive user or som= eone who for any reason does not create them before the creation deadline, = and the commit-reveal migration is useless for anyone with an address type = that isn't hashed because any attacker would have access to the material ne= eded to create a valid pre-commitment for a spend.=C2=A0 > > >=20 > > > However, by layering them, and allowing any single one of them=C2=A0t= o be used, complete coverage of any conceivable key generation method can b= e achieved for hashed address types. Coverage of non-hashed address types i= s fundamentally impossible, because the requirement to allow use of commit-= reveal migration would inherently leave such address types still exposed to= a quantum attacker.=C2=A0 > > >=20 > > >=20 > > > - 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 obse= rvant=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 unable t= o recover their coins is if they have lost access to their private keys. Th= at case is completely outside of the scope of any of these proposals, and i= nherently impossible to cover.=C2=A0 > > >=20 > > > Shinobi > > >=20 > > > Sent with Proton Mail secure email. > > >=20 > > > -- > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+unsubscribe@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/sdGGYMMWowlFff6Yh8usMel61HVYmV8KPMqT9np2kK7GxPbVaogJ2aJSFe4v16VNLef4e= DwNgfReiK-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/= XeI-rNO4AO9UCO-CL4K8scZ8VZjc_5ctaY4sw98wepKsOgEQkpExB8eagrO_TqplOUpt9WERYxi= tzsoCaIjoz99M9mfrrIYMKkdMij1_Pls%3D%40proton.me. -----------------------bdf78a96de122f1b4d59fc018a796e68 Content-Type: multipart/related;boundary=---------------------ee9360adb54796d517e742692202a744 -----------------------ee9360adb54796d517e742692202a744 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't see what the point of your response is here, given I specifically = and explicitly state in the original post that address types revealing publ= ic keys on-chain are out of scope here, uncoverable in this way due to the = proposal involving commit-reveal as an allowed mechanism.
<= /blockquote>

The words you quoted were written as a counterpoint to your cl= aim that "by layering them, and allowing any single one of them to = be used, complete coverage of any conceivable key generation method 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 used satoshi's = coins as an example but the same is true of some coins on hashed address ty= pes (see my reused paper wallet example).

Any UT= XO which does have a KA is perfectly rescuable, regardless of t= he type of address it sits on. It just so happens that some address types e= ncourage more KA's than others (e.g. hashed addresses), but not all coins o= n 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 combinat= ion of these two/three specific things. These specific mechanisms layered t= ogether, and applied as an additional encumbrance only on hashed address ty= pes, ignoring P2TR and P2PK, would achieve complete coverage of any feasibl= e key generation scheme.

<= /span>
You said in your OP that "Coverage of non-hashed address types is= fundamentally impossible", and so you focus mostly on hashed 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 should seek to c= over as many UTXOs as possible (within reason), so we ought to cover P2TR c= oins as well if it's feasible to do so, which it clearly is.

Whether i= t 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 hashed address = has an EC public key exposed on-chain prior to the activation height of the= rescue protocol fork, then we can mark that address as having no "hashed a= ddress knowledge asymmetry", and disallow the use of that specific KA for coins on that specific address. Other KA's like BIP32 derivati= on would remain completely usable for rescue.

The same thing is true o= f revealing your xpubs, which is just as widespread (if not moreso) of a pr= actice. That completely undermines the KA that HD recovery proofs depend on= .

Also not true. Revealing your account-level (i.e. = m/44'/0'/0'=E2=80=8B) xpub does not give a quantum adversary any inf= ormation 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 mul= tisig setups. The hardened derivation of the account-level 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 h= elp in deriving it from the coin-level parent key. I'd encourage you to rev= isit Laolu's thread on the ML and you'll see this is exactly what his best ZKP benchmark does= .

=
Howev= er, revealing your xpub does give a CRQC the ability to forge t= he hashed-address KA proof, because they can re-derive the hidden public ke= y, crack it, and forge a signature + KA-proof to steal the coins. Since xpu= bs are shared off-chain, validator nodes won't know that they should disabl= e the hashed-address KA for children of the exposed xpub. So there is some = meat to the argument that we ought not to allow hashed address KA's at all,= because they would encourage selling of xpubs to CRQCs and enable more the= ft than would otherwise be possible. I'm personally still undecided on this= problem.

I don't see how this is a useful response or criticism, unle= ss you also want to apply the same degree of criticism to HD recovery proof= s in general as well.

I'm not trying to criticize you or y= our proposal, other than by correcting false statements. I'm sorry if my pr= ior reply was confusing, I can write a bit indirectly at times.

The general idea o= f layering different KA's is excellent, and I fully support it. But it's al= so 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 soft-fork, and as i said= earlier, misconceptions abound here.

The most common misconception I see in this = field of research is that people think too much about the proving mechanism= and not enough about the knowledge asymmetries and hard relations. The exa= ct tooling used to prove & authenticate KA's (ZKPs, commit/reveal, etc)= should IMO be decoupled from the discussion of which coins can/can't be re= scued. Pretty much any KA you can authenticate with a ZKP can be authentica= ted with commit/reveal, and vice-versa.

So there should really be two discussions:=

<= /div>
<= ol data-editing-info=3D"{"orderedStyleType":1,"unorderedStyl= eType":1}" style=3D"margin-top: 0px; margin-bottom: 0px;" data-listcha= in=3D"__List_Chain_1100">
  • Which knowledge asymmetries should be allowed for rescue?
    • Which proving system sh= ould we use to authenticate knowledge asymmetries?

    On the s= ubject of (1), I parsed the point of your OP roughly as "more is better" wh= en it comes to KA's, and mostly I agree. Unfortunately we can't recover eve= ry 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 y= ourself only to KA's whose existence can be checked on-chain, like the hash= ed address KA, leaving all other addresses untouched, which IMO is a bad pl= an because we'll have poor practical results (1/3 of the supply remains to = be siezed or frozen).

    On (2), I think you may have some misunderstandings about ho= w commit/reveal 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 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 &= 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/XeI-rN= O4AO9UCO-CL4K8scZ8VZjc_5ctaY4sw98wepKsOgEQkpExB8eagrO_TqplOUpt9WERYxitzsoCa= Ijoz99M9mfrrIYMKkdMij1_Pls%3D%40proton.me.
    -----------------------ee9360adb54796d517e742692202a744-- -----------------------bdf78a96de122f1b4d59fc018a796e68-- -----------------------40ca733e194f82972ba539db593de9f4 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== -----------------------40ca733e194f82972ba539db593de9f4-- --------f4eaf692b48ad53afc105149fe6d4600ccee6eba290c3afe0ad033886d1cfa7b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmpXCboJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmf0tZg5LONDGqUjvozGe8t7MWNtV5izI0LgZYA+ J26KSBYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAB/cAD/RSyUNCoSW+qxXJ0q 84oiAThJJGroExyrri4DO976DZIBAI6cUlO6C8H1UoWrcuXCE6s2OtlVIdIb SjowHyjJhHMM =BPEV -----END PGP SIGNATURE----- --------f4eaf692b48ad53afc105149fe6d4600ccee6eba290c3afe0ad033886d1cfa7b--