Delivery-date: Tue, 19 Aug 2025 14:11:08 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uoTbl-0004Kq-E9 for bitcoindev@gnusha.org; Tue, 19 Aug 2025 14:11:08 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-30ccebab467sf10430536fac.2 for ; Tue, 19 Aug 2025 14:11:05 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1755637859; cv=pass; d=google.com; s=arc-20240605; b=RZ+pAHvqic5EmSHaUhsoMfhek0jN5U7OtmC9felfE59cMuM42UYMFtbwGxyVfIT12Z bRZZ5mNSLs9UJ1kFo/YOkodNmZ0Q+C3ZgjzsTrm22kNOkI4pWauISX6oIWUAhERDuFe6 NeB8VB2IcjQ3X0EVG9sXTo0W6Xl126o5GqD0R42nHmeokg3TgOlqKmPVwS9x//JPan3L Tn/tP8UzvzDCJHtPSedFSd9u2cod4RMrUtgm9aScqrwrv9nKvK1IfVz7IBQpUmiXCWo5 0qRH7B2YF6iwFjNADHUNisZ6/DuEhxcnJKC+5lXZmZ30ww2aY/qAx7HteKWFRsxIaDK9 091A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; 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=RQ6s0lDMtJ/QKQ0uwTJ3+WZh4xlQW9RXxTdt5nnmdhI=; fh=VI2DvhpS50TTdGdAsKMHRRC5X/MuIyRpcrUcDScGbww=; b=XW4Y34XJx+pw5Jr4tPXRqG1QjwC1kDptBft4kyQ8XSloWDgMhbuYg6VhS6lzFsUSOY cTmqd2cy55iTeEXOSidtSEMRd0nxEbA0oO3m9NhZfAWfROYidHLIay3U/jMLnLhPZ0lo PCLodwduqV2eLjvEhjGZ2x/kK51L+LVhYKO7hx1e6X9PfPLIqGVx0ekdGhtVBRMr4Jjf ahyaafbLDk+1x9mdxiA1YQIcXfJEyxoHZQMiAls6+iADdz0jc8vbYQ+kviRuJ8nAHN95 6dct3+9aRQXVwpKqIocjSMNvQEHG7uW7H6+4ad/k/go/qHrMyG1tEewBHWj+h81rTDWp f7ow==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=elNrcTrB; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.28 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=20230601; t=1755637859; x=1756242659; 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:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=RQ6s0lDMtJ/QKQ0uwTJ3+WZh4xlQW9RXxTdt5nnmdhI=; b=agjUjy5qn/RzU21u1ZRNoGHIUv+AeOit/VCTiTJ3HH8tgYtwlDE2jfqgkKKIGBQMwv ZCWFOrbsuFvXpb6MpAUQFyOTrN93bZRK69yWn/+m5UBMAfe91szI3blrjMEpB6SbuQhJ qsHoBORXz3uzalscOW/r8NFVYBrpfX+wV12mO3O6SEB7SwYeaMf592AKWXGR+KyGbkv1 5NBh9uCXcpb3TeXi7AvPk7ZRlLGNPQcvpvkNtWJv+RKvw4hlwgzuPT/5lGcaLKdo5njR p6IoNMQuNLEvBn2sDUDfZbh4S6lfSj0t69Y/MCbvc/ZaXTsi4QReqRThZRXDML4eJNiq rjMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755637859; x=1756242659; 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: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; bh=RQ6s0lDMtJ/QKQ0uwTJ3+WZh4xlQW9RXxTdt5nnmdhI=; b=f6JlPHDXyGiN+MbSrET/qy8+YRZMrZ2hR+NiyEJ0PM4j1U0CjJx3/Jk05brkf60B4p yLoTS8A86DdjUhLBDrMrKjmrEab4DP2Z751Xq/gss+IfNSfLt1SGpO3SoyYfchi8XMz0 /3NIpSfB/BpAN0bD7o//tZyouMOJmcTLiQ8Ol5+vVjNsChkyMiprz9y1hRMv9IwiP2l5 02cS0Bw5AiPCWvlgMCnOuV/e7kixGG0/mp3GL408aahbByaTeuoUaj7zOKT9oSr4s+Gz 1zC/ocjgd+C0DDkgSppwG+KQaw/EWr6Hjq+QuxchhQIp30YRaUpJMxcgkeRdZHYkPG/Y st8w== X-Forwarded-Encrypted: i=2; AJvYcCXwy4T9F4WNgx1+XVEUQ26h9jjcMmj6INu48WU3+k94lQt2ypJIubz3PV/8swZ26KXBL9Y7iTgRtxzO@gnusha.org X-Gm-Message-State: AOJu0YxY/tTAJHBgMTn8uLCR++FHQkB3K2TkeCLhjUDaoZMdMT2MpNmH GTxtraOCI2Fn+twdRQfhgV8/q7DdDc+mhkX+K+b2z0g80ea9utthHN8R X-Google-Smtp-Source: AGHT+IGAHIoph/iT090b5C44mfZe0InC4VlFAK6lonl4uuc5DH1yrKg6u7M29E4p5cguSA7ROioCAg== X-Received: by 2002:a05:6871:8905:b0:300:d9f4:dfaa with SMTP id 586e51a60fabf-311229b1f63mr348161fac.27.1755637859262; Tue, 19 Aug 2025 14:10:59 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcxTZA2OKKNrItEWaBbCCqBNEwoN4aiW2ocZAta9RwcPQ== Received: by 2002:a05:6870:a984:b0:2ff:8c0f:7759 with SMTP id 586e51a60fabf-30cce772abals2877772fac.0.-pod-prod-09-us; Tue, 19 Aug 2025 14:10:55 -0700 (PDT) X-Received: by 2002:a05:6808:6f82:b0:41d:8847:5466 with SMTP id 5614622812f47-4377202f742mr282291b6e.16.1755637855761; Tue, 19 Aug 2025 14:10:55 -0700 (PDT) Received: by 2002:a05:6504:5408:b0:2bc:427:fa2 with SMTP id a1c4a302cd1d6-2c0a809450amsc7a; Tue, 19 Aug 2025 08:01:12 -0700 (PDT) X-Received: by 2002:a05:6512:159a:b0:55c:e521:165a with SMTP id 2adb3069b0e04-55e007aecefmr857418e87.20.1755615669182; Tue, 19 Aug 2025 08:01:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1755615669; cv=none; d=google.com; s=arc-20240605; b=iP9yWf4Y9RcF6HqROvfNESg8TRnZGMFmbzkp87vXmaG8Itt+KSIDvV2g5mFd52MStM TMB+W/Uh8tilhHtt7kh4MG6+QwHBpgwCFsVTXKXABjxj5XXi45J0rZD5QzuaL7AabAUA fz5fo2E9JnOzSyP2jXpxtp2uzX6bH9+n5DG3PlmWCdc/mQ4jRkOBu0C5BA/lZjuGKgtp CY0NpKVYrBckKQnRWvaPf3mAaHyZT31ovLWX2B2M9JpZkiMaZcphWUtKzbudYhu/+Ybb eNyd4+kGmOrtbwuUJ/gAIP6linfAvam93P9LpRCERo4e6QaZ1WPb89hQl7pyvRHzh/mF WoMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=2JaYaaOZNwadOwyGLDZ3ehkaBi5u4Q+VcTM9C1cGOiM=; fh=yX/ghkT6dP+ZKvK7/b8r8aOQXrA/vrdjWu8n4+C271k=; b=AWBWYbvsEbJsHI0261sR2WTUaVtPGAIfxatdvoGYXtN/8FO/D/pu7VrVgRjLXg0rFz fuN5kLCz+1GkTqmOrhzw2XDcn0N9njbI3ZY7s5F/DlTLPE0i5G9fPvZECcznCOqZsh14 XmDBsZh8ajS13LT/0AH9AEhqIzTr1ALQNTvUe2NCWcLocfJYOexv/bkILC1TskSOXjRr 5kB1+VBolnhEEECRKWSc1236qkIgXx7Ie9sghj9+d/3xz6ylDCZY9+Sl645gLSAyhrjf Jl/iBEamgbE3H62OlSmY9duUw67nF0TzlUfpDDSL+X7WCPri5KYVSl/pG/qMMEpyqq10 h1wg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=elNrcTrB; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.28 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch. [79.135.106.28]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-55cf4437ab3si175504e87.2.2025.08.19.08.01.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Aug 2025 08:01:09 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.28 as permitted sender) client-ip=79.135.106.28; Date: Tue, 19 Aug 2025 15:01:02 +0000 To: James T From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: [BIP Proposal] No burn, Quantum Migration Proposal, Quantum Secure Asset Verification & Escrow (QSAVE) Message-ID: <2gC13oDaC58JAFFSQ0qBve4whtVS0W5oVLNuxaWEfBFvYzTt_rHAhU6Asdb33xwK3mm6DZ6xuK83N8crsEdryPvxH5DaY6J1uRJXdiNg2TA=@proton.me> In-Reply-To: <2e635098-a8f5-43d6-b8e9-5971ba8ba218n@googlegroups.com> References: <2e635098-a8f5-43d6-b8e9-5971ba8ba218n@googlegroups.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 0b63e6143eabba8c962f096ad6bfb825d9fb235f MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------c332c9882902573073ef16bc3e561b7f715d5635cba7b060c974663f86b671fc"; 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=elNrcTrB; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.28 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.2 (+) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------c332c9882902573073ef16bc3e561b7f715d5635cba7b060c974663f86b671fc Content-Type: multipart/mixed;boundary=---------------------613201bdd13d8b2e732bd90cad4f5413 -----------------------613201bdd13d8b2e732bd90cad4f5413 Content-Type: multipart/alternative;boundary=---------------------41c78c948804fe9c6713522288293f65 -----------------------41c78c948804fe9c6713522288293f65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi James, > Remember, if the burn happens, tens of thousands of people will open safe= ty deposit boxes full of Bitcoin addresses and find them zeroed out. Only o= ur solution provides a solution to this and preserves the Digital Gold prom= ise. That's simply not true. There are many cryptographic solutions discussed on= this mailing list which appear to allow coin recovery after=C2=A0Q-day wit= hout=C2=A0resorting to centralizing trust in fallible KYC systems. Zero kno= wledge proofs (STARKs or SNARKs) and commit/reveal protocols are the first = that come to mind. These could recover a majority of users' at-risk coins, = as most wallets from the past 10 years either (a) use hardened BIP32 key de= rivation and/or (b) have unexposed public keys. These upgrades can all be d= one as a soft fork if designed correctly. These tricks aren't perfect though: UTXOs belonging to bare-P2PK addresses,= paper wallets, or brain wallets, which were generated without hardened BIP= 32 and have previously exposed pubkeys posted on-chain. For these UTXOs it = is impossible (AFAIK) for anyone to distinguish an honest witness from a CR= QC-attack witness. It is also hard to identify these addresses, because we = can't tell just from looking at a public key whether it was generated from = BIP32 or not. We can guess based on the key's earliest usage timestamp (bef= ore/after BIP32 introduction), but there is no rigorous mathematical test w= e can apply. It's naive to say "only your solution" is the correct one. > The Bitcoin dev team proposing a burn solution is the same problem you ar= ticulate: a small group of people (80% of miners) voting to burn coins. The bitcoin ecosystem is a complex feedback loop between miners, users, and= developers. It's more complicated than just miners voting on stuff. Miners= can mine whatever chain they want, but if bitcoin node-runners don't want = to follow their chain, then miners are wasting energy mining coins they won= 't be able to spend, except with other miners on the same chain.=C2=A0 Likewise, if core developers publish code which is too controversial, node-= runners will fork bitcoin core and run different code. We're seeing this to= day with mempool policy debates (Knots vs Core). Just imagine the fragmenta= tion that a KYC system would cause by comparison. But node-runners don't have all the power either. If miners boycott a chain= , that chain is weakened and can be more easily 51% attacked. If developers= stop working on a chain's codebase, it will ossify. What you're proposing in OP is wildly different than the status quo. IIUC, = you're suggesting that core devs should publish code which gives full contr= ol of select (quantum-vulnerable) UTXOs to a specific group of people who a= re trusted to properly redistribute those coins to their original hodlers (= or their heirs). Even if everyone adopts the code (unlikely) and even if th= e KYC system works perfectly (dubious), it's a really bad precedent to set = - See Craig Wright's failed attempts to legally pressure core devs into har= d-forking satoshi's coins over to him. > It would be really helpful if the Bitcoin consensus said, "We favor white= hat actors protecting Bitcoin". Although there are no Bitcoin terms and co= nditions or EULA, this would massively protect white hats. Maybe we should draft an open letter to the quantum computing companies ask= ing them to treat bitcoin nicely, and telling them what we'd like them to d= o? We could have various public bitcoin-related groups and personalities si= gn on. I have no clue what the content should be... regards, conduition On Monday, August 18th, 2025 at 11:12 AM, 'James T' via Bitcoin Development= Mailing List wrote: > I am suggesting that Bitcoin elects people who can arbitrate reasonable c= laims. The Bitcoin dev team proposing a burn solution is the same problem y= ou articulate: a small group of people (80% of miners) voting to burn coins= . I don't see a way around this fundamental problem. The keys will fail in = the future; some human intervention is going to happen. Remember, if the bu= rn happens, tens of thousands of people will open safety deposit boxes full= of Bitcoin addresses and find them zeroed out. Only our solution provides = a solution to this and preserves the Digital Gold promise. >=20 > We like to assume there is no human intervention in Bitcoin and it's all = algorithmic, but that's not true. There is an army of people working to sec= ure Bitcoin behind the scenes, including upfront KYC/AML and after-the-fact= recovery by private companies and law enforcement when there is a hack. Th= is all works on a worldwide basis today. >=20 > No lawyers have been involved in the drafting of our proposal. I would we= lcome input, but it's really an engineering problem. Once Bitcoin keys can = no longer be relied on, what do we do to establish ownership? Deleting owne= rship is certainly one solution, but I just don't think it is a fair one. >=20 > We are proposing our solution as either a hard fork or a no-fork. Either = way, we still have to solve the problem of a room full of elected experts t= o adjudicate claims (obviously, they would be distributed worldwide, and of= ten it could be achieved algorithmically). >=20 > In the no-fork solution, we encourage - maybe reward - white hat quantum = actors to recover vulnerable Bitcoin under lost property law. If it's claim= ed, then it's returned; if not claimed, it's invested for the public good. = This is then a race between white hat and black hat actors. BUT most laws w= ill deter white hat actors because it might be considered computer misuse. = It would be really helpful if the Bitcoin consensus said, "We favor white h= at actors protecting Bitcoin". Although there are no Bitcoin terms and cond= itions or EULA, this would massively protect white hats. >=20 > In the hard fork solution, instead of burning the coins, they go into the= recovery process, and here the Bitcoin consensus has made a clear protocol= decision, and there is no white hat actor risk. >=20 > I apologize for the lack of technical details at this point. We have a lo= t of code written, and I did make a note to that effect in my submission, b= ut that bit seems to have been cut off. The recovery process has to obey th= e law and be distributable worldwide, and be fair, and I think it is possib= le to do all that. Not simple, of course. In the meantime, there are plenty= of best practices that can be implemented to better protect and prepare th= e network, which I know are in process. >=20 > Best, >=20 >=20 > James T >=20 >=20 > On Friday, August 8, 2025 at 7:07:25=E2=80=AFPM UTC-7 conduition wrote: >=20 > > Hi James, > > This is a curious idea, though I'm not seeing any technical details of = how this "BIP" would maintain Bitcoin's value as a distributed system. It m= ore-or-less sounds like you're suggesting to vest the power of quantum-reco= very using legal mechanisms (e.g. KYC, real-world evidence, etc)... in a gr= oup of people working in an office somewhere? Surely you realize that's imp= ractical and un-scaleable. Besides, even if you had all the manpower needed= to do it, no one who owns Bitcoin would run a node which subscribes to suc= h consensus rules. A huge portion of the supply on that (hardforked) chain = would be effectively under the total control of a select few. Who elects th= ese people? > >=20 > > It sounds like something a corporate lawyer would cook up if asked how = to solve the post-quantum-rescue problem. Not to say that legal opinions on= quantum migration are unwanted. I'm sure there are interesting legal quest= ions to be debated around the rights of property holders in case of a possi= ble quantum-freeze. But this proposal at least is DOA because KYC cannot be= the answer, for practical and ethical reasons. > >=20 > > Perhaps, independent of any technical consensus upgrades, it would be w= ise to encourage quantum adversaries to become benevolent, somehow. I'm not= sure what that looks like. If a quantum freeze doesn't happen, there ought= to be legal guidelines for how quantum giants like Google or IBM should be= have given their newfound quantum weaponry. It'll be impossible to fully en= force any such rules, but if they want to play nice, someone should tell th= em what "playing nice" actually looks like. > >=20 > > regards, > > conduition > > On Thursday, August 7, 2025 at 5:26:07=E2=80=AFPM UTC-7 James T wrote: > >=20 > > > This BIP Proposal is an alternative to QRAMP or a quantum winner-take= s-all approach to the migration from a pre- to post quantum blockchain. It = could be implemented as a hard fork OR as a consensus that quantum actors c= an legitimately move funds to safe addresses for protective custody and pub= lic good. It could even go forward with no consensuses at all since it is f= unctionally equivalent to a quantum winner-takes-all at the protocol level. > > >=20 > > > BIP: TBD > > >=20 > > > Title: Quantum Secure Asset Verification & Escrow (QSAVE) > > >=20 > > > Author: James Tagg > > >=20 > > > Status: Draft > > >=20 > > > Type: Standards Track > > >=20 > > > Layer: Consensus (Consensus / Soft Fork / Hard Fork) > > >=20 > > > Created: > > >=20 > > > License: > > >=20 > > > Abstract > > >=20 > > > This BIP proposes QSAVE (Quantum Secure Asset Verification & Escrow) = - a non-sovereign wealth fund providing protective custody for Bitcoin vuln= erable to quantum attack (see Appendix for detailed vulnerability assessmen= t). QSAVE preserves 100% of the principal for rightful owners while using g= enerated returns to fund the protocol and global public good. It provides a= n alternative to the QRAMP (Quantum Resistant Asset Migration Protocol) pro= posal (which makes coins unspendable) or taking no action (which allows qua= ntum appropriation, which many view as theft). This proposal addresses coin= s that are dormant but acknowledges there may be coins that have quantum wa= termarks but have not migrated to quantum addresses. A separate BIP proposa= l will address this case. > > >=20 > > > Motivation > > >=20 > > > Chain analysis reveals 3.5-5.5 million Bitcoin (~17-28% of circulatin= g supply) have exposed public keys vulnerable to quantum attack (see Append= ix: Quantum Vulnerability Assessment for detailed breakdown). > > >=20 > > > With sufficient education and proactive migration, a significant port= ion of the 2-4M BTC in reused addresses could be moved to quantum-safe addr= esses before the threat materializes. Modern wallets are increasingly imple= menting best practices such as always sending change to fresh addresses. Ho= wever, some portion will inevitably remain unprotected when quantum compute= rs arrive due to: > > >=20 > > > - Owners who don't follow Bitcoin news > > >=20 > > > - Forgotten wallets discovered years later > > >=20 > > > - Cold storage assumed long term safe > > >=20 > > > - Users who die and whose heirs have yet to uncover the keys > > >=20 > > > - Users who procrastinate or underestimate the threat > > >=20 > > > When quantum computers capable of running Shor's algorithm arrive, th= e remaining vulnerable coins face two equally problematic outcomes: > > >=20 > > > 1. Quantum appropriation: First actors with quantum computers take th= e coins > > >=20 > > > 2. Forced burning: The community burns coins preventatively (by makin= g them unspendable), breaking Bitcoin's promise as a store of value > > >=20 > > > This BIP proposes a third way: QSAVE - protective custody that preser= ves ownership rights and puts dormant capital to work for humanity. > > >=20 > > > Note on "Theft": Bitcoin's protocol operates purely through cryptogra= phic proofs, without built-in concepts of ownership or theft=E2=80=94these = are legal constructs that vary by jurisdiction. The community holds diverge= nt views: some consider using advanced technology to derive private keys as= legitimate within Bitcoin's rules, while others view it as unethical appro= priation of others' funds. > > >=20 > > > QSAVE addresses both perspectives: If quantum key derivation is consi= dered fair game, then racing to secure vulnerable coins before malicious ac= tors is simply good-faith participation in the system. If it's deemed uneth= ical, then the community needs a consensus solution that balances property = rights with Bitcoin's algorithmic nature. Either way, protective custody pr= eserves coins for their rightful owners rather than allowing them to be sto= len or destroyed. > > >=20 > > > The Inheritance Vulnerability Window > > >=20 > > > Consider the "Auntie Alice's Bitcoin" scenario: Alice stores Bitcoin = in cold storage as inheritance for her grandchildren, with keys secured in = a safe deposit box. She doesn't follow Bitcoin news and remains unaware of = quantum threats. She passes away and by the time her heirs discover the wal= let, quantum computers capable of deriving private keys have emerged. > > >=20 > > > Three outcomes are possible: > > >=20 > > > 1. Without protection: Quantum actors take the grandchildren's inheri= tance > > >=20 > > > 2. With burning: The network destroys legitimate inheritance funds > > >=20 > > > 3. With protective custody: Heirs can claim their inheritance with pr= oper evidence (will, keys, proof of box opening) > > >=20 > > > This illustrates why we cannot assume dormant equals lost and why pro= tective custody is the only approach that preserves legitimate ownership ri= ghts. The inability to distinguish between lost coins and stored coins is t= he fundamental reason protective custody is essential. > > >=20 > > > Principles > > >=20 > > > 1. Preserve the principal - 100% of recovered Bitcoin remains availab= le for rightful owners to reclaim at any time > > >=20 > > > 2. Ensure long-term store of value by avoiding any pre-emptive burn (= making coins unspendable) > > >=20 > > > 3. Avoid market shocks by keeping principal locked while only using g= enerated returns > > >=20 > > > 4. Generate returns for the benefit of humanity through conservative = yield strategies > > >=20 > > > 5. Protect the Chain, ensuring smooth transition to post-quantum era > > >=20 > > > 6. Enable priority recovery through quantum watermark system > > >=20 > > > Recovery Process > > >=20 > > > Recovery Timing Matrix > > >=20 > > > | Scenario | Timing | Method | Requirements | > > >=20 > > > |---------------------------|-------------------------------|--------= -------------------|----------------------------| > > >=20 > > > | M-Day (Migration Day) | Pre-Q-Day with Hard Fork | Consensus-based = migration | Hard fork implementation | > > >=20 > > > | Q-Day (Quantum Day) | When quantum computers arrive | White-hat rec= overy race | No protocol changes needed | > > >=20 > > > | Emergency Cut-over | Catastrophic quantum break | Parallel chain mi= gration | Rapid consensus response | > > >=20 > > > | Overlapping M/Q-Day | Both processes active | Concurrent migrations= | Mempool competition | > > >=20 > > > Recovery Protocol > > >=20 > > > All recovery transactions follow the same pattern: > > >=20 > > > 1. Move vulnerable coins to protective custody addresses > > >=20 > > > 2. Leave OP_RETURN notification on original address with recovery inf= ormation > > >=20 > > > 3. Prioritize by dormant period and value at risk > > >=20 > > > 4. Quantum watermarks permit immediate return of funds > > >=20 > > > Consensus Layer > > >=20 > > > Implementation varies based on timing and consensus level (see Recove= ry Timing Matrix above): > > >=20 > > > No Action: PQP (Post Quantum Pay) wallet technology - purely commerci= al/user layer > > >=20 > > > Consensus: Community endorsement strengthens legal position for white= -hat recovery > > >=20 > > > Soft Fork: Taproot V2/BIP-360 enables voluntary migration (doesn't pr= otect dormant accounts) > > >=20 > > > Hard Fork: Required for pre-Q-Day recovery or emergency cut-over scen= arios > > >=20 > > > Implementation Timeline > > >=20 > > > Phase 0: Launch - Live from Day One > > >=20 > > > - DAO Governance: Active voting on proposals from day one > > >=20 > > > - Initial Publication: Non-Sovereign Wealth Fund Proposal Discussion > > >=20 > > > Phase 1: Consensus Building & Infrastructure (Months 1-6) > > >=20 > > > - Community discussion and refinement (while QD3 registrations contin= ue) > > >=20 > > > - Technical specification development for advanced features > > >=20 > > > - Technical specification for backup chain > > >=20 > > > - Legal framework establishment with states > > >=20 > > > - Coordination with regulatory bodies for good-faith protections > > >=20 > > > - Signing the main quantum computer makers to the recovery principles > > >=20 > > > - Begin backup chain development using post-quantum signature schemes= (e.g., FIPS 204 ML-DSA) > > >=20 > > > Phase 2: Enhanced Infrastructure (Months 7-12) > > >=20 > > > - Smart contract deployment for fund management > > >=20 > > > - Advanced governance system implementation > > >=20 > > > - Claim verification protocol enhancements > > >=20 > > > - Complete backup chain synchronization and cut over process > > >=20 > > > - Multi-signature protective custody addresses pre-established > > >=20 > > > Phase 3: Recovery Preparation (Months 13-18) > > >=20 > > > - Public notification system deployment > > >=20 > > > - Recovery transaction staging > > >=20 > > > - Security audits of all systems > > >=20 > > > - Publish recovery chain software > > >=20 > > > - Public notice period initiation (6 months before recovery) > > >=20 > > > - Broadcast intent to recover specific UTXOs > > >=20 > > > - Allow time for unregistered owners to move coins or register claims > > >=20 > > > - Publish recovery transactions in mempool but not mine > > >=20 > > > Phase 4: Active Recovery (Month 19+) > > >=20 > > > - Execute recovery per Recovery Timing Matrix > > >=20 > > > - Use Recovery Protocol for all transactions > > >=20 > > > - Manage protective custody with multi-signature addresses > > >=20 > > > - Process ownership claims per Claim Verification Protocol > > >=20 > > > - Initiate fund operations per Fund Architecture > > >=20 > > > Proposed Fund Architecture > > >=20 > > > +-----------------------------------------+ > > >=20 > > > | Recovered Bitcoin | > > >=20 > > > | (Principal - 100% Preserved) | > > >=20 > > > +-----------------------------------------+ > > >=20 > > > | > > >=20 > > > v > > >=20 > > > +-----------------------------------------+ > > >=20 > > > | Conservative Strategies | > > >=20 > > > | (3-5% Annual Return) | > > >=20 > > > | * Lightning Network Liquidity | > > >=20 > > > | * DeFi Lending Protocols | > > >=20 > > > | * Bitcoin-backed Stablecoins | > > >=20 > > > +-----------------------------------------+ > > >=20 > > > | > > >=20 > > > v > > >=20 > > > +-----------------------------------------+ > > >=20 > > > | Interest Distribution | > > >=20 > > > | (Public Good Only) | > > >=20 > > > | * Open Source Development | > > >=20 > > > | * Quantum Security Research | > > >=20 > > > | * Global Infrastructure | > > >=20 > > > | * AI Safety & Alignment | > > >=20 > > > +-----------------------------------------+ > > >=20 > > > Claim Verification Protocol > > >=20 > > > Original owners can reclaim their coins at ANY time by providing: > > >=20 > > > Prior to Break (Q-Day): > > >=20 > > > 1. Cryptographic Proof: Message signed with their key > > >=20 > > > 2. Optional Supporting Evidence: Transaction history, temporal patter= ns if there is any doubt/dispute on Q-Day date > > >=20 > > > Post Break: > > >=20 > > > 1. Identity Verification: Since quantum computers will create publicl= y available databases of all exposed private keys (similar to existing data= bases of classically compromised keys), possession of the private key alone= is insufficient. > > >=20 > > > 2. Required Evidence: > > >=20 > > > - government-issued identification > > >=20 > > > - Historical transaction knowledge > > >=20 > > > - Temporal pattern matching > > >=20 > > > - Social recovery attestations > > >=20 > > > This approach recognizes that post-quantum, private key possession be= comes meaningless as proof of ownership since quantum-derived key databases= will be publicly available. > > >=20 > > > Three-tier Evidence Hierarchy > > >=20 > > > The claim verification process employs a three-tier evidence hierarch= y to evaluate ownership claims with staking and slashing to prevent fraud a= nd partial time based awards in case of partial proof. Evidence strength: > > >=20 > > > - Tier 1: Cryptographic proofs with verifiable pre-break timestamps (= signatures in pre-quantum blocks and similar immutable records) > > >=20 > > > - Tier 2: Third-party records (exchange logs, bankruptcy filings, pro= bate rulings, trustee statements) > > >=20 > > > - Tier 3: Supporting materials (affidavits, chain-of-inheritance, med= ia coverage, witness declarations) > > >=20 > > > Governance Structure > > >=20 > > > The QSAVE fund requires robust decentralized governance to ensure pro= per stewardship of recovered assets. The governance framework must balance = efficiency with decentralization while maintaining absolute commitment to p= rincipal preservation. > > >=20 > > > Core Governance Principles: > > >=20 > > > - Quadratic Voting: Reduces influence of large stakeholders while mai= ntaining democratic participation > > >=20 > > > - Multi-Council Structure: Separates technical, allocation, and audit= functions to prevent capture > > >=20 > > > - Constraints: Only generated returns may be allocated (per principle= #1) > > >=20 > > > - Emergency Procedures: Supermajority (75%) required for emergency ac= tions; freeze of recovery process can be executed by authorized individuals= until quarum can be established. > > >=20 > > > Governance Bodies: > > >=20 > > > - Technical Council: Oversees security, recovery operations, and tech= nical infrastructure > > >=20 > > > - Allocation Council: Manages distribution of generated returns to fo= r the public good thru charitable donation, impact investing or research fu= nding. > > >=20 > > > - Audit Council: Provides independent oversight and transparency repo= rting > > >=20 > > > Safeguards: > > >=20 > > > - Staggered terms to ensure continuity > > >=20 > > > - Public transparency of all decisions > > >=20 > > > - Time-locked implementations for non-emergency changes > > >=20 > > > - Immutable smart contracts for principal preservation > > >=20 > > > Rationale > > >=20 > > > The QSAVE protocol represents the optimal technical implementation fo= r addressing quantum vulnerability. Unlike binary approaches (burn or allow= appropriation), QSAVE introduces a third path that aligns with Bitcoin's c= ore principles while solving practical challenges. > > >=20 > > > Technical Neutrality > > >=20 > > > QSAVE maintains implementation flexibility: > > >=20 > > > - Fork-neutral: Works with or without protocol changes (see Recovery = Timing Matrix) > > >=20 > > > - Price-neutral: Markets have already priced quantum risk (per BlackR= ock ETF disclosures) > > >=20 > > > - Liquidity-neutral: Principal preservation prevents market disruptio= n > > >=20 > > > Implementation Advantages > > >=20 > > > - Transparent Operations: All movements follow Recovery Protocol > > >=20 > > > - Decentralized Governance: See Governance Structure section > > >=20 > > > - Auditable Recovery: See Claim Verification Protocol > > >=20 > > > - Progressive Deployment: Phase 0 operational from day one > > >=20 > > > Risk Mitigation > > >=20 > > > The protocol addresses key operational risks: > > >=20 > > > - Race Condition Risk: Pre-positioned infrastructure for rapid Q-Day = response > > >=20 > > > - Legal Clarity: Aligns with established lost & found precedents > > >=20 > > > - Governance Capture: Quadratic voting and mandatory principal preser= vation constraints > > >=20 > > > - Technical Failure: Backup chain with post-quantum signatures ensure= s continuity > > >=20 > > > Legal Framework Considerations > > >=20 > > > The recovery process aligns with established legal principles in many= jurisdictions. Under precedents like People v. Jennings (NY 1986), tempora= ry custody without intent to permanently deprive does not constitute larcen= y. This is analogous to moving lost property to a lost & found =E2=80=94 a = universally accepted practice despite technically involving "taking without= permission." > > >=20 > > > In the United States alone, over 400 million items are moved to lost = & found departments annually without legal consequence. QSAVE applies this = same principle to digital assets vulnerable to quantum attack, providing a = protective custody mechanism that preserves ownership rights. > > >=20 > > > Furthermore, the U.S. Department of Justice's policy on good-faith se= curity research provides additional legal clarity for recovery operators ac= ting to protect vulnerable assets from quantum threats. > > >=20 > > > Legal clarification and Jurisdiction choices need to be made. > > >=20 > > > The Sovereign Law Paradox > > >=20 > > > Without protective frameworks, law-abiding states face a critical dis= advantage. Bad actors operating from jurisdictions with weak or non-existen= t cryptocurrency regulations can exploit quantum vulnerabilities with impun= ity, while good-faith actors in law-compliant states remain paralyzed by le= gal uncertainty. This creates a systematic wealth transfer from citizens of= law-abiding nations to criminal organizations and rogue states. The strong= est property laws paradoxically create the weakest defense against quantum = theft. Jurisdictions are developing good faith exemptions to their computer= security laws and these will need to accelerate. > > >=20 > > > Economic Impact > > >=20 > > > Positive Effects > > >=20 > > > - Removes quantum uncertainty from Bitcoin price > > >=20 > > > - Funds public good without inflation or taxation (see Fund Architect= ure) > > >=20 > > > - Preserves Bitcoin's fixed supply economics (Principle #1) > > >=20 > > > - Creates new model for decentralized capital allocation > > >=20 > > > Neutral Effects > > >=20 > > > - No net change in circulating supply (coins preserved, not spent) > > >=20 > > > - Market has already priced in quantum risk per BlackRock ETF terms > > >=20 > > > - Interest generation creates minimal selling pressure > > >=20 > > > Appendix: Quantum Vulnerability > > >=20 > > > Vulnerable Address Categories > > >=20 > > > | Category | Address Type | Key Status | Quantum Vulnerable | Est. BT= C (M) | Recovery Priority | Notes | > > >=20 > > > |-----------------------|------------------|------------|------------= --------|--------------|-------------------|-------------------------------= -----| > > >=20 > > > | P2PK Outputs | P2PK | Various | Yes | 1.9-2.0 | Critical | Directly= exposed public keys | > > >=20 > > > | Taproot (All) | P2TR | Various | Yes | 0.5-1 | Critical | ALL Tapro= ot addresses exposed | > > >=20 > > > | Reused P2PKH (spent) | P2PKH | Various | Yes | 2-4 | High | Spent = =3D pubkey revealed | > > >=20 > > > | Reused P2WPKH (spent) | P2WPKH | Various | Yes | ~0.5-1 | High | Mo= dern but still vulnerable | > > >=20 > > > | Unused P2PKH | P2PKH | Various | No | 6-8 | Protected | Hash only; = quantum-safe | > > >=20 > > > | Unused P2WPKH | P2WPKH | Various | No | 4-6 | Protected | Modern sa= fe until spent | > > >=20 > > > | Script Hash | P2SH/P2WSH | Various | Mostly No | 3-4 | Protected | = Generally safe (depends on script) | > > >=20 > > > | Total Vulnerable | | | Yes | 3.5-5.5M | | 17-28% of supply | > > >=20 > > > Quantum Risk > > >=20 > > > There is a lack of consensus on the timeline for the quantum threat o= ther than it appears to be accelerating: > > >=20 > > > Expert Consensus: > > >=20 > > > - Conservative estimates (NIST IR 8413): 2035-2050 > > >=20 > > > - Aggressive projections: 2027-2035 > > >=20 > > > - Industry leaders (including Brock Pierce at Tokenize 2025): "Yes, q= uantum was 20 years away until recently. It's likely this decade. Most peop= le are now pinpointing it at 2027. I think that's early, but there's some b= right minds working on it." > > >=20 > > > Recent Technical Advances: > > >=20 > > > - Google's 2025 research: Demonstrated that 2048-bit RSA encryption c= ould theoretically be broken by a quantum computer with 1 million noisy qub= its running for one week (20-fold decrease from previous estimate) > > >=20 > > > - Jensen Huang (NVIDIA CEO): Shifted to optimistic stance, stating qu= antum computing is "reaching an inflection point" and we're "within reach o= f being able to apply quantum computing" to solve problems "in the coming y= ears" > > >=20 > > > Regulatory Requirements: > > >=20 > > > - U.S. National Security Systems must use quantum-resistant algorithm= s for new acquisitions after January 1, 2027 (NSA CNSA 2.0) > > >=20 > > > - Given 1-5 year government procurement cycles, blockchain proposals = today must be quantum-proof > > >=20 > > > References > > >=20 > > > 1. NIST IR 8413 - "Status Report on the Third Round of the NIST Post-= Quantum Cryptography Standardization Process", July 2022. > > >=20 > > > https://doi.org/10.6028/NIST.IR.8413 > > >=20 > > > 2. NSA CNSA 2.0 - "Commercial National Security Algorithm Suite 2.0 F= AQ", September 7, 2022. > > >=20 > > > https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0= _FAQ_.PDF > > >=20 > > > 3. Google Quantum AI - "Quantum Advantage in Error Correction", Natur= e, 2025. > > >=20 > > > Demonstrated 99.85% reduction in required quantum resources. > > >=20 > > > 4. Jensen Huang - "Nvidia CEO says quantum computing is at an inflect= ion point", Channel News Asia, June 11, 2025. > > >=20 > > > https://www.channelnewsasia.com/business/nvidia-ceo-says-quantum-comp= uting-inflection-point-5174861 > > >=20 > > > 5. Global Risk Institute - "Quantum Threat Timeline 2025: Executive P= erspectives on Barriers to Action", 2025. > > >=20 > > > https://globalriskinstitute.org/publication/quantum-threat-timeline-2= 025-executive-perspectives-on-barriers-to-action/ > > >=20 > > > 6. Brock Pierce - "Million Dollar Bitcoin CONFIRMED! Brock Pierce & M= ichael Terpin Drop BOMBS at Tokenize! 2025." YouTube, timestamp 18:10. > > >=20 > > > https://www.youtube.com/watch?v=3DDhYO1Jxmano > > >=20 > > > 7. Satoshi Nakamoto - BitcoinTalk Forum post, 2010. "If it happens gr= adually, we can transition to something stronger." > > >=20 > > > https://bitcointalk.org/index.php?topic=3D3120.0 > > >=20 > > > 8. FIPS 204 - "Module-Lattice-Based Digital Signature Standard", Augu= st 2024. > > >=20 > > > Specifies CRYSTALS-Dilithium (ML-DSA). > > >=20 > > > 9. BIP 341 - "Taproot: SegWit version 1 spending rules", January 2020= . > > >=20 > > > https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki > > >=20 > > > 10. BlackRock iShares Bitcoin Trust - Prospectus acknowledging quantu= m computing risk to Bitcoin holdings, 2024. > > >=20 > > > 11. Mosca, M. - "Quantum Threat Timeline," University of Waterloo, 20= 23. > > >=20 > > > Estimates 2035-2040 timeline for quantum threats to cryptography. >=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/2e635098-a8f5-43d6-b8e9-5971ba8ba218n%40googlegroups.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/= 2gC13oDaC58JAFFSQ0qBve4whtVS0W5oVLNuxaWEfBFvYzTt_rHAhU6Asdb33xwK3mm6DZ6xuK8= 3N8crsEdryPvxH5DaY6J1uRJXdiNg2TA%3D%40proton.me. -----------------------41c78c948804fe9c6713522288293f65 Content-Type: multipart/related;boundary=---------------------86e48fec93d8ed8861f7e152f49b3f0c -----------------------86e48fec93d8ed8861f7e152f49b3f0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi James,

