Delivery-date: Tue, 19 Aug 2025 14:10:27 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uoTb6-0004BO-5T for bitcoindev@gnusha.org; Tue, 19 Aug 2025 14:10:27 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-30cce87c38dsf2620958fac.1 for ; Tue, 19 Aug 2025 14:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1755637818; x=1756242618; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=gTVFFIozcFscLtmReenAYmR4BtyDDghj2QWFCuo2a5E=; b=PmcDfvmGPblHc8adGHNGM3Ha1P7EleTTAYdWkLd+6JScTQdTLfWIXMDxsY3fp+AC36 Sg1EZD1V/BHRBtgv70o3OblkjkFll0LTC0/iDmKLvKQER36KutPu69c7A8s1QbWqp1R6 edIBlMt3Ie259H1JREmk0Z45+87x1W/xhNxdEFUUfNT0NhTK2Fj8+wRYDaXs0YUNpTKO DTb3AaaA6WJZydCfjamfIEUL+MyMLyneRrNEQkv8dYdDTOfSS19X0czTiHaGmjS0+poE HR92YQzEXSjPso5103sQ3NeEKtBTVA0dXy7VxZ7+510n/Jcvufc5NePtzoyVMulKlYdO VdPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1755637818; x=1756242618; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=gTVFFIozcFscLtmReenAYmR4BtyDDghj2QWFCuo2a5E=; b=GviMavqVG3dIFPMusbhDc5cEebm/aIP5r4WYpJ11kqeMCd2dEEXweUEO6QJfPWXxsB ARh5gRqGTaGNOkXAVgN6Jx8+hiT5fx30a4zOMpM9zsPXnAkjhNFQX8VNko2qHAWMn5ld QaxSUjKeTUXztCVux/wfynn/AGjT+qnVKSosiTzjCyJnq+IoTCKe38swe8ImndEqScPG TZ1f+EjKr2iy0QGH19J5uqAkCg18zqI1XixUdgdTyKYli6rJz5V233yZjT9nqAPfzbuX v4FyehdjqiWDbWqknlHJ08/svkU2anc66euDnZb8y6het1CQTmuTphOJZJAv5vb4+Yuw XKiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755637818; x=1756242618; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=gTVFFIozcFscLtmReenAYmR4BtyDDghj2QWFCuo2a5E=; b=Ks/HExsanlq4WdwU5/iXVj74n7QpCgblYbK3vj7ab9yDlxHe9mMHapKk+COyAAmN/E +FKVOoxfau9meH0KbhzPGj+exOyv0Wniq9wl1Ao9aqoZvozKm4EuY6OuB5uJ7ORq7/pR HfZHBefL5p0SIrdCO6PqqKtn99m3+XWYPF2vuVkyvKXv/xx9L2dYiNNWcWw1XqqZHrm8 EqDoXZA1gcp8Qms76lpgZX4fkJwh6NACgRbpJvioi+dyVNnoZnFPXTPiLziK+e2CKVMi yFaXDNxTlrVwz6jux4sUSIjnc748kjRw9jACv8ryeTxVGOZSLuF4tbDy4y7/v5l5zJSq l8Lg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVooi8wO60uNgYxIPxGkIRopXE9XfFbIM29lC7TMr2DYdGNeEblx56GhaVdqH7m6vcAqd8ViGE7yK1U@gnusha.org X-Gm-Message-State: AOJu0YxXQL2m9rWfs5Tyy4sd2xOQiNJfu2NlQB0pZF28YKfBxJZ5sofk oCZvU2FR8NdHTf/7EVvPoYCOFaKn/9ppfAnJCBISjVNCsOFD+UbjNQ53 X-Google-Smtp-Source: AGHT+IEFrqPcs2quEZOuhZuTNL8Gu23Q2pEqrTlh01l0+KUi3eNaeOt2pRZ6u9xjQeLbWKsXApIclQ== X-Received: by 2002:a05:6870:1f19:b0:301:dceb:3246 with SMTP id 586e51a60fabf-311229eed9bmr316498fac.33.1755637817341; Tue, 19 Aug 2025 14:10:17 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfm8cR5bbZpYfSze/bbWI31kITkLPISluA+/9GxH9h0NA== Received: by 2002:a05:687c:20e7:b0:30c:5e6c:2257 with SMTP id 586e51a60fabf-31121013711ls61825fac.1.-pod-prod-00-us-canary; Tue, 19 Aug 2025 14:10:12 -0700 (PDT) X-Received: by 2002:a05:6808:220e:b0:404:a4bf:d541 with SMTP id 5614622812f47-4377172abcemr546452b6e.11.1755637812719; Tue, 19 Aug 2025 14:10:12 -0700 (PDT) Received: by 2002:a05:690c:26c7:b0:71f:9f84:d07 with SMTP id 00721157ae682-71fb11b75eems7b3; Tue, 19 Aug 2025 13:59:53 -0700 (PDT) X-Received: by 2002:a05:690c:6f0f:b0:71c:1592:6efa with SMTP id 00721157ae682-71fb1e73e75mr10588567b3.13.1755637191914; Tue, 19 Aug 2025 13:59:51 -0700 (PDT) Date: Tue, 19 Aug 2025 13:59:51 -0700 (PDT) From: Erik Aronesty To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <2e635098-a8f5-43d6-b8e9-5971ba8ba218n@googlegroups.com> References: <2e635098-a8f5-43d6-b8e9-5971ba8ba218n@googlegroups.com> Subject: [bitcoindev] Re: [BIP Proposal] No burn, Quantum Migration Proposal, Quantum Secure Asset Verification & Escrow (QSAVE) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_15058_1431439207.1755637191474" X-Original-Sender: earonesty@gmail.com 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: -0.5 (/) ------=_Part_15058_1431439207.1755637191474 Content-Type: multipart/alternative; boundary="----=_Part_15059_425509788.1755637191474" ------=_Part_15059_425509788.1755637191474 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable if the error correcton becomes possible, and processessive non-SAT solving= =20 algos exist (both are requirements, neither is sure), then quantim will=20 matter *slowly* over time. not overnight. - allowing people to migrate to quantum sigs is a soft-fork. easily solves= =20 all the active wallets and most cold wallets, probably 70% of the coins=20 that aren't lost. a study on this is merited. all migration has to happen= =20 before quantum is effective. this works for exposed pubkeys. - requiring a "quantum upgrade" for future spend ... can also be a soft=20 fork. someone posts a "quantum secure claim" against a p2sh wallet. the= =20 claim contains a quantum secure pubkey and a signature that uses the=20 unrevealed private key from the p2sh. only when the script is revealed=20 can we know if the claim was accurate. this allows unmigrated p2sh spends= =20 in a quantum secure manner, even while quantum is effective - claims work for exposed pubkeys while not effective, especially=20 time-locked. this allows coins to remain unmoved, in cold storage, but=20 locked against future spends. =20 if someone doesn't do ANY of these things and STILL spends using an=20 outdated protocol? it's just like losing your keys. it's a mistake, and= =20 we don't fix other people's mistakes On Monday, August 18, 2025 at 10:12:36=E2=80=AFAM UTC-7 James T wrote: > I *am* suggesting that Bitcoin elects people who can arbitrate reasonable= =20 > claims. The Bitcoin dev team proposing a burn solution is the same proble= m=20 > you articulate: a small group of people (80% of miners) voting to burn=20 > coins. I don't see a way around this fundamental problem. The keys will= =20 > fail in the future; some human intervention is going to happen. Remember,= =20 > if the burn happens, tens of thousands of people will open safety deposit= =20 > boxes full of Bitcoin addresses and find them zeroed out. Only our soluti= on=20 > provides a solution to this and preserves the Digital Gold promise. > > We like to assume there is no human intervention in Bitcoin and it's all= =20 > algorithmic, but that's not true. There is an army of people working to= =20 > secure Bitcoin behind the scenes, including upfront KYC/AML and=20 > after-the-fact recovery by private companies and law enforcement when the= re=20 > is a hack. This all works on a worldwide basis today. > > No lawyers have been involved in the drafting of our proposal. I would=20 > welcome input, but it's really an engineering problem. Once Bitcoin keys= =20 > can no longer be relied on, what do we do to establish ownership? Deletin= g=20 > ownership is certainly one solution, but I just don't think it is a fair= =20 > one. > > We are proposing our solution as either a hard fork or a no-fork. Either= =20 > way, we still have to solve the problem of a room full of elected experts= =20 > to adjudicate claims (obviously, they would be distributed worldwide, and= =20 > often it could be achieved algorithmically). > > In the no-fork solution, we encourage - maybe reward - white hat quantum= =20 > actors to recover vulnerable Bitcoin under lost property law. If it's=20 > claimed, then it's returned; if not claimed, it's invested for the public= =20 > good. This is then a race between white hat and black hat actors. BUT mos= t=20 > laws will deter white hat actors because it might be considered computer= =20 > misuse. It would be really helpful if the Bitcoin consensus said, "We fav= or=20 > white hat actors protecting Bitcoin". Although there are no Bitcoin terms= =20 > and conditions or EULA, this would massively protect white hats. > > In the hard fork solution, instead of burning the coins, they go into the= =20 > recovery process, and here the Bitcoin consensus has made a clear protoco= l=20 > decision, and there is no white hat actor risk. > > I apologize for the lack of technical details at this point. We have a lo= t=20 > of code written, and I did make a note to that effect in my submission, b= ut=20 > that bit seems to have been cut off. The recovery process has to obey the= =20 > law and be distributable worldwide, and be fair, and I think it is possib= le=20 > to do all that. Not simple, of course. In the meantime, there are plenty = of=20 > best practices that can be implemented to better protect and prepare the= =20 > network, which I know are in process. > > Best, > > > James T > > > On Friday, August 8, 2025 at 7:07:25=E2=80=AFPM UTC-7 conduition wrote: > >> Hi James, >> >> This is a curious idea, though I'm not seeing any technical details of= =20 >> how this "BIP" would maintain Bitcoin's value as a distributed system. I= t=20 >> more-or-less sounds like you're suggesting to vest the power of=20 >> quantum-recovery using legal mechanisms (e.g. KYC, real-world evidence,= =20 >> etc)... in a group of people working in an office somewhere? Surely you= =20 >> realize that's impractical and un-scaleable. Besides, even if you had al= l=20 >> the manpower needed to do it, no one who owns Bitcoin would run a node= =20 >> which subscribes to such consensus rules. A huge portion of the supply o= n=20 >> that (hardforked) chain would be effectively under the total control of = a=20 >> select few. Who elects these people? >> >> It sounds like something a corporate lawyer would cook up if asked how t= o=20 >> solve the post-quantum-rescue problem. Not to say that legal opinions on= =20 >> quantum migration are unwanted. I'm sure there are interesting legal=20 >> questions to be debated around the rights of property holders in case of= a=20 >> possible quantum-freeze. But this proposal at least is DOA because KYC= =20 >> *cannot* be the answer, for practical and ethical reasons. >> >> Perhaps, independent of any technical consensus upgrades, it would be=20 >> wise to encourage quantum adversaries to become benevolent, somehow. I'm= =20 >> not sure what that looks like. If a quantum freeze doesn't happen, there= =20 >> ought to be legal guidelines for how quantum giants like Google or IBM= =20 >> should behave given their newfound quantum weaponry. It'll be impossible= to=20 >> fully enforce any such rules, but if they *want* to play nice, someone= =20 >> should tell them what "playing nice" actually looks like. >> >> regards, >> conduition >> On Thursday, August 7, 2025 at 5:26:07=E2=80=AFPM UTC-7 James T wrote: >> >>> This BIP Proposal is an alternative to QRAMP or a quantum=20 >>> winner-takes-all approach to the migration from a pre- to post quantum= =20 >>> blockchain. It could be implemented as a hard fork OR as a consensus th= at=20 >>> quantum actors can legitimately move funds to safe addresses for protec= tive=20 >>> custody and public good. It could even go forward with no consensuses a= t=20 >>> all since it is functionally equivalent to a quantum winner-takes-all a= t=20 >>> the protocol level.=20 >>> >>> =20 >>> >>> BIP: TBD >>> >>> Title: Quantum Secure Asset Verification & Escrow (QSAVE) >>> >>> Author: James Tagg=20 >>> >>> Status: Draft >>> >>> Type: Standards Track >>> >>> Layer: Consensus (Consensus / Soft Fork / Hard Fork) >>> >>> Created: >>> >>> License:=20 >>> >>> =20 >>> >>> Abstract >>> >>> =20 >>> >>> This BIP proposes QSAVE (Quantum Secure Asset Verification & Escrow) - = a=20 >>> non-sovereign wealth fund providing protective custody for Bitcoin=20 >>> vulnerable to quantum attack (see Appendix for detailed vulnerability= =20 >>> assessment). QSAVE preserves 100% of the principal for rightful owners= =20 >>> while using generated returns to fund the protocol and global public go= od.=20 >>> It provides an alternative to the QRAMP (Quantum Resistant Asset Migrat= ion=20 >>> Protocol) proposal (which makes coins unspendable) or taking no action= =20 >>> (which allows quantum appropriation, which many view as theft). This=20 >>> proposal addresses coins that are dormant but acknowledges there may be= =20 >>> coins that have quantum watermarks but have not migrated to quantum=20 >>> addresses. A separate BIP proposal will address this case. >>> >>> =20 >>> >>> Motivation >>> >>> =20 >>> >>> Chain analysis reveals 3.5-5.5 million Bitcoin (~17-28% of circulating= =20 >>> supply) have exposed public keys vulnerable to quantum attack (see=20 >>> Appendix: Quantum Vulnerability Assessment for detailed breakdown). >>> >>> =20 >>> >>> With sufficient education and proactive migration, a significant portio= n=20 >>> of the 2-4M BTC in reused addresses could be moved to quantum-safe=20 >>> addresses before the threat materializes. Modern wallets are increasing= ly=20 >>> implementing best practices such as always sending change to fresh=20 >>> addresses. However, some portion will inevitably remain unprotected whe= n=20 >>> quantum computers arrive due to: >>> >>> =20 >>> >>> - Owners who don't follow Bitcoin news >>> >>> - Forgotten wallets discovered years later >>> >>> - Cold storage assumed long term safe >>> >>> - Users who die and whose heirs have yet to uncover the keys >>> >>> - Users who procrastinate or underestimate the threat >>> >>> =20 >>> >>> When quantum computers capable of running Shor's algorithm arrive, the= =20 >>> remaining vulnerable coins face two equally problematic outcomes: >>> >>> =20 >>> >>> 1. Quantum appropriation: First actors with quantum computers take the= =20 >>> coins >>> >>> 2. Forced burning: The community burns coins preventatively (by making= =20 >>> them unspendable), breaking Bitcoin's promise as a store of value >>> >>> =20 >>> >>> This BIP proposes a third way: QSAVE - protective custody that preserve= s=20 >>> ownership rights and puts dormant capital to work for humanity. >>> >>> =20 >>> >>> Note on "Theft": Bitcoin's protocol operates purely through=20 >>> cryptographic proofs, without built-in concepts of ownership or theft= =E2=80=94these=20 >>> are legal constructs that vary by jurisdiction. The community holds=20 >>> divergent views: some consider using advanced technology to derive priv= ate=20 >>> keys as legitimate within Bitcoin's rules, while others view it as=20 >>> unethical appropriation of others' funds. >>> >>> =20 >>> >>> QSAVE addresses both perspectives: If quantum key derivation is=20 >>> considered fair game, then racing to secure vulnerable coins before=20 >>> malicious actors is simply good-faith participation in the system. If i= t's=20 >>> deemed unethical, then the community needs a consensus solution that=20 >>> balances property rights with Bitcoin's algorithmic nature. Either way,= =20 >>> protective custody preserves coins for their rightful owners rather tha= n=20 >>> allowing them to be stolen or destroyed. >>> >>> =20 >>> >>> The Inheritance Vulnerability Window >>> >>> =20 >>> >>> Consider the "Auntie Alice's Bitcoin" scenario: Alice stores Bitcoin in= =20 >>> cold storage as inheritance for her grandchildren, with keys secured in= a=20 >>> safe deposit box. She doesn't follow Bitcoin news and remains unaware o= f=20 >>> quantum threats. She passes away and by the time her heirs discover the= =20 >>> wallet, quantum computers capable of deriving private keys have emerged= . >>> >>> =20 >>> >>> Three outcomes are possible: >>> >>> =20 >>> >>> 1. Without protection: Quantum actors take the grandchildren's=20 >>> inheritance >>> >>> 2. With burning: The network destroys legitimate inheritance funds >>> >>> 3. With protective custody: Heirs can claim their inheritance with=20 >>> proper evidence (will, keys, proof of box opening) >>> >>> =20 >>> >>> This illustrates why we cannot assume dormant equals lost and why=20 >>> protective custody is the only approach that preserves legitimate owner= ship=20 >>> rights. The inability to distinguish between lost coins and stored coin= s is=20 >>> the fundamental reason protective custody is essential. >>> >>> =20 >>> >>> Principles >>> >>> =20 >>> >>> 1. Preserve the principal - 100% of recovered Bitcoin remains available= =20 >>> for rightful owners to reclaim at any time >>> >>> 2. Ensure long-term store of value by avoiding any pre-emptive burn=20 >>> (making coins unspendable) >>> >>> 3. Avoid market shocks by keeping principal locked while only using=20 >>> generated returns >>> >>> 4. Generate returns for the benefit of humanity through conservative=20 >>> yield strategies >>> >>> 5. Protect the Chain, ensuring smooth transition to post-quantum era >>> >>> 6. Enable priority recovery through quantum watermark system >>> >>> =20 >>> >>> Recovery Process >>> >>> =20 >>> >>> Recovery Timing Matrix >>> >>> =20 >>> >>> | Scenario | Timing |=20 >>> Method | Requirements | >>> >>> >>> |---------------------------|-------------------------------|----------= -----------------|----------------------------| >>> >>> | M-Day (Migration Day) | Pre-Q-Day with Hard Fork |=20 >>> Consensus-based migration | Hard fork implementation | >>> >>> | Q-Day (Quantum Day) | When quantum computers arrive | White-hat= =20 >>> recovery race | No protocol changes needed | >>> >>> | Emergency Cut-over | Catastrophic quantum break | Parallel= =20 >>> chain migration | Rapid consensus response | >>> >>> | Overlapping M/Q-Day | Both processes active | Concurren= t=20 >>> migrations | Mempool competition | >>> >>> =20 >>> >>> Recovery Protocol >>> >>> =20 >>> >>> All recovery transactions follow the same pattern: >>> >>> =20 >>> >>> 1. Move vulnerable coins to protective custody addresses >>> >>> 2. Leave OP_RETURN notification on original address with recovery=20 >>> information >>> >>> 3. Prioritize by dormant period and value at risk >>> >>> 4. Quantum watermarks permit immediate return of funds >>> >>> =20 >>> >>> Consensus Layer >>> >>> =20 >>> >>> Implementation varies based on timing and consensus level (see Recovery= =20 >>> Timing Matrix above): >>> >>> =20 >>> >>> No Action: PQP (Post Quantum Pay) wallet technology - purely=20 >>> commercial/user layer >>> >>> =20 >>> >>> Consensus: Community endorsement strengthens legal position for=20 >>> white-hat recovery >>> >>> =20 >>> >>> Soft Fork: Taproot V2/BIP-360 enables voluntary migration (doesn't=20 >>> protect dormant accounts) >>> >>> =20 >>> >>> Hard Fork: Required for pre-Q-Day recovery or emergency cut-over=20 >>> scenarios >>> >>> =20 >>> >>> Implementation Timeline >>> >>> =20 >>> >>> Phase 0: Launch - Live from Day One >>> >>> - DAO Governance: Active voting on proposals from day one >>> >>> - Initial Publication: Non-Sovereign Wealth Fund Proposal Discussion >>> >>> =20 >>> >>> Phase 1: Consensus Building & Infrastructure (Months 1-6) >>> >>> - Community discussion and refinement (while QD3 registrations continue= ) >>> >>> - Technical specification development for advanced features >>> >>> - Technical specification for backup chain >>> >>> - Legal framework establishment with states >>> >>> - Coordination with regulatory bodies for good-faith protections >>> >>> - Signing the main quantum computer makers to the recovery principles >>> >>> - Begin backup chain development using post-quantum signature schemes= =20 >>> (e.g., FIPS 204 ML-DSA) >>> >>> =20 >>> >>> Phase 2: Enhanced Infrastructure (Months 7-12) >>> >>> - Smart contract deployment for fund management >>> >>> - Advanced governance system implementation >>> >>> - Claim verification protocol enhancements >>> >>> - Complete backup chain synchronization and cut over process >>> >>> - Multi-signature protective custody addresses pre-established >>> >>> =20 >>> >>> Phase 3: Recovery Preparation (Months 13-18) >>> >>> - Public notification system deployment >>> >>> - Recovery transaction staging >>> >>> - Security audits of all systems >>> >>> - Publish recovery chain software >>> >>> - Public notice period initiation (6 months before recovery) >>> >>> - Broadcast intent to recover specific UTXOs >>> >>> - Allow time for unregistered owners to move coins or register claims >>> >>> - Publish recovery transactions in mempool but not mine >>> >>> =20 >>> >>> Phase 4: Active Recovery (Month 19+) >>> >>> - Execute recovery per Recovery Timing Matrix >>> >>> - Use Recovery Protocol for all transactions >>> >>> - Manage protective custody with multi-signature addresses >>> >>> - Process ownership claims per Claim Verification Protocol >>> >>> - Initiate fund operations per Fund Architecture >>> >>> =20 >>> >>> Proposed Fund Architecture >>> >>> =20 >>> >>> +-----------------------------------------+ >>> >>> | Recovered Bitcoin | >>> >>> | (Principal - 100% Preserved) | >>> >>> +-----------------------------------------+ >>> >>> | >>> >>> v >>> >>> +-----------------------------------------+ >>> >>> | Conservative Strategies | >>> >>> | (3-5% Annual Return) | >>> >>> | * Lightning Network Liquidity | >>> >>> | * DeFi Lending Protocols | >>> >>> | * Bitcoin-backed Stablecoins | >>> >>> +-----------------------------------------+ >>> >>> | >>> >>> v >>> >>> +-----------------------------------------+ >>> >>> | Interest Distribution | >>> >>> | (Public Good Only) | >>> >>> | * Open Source Development | >>> >>> | * Quantum Security Research | >>> >>> | * Global Infrastructure | >>> >>> | * AI Safety & Alignment | >>> >>> +-----------------------------------------+ >>> >>> =20 >>> >>> Claim Verification Protocol >>> >>> =20 >>> >>> Original owners can reclaim their coins at ANY time by providing: >>> >>> =20 >>> >>> Prior to Break (Q-Day): >>> >>> 1. Cryptographic Proof: Message signed with their key >>> >>> 2. Optional Supporting Evidence: Transaction history, temporal patterns= =20 >>> if there is any doubt/dispute on Q-Day date >>> >>> =20 >>> >>> Post Break: >>> >>> 1. Identity Verification: Since quantum computers will create publicly= =20 >>> available databases of all exposed private keys (similar to existing=20 >>> databases of classically compromised keys), possession of the private k= ey=20 >>> alone is insufficient. >>> >>> 2. Required Evidence: >>> >>> - government-issued identification >>> >>> - Historical transaction knowledge >>> >>> - Temporal pattern matching >>> >>> - Social recovery attestations >>> >>> =20 >>> >>> This approach recognizes that post-quantum, private key possession=20 >>> becomes meaningless as proof of ownership since quantum-derived key=20 >>> databases will be publicly available. >>> >>> =20 >>> >>> Three-tier Evidence Hierarchy >>> >>> =20 >>> >>> The claim verification process employs a three-tier evidence hierarchy= =20 >>> to evaluate ownership claims with staking and slashing to prevent fraud= and=20 >>> partial time based awards in case of partial proof. Evidence strength: >>> >>> =20 >>> >>> - Tier 1: Cryptographic proofs with verifiable pre-break timestamps=20 >>> (signatures in pre-quantum blocks and similar immutable records) >>> >>> - Tier 2: Third-party records (exchange logs, bankruptcy filings,=20 >>> probate rulings, trustee statements) >>> >>> - Tier 3: Supporting materials (affidavits, chain-of-inheritance, media= =20 >>> coverage, witness declarations) >>> >>> =20 >>> >>> Governance Structure >>> >>> =20 >>> >>> The QSAVE fund requires robust decentralized governance to ensure prope= r=20 >>> stewardship of recovered assets. The governance framework must balance= =20 >>> efficiency with decentralization while maintaining absolute commitment = to=20 >>> principal preservation. >>> >>> =20 >>> >>> Core Governance Principles: >>> >>> - Quadratic Voting: Reduces influence of large stakeholders while=20 >>> maintaining democratic participation >>> >>> - Multi-Council Structure: Separates technical, allocation, and audit= =20 >>> functions to prevent capture >>> >>> - Constraints: Only generated returns may be allocated (per principle #= 1) >>> >>> - Emergency Procedures: Supermajority (75%) required for emergency=20 >>> actions; freeze of recovery process can be executed by authorized=20 >>> individuals until quarum can be established. >>> >>> =20 >>> >>> Governance Bodies: >>> >>> - Technical Council: Oversees security, recovery operations, and=20 >>> technical infrastructure >>> >>> - Allocation Council: Manages distribution of generated returns to for= =20 >>> the public good thru charitable donation, impact investing or research= =20 >>> funding. >>> >>> - Audit Council: Provides independent oversight and transparency=20 >>> reporting >>> >>> =20 >>> >>> Safeguards: >>> >>> - Staggered terms to ensure continuity >>> >>> - Public transparency of all decisions >>> >>> - Time-locked implementations for non-emergency changes >>> >>> - Immutable smart contracts for principal preservation >>> >>> =20 >>> >>> Rationale >>> >>> =20 >>> >>> The QSAVE protocol represents the optimal technical implementation for= =20 >>> addressing quantum vulnerability. Unlike binary approaches (burn or all= ow=20 >>> appropriation), QSAVE introduces a third path that aligns with Bitcoin'= s=20 >>> core principles while solving practical challenges. >>> >>> =20 >>> >>> Technical Neutrality >>> >>> =20 >>> >>> QSAVE maintains implementation flexibility: >>> >>> - Fork-neutral: Works with or without protocol changes (see Recovery=20 >>> Timing Matrix) >>> >>> - Price-neutral: Markets have already priced quantum risk (per BlackRoc= k=20 >>> ETF disclosures) >>> >>> - Liquidity-neutral: Principal preservation prevents market disruption >>> >>> =20 >>> >>> Implementation Advantages >>> >>> - Transparent Operations: All movements follow Recovery Protocol >>> >>> - Decentralized Governance: See Governance Structure section >>> >>> - Auditable Recovery: See Claim Verification Protocol >>> >>> - Progressive Deployment: Phase 0 operational from day one >>> >>> =20 >>> >>> Risk Mitigation >>> >>> =20 >>> >>> The protocol addresses key operational risks: >>> >>> - Race Condition Risk: Pre-positioned infrastructure for rapid Q-Day=20 >>> response >>> >>> - Legal Clarity: Aligns with established lost & found precedents >>> >>> - Governance Capture: Quadratic voting and mandatory principal=20 >>> preservation constraints >>> >>> - Technical Failure: Backup chain with post-quantum signatures ensures= =20 >>> continuity >>> >>> =20 >>> >>> Legal Framework Considerations >>> >>> =20 >>> >>> The recovery process aligns with established legal principles in many= =20 >>> jurisdictions. Under precedents like People v. Jennings (NY 1986),=20 >>> temporary custody without intent to permanently deprive does not consti= tute=20 >>> larceny. This is analogous to moving lost property to a lost & found = =E2=80=94 a=20 >>> universally accepted practice despite technically involving "taking wit= hout=20 >>> permission." >>> >>> =20 >>> >>> In the United States alone, over 400 million items are moved to lost &= =20 >>> found departments annually without legal consequence. QSAVE applies thi= s=20 >>> same principle to digital assets vulnerable to quantum attack, providin= g a=20 >>> protective custody mechanism that preserves ownership rights. >>> >>> =20 >>> >>> Furthermore, the U.S. Department of Justice's policy on good-faith=20 >>> security research provides additional legal clarity for recovery operat= ors=20 >>> acting 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=20 >>> disadvantage. Bad actors operating from jurisdictions with weak or=20 >>> non-existent cryptocurrency regulations can exploit quantum vulnerabili= ties=20 >>> with impunity, while good-faith actors in law-compliant states remain= =20 >>> paralyzed by legal uncertainty. This creates a systematic wealth transf= er=20 >>> from citizens of law-abiding nations to criminal organizations and rogu= e=20 >>> states. The strongest property laws paradoxically create the weakest=20 >>> defense against quantum theft. Jurisdictions are developing good faith= =20 >>> exemptions to their computer security laws and these will need to=20 >>> accelerate. >>> >>> =20 >>> >>> Economic Impact >>> >>> =20 >>> >>> Positive Effects >>> >>> - Removes quantum uncertainty from Bitcoin price >>> >>> - Funds public good without inflation or taxation (see Fund Architectur= e) >>> >>> - Preserves Bitcoin's fixed supply economics (Principle #1) >>> >>> - Creates new model for decentralized capital allocation >>> >>> =20 >>> >>> Neutral Effects >>> >>> - No net change in circulating supply (coins preserved, not spent) >>> >>> - Market has already priced in quantum risk per BlackRock ETF terms >>> >>> - Interest generation creates minimal selling pressure >>> >>> =20 >>> >>> Appendix: Quantum Vulnerability >>> >>> =20 >>> >>> Vulnerable Address Categories >>> >>> =20 >>> >>> | Category | Address Type | Key Status | Quantum=20 >>> Vulnerable | Est. BTC (M) | Recovery Priority |=20 >>> Notes | >>> >>> >>> |-----------------------|------------------|------------|--------------= ------|--------------|-------------------|---------------------------------= ---| >>> >>> | P2PK Outputs | P2PK | Various |=20 >>> Yes | 1.9-2.0 | Critical | Directly expose= d=20 >>> public keys | >>> >>> | Taproot (All) | P2TR | Various |=20 >>> Yes | 0.5-1 | Critical | ALL Taproot=20 >>> addresses exposed | >>> >>> | Reused P2PKH (spent) | P2PKH | Various |=20 >>> Yes | 2-4 | High | Spent =3D pubke= y=20 >>> revealed | >>> >>> | Reused P2WPKH (spent) | P2WPKH | Various |=20 >>> Yes | ~0.5-1 | High | Modern but stil= l=20 >>> vulnerable | >>> >>> | Unused P2PKH | P2PKH | Various |=20 >>> No | 6-8 | Protected | Hash only;=20 >>> quantum-safe | >>> >>> | Unused P2WPKH | P2WPKH | Various |=20 >>> No | 4-6 | Protected | Modern safe unt= il=20 >>> spent | >>> >>> | Script Hash | P2SH/P2WSH | Various | Mostly=20 >>> No | 3-4 | Protected | Generally safe (depend= s on=20 >>> script) | >>> >>> | Total Vulnerable | | |=20 >>> Yes | 3.5-5.5M | | 17-28% of=20 >>> supply | >>> >>> =20 >>> >>> Quantum Risk >>> >>> =20 >>> >>> There is a lack of consensus on the timeline for the quantum threat=20 >>> other than it appears to be accelerating: >>> >>> =20 >>> >>> Expert Consensus: >>> >>> - Conservative estimates (NIST IR 8413): 2035-2050 >>> >>> - Aggressive projections: 2027-2035 >>> >>> - Industry leaders (including Brock Pierce at Tokenize 2025): "Yes,=20 >>> quantum was 20 years away until recently. It's likely this decade. Most= =20 >>> people are now pinpointing it at 2027. I think that's early, but there'= s=20 >>> some bright minds working on it." >>> >>> =20 >>> >>> Recent Technical Advances: >>> >>> - Google's 2025 research: Demonstrated that 2048-bit RSA encryption=20 >>> could theoretically be broken by a quantum computer with 1 million nois= y=20 >>> qubits running for one week (20-fold decrease from previous estimate) >>> >>> - Jensen Huang (NVIDIA CEO): Shifted to optimistic stance, stating=20 >>> quantum computing is "reaching an inflection point" and we're "within r= each=20 >>> of being able to apply quantum computing" to solve problems "in the com= ing=20 >>> years" >>> >>> =20 >>> >>> Regulatory Requirements: >>> >>> - U.S. National Security Systems must use quantum-resistant algorithms= =20 >>> for new acquisitions after January 1, 2027 (NSA CNSA 2.0) >>> >>> - Given 1-5 year government procurement cycles, blockchain proposals=20 >>> today must be quantum-proof >>> >>> =20 >>> >>> References >>> >>> =20 >>> >>> 1. NIST IR 8413 - "Status Report on the Third Round of the NIST=20 >>> Post-Quantum Cryptography Standardization Process", July 2022. >>> >>> https://doi.org/10.6028/NIST.IR.8413 >>> >>> =20 >>> >>> 2. NSA CNSA 2.0 - "Commercial National Security Algorithm Suite 2.0=20 >>> FAQ", September 7, 2022. >>> >>> =20 >>> https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_F= AQ_.PDF >>> >>> =20 >>> >>> 3. Google Quantum AI - "Quantum Advantage in Error Correction", Nature,= =20 >>> 2025. >>> >>> Demonstrated 99.85% reduction in required quantum resources. >>> >>> =20 >>> >>> 4. Jensen Huang - "Nvidia CEO says quantum computing is at an inflectio= n=20 >>> point", Channel News Asia, June 11, 2025. >>> >>> =20 >>> https://www.channelnewsasia.com/business/nvidia-ceo-says-quantum-comput= ing-inflection-point-5174861 >>> >>> =20 >>> >>> 5. Global Risk Institute - "Quantum Threat Timeline 2025: Executive=20 >>> Perspectives on Barriers to Action", 2025. >>> >>> =20 >>> https://globalriskinstitute.org/publication/quantum-threat-timeline-202= 5-executive-perspectives-on-barriers-to-action/ >>> >>> =20 >>> >>> 6. Brock Pierce - "Million Dollar Bitcoin CONFIRMED! Brock Pierce &=20 >>> Michael Terpin Drop BOMBS at Tokenize! 2025." YouTube, timestamp 18:10. >>> >>> https://www.youtube.com/watch?v=3DDhYO1Jxmano >>> >>> =20 >>> >>> 7. Satoshi Nakamoto - BitcoinTalk Forum post, 2010. "If it happens=20 >>> gradually, we can transition to something stronger." >>> >>> https://bitcointalk.org/index.php?topic=3D3120.0 >>> >>> =20 >>> >>> 8. FIPS 204 - "Module-Lattice-Based Digital Signature Standard", August= =20 >>> 2024. >>> >>> Specifies CRYSTALS-Dilithium (ML-DSA). >>> >>> =20 >>> >>> 9. BIP 341 - "Taproot: SegWit version 1 spending rules", January 2020. >>> >>> https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki >>> >>> =20 >>> >>> 10. BlackRock iShares Bitcoin Trust - Prospectus acknowledging quantum= =20 >>> computing risk to Bitcoin holdings, 2024. >>> >>> =20 >>> >>> 11. Mosca, M. - "Quantum Threat Timeline," University of Waterloo, 2023= . >>> >>> 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= c76564f5-8a4c-43f9-be10-323b0d013baan%40googlegroups.com. ------=_Part_15059_425509788.1755637191474 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable if the error correcton becomes possible, and processessive non-SAT solving = algos exist (both are requirements, neither is sure), then quantim will mat= ter *slowly* over time.=C2=A0 =C2=A0not overnight.

- allowing pe= ople to migrate to quantum sigs is a soft-fork.=C2=A0 easily solves all the= active wallets and most cold wallets, probably 70% of the coins that aren'= t lost. a study on this is merited.=C2=A0 all migration has to happen befor= e quantum is effective.=C2=A0 this works for exposed pubkeys.

-= =C2=A0requiring a "quantum upgrade" for future spend ... can also be a soft= fork.=C2=A0 someone posts a "quantum secure claim" against a p2sh wallet.= =C2=A0 =C2=A0 the claim contains a quantum secure pubkey and a signature th= at uses the unrevealed private key from the p2sh.=C2=A0 =C2=A0only when the= script is revealed can we know if the claim was accurate.=C2=A0 =C2=A0this= allows unmigrated p2sh spends in a quantum secure manner, even while quant= um is effective

- claims work for exposed pubkeys while not effe= ctive, especially time-locked.=C2=A0 =C2=A0this allows coins to remain unmo= ved, in cold storage, but locked against future spends.=C2=A0 =C2=A0
<= br />if someone doesn't do ANY of these things and STILL spends using an ou= tdated protocol?=C2=A0 it's just like losing your keys.=C2=A0 =C2=A0it's a = mistake, and we don't fix other people's mistakes

On Monday, August 18, 2= 025 at 10:12:36=E2=80=AFAM UTC-7 James T wrote:
I am suggesting that Bitcoin= elects people who can arbitrate reasonable claims. The Bitcoin dev team pr= oposing a burn solution is the same problem you articulate: a small group o= f 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 int= ervention is going to happen. Remember, if the burn happens, tens of thousa= nds 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 pre= serves the Digital Gold promise.

We like to assume= there is no human intervention in Bitcoin and it's all algorithmic, bu= t that's not true. There is an army of people working to secure Bitcoin= behind the scenes, including upfront KYC/AML and after-the-fact recovery b= y private companies and law enforcement when there is a hack. This all work= s on a worldwide basis today.

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

<= /div>
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 e= xperts to adjudicate claims (obviously, they would be distributed worldwide= , and often it could be achieved algorithmically).

In the no-fork solution, we encourage - maybe reward - white hat quantum a= ctors to recover vulnerable Bitcoin under lost property law. If it's cl= aimed, then it's returned; if not claimed, it's invested for the pu= blic good. This is then a race between white hat and black hat actors. BUT = most laws will deter white hat actors because it might be considered comput= er misuse. It would be really helpful if the Bitcoin consensus said, "= We favor white hat actors protecting Bitcoin". Although there are no B= itcoin terms and conditions or EULA, this would massively protect white hat= s.

In the hard fork solution, instead of burning t= he 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.<= /div>

I apologize for the lack of technical details at t= his point. We have a lot of code written, and I did make a note to that eff= ect in my submission, but that bit seems to have been cut off. The recovery= process has to obey the law and be distributable worldwide, and be fair, a= nd I think it is possible to do all that. Not simple, of course. In the mea= ntime, 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 conduition wro= te:
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 v= est the power of quantum-recovery using legal mechanisms (e.g. KYC, real-wo= rld evidence, etc)... in a group of people working in an office somewhere? = Surely you realize that's impractical and un-scaleable. Besides, even i= f you had all the manpower needed to do it, no one who owns Bitcoin would r= un a node which subscribes to such consensus rules. A huge portion of the s= upply on that (hardforked) chain would be effectively under the total contr= ol of a select few. Who elects these people?

It so= unds 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 questions = to be debated around the rights of property holders in case of a possible q= uantum-freeze. But this proposal at least is DOA because KYC cannot = be the answer, for practical and ethical reasons.

= Perhaps, independent 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 o= ught to be legal guidelines for how quantum giants like Google or IBM shoul= d behave given their newfound quantum weaponry. It'll be impossible to = fully enforce any such rules, but if they want=C2=A0to play nice, so= meone should tell them what "playing nice" actually looks like.

regards,
conduition
On Thursday, August 7, 20= 25 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.

=C2=A0

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: =

=C2=A0

Abstract<= /u>

=C2=A0

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.

=C2=A0

Motivation

=C2=A0

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).

