Delivery-date: Mon, 18 Aug 2025 10:12:45 -0700 Received: from mail-qv1-f59.google.com ([209.85.219.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uo3PW-0005Fn-Vi for bitcoindev@gnusha.org; Mon, 18 Aug 2025 10:12:45 -0700 Received: by mail-qv1-f59.google.com with SMTP id 6a1803df08f44-70ba7aa11c2sf66989056d6.1 for ; Mon, 18 Aug 2025 10:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1755537156; x=1756141956; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to: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=/AGKORQFKAEwWRoASt2OJx6+wkiQ2NRuFm1Kc9Jz/9Y=; b=aB6BngSybRKIWO7ezhFsAUuepg/nyNzk2hP15bK024PncEq41wHxaY+KVhDIufKlF1 lp5ARNKV6PPeYE/EXFB422X3gF4BZPozI3EzI47/XKAAcjIwQw+P2PyZqVAIwE0RYO40 VopLX+gg5UkRt3UCF8TdxK0FsW/TSbu9Cw71ad1jqOoUYppRuU2PPPAkSg85161+4D4Y XutpLEou2dJk0OPtMzRPp0POsJqPBmbh7KG7+j/m53yLLJ7waPXMij6EFJpQ6xkEqNEf Cvs7nG3VT7xU1t7mZJqbdKPzpbyFhXFcZtH3eqyltEhw05Lwjoolt5bK6yR5zOpF4Ih2 41qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755537156; x=1756141956; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/AGKORQFKAEwWRoASt2OJx6+wkiQ2NRuFm1Kc9Jz/9Y=; b=YtWERaG7tpCx24SrrwT0BUfr9MlB6PPk/oN8l/c43xwle1kFX793KxaJ2yzFWMQT/N HS3QyiXDNYwMHsnKeK4cfN8NjXXzOqGJpMuFPlN69lUEkmJMnxfEvTAPbHGnO5NQh7we eraa5/vjaMTxh0fg4tRkei1iCoNsjk8/KhGhtWcd47AKUbfgCofoQ9aI4U9bYFakP6GC 52eLiLlzPndZIPNc0nItx0aNgfCXorgUo0hoBSImKuR1vEmTMteCVT9gI1UOeXsd6b7F WtuBLJ1HyiWMuXQbZ24M3EhPzszqiDxCpNSkJ/MYgCUzkyGMIR9EXG5RzEct9EtxWw9C iQuw== X-Forwarded-Encrypted: i=1; AJvYcCUlEIPp8ssc0XUdVu5svnyupfatV/b+bsm0MXvHN5XTDbl4glQenkwwKKusFt7gVdfrN9dzV+Mvbehp@gnusha.org X-Gm-Message-State: AOJu0YzT4KDLvmqmuSanhN7LpGGo3RqbUTLnBAGq8kwYzIYN8IKjtHq4 HsWb0ApcXhj8BKi+QJRlTxlJwj8viA2NZWwM8QIam0jEIzLv4yqnCk6N X-Google-Smtp-Source: AGHT+IF1Pcu0IdaGYkMPRqAcaNWn6TxVPg6G683wB0axqvdtcXIlwAhwEk61eEEkRJEl5bNIp8gDXA== X-Received: by 2002:a05:620a:45a2:b0:7e8:12c1:4d5b with SMTP id af79cd13be357-7e87df69771mr1670242085a.6.1755537156137; Mon, 18 Aug 2025 10:12:36 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdVNbY9tLQSconAGBg/smWBhhX3QlbqCzrjJQXekhScZw== Received: by 2002:a05:622a:11cb:b0:4b0:7448:c7ee with SMTP id d75a77b69052e-4b1156a2f5fls63447551cf.1.-pod-prod-03-us; Mon, 18 Aug 2025 10:12:31 -0700 (PDT) X-Received: by 2002:a05:622a:5a8d:b0:4b0:d8b6:dc5d with SMTP id d75a77b69052e-4b11e1824d9mr201567391cf.23.1755537151020; Mon, 18 Aug 2025 10:12:31 -0700 (PDT) Received: by 2002:a05:690c:fd1:b0:71a:2700:7cf0 with SMTP id 00721157ae682-71c340211b2ms7b3; Thu, 14 Aug 2025 14:26:32 -0700 (PDT) X-Received: by 2002:a05:690c:9c08:b0:71b:7139:b949 with SMTP id 00721157ae682-71e47987b69mr6916217b3.37.1755206791652; Thu, 14 Aug 2025 14:26:31 -0700 (PDT) Date: Thu, 14 Aug 2025 14:26:31 -0700 (PDT) From: "'James T' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <2e635098-a8f5-43d6-b8e9-5971ba8ba218n@googlegroups.com> In-Reply-To: References: 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_939902_1865653585.1755206791280" X-Original-Sender: tagg.james@googlemail.com X-Original-From: James T Reply-To: James T 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.4 (+) ------=_Part_939902_1865653585.1755206791280 Content-Type: multipart/alternative; boundary="----=_Part_939903_240511289.1755206791280" ------=_Part_939903_240511289.1755206791280 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I *am* suggesting that Bitcoin elects people who can arbitrate reasonable= =20 claims. The Bitcoin dev team proposing a burn solution is the same problem= =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 solution= =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 there= =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? Deleting= =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 most= =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 favor= =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 protocol= =20 decision, and there is no white hat actor risk. I apologize for the lack of technical details at this point. We have a lot= =20 of code written, and I did make a note to that effect in my submission, but= =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 possible= =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 ho= w=20 > this "BIP" would maintain Bitcoin's value as a distributed system. It=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 all= =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 on= =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 to= =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 wis= e=20 > to encourage quantum adversaries to become benevolent, somehow. I'm not= =20 > sure what that looks like. If a quantum freeze doesn't happen, there ough= t=20 > to be legal guidelines for how quantum giants like Google or IBM should= =20 > behave given their newfound quantum weaponry. It'll be impossible to full= y=20 > enforce any such rules, but if they *want* to play nice, someone should= =20 > 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 tha= t=20 >> quantum actors can legitimately move funds to safe addresses for protect= ive=20 >> custody and public good. It could even go forward with no consensuses at= =20 >> all since it is functionally equivalent to a quantum winner-takes-all at= =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 goo= d.=20 >> It provides an alternative to the QRAMP (Quantum Resistant Asset Migrati= on=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 portion= =20 >> of the 2-4M BTC in reused addresses could be moved to quantum-safe=20 >> addresses before the threat materializes. Modern wallets are increasingl= y=20 >> implementing best practices such as always sending change to fresh=20 >> addresses. However, some portion will inevitably remain unprotected when= =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 preserves= =20 >> ownership rights and puts dormant capital to work for humanity. >> >> =20 >> >> Note on "Theft": Bitcoin's protocol operates purely through cryptographi= c=20 >> proofs, without built-in concepts of ownership or theft=E2=80=94these ar= e legal=20 >> constructs that vary by jurisdiction. The community holds divergent view= s:=20 >> some consider using advanced technology to derive private keys as=20 >> legitimate within Bitcoin's rules, while others view it as unethical=20 >> 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 it= '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 than= =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 of= =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 inheritan= ce >> >> 2. With burning: The network destroys legitimate inheritance funds >> >> 3. With protective custody: Heirs can claim their inheritance with prope= r=20 >> 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 owners= hip=20 >> rights. The inability to distinguish between lost coins and stored coins= 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 | Concurrent= =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 white-ha= t=20 >> 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 scenari= os >> >> =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 ke= y=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 t= o=20 >> 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, probat= e=20 >> 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 proper= =20 >> stewardship of recovered assets. The governance framework must balance= =20 >> efficiency with decentralization while maintaining absolute commitment t= o=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 reporti= ng >> >> =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 allo= w=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 BlackRock= =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 constit= ute=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 with= out=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 this= =20 >> same principle to digital assets vulnerable to quantum attack, providing= 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 operato= rs=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 vulnerabilit= ies=20 >> with impunity, while good-faith actors in law-compliant states remain=20 >> paralyzed by legal uncertainty. This creates a systematic wealth transfe= r=20 >> from citizens of law-abiding nations to criminal organizations and rogue= =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 Architecture= ) >> >> - 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 exposed= =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 pubkey= =20 >> revealed | >> >> | Reused P2WPKH (spent) | P2WPKH | Various |=20 >> Yes | ~0.5-1 | High | Modern but still= =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 unti= l=20 >> spent | >> >> | Script Hash | P2SH/P2WSH | Various | Mostly=20 >> No | 3-4 | Protected | Generally safe (depends= 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 othe= r=20 >> 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 coul= d=20 >> theoretically be broken by a quantum computer with 1 million noisy qubit= s=20 >> 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 re= ach=20 >> of being able to apply quantum computing" to solve problems "in the comi= ng=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 FAQ"= ,=20 >> September 7, 2022. >> >> =20 >> https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FA= Q_.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 inflection= =20 >> point", Channel News Asia, June 11, 2025. >> >> =20 >> https://www.channelnewsasia.com/business/nvidia-ceo-says-quantum-computi= ng-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-2025= -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/= 2e635098-a8f5-43d6-b8e9-5971ba8ba218n%40googlegroups.com. ------=_Part_939903_240511289.1755206791280 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am suggesting that Bitcoin elects people who can arbitrate re= asonable 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 wil= l fail in the future; some human intervention is going to happen. Remember,= if the burn 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.
<= div>
We like to assume there is no human intervention in Bi= tcoin and it's all algorithmic, but that's not true. There is an army of pe= ople working to secure Bitcoin behind the scenes, including upfront KYC/AML= and after-the-fact recovery by private companies and law enforcement when = there is a hack. This all works on a worldwide basis today.

No lawyers have been involved in the drafting of our proposal. = 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 ownership? Del= eting ownership is certainly one solution, but I just don't think it is a f= air one.

We are proposing our solution as either= a hard fork or a no-fork. Either way, we still have to solve the problem o= f a room full of elected experts to adjudicate claims (obviously, they woul= d be distributed worldwide, and often it could be achieved algorithmically)= .

In the no-fork solution, we encourage - maybe = reward - white hat quantum actors to recover vulnerable Bitcoin under lost = property law. If it's claimed, then it's returned; if not claimed, it's inv= ested for the public 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 c= onsidered computer misuse. It would be really helpful if the Bitcoin consen= sus said, "We favor white hat actors protecting Bitcoin". Although there ar= e no Bitcoin terms and conditions or EULA, this would massively protect whi= te hats.

In the hard fork solution, instead of b= urning the coins, they go into the recovery process, and here the Bitcoin c= onsensus has made a clear protocol decision, and there is no white hat acto= r 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 conduition wrote:
Hi James,

This is a curious idea, though I&= #39;m not seeing any technical details of how this "BIP" would ma= intain Bitcoin's value as a distributed system. It more-or-less sounds = like you're suggesting to vest the power of quantum-recovery using lega= l mechanisms (e.g. KYC, real-world evidence, etc)... in a group of people w= orking in an office somewhere? Surely you realize that's impractical an= d 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 such consensus= rules. A huge portion of the supply on that (hardforked) chain would be ef= fectively under the total control of a select few. Who elects these people?=

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 a= re interesting legal questions to be debated around the rights of property = holders in case of a possible quantum-freeze. But this proposal at least is= DOA because KYC cannot be the answer, for practical and ethical rea= sons.

Perhaps, independent of any technical consen= sus upgrades, it would be wise to encourage quantum adversaries to become b= enevolent, somehow. I'm not sure what that looks like. If a quantum fre= eze doesn't happen, there ought to be legal guidelines for how quantum = giants like Google or IBM should behave given their newfound quantum weapon= ry. It'll be impossible to fully enforce any such rules, but if they want=C2=A0to play nice, someone should tell them what "playing ni= ce" actually looks like.

regards,
c= onduition
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.

=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/2e635098-a8f5-43d6-b8e9-5971ba8ba218n%40googlegroups.com.
------=_Part_939903_240511289.1755206791280-- ------=_Part_939902_1865653585.1755206791280--