<= blockquote style=3D"border-left: 3px solid rgb(200, 200, 200); border-top-c= olor: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); border-bo= ttom-color: rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 10= 2);">
Remember, if the = burn happens, tens of thousands of people will open safety deposit boxes fu= ll of Bitcoin addresses and find them zeroed out. Only our solution provide= s a solution to this and preserves the Digital Gold promise.

That's simply not true. There are many cryptograph= ic solutions discussed on this mailing list which appear to allow coin reco= very after Q-day without resorting to centraliz= ing trust in fallible KYC systems. Zero knowledge proofs (STARKs or SNARKs)= and commit/reveal = protocols are the first that come to mind. These could recover = a majority of users' at-risk coins, as most wallets from the past 10 years = either (a) use hardened BIP32 key derivation and/or (b) have unexposed publ= ic keys. These upgrades can all be done as a soft fork if designed correctl= y.

<= div>Th= ese tricks aren't perfect though: UTXOs belonging to bare-P2PK addresses, p= aper wallets, or brain wallets, which were generated without hardened BIP32= have previously exposed pubkeys posted on-chain. For these UT= XOs it is impossible (AFAIK) for anyone to distinguish an honest witness fr= om a CRQC-attack witness. It is also hard to identify these addresses, beca= use we can't tell just from looking at a public key whether it was generate= d from BIP32 or not. We can guess based on the key's earliest usage timesta= mp (before/after BIP32 introduction), but there is no rigorous mathematical= test we can apply.
<= br>
It's naive to say "only your solution" is the correct one.