=C2=A0

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:

=C2=A0

- Owners who don= 9;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

=C2=A0

When quantum comput= ers capable of running Shor's algorithm arrive, the remaining vulnerabl= e coins face two equally problematic outcomes:

=C2=A0

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

=C2=A0

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

=C2=A0

Note on "Theft= ": Bitcoin's protocol operates purely through cryptographic proofs= , without built-in concepts of ownership or theft=E2=80=94these are legal c= onstructs 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 app= ropriation of others' funds.

=C2=A0

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, prot= ective custody preserves coins for their rightful owners rather than allowi= ng them to be stolen or destroyed.

=C2=A0

The Inheritance Vul= nerability Window

=C2=A0

Consider the "= Auntie Alice's Bitcoin" scenario: Alice stores Bitcoin in cold sto= rage as inheritance for her grandchildren, with keys secured in a safe depo= sit box. She doesn'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.

=C2=A0

Three outcomes are = possible:

=C2=A0

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)

=C2=A0

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

=C2=A0

Principles

=C2=A0

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

=C2=A0

Recovery Process=

=C2=A0

Recovery Timing Mat= rix

=C2=A0

| Scenario=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 | Timing=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 | Method=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Requireme= nts=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |

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

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

| Q-Day (Quantum Da= y)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | When quantum computers arrive | Wh= ite-hat recovery race=C2=A0=C2=A0 | No protocol changes needed |<= /u>