The Bitcoin dev team proposing a burn solution is the same = problem you articulate: a small group of people (80% of miners) voting to b= urn coins.

The bitcoin ecosystem is= a complex feedback loop between miners, users, and developers. It's more c= omplicated than just miners voting on stuff. Miners can mine whatever chain= they want, but if bitcoin node-runners don't want to follow their chain, t= hen miners are wasting energy mining coins they won't be able to spend, exc= ept with other miners on the same chain. 

Likewise, if core developers pub= lish code which is too controversial, node-runners will fork bitcoin core a= nd run different code. We're seeing this today with mempool policy debates = (Knots vs Core). Just imagine the fragmentation that a KYC system would cau= se by comparison.

But node-runners don't have all the power either. If miners b= oycott a chain, that chain is weakened and can be more easily 51% attacked.= If developers stop working on a chain's codebase, it will ossify.

What you're = proposing in OP is wildly different than the status quo. IIUC, you're sugge= sting that core devs should publish code which gives full control of select= (quantum-vulnerable) UTXOs to a specific group of people who are trusted t= o properly redistribute those coins to their original hodlers (or their hei= rs). Even if everyone adopts the code (unlikely) and even if the KYC system= works perfectly (dubious), it's a really bad precedent to set - See Craig = Wright's failed attempts to legally pressure core devs into hard-forking sa= toshi's coins over to him.

It would be really helpful if the Bitcoi= n consensus said, "We favor white hat actors protecting Bitcoin". Although = there are no Bitcoin terms and conditions or EULA, this would massively pro= tect white hats.

Maybe we should = draft an open letter to the quantum computing companies asking them to trea= t bitcoin nicely, and telling them what we'd like them to do? We could have= various public bitcoin-related groups and personalities sign on.

=
I have no clue what = the content should be...

=
regards,
conduition
On Monday, August 18th, 2025 at 11:12 AM, 'James T' via Bitcoin Dev= elopment Mailing List <bitcoindev@googlegroups.com> wrote:
I am suggesting that Bitcoin elects people who can = arbitrate reasonable claims. The Bitcoin dev team proposing a burn solution= is the same problem you articulate: a small group of people (80% of miners= ) voting to burn coins. I don't see a way around this fundamental problem. = The keys will fail in the future; some human intervention is going to happe= n. Remember, if the burn happens, tens of thousands of people will open saf= ety deposit boxes full of Bitcoin addresses and find them zeroed out. Only = our solution provides a solution to this and preserves the Digital Gold pro= mise.

We like to assume there is no human interven= tion in Bitcoin and it's all algorithmic, but that's not true. There is an = army of people working to secure Bitcoin behind the scenes, including upfro= nt KYC/AML and after-the-fact recovery by private companies and law enforce= ment when there is a hack. This all works on a worldwide basis today.
=