| Emergency Cut-ove= r=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Catastrophic quantum break=C2= =A0=C2=A0=C2=A0 | Parallel chain migration=C2=A0 | Rapid consensus response= =C2=A0=C2=A0 |

| Overlapping M/Q-D= ay=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Both processes active=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Concurrent migrations=C2=A0=C2=A0=C2= =A0=C2=A0 | Mempool competition=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=

=C2=A0

Recovery Protocol

=C2=A0

All recovery transa= ctions follow the same pattern:

=C2=A0

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

=C2=A0

Consensus Layer<= /u>

=C2=A0

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

=C2=A0

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

=C2=A0

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

=C2=A0

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

=C2=A0

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

=C2=A0

Implementation Time= line

=C2=A0

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

=C2=A0

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>

=C2=A0

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

=C2=A0

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)

=C2=A0 - Broadcast = intent to recover specific UTXOs

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

=C2=A0 - Publish re= covery transactions in mempool but not mine

=C2=A0

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

=C2=A0

Proposed Fund Archi= tecture

=C2=A0

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

|=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Recovered Bitcoin=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

|=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 (Principal - 100% Preserved)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |

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

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 v

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

|=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Conservative Strategies=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |

|=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 (3-5% Annual Return)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

|=C2=A0=C2=A0=C2=A0= =C2=A0 * Lightning Network Liquidity=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<= u>