No lawyers have been involved in the drafting of our pr= oposal. I would welcome input, but it's really an engineering problem. Once= Bitcoin keys can no longer be relied on, what do we do to establish owners= hip? Deleting ownership is certainly one solution, but I just don't think i= t is a fair one.

We are proposing our solution as = either a hard fork or a no-fork. Either way, we still have to solve the pro= blem of a room full of elected experts to adjudicate claims (obviously, the= y would be distributed worldwide, and often it could be achieved algorithmi= cally).

In the no-fork solution, we encourage - ma= ybe reward - white hat quantum actors to recover vulnerable Bitcoin under l= ost property law. If it's claimed, then it's returned; if not claimed, it's= invested for the public good. This is then a race between white hat and bl= ack hat actors. BUT most laws will deter white hat actors because it might = be considered computer misuse. It would be really helpful if the Bitcoin co= nsensus said, "We favor white hat actors protecting Bitcoin". Although ther= e are no Bitcoin terms and conditions or EULA, this would massively protect= white hats.

In the hard fork solution, instead of= burning the coins, they go into the recovery process, and here the Bitcoin= consensus has made a clear protocol decision, and there is no white hat ac= tor risk.

I apologize for the lack of technical de= tails at this point. We have a lot of code written, and I did make a note t= o that effect in my submission, but that bit seems to have been cut off. Th= e recovery process has to obey the law and be distributable worldwide, and = be fair, and I think it is possible to do all that. Not simple, of course. = In the meantime, there are plenty of best practices that can be implemented= to better protect and prepare the network, which I know are in process.

Best,


James = T


On Friday, August 8, 2025 at 7:07:25=E2=80=AFPM UTC-7 cond= uition wrote:
= Hi James,

This is a curious idea, though I'm not seeing = any technical details of how this "BIP" would maintain Bitcoin's value as a= distributed system. It more-or-less sounds like you're suggesting to vest = the power of quantum-recovery using legal mechanisms (e.g. KYC, real-world = evidence, etc)... in a group of people working in an office somewhere? Sure= ly you realize that's impractical and un-scaleable. Besides, even if you ha= d all the manpower needed to do it, no one who owns Bitcoin would run a nod= e which subscribes to such consensus rules. A huge portion of the supply on= that (hardforked) chain would be effectively under the total control of a = select few. Who elects these people?

It sounds lik= e something a corporate lawyer would cook up if asked how to solve the post= -quantum-rescue problem. Not to say that legal opinions on quantum migratio= n are unwanted. I'm sure there are interesting legal questions to be debate= d around the rights of property holders in case of a possible quantum-freez= e. But this proposal at least is DOA because KYC cannot be the answe= r, for practical and ethical reasons.

Perhaps, ind= ependent of any technical consensus upgrades, it would be wise to encourage= quantum adversaries to become benevolent, somehow. I'm not sure what that = looks like. If a quantum freeze doesn't happen, there ought to be legal gui= delines for how quantum giants like Google or IBM should behave given their= newfound quantum weaponry. It'll be impossible to fully enforce any such r= ules, but if they want to play nice, someone should tell them what "= playing nice" actually looks like.

regards,
<= div>conduition
On Thursday, August 7, 2025 at 5:26:07=E2=80=AFPM UTC-7 James T = wrote:

This BIP Proposal i= s an alternative to QRAMP or a quantum winner-takes-all approach to the mig= ration from a pre- to post quantum blockchain. It could be implemented as a= hard fork OR as a consensus that quantum actors can legitimately move funds to safe addresses for protective custod= y and public good. It could even go forward with no consensuses at all sinc= e it is functionally equivalent to a quantum winner-takes-all at the protoc= ol level.

BIP: TBD<= /u>

Title: Quantum Secu= re Asset Verification & Escrow (QSAVE)

Author: James Tagg =

Status: Draft

Type: Standards Tra= ck

Layer: Consensus (C= onsensus / Soft Fork / Hard Fork)

Created:<= /u>

License: =

Abstract<= /u>

This BIP proposes Q= SAVE (Quantum Secure Asset Verification & Escrow) - a non-sovereign wea= lth fund providing protective custody for Bitcoin vulnerable to quantum att= ack (see Appendix for detailed vulnerability assessment). QSAVE preserves 100% of the principal for rightful owners whi= le using generated returns to fund the protocol and global public good. It = provides an alternative to the QRAMP (Quantum Resistant Asset Migration Pro= tocol) proposal (which makes coins unspendable) or taking no action (which allows quantum appropriation, whic= h many view as theft). This proposal addresses coins that are dormant but a= cknowledges there may be coins that have quantum watermarks but have not mi= grated to quantum addresses. A separate BIP proposal will address this case.

Motivation

Chain analysis reve= als 3.5-5.5 million Bitcoin (~17-28% of circulating supply) have exposed pu= blic keys vulnerable to quantum attack (see Appendix: Quantum Vulnerability= Assessment for detailed breakdown).

With sufficient edu= cation and proactive migration, a significant portion of the 2-4M BTC in re= used addresses could be moved to quantum-safe addresses before the threat m= aterializes. Modern wallets are increasingly implementing best practices such as always sending change to fresh address= es. However, some portion will inevitably remain unprotected when quantum c= omputers arrive due to:

- Owners who don't = follow Bitcoin news

- Forgotten wallets= discovered years later

- Cold storage assu= med long term safe

- Users who die and= whose heirs have yet to uncover the keys

- Users who procras= tinate or underestimate the threat

When quantum comput= ers capable of running Shor's algorithm arrive, the remaining vulnerable co= ins face two equally problematic outcomes:

1. Quantum appropri= ation: First actors with quantum computers take the coins

2. Forced burning: = The community burns coins preventatively (by making them unspendable), brea= king Bitcoin's promise as a store of value

This BIP proposes a= third way: QSAVE - protective custody that preserves ownership rights and = puts dormant capital to work for humanity.

Note on "Theft": Bi= tcoin's protocol operates purely through cryptographic proofs, without buil= t-in concepts of ownership or theft=E2=80=94these are legal constructs that= vary by jurisdiction. The community holds divergent views: some consider using advanced technology to derive private keys as l= egitimate within Bitcoin's rules, while others view it as unethical appropr= iation of others' funds.

QSAVE addresses bot= h perspectives: If quantum key derivation is considered fair game, then rac= ing to secure vulnerable coins before malicious actors is simply good-faith= participation in the system. If it's deemed unethical, then the community needs a consensus solution that balan= ces property rights with Bitcoin's algorithmic nature. Either way, protecti= ve custody preserves coins for their rightful owners rather than allowing t= hem to be stolen or destroyed.