|=C2=A0=C2=A0=C2=A0= =C2=A0 * DeFi Lending Protocols=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |

|=C2=A0=C2=A0=C2=A0= =C2=A0 * Bitcoin-backed Stablecoins=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |

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

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 v

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

|=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Interest Distribution=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

|=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (Public Good Only)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

|=C2=A0=C2=A0=C2=A0= =C2=A0 * Open Source Development=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |

|=C2=A0=C2=A0=C2=A0= =C2=A0 * Quantum Security Research=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |

|=C2=A0=C2=A0=C2=A0= =C2=A0 * Global Infrastructure=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |

|=C2=A0=C2=A0=C2=A0= =C2=A0 * AI Safety & Alignment=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

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

=C2=A0

Claim Verification = Protocol

=C2=A0

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

=C2=A0

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

=C2=A0

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:

=C2=A0=C2=A0 - gove= rnment-issued identification

=C2=A0=C2=A0 - Hist= orical transaction knowledge

=C2=A0=C2=A0 - Temp= oral pattern matching

=C2=A0=C2=A0 - Soci= al recovery attestations

=C2=A0

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.

=C2=A0

Three-tier Evidence= Hierarchy

=C2=A0

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:

=C2=A0

- 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)

=C2=A0

Governance Structur= e

=C2=A0

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.