The Inheritance Vul= nerability Window

Consider the "Aunti= e Alice's Bitcoin" scenario: Alice stores Bitcoin in cold storage as inheri= tance for her grandchildren, with keys secured in a safe deposit box. She d= oesn't follow Bitcoin news and remains unaware of quantum threats. She passes away and by the time her heirs disc= over the wallet, quantum computers capable of deriving private keys have em= erged.

Three outcomes are = possible:

1. Without protecti= on: Quantum actors take the grandchildren's inheritance

2. With burning: Th= e network destroys legitimate inheritance funds

3. With protective = custody: Heirs can claim their inheritance with proper evidence (will, keys= , proof of box opening)

This illustrates wh= y we cannot assume dormant equals lost and why protective custody is the on= ly approach that preserves legitimate ownership rights. The inability to di= stinguish between lost coins and stored coins is the fundamental reason protective custody is essential.=

Principles

1. Preserve the pri= ncipal - 100% of recovered Bitcoin remains available for rightful owners to= reclaim at any time

2. Ensure long-term= store of value by avoiding any pre-emptive burn (making coins unspendable)=

3. Avoid market sho= cks by keeping principal locked while only using generated returns

4. Generate returns= for the benefit of humanity through conservative yield strategies

5. Protect the Chai= n, ensuring smooth transition to post-quantum era

6. Enable priority = recovery through quantum watermark system

Recovery Process=

Recovery Timing Mat= rix

| Scenario = | Timing | Method | Requ= irements |

|------------------= ---------|-------------------------------|---------------------------|-----= -----------------------|

| M-Day (Migration = Day) | Pre-Q-Day with Hard Fork | Consensus-based migration | Hard= fork implementation |

| Q-Day (Quantum Da= y) | When quantum computers arrive | White-hat recovery race | No p= rotocol changes needed |

| Emergency Cut-ove= r | Catastrophic quantum break | Parallel chain migration | Rapi= d consensus response |

| Overlapping M/Q-D= ay | Both processes active | Concurrent migrations | Memp= ool competition |

Recovery Protocol

All recovery transa= ctions follow the same pattern:

1. Move vulnerable = coins to protective custody addresses

2. Leave OP_RETURN = notification on original address with recovery information

3. Prioritize by do= rmant period and value at risk

4. Quantum watermar= ks permit immediate return of funds

Consensus Layer<= /u>

Implementation vari= es based on timing and consensus level (see Recovery Timing Matrix above):<= u>

No Action: PQP (Pos= t Quantum Pay) wallet technology - purely commercial/user layer

Consensus: Communit= y endorsement strengthens legal position for white-hat recovery