=C2=A0

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.

=C2=A0

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

=C2=A0

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

=C2=A0

Rationale=

=C2=A0

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.

=C2=A0

Technical Neutralit= y

=C2=A0

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

=C2=A0

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

=C2=A0

Risk Mitigation<= /u>

=C2=A0

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

=C2=A0

Legal Framework Con= siderations

=C2=A0

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 &qu= ot;taking without permission."

=C2=A0

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>

=C2=A0

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

=C2=A0

Legal clarification= and Jurisdiction choices need to be made.

=C2=A0

The Sovereign Law P= aradox

=C2=A0

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.

=C2=A0

Economic Impact<= /u>

=C2=A0

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

=C2=A0

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

=C2=A0

Appendix: Quantum V= ulnerability

=C2=A0

Vulnerable Address = Categories

=C2=A0

| Category=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Add= ress Type=C2=A0=C2=A0=C2=A0=C2=A0 | Key Status | Quantum Vulnerable | Est. = BTC (M) | Recovery Priority | Notes=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

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

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

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

| Reused P2PKH (spe= nt)=C2=A0 | P2PKH=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | Various=C2=A0=C2=A0=C2=A0 | Yes=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 2-4=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | High=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Spent =3D pubke= y revealed=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |

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

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

| Unused P2WPKH=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | P2WPKH=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Various=C2=A0=C2=A0=C2=A0 | No=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 | 4-6=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | Protected=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Modern sa= fe until spent=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |

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

| Total Vulnerable= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Yes=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | 3.5-5.5M=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | = 17-28% of supply=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<= /p>

=C2=A0

Quantum Risk=

=C2=A0

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

=C2=A0

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 pinpo= inting it at 2027. I think that's early, but there's some bright minds working on it."

=C2=A0

Recent Technical Ad= vances:

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

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

=C2=A0

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

=C2=A0

References

=C2=A0

1. NIST IR 8413 - &= quot;Status Report on the Third Round of the NIST Post-Quantum Cryptography= Standardization Process", July 2022.

=C2=A0=C2=A0 https://doi.org/10.6028/NIST.IR.8413

=C2=A0

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

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

=C2=A0

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

=C2=A0=C2=A0 Demons= trated 99.85% reduction in required quantum resources.=

=C2=A0

4. Jensen Huang - &= quot;Nvidia CEO says quantum computing is at an inflection point", Cha= nnel News Asia, June 11, 2025.

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

=C2=A0

5. Global Risk Inst= itute - "Quantum Threat Timeline 2025: Executive Perspectives on Barri= ers to Action", 2025.

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

=C2=A0

6. Brock Pierce - &= quot;Million Dollar Bitcoin CONFIRMED! Brock Pierce & Michael Terpin Dr= op BOMBS at Tokenize! 2025." YouTube, timestamp 18:10.

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

=C2=A0

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

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

=C2=A0

8. FIPS 204 - "= ;Module-Lattice-Based Digital Signature Standard", August 2024.=

=C2=A0=C2=A0 Specif= ies CRYSTALS-Dilithium (ML-DSA).

=C2=A0

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

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

=C2=A0

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

=C2=A0

11. Mosca, M. - &qu= ot;Quantum Threat Timeline," University of Waterloo, 2023.

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

--
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/bitcoind= ev/c76564f5-8a4c-43f9-be10-323b0d013baan%40googlegroups.com.
------=_Part_15059_425509788.1755637191474-- ------=_Part_15058_1431439207.1755637191474--