Soft Fork: Taproot = V2/BIP-360 enables voluntary migration (doesn't protect dormant accounts)

Hard Fork: Required= for pre-Q-Day recovery or emergency cut-over scenarios

Implementation Time= line

Phase 0: Launch - L= ive from Day One

- DAO Governance: A= ctive voting on proposals from day one

- Initial Publicati= on: Non-Sovereign Wealth Fund Proposal Discussion

Phase 1: Consensus = Building & Infrastructure (Months 1-6)

- Community discuss= ion and refinement (while QD3 registrations continue)<= /p>

- Technical specifi= cation development for advanced features

- Technical specifi= cation for backup chain

- Legal framework e= stablishment with states

- Coordination with= regulatory bodies for good-faith protections

- Signing the main = quantum computer makers to the recovery principles

- Begin backup chai= n development using post-quantum signature schemes (e.g., FIPS 204 ML-DSA)<= u>

Phase 2: Enhanced I= nfrastructure (Months 7-12)

- Smart contract de= ployment for fund management

- Advanced governan= ce system implementation

- Claim verificatio= n protocol enhancements

- Complete backup c= hain synchronization and cut over process

- Multi-signature p= rotective custody addresses pre-established

Phase 3: Recovery P= reparation (Months 13-18)

- Public notificati= on system deployment

- Recovery transact= ion staging

- Security audits o= f all systems

- Publish recovery = chain software

- Public notice per= iod initiation (6 months before recovery)

- Broadcast inten= t to recover specific UTXOs

- Allow time for = unregistered owners to move coins or register claims

- Publish recover= y transactions in mempool but not mine

Phase 4: Active Rec= overy (Month 19+)

- Execute recovery = per Recovery Timing Matrix

- Use Recovery Prot= ocol for all transactions

- Manage protective= custody with multi-signature addresses

- Process ownership= claims per Claim Verification Protocol

- Initiate fund ope= rations per Fund Architecture

Proposed Fund Archi= tecture

+------------------= -----------------------+

| Recovere= d Bitcoin |

| (Principal -= 100% Preserved) |

+------------------= -----------------------+

|<= u>

v<= u>

+------------------= -----------------------+

| Conservati= ve Strategies |

| (3-5% Annu= al Return) |

| * Lightning N= etwork Liquidity |

| * DeFi Lendin= g Protocols |

| * Bitcoin-bac= ked Stablecoins |

+------------------= -----------------------+

|<= u>

v<= u>

+------------------= -----------------------+

| Interest = Distribution |

| (Public G= ood Only) |

| * Open Source= Development |

| * Quantum Sec= urity Research |

| * Global Infr= astructure |

| * AI Safety &= amp; Alignment |

+------------------= -----------------------+

Claim Verification = Protocol

Original owners can= reclaim their coins at ANY time by providing:

Prior to Break (Q-D= ay):

1. Cryptographic Pr= oof: Message signed with their key

2. Optional Support= ing Evidence: Transaction history, temporal patterns if there is any doubt/= dispute on Q-Day date

Post Break:<= u>

1. Identity Verific= ation: Since quantum computers will create publicly available databases of = all exposed private keys (similar to existing databases of classically comp= romised keys), possession of the private key alone is insufficient.

2. Required Evidenc= e:

- government-iss= ued identification

- Historical tra= nsaction knowledge

- Temporal patte= rn matching

- Social recover= y attestations

This approach recog= nizes that post-quantum, private key possession becomes meaningless as proo= f of ownership since quantum-derived key databases will be publicly availab= le.

Three-tier Evidence= Hierarchy

The claim verificat= ion process employs a three-tier evidence hierarchy to evaluate ownership c= laims with staking and slashing to prevent fraud and partial time based awa= rds in case of partial proof. Evidence strength:

- Tier 1: Cryptogra= phic proofs with verifiable pre-break timestamps (signatures in pre-quantum= blocks and similar immutable records)

- Tier 2: Third-par= ty records (exchange logs, bankruptcy filings, probate rulings, trustee sta= tements)

- Tier 3: Supportin= g materials (affidavits, chain-of-inheritance, media coverage, witness decl= arations)

Governance Structur= e

The QSAVE fund requ= ires robust decentralized governance to ensure proper stewardship of recove= red assets. The governance framework must balance efficiency with decentral= ization while maintaining absolute commitment to principal preservation.

Core Governance Pri= nciples:

- Quadratic Voting:= Reduces influence of large stakeholders while maintaining democratic parti= cipation

- Multi-Council Str= ucture: Separates technical, allocation, and audit functions to prevent cap= ture

- Constraints: Only= generated returns may be allocated (per principle #1)=

- Emergency Procedu= res: Supermajority (75%) required for emergency actions; freeze of recovery= process can be executed by authorized individuals until quarum can be esta= blished.

Governance Bodies:<= u>

- Technical Council= : Oversees security, recovery operations, and technical infrastructure

- Allocation Counci= l: Manages distribution of generated returns to for the public good thru ch= aritable donation, impact investing or research funding.

- Audit Council: Pr= ovides independent oversight and transparency reporting

Safeguards:<= u>

- Staggered terms t= o ensure continuity

- Public transparen= cy of all decisions

- Time-locked imple= mentations for non-emergency changes

- Immutable smart c= ontracts for principal preservation

Rationale=

The QSAVE protocol = represents the optimal technical implementation for addressing quantum vuln= erability. Unlike binary approaches (burn or allow appropriation), QSAVE in= troduces a third path that aligns with Bitcoin's core principles while solving practical challenges.

Technical Neutralit= y

QSAVE maintains imp= lementation flexibility:

- Fork-neutral: Wor= ks with or without protocol changes (see Recovery Timing Matrix)<= /u>

- Price-neutral: Ma= rkets have already priced quantum risk (per BlackRock ETF disclosures)

- Liquidity-neutral= : Principal preservation prevents market disruption

Implementation Adva= ntages

- Transparent Opera= tions: All movements follow Recovery Protocol

- Decentralized Gov= ernance: See Governance Structure section

- Auditable Recover= y: See Claim Verification Protocol

- Progressive Deplo= yment: Phase 0 operational from day one

Risk Mitigation<= /u>

The protocol addres= ses key operational risks:

- Race Condition Ri= sk: Pre-positioned infrastructure for rapid Q-Day response

- Legal Clarity: Al= igns with established lost & found precedents

- Governance Captur= e: Quadratic voting and mandatory principal preservation constraints=

- Technical Failure= : Backup chain with post-quantum signatures ensures continuity

Legal Framework Con= siderations

The recovery proces= s aligns with established legal principles in many jurisdictions. Under pre= cedents like People v. Jennings (NY 1986), temporary custody without intent= to permanently deprive does not constitute larceny. This is analogous to moving lost property to a lost & found = =E2=80=94 a universally accepted practice despite technically involving "ta= king without permission."

In the United State= s alone, over 400 million items are moved to lost & found departments a= nnually without legal consequence. QSAVE applies this same principle to dig= ital assets vulnerable to quantum attack, providing a protective custody mechanism that preserves ownership rights.<= u>

Furthermore, the U.= S. Department of Justice's policy on good-faith security research provides = additional legal clarity for recovery operators acting to protect vulnerabl= e assets from quantum threats.

Legal clarification= and Jurisdiction choices need to be made.

The Sovereign Law P= aradox

Without protective = frameworks, law-abiding states face a critical disadvantage. Bad actors ope= rating from jurisdictions with weak or non-existent cryptocurrency regulati= ons can exploit quantum vulnerabilities with impunity, while good-faith actors in law-compliant states remain para= lyzed by legal uncertainty. This creates a systematic wealth transfer from = citizens of law-abiding nations to criminal organizations and rogue states.= The strongest property laws paradoxically create the weakest defense against quantum theft. Jurisdictions are develo= ping good faith exemptions to their computer security laws and these will n= eed to accelerate.

Economic Impact<= /u>

Positive Effects=

- Removes quantum u= ncertainty from Bitcoin price

- Funds public good= without inflation or taxation (see Fund Architecture)=

- Preserves Bitcoin= 's fixed supply economics (Principle #1)

- Creates new model= for decentralized capital allocation

Neutral Effects<= /u>

- No net change in = circulating supply (coins preserved, not spent)

- Market has alread= y priced in quantum risk per BlackRock ETF terms

- Interest generati= on creates minimal selling pressure

Appendix: Quantum V= ulnerability

Vulnerable Address = Categories

| Category = | Address Type | Key Status | Quantum Vulnerable | Est. BTC (M) | = Recovery Priority | Notes |

|------------------= -----|------------------|------------|--------------------|--------------|-= ------------------|------------------------------------|

| P2PK Outputs = | P2PK | Various | Yes | 1.9-2.0 | = Critical | Directly exposed public keys |

| Taproot (All) = | P2TR | Various | Yes | 0.5-1 | = Critical | ALL Taproot addresses exposed |

| Reused P2PKH (spe= nt) | P2PKH | Various | Yes | 2-4 | = High | Spent =3D pubkey revealed |

| Reused P2WPKH (sp= ent) | P2WPKH | Various | Yes | ~0.5-1 | = High | Modern but still vulnerable |

| Unused P2PKH = | P2PKH | Various | No | 6-8 | = Protected | Hash only; quantum-safe |

| Unused P2WPKH = | P2WPKH | Various | No | 4-6 | = Protected | Modern safe until spent |

| Script Hash = | P2SH/P2WSH | Various | Mostly No | 3-4 | = Protected | Generally safe (depends on script) |

| Total Vulnerable = | | | Yes | 3.5-5.5M | = | 17-28% of supply |

Quantum Risk=

There is a lack of = consensus on the timeline for the quantum threat other than it appears to b= e accelerating:

Expert Consensus:

- Conservative esti= mates (NIST IR 8413): 2035-2050

- Aggressive projec= tions: 2027-2035

- Industry leaders = (including Brock Pierce at Tokenize 2025): "Yes, quantum was 20 years away = until recently. It's likely this decade. Most people are now pinpointing it= at 2027. I think that's early, but there's some bright minds working on it."

Recent Technical Ad= vances:

- Google's 2025 res= earch: Demonstrated that 2048-bit RSA encryption could theoretically be bro= ken by a quantum computer with 1 million noisy qubits running for one week = (20-fold decrease from previous estimate)

- Jensen Huang (NVI= DIA CEO): Shifted to optimistic stance, stating quantum computing is "reach= ing an inflection point" and we're "within reach of being able to apply qua= ntum computing" to solve problems "in the coming years"

Regulatory Requirem= ents:

- U.S. National Sec= urity Systems must use quantum-resistant algorithms for new acquisitions af= ter January 1, 2027 (NSA CNSA 2.0)

- Given 1-5 year go= vernment procurement cycles, blockchain proposals today must be quantum-pro= of

References

1. NIST IR 8413 - "= Status Report on the Third Round of the NIST Post-Quantum Cryptography Stan= dardization Process", July 2022.

https://doi.org/10.6028/NIST.IR.8413

2. NSA CNSA 2.0 - "= Commercial National Security Algorithm Suite 2.0 FAQ", September 7, 2022.

https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.= PDF

3. Google Quantum A= I - "Quantum Advantage in Error Correction", Nature, 2025.

Demonstrated 99.= 85% reduction in required quantum resources.

4. Jensen Huang - "= Nvidia CEO says quantum computing is at an inflection point", Channel News = Asia, June 11, 2025.

https://www.channelnewsasia.com/business/nvidia-ceo-says-quantum-computing-= inflection-point-5174861

5. Global Risk Inst= itute - "Quantum Threat Timeline 2025: Executive Perspectives on Barriers t= o Action", 2025.

https://globalriskinstitute.org/publication/quantum-threat-timeline-2025-ex= ecutive-perspectives-on-barriers-to-action/

6. Brock Pierce - "= Million Dollar Bitcoin CONFIRMED! Brock Pierce & Michael Terpin Drop BO= MBS at Tokenize! 2025." YouTube, timestamp 18:10.

https://www.youtube.com/watch?v=3DDhYO1Jxmano

7. Satoshi Nakamoto= - BitcoinTalk Forum post, 2010. "If it happens gradually, we can transitio= n to something stronger."

https://bitcointalk.org/index.php?topic=3D3120.0

8. FIPS 204 - "Modu= le-Lattice-Based Digital Signature Standard", August 2024.

Specifies CRYSTA= LS-Dilithium (ML-DSA).

9. BIP 341 - "Tapro= ot: SegWit version 1 spending rules", January 2020.

https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

10. BlackRock iShar= es Bitcoin Trust - Prospectus acknowledging quantum computing risk to Bitco= in holdings, 2024.

11. Mosca, M. - "Qu= antum Threat Timeline," University of Waterloo, 2023.<= /p>

Estimates 2035-= 2040 timeline for quantum threats to cryptography.

--
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/2e635098-a8f5-43d6-b8e9-5971ba8ba218n%40googlegroups.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/2gC13o= DaC58JAFFSQ0qBve4whtVS0W5oVLNuxaWEfBFvYzTt_rHAhU6Asdb33xwK3mm6DZ6xuK83N8crs= EdryPvxH5DaY6J1uRJXdiNg2TA%3D%40proton.me.
-----------------------86e48fec93d8ed8861f7e152f49b3f0c-- -----------------------41c78c948804fe9c6713522288293f65-- -----------------------613201bdd13d8b2e732bd90cad4f5413 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== -----------------------613201bdd13d8b2e732bd90cad4f5413-- --------c332c9882902573073ef16bc3e561b7f715d5635cba7b060c974663f86b671fc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmikkZwJkHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmf63rTI61q/ogQUVYZ7YjaBviTF5P+uvEpye7Ld gqSHUhYhBEdIka0CMtrLdg13a3gpbO2E9rPFAABrrQD+NmoWAcZcLj0l29TM n19ZFSmFQ71mwTWrkO8Z6DaU/PgBAOvV+cJg/gFNYiDNar0T8h6ZydZZgmm4 5cga2I/FJRUJ =x75s -----END PGP SIGNATURE----- --------c332c9882902573073ef16bc3e561b7f715d5635cba7b060c974663f86b671fc--