From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 22 Sep 2026 16:14:36 -0700 Received: from mail-oi1-f187.google.com ([209.85.167.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x99h2-00029F-Oi for bitcoindev@gnusha.org; Tue, 22 Sep 2026 16:14:35 -0700 Received: by mail-oi1-f187.google.com with SMTP id 5614622812f47-4c55ba309c2sf905735b6e.1 for ; Tue, 22 Sep 2026 16:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1790118867; x=1790723667; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :content-type:mime-version:subject:references:in-reply-to:message-id :to:from:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=yDWXt0EL7THs0NFFvbY5byhLryeaDOzNQZkiuOW/Flw=; b=fWqChqaNxu5piADn5AF+uhMg05UhLGxxjWVqbU0EqxZM1KQDEAl3V7EOpcUJT5YUGt yw+AkAwsrEMh8YTvEdeIxb2URP4gcDYgHTj0NPhdNdkbOKpK+tc/ksmi9jZ9ZZYVJy2D 3YCRahvEG8MIfgvEBj9rTPIjZOzOoRempViSnIhs5po4FN6EL1GsMu2PgN0GOAMb2VXf 7ndcxRajc4w6DPVvwMeCzRvilCuoIvOMs9s8tqcPm8XC+7Mbb4iLUWG6cHohsfxsWdiB UcxCBOPVl36w9NTZ2uwp/Y8WrcFDFMolQRf4CGM+KwgWTBZVYuigkAub9sgFfjveVc4n yYBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790118867; x=1790723667; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :content-type: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:content-type; bh=yDWXt0EL7THs0NFFvbY5byhLryeaDOzNQZkiuOW/Flw=; b=Ptm9zZhDTEQ3eNxNti7nHvMJZPtBnNwmp5WijhThBlbk8sqaIClHgV03X74ZjevJ6f FdcKi65lhVZziP4ntxTiIzwxL6t70GfhW2XnWHyg4JpINZsp34E/MMMyyARKuZw1gmgE tpH5zhgrIOLg7P/+fxjbg0Jkd8EqChjMvKcaSGqphgE/KncuCFdKjvc8WjDWhTbw+uUw V7IOBHsdhtzYRWQkjGC6tpX8dnLrz7JoQ+T8pVWp3DBvpxXp357qolOkVmCeww45AiW3 6kMwvhCpcJfBbQAdjg1ielpwtYqS3z4nLO8ioXjUSHzufkxpx5HioKZLNdM1NcuV1oG5 +N7Q== X-Forwarded-Encrypted: i=1; AKwUvBwU/K9ZR0YhZDz1gdJvB42iQ2NggVL1V6AYbQKtWXoTxH/WDKZ6D+s67mcpP4YFlkvYjxPpRAZGJCpd@gnusha.org X-Gm-Message-State: AFuF++mSerqQ4UIsZWXGOUgF3s7AxhPRXOMm1bcrlUFuBwmWO0GhQ6kU ng/Idvyhh7lbBEtcpZEWlRir+7DqT3Zn7DzJrxXLRKiqudFYvNUQ/Q4H X-Received: by 2002:a05:6870:8897:b0:451:25f2:da63 with SMTP id 586e51a60fabf-49089c3c84fmr1144972fac.6.1790118866577; Tue, 22 Sep 2026 16:14:26 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfHUxElALMQkamlKADJHSbaaOqUCDZURwhc0ZKJjWxgzg==" Received: by 2002:a05:6871:14e:b0:479:bbe:a714 with SMTP id 586e51a60fabf-485709141b5ls9400119fac.0.-pod-prod-08-us; Tue, 22 Sep 2026 16:14:18 -0700 (PDT) X-Received: by 2002:a05:6808:6712:b0:4c3:4e34:c69e with SMTP id 5614622812f47-4d5b6491f91mr996269b6e.8.1790118858397; Tue, 22 Sep 2026 16:14:18 -0700 (PDT) Received: by 2002:a05:690c:23c2:b0:81e:11b4:1172 with SMTP id 00721157ae682-89adb36ef90ms7b3; Mon, 21 Sep 2026 16:23:13 -0700 (PDT) X-Received: by 2002:a05:690c:e18f:10b0:861:804f:32ff with SMTP id 00721157ae682-89731ba6167mr29359277b3.27.1790032992857; Mon, 21 Sep 2026 16:23:12 -0700 (PDT) Date: Mon, 21 Sep 2026 16:23:12 -0700 (PDT) From: "'James T' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <48b51073-e3d5-4875-a16d-216fb12fa7fcn@googlegroups.com> In-Reply-To: References: <2e635098-a8f5-43d6-b8e9-5971ba8ba218n@googlegroups.com> Subject: Re: [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_74948_263735236.1790032992515" 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_74948_263735236.1790032992515 Content-Type: multipart/alternative; boundary="----=_Part_74949_834180826.1790032992515" ------=_Part_74949_834180826.1790032992515 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 Yes, SHA256 was a concern at the time, and quantum computers were a distant= =20 thought, but he acknowledged that in certain circumstances we might need to= =20 rewrite the chain. However, you are right: this is vanishingly unlikely to= =20 be approved, so I have thought more about it. I am suggesting that either= =20 we legalize white-hat hacking and lock old coins so they can only be moved= =20 to a lost property office after a certain time - that would be defined as a= =20 white-hat act. I think a simple consensus vote could give that permission= =20 in the USA. That way, only someone with the right key can move coins, but= =20 after a certain time, that key needs a second factor. A ZK proof of=20 derivation from your seed would work, or, for extremely old coins, we would= =20 need corroboration that can't be found uniquely on-chain and might require= =20 further evidence. This sort of locking soft fork would avoid a burn and buy= =20 time for a clean migration. I have written this up as a BIP proposal, which= =20 I'll post soon.=20 On Monday, September 15, 2025 at 12:20:23=E2=80=AFPM UTC-7 conduition wrote= : > Hi James, > > Notice how satoshi is talking about replacing the hash function SHA256 in= =20 > the context of blocks and proof-of-work, and that if SHA256 is broken we= =20 > could walk the chain back a bit and then "continue from there with a new= =20 > hash function". He's saying the community can come to consensus *on a new= =20 > hash algo* and then nodes continue operating under the same decentralized= =20 > PoW protocol from then onwards, just with a slightly cryptographic=20 > primitive underlying it. > > He is most definitely *not* saying the community should vest the power to= =20 > mint new blocks in some trusted block-producing organization. That would = be=20 > more closely analogous to what QSAVE is proposing, and would likewise be = a=20 > total reversal of the principles that Bitcoin was founded on. > > Unfortunately, a consensus hash algorithm switcheroo is much easier to=20 > engineer than migrating the UTXO set to a new PQ secure signing primitive= ,=20 > because with UTXOs we're talking about an authentication (ownership)=20 > problem, rather than a coordination (consensus) problem. As you know, the= =20 > network can't just hot-swap signing algorithms for old UTXOs the same way= =20 > we can hot-swap hash algorithms for new blocks. > > For the curious, here is the original thread where Satoshi said these=20 > things. https://bitcointalk.org/index.php?topic=3D191.0 > > > regards, > conduition > On Friday, September 5th, 2025 at 9:45 AM, 'James T' via Bitcoin=20 > Development Mailing List wrote: > > If we are going to quote Satoshi, *he imagined that some group of=20 > people=E2=80=94the consensus=E2=80=94could come together and agree on wha= t the chain should=20 > say if the underlying maths failed. =E2=80=9CIf SHA-256 became completely= broken, I=20 > think we could come to some agreement about what the honest blockchain wa= s=20 > before the trouble started, lock that in, and continue from there with a= =20 > new hash function.=E2=80=9D * > > *This is exactly what I am proposing; that we come to some agreement abou= t=20 > what the honest blockchain. If ECSDA is compromised, the only way to fix = it=20 > will be to reach a consensus, and that will require the labor of people.* > > So far from being a non-negotiable point, this was anticipated from the= =20 > beginning. I do agree with the sentiment. It would be great to have a=20 > protocol that operated independently of any human involvement but, the ve= ry=20 > fact that we are having this debate means we are past that point. We will= =20 > have to decide which path to take and I think the QSAVE proposal does the= =20 > least harm and the most good. > > Best, > > James > > On Tuesday, August 19, 2025 at 3:54:01=E2=80=AFAM UTC-7 Javier Mateos wro= te: > >> Hi James, thanks for opening this discussion. >> >> One point that is non-negotiable in Bitcoin is "embedding" in the code a= =20 >> group of people to arbitrate claims. That goes against de very essence o= f=20 >> the network ("trustless") and was part of the reason Bitcoin was created= . >> >> While not strictly canonical from Satoshi, his messages are clear: "what= =20 >> is needed is an electronic payment system based on cryptographic proof= =20 >> instead of trust..." and "lost coins only make everyone else's coins wor= th=20 >> slightly more..." Coin loss is an inherent risk of the system, but that= =20 >> shouldn=C2=B4t be confused with designing a protocol that automatically = protects=20 >> funds and transactions via human arbiters. >> >> That's why I consider this (and other) debates about preparing Bitcoin t= o=20 >> survive in a potentially dangerous quantum enviroment valid, whether tha= t=20 >> happens in 5 years or 100. Sooner or later, upgrades will be needeed, bu= t=20 >> the response must be technical and opt-in (migration to post-quantum=20 >> signatures, inheritable vaults, voluntary mechanisms), not a return to= =20 >> introducing judges into consensus. >> >> Best regards, >> Javier Mateos >> >> El lunes, 18 de agosto de 2025 a las 14:12:36 UTC-3, James T escribi=C3= =B3: >> >>> I *am* suggesting that Bitcoin elects people who can arbitrate=20 >>> reasonable claims. The Bitcoin dev team proposing a burn solution is th= e=20 >>> same problem you articulate: a small group of people (80% of miners) vo= ting=20 >>> to burn coins. I don't see a way around this fundamental problem. The k= eys=20 >>> will fail in the future; some human intervention is going to happen.=20 >>> Remember, if the burn happens, tens of thousands of people will open sa= fety=20 >>> deposit boxes full of Bitcoin addresses and find them zeroed out. Only = our=20 >>> solution provides a solution to this and preserves the Digital Gold pro= mise. >>> >>> We like to assume there is no human intervention in Bitcoin and it's al= l=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 t= here=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 key= s=20 >>> can no longer be relied on, what do we do to establish ownership? Delet= ing=20 >>> ownership is certainly one solution, but I just don't think it is a fai= r=20 >>> one. >>> >>> We are proposing our solution as either a hard fork or a no-fork. Eithe= r=20 >>> way, we still have to solve the problem of a room full of elected exper= ts=20 >>> to adjudicate claims (obviously, they would be distributed worldwide, a= nd=20 >>> often it could be achieved algorithmically). >>> >>> In the no-fork solution, we encourage - maybe reward - white hat quantu= m=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 publ= ic=20 >>> good. This is then a race between white hat and black hat actors. BUT m= ost=20 >>> laws will deter white hat actors because it might be considered compute= r=20 >>> misuse. It would be really helpful if the Bitcoin consensus said, "We f= avor=20 >>> white hat actors protecting Bitcoin". Although there are no Bitcoin ter= ms=20 >>> and conditions or EULA, this would massively protect white hats. >>> >>> In the hard fork solution, instead of burning the coins, they go into= =20 >>> the recovery process, and here the Bitcoin consensus has made a clear= =20 >>> protocol decision, and there is no white hat actor risk. >>> >>> I apologize for the lack of technical details at this point. We have a= =20 >>> lot of code written, and I did make a note to that effect in my submiss= ion,=20 >>> but that bit seems to have been cut off. The recovery process has to ob= ey=20 >>> the law and be distributable worldwide, and be fair, and I think it is= =20 >>> possible to do all that. Not simple, of course. In the meantime, there = are=20 >>> plenty of best practices that can be implemented to better protect and= =20 >>> 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'm not seeing any technical details of= =20 >>>> how 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 yo= u=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 o= f a=20 >>>> select few. Who elects these people? >>>> >>>> It sounds like something a corporate lawyer would cook up if asked how= =20 >>>> to solve the post-quantum-rescue problem. Not to say that legal opinio= ns 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, the= re=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 impossib= le 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 quantu= m=20 >>>>> blockchain. It could be implemented as a hard fork OR as a consensus = that=20 >>>>> quantum actors can legitimately move funds to safe addresses for prot= ective=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 >>>>> >>>>> 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 >>>>> >>>>> Abstract >>>>> >>>>> This BIP proposes QSAVE (Quantum Secure Asset Verification & Escrow) = -=20 >>>>> a 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 owner= s=20 >>>>> while using generated returns to fund the protocol and global public = good.=20 >>>>> It provides an alternative to the QRAMP (Quantum Resistant Asset Migr= ation=20 >>>>> Protocol) proposal (which makes coins unspendable) or taking no actio= n=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. >>>>> >>>>> Motivation >>>>> >>>>> Chain analysis reveals 3.5-5.5 million Bitcoin (~17-28% of circulatin= g=20 >>>>> supply) have exposed public keys vulnerable to quantum attack (see=20 >>>>> Appendix: Quantum Vulnerability Assessment for detailed breakdown). >>>>> >>>>> With sufficient education and proactive migration, a significant=20 >>>>> portion of the 2-4M BTC in reused addresses could be moved to quantum= -safe=20 >>>>> addresses before the threat materializes. Modern wallets are increasi= ngly=20 >>>>> implementing best practices such as always sending change to fresh=20 >>>>> addresses. However, some portion will inevitably remain unprotected w= hen=20 >>>>> quantum computers arrive due to: >>>>> >>>>> - 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 >>>>> >>>>> When quantum computers capable of running Shor's algorithm arrive, th= e=20 >>>>> remaining vulnerable coins face two equally problematic outcomes: >>>>> >>>>> 1. Quantum appropriation: First actors with quantum computers take th= e=20 >>>>> coins >>>>> >>>>> 2. Forced burning: The community burns coins preventatively (by makin= g=20 >>>>> them unspendable), breaking Bitcoin's promise as a store of value >>>>> >>>>> This BIP proposes a third way: QSAVE - protective custody that=20 >>>>> preserves ownership rights and puts dormant capital to work for human= ity. >>>>> >>>>> 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 pr= ivate=20 >>>>> keys as legitimate within Bitcoin's rules, while others view it as=20 >>>>> unethical appropriation of others' funds. >>>>> >>>>> 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 wa= y,=20 >>>>> protective custody preserves coins for their rightful owners rather t= han=20 >>>>> allowing them to be stolen or destroyed. >>>>> >>>>> The Inheritance Vulnerability Window >>>>> >>>>> Consider the "Auntie Alice's Bitcoin" scenario: Alice stores Bitcoin= =20 >>>>> in cold storage as inheritance for her grandchildren, with keys secur= ed in=20 >>>>> a safe deposit box. She doesn't follow Bitcoin news and remains unawa= re of=20 >>>>> quantum threats. She passes away and by the time her heirs discover t= he=20 >>>>> wallet, quantum computers capable of deriving private keys have emerg= ed. >>>>> >>>>> Three outcomes are possible: >>>>> >>>>> 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) >>>>> >>>>> This illustrates why we cannot assume dormant equals lost and why=20 >>>>> protective custody is the only approach that preserves legitimate own= ership=20 >>>>> rights. The inability to distinguish between lost coins and stored co= ins is=20 >>>>> the fundamental reason protective custody is essential. >>>>> >>>>> Principles >>>>> >>>>> 1. Preserve the principal - 100% of recovered Bitcoin remains=20 >>>>> available 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 >>>>> >>>>> Recovery Process >>>>> >>>>> Recovery Timing Matrix >>>>> >>>>> | Scenario | Timing | Method | Requirements | >>>>> >>>>> >>>>> |---------------------------|-------------------------------|--------= -------------------|----------------------------| >>>>> >>>>> | M-Day (Migration Day) | Pre-Q-Day with Hard Fork | Consensus-based= =20 >>>>> 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 chain=20 >>>>> migration | Rapid consensus response | >>>>> >>>>> | Overlapping M/Q-Day | Both processes active | Concurrent migrations= =20 >>>>> | Mempool competition | >>>>> >>>>> Recovery Protocol >>>>> >>>>> All recovery transactions follow the same pattern: >>>>> >>>>> 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 >>>>> >>>>> Consensus Layer >>>>> >>>>> Implementation varies based on timing and consensus level (see=20 >>>>> Recovery Timing Matrix above): >>>>> >>>>> No Action: PQP (Post Quantum Pay) wallet technology - purely=20 >>>>> commercial/user layer >>>>> >>>>> Consensus: Community endorsement strengthens legal position for=20 >>>>> white-hat recovery >>>>> >>>>> Soft Fork: Taproot V2/BIP-360 enables voluntary migration (doesn't=20 >>>>> protect dormant accounts) >>>>> >>>>> Hard Fork: Required for pre-Q-Day recovery or emergency cut-over=20 >>>>> scenarios >>>>> >>>>> Implementation Timeline >>>>> >>>>> Phase 0: Launch - Live from Day One >>>>> >>>>> - DAO Governance: Active voting on proposals from day one >>>>> >>>>> - Initial Publication: Non-Sovereign Wealth Fund Proposal Discussion >>>>> >>>>> Phase 1: Consensus Building & Infrastructure (Months 1-6) >>>>> >>>>> - Community discussion and refinement (while QD3 registrations=20 >>>>> 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) >>>>> >>>>> 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 >>>>> >>>>> 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 >>>>> >>>>> 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 >>>>> >>>>> Proposed Fund Architecture >>>>> >>>>> +-----------------------------------------+ >>>>> >>>>> | 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 | >>>>> >>>>> +-----------------------------------------+ >>>>> >>>>> Claim Verification Protocol >>>>> >>>>> Original owners can reclaim their coins at ANY time by providing: >>>>> >>>>> Prior to Break (Q-Day): >>>>> >>>>> 1. Cryptographic Proof: Message signed with their key >>>>> >>>>> 2. Optional Supporting Evidence: Transaction history, temporal=20 >>>>> patterns if there is any doubt/dispute on Q-Day date >>>>> >>>>> Post Break: >>>>> >>>>> 1. Identity Verification: Since quantum computers will create publicl= y=20 >>>>> available databases of all exposed private keys (similar to existing= =20 >>>>> databases of classically compromised keys), possession of the private= key=20 >>>>> alone is insufficient. >>>>> >>>>> 2. Required Evidence: >>>>> >>>>> - government-issued identification >>>>> >>>>> - Historical transaction knowledge >>>>> >>>>> - Temporal pattern matching >>>>> >>>>> - Social recovery attestations >>>>> >>>>> 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. >>>>> >>>>> Three-tier Evidence Hierarchy >>>>> >>>>> The claim verification process employs a three-tier evidence hierarch= y=20 >>>>> to evaluate ownership claims with staking and slashing to prevent fra= ud and=20 >>>>> partial time based awards in case of partial proof. Evidence strength= : >>>>> >>>>> - 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,=20 >>>>> media coverage, witness declarations) >>>>> >>>>> Governance Structure >>>>> >>>>> The QSAVE fund requires robust decentralized governance to ensure=20 >>>>> proper stewardship of recovered assets. The governance framework must= =20 >>>>> balance efficiency with decentralization while maintaining absolute= =20 >>>>> commitment to principal preservation. >>>>> >>>>> 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= =20 >>>>> #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. >>>>> >>>>> Governance Bodies: >>>>> >>>>> - Technical Council: Oversees security, recovery operations, and=20 >>>>> technical infrastructure >>>>> >>>>> - Allocation Council: Manages distribution of generated returns to fo= r=20 >>>>> the public good thru charitable donation, impact investing or researc= h=20 >>>>> funding. >>>>> >>>>> - Audit Council: Provides independent oversight and transparency=20 >>>>> reporting >>>>> >>>>> Safeguards: >>>>> >>>>> - Staggered terms to ensure continuity >>>>> >>>>> - Public transparency of all decisions >>>>> >>>>> - Time-locked implementations for non-emergency changes >>>>> >>>>> - Immutable smart contracts for principal preservation >>>>> >>>>> Rationale >>>>> >>>>> The QSAVE protocol represents the optimal technical implementation fo= r=20 >>>>> addressing quantum vulnerability. Unlike binary approaches (burn or a= llow=20 >>>>> appropriation), QSAVE introduces a third path that aligns with Bitcoi= n's=20 >>>>> core principles while solving practical challenges. >>>>> >>>>> Technical Neutrality >>>>> >>>>> 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=20 >>>>> BlackRock ETF disclosures) >>>>> >>>>> - Liquidity-neutral: Principal preservation prevents market disruptio= n >>>>> >>>>> 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 >>>>> >>>>> Risk Mitigation >>>>> >>>>> 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 ensure= s=20 >>>>> continuity >>>>> >>>>> Legal Framework Considerations >>>>> >>>>> 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 cons= titute=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 w= ithout=20 >>>>> permission." >>>>> >>>>> In the United States alone, over 400 million items are moved to lost = &=20 >>>>> found departments annually without legal consequence. QSAVE applies t= his=20 >>>>> same principle to digital assets vulnerable to quantum attack, provid= ing a=20 >>>>> protective custody mechanism that preserves ownership rights. >>>>> >>>>> Furthermore, the U.S. Department of Justice's policy on good-faith=20 >>>>> security research provides additional legal clarity for recovery oper= ators=20 >>>>> acting to protect vulnerable assets from quantum threats. >>>>> >>>>> Legal clarification and Jurisdiction choices need to be made. >>>>> >>>>> The Sovereign Law Paradox >>>>> >>>>> 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 vulnerabi= lities=20 >>>>> with impunity, while good-faith actors in law-compliant states remain= =20 >>>>> paralyzed by legal uncertainty. This creates a systematic wealth tran= sfer=20 >>>>> from citizens of law-abiding nations to criminal organizations and ro= gue=20 >>>>> states. The strongest property laws paradoxically create the weakest= =20 >>>>> defense against quantum theft. Jurisdictions are developing good fait= h=20 >>>>> exemptions to their computer security laws and these will need to=20 >>>>> accelerate. >>>>> >>>>> Economic Impact >>>>> >>>>> Positive Effects >>>>> >>>>> - Removes quantum uncertainty from Bitcoin price >>>>> >>>>> - Funds public good without inflation or taxation (see Fund=20 >>>>> Architecture) >>>>> >>>>> - Preserves Bitcoin's fixed supply economics (Principle #1) >>>>> >>>>> - Creates new model for decentralized capital allocation >>>>> >>>>> 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 >>>>> >>>>> Appendix: Quantum Vulnerability >>>>> >>>>> Vulnerable Address Categories >>>>> >>>>> | Category | Address Type | Key Status | Quantum Vulnerable | Est. BT= C=20 >>>>> (M) | Recovery Priority | Notes | >>>>> >>>>> >>>>> |-----------------------|------------------|------------|------------= --------|--------------|-------------------|-------------------------------= -----| >>>>> >>>>> | P2PK Outputs | P2PK | Various | Yes | 1.9-2.0 | Critical | Directly= =20 >>>>> exposed public keys | >>>>> >>>>> | Taproot (All) | P2TR | Various | Yes | 0.5-1 | Critical | ALL=20 >>>>> Taproot addresses exposed | >>>>> >>>>> | Reused P2PKH (spent) | P2PKH | Various | Yes | 2-4 | High | Spent = =3D=20 >>>>> pubkey revealed | >>>>> >>>>> | Reused P2WPKH (spent) | P2WPKH | Various | Yes | ~0.5-1 | High |=20 >>>>> Modern but still vulnerable | >>>>> >>>>> | Unused P2PKH | P2PKH | Various | No | 6-8 | Protected | Hash only;= =20 >>>>> quantum-safe | >>>>> >>>>> | Unused P2WPKH | P2WPKH | Various | No | 4-6 | Protected | Modern=20 >>>>> safe until spent | >>>>> >>>>> | Script Hash | P2SH/P2WSH | Various | Mostly No | 3-4 | Protected |= =20 >>>>> Generally safe (depends on script) | >>>>> >>>>> | Total Vulnerable | | | Yes | 3.5-5.5M | | 17-28% of supply | >>>>> >>>>> Quantum Risk >>>>> >>>>> There is a lack of consensus on the timeline for the quantum threat= =20 >>>>> other than it appears to be accelerating: >>>>> >>>>> 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. Mo= st=20 >>>>> people are now pinpointing it at 2027. I think that's early, but ther= e's=20 >>>>> some bright minds working on it." >>>>> >>>>> 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 no= isy=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= reach=20 >>>>> of being able to apply quantum computing" to solve problems "in the c= oming=20 >>>>> years" >>>>> >>>>> Regulatory Requirements: >>>>> >>>>> - U.S. National Security Systems must use quantum-resistant algorithm= s=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 >>>>> >>>>> References >>>>> >>>>> 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 >>>>> >>>>> 2. NSA CNSA 2.0 - "Commercial National Security Algorithm Suite 2.0= =20 >>>>> FAQ", September 7, 2022. >>>>> >>>>> >>>>> https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0= _FAQ_.PDF >>>>> >>>>> 3. Google Quantum AI - "Quantum Advantage in Error Correction",=20 >>>>> Nature, 2025. >>>>> >>>>> Demonstrated 99.85% reduction in required quantum resources. >>>>> >>>>> 4. Jensen Huang - "Nvidia CEO says quantum computing is at an=20 >>>>> inflection point", Channel News Asia, June 11, 2025. >>>>> >>>>> >>>>> https://www.channelnewsasia.com/business/nvidia-ceo-says-quantum-comp= uting-inflection-point-5174861 >>>>> >>>>> 5. Global Risk Institute - "Quantum Threat Timeline 2025: Executive= =20 >>>>> Perspectives on Barriers to Action", 2025. >>>>> >>>>> >>>>> https://globalriskinstitute.org/publication/quantum-threat-timeline-2= 025-executive-perspectives-on-barriers-to-action/ >>>>> >>>>> 6. Brock Pierce - "Million Dollar Bitcoin CONFIRMED! Brock Pierce &= =20 >>>>> Michael Terpin Drop BOMBS at Tokenize! 2025." YouTube, timestamp 18:1= 0. >>>>> >>>>> https://www.youtube.com/watch?v=3DDhYO1Jxmano >>>>> >>>>> 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 >>>>> >>>>> 8. FIPS 204 - "Module-Lattice-Based Digital Signature Standard",=20 >>>>> August 2024. >>>>> >>>>> Specifies CRYSTALS-Dilithium (ML-DSA). >>>>> >>>>> 9. BIP 341 - "Taproot: SegWit version 1 spending rules", January 2020= . >>>>> >>>>> https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki >>>>> >>>>> 10. BlackRock iShares Bitcoin Trust - Prospectus acknowledging quantu= m=20 >>>>> computing risk to Bitcoin holdings, 2024. >>>>> >>>>> 11. Mosca, M. - "Quantum Threat Timeline," University of Waterloo,=20 >>>>> 2023. >>>>> >>>>> Estimates 2035-2040 timeline for quantum threats to cryptography. >>>>> >>>> --=20 > You received this message because you are subscribed to a topic in the=20 > Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit=20 > https://groups.google.com/d/topic/bitcoindev/PjpaidcHX4A/unsubscribe. > To unsubscribe from this group and all its topics, send an email to=20 > bitcoindev+...@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/e4c8c8e8-0ffe-42a6-905a-0859= b2123f73n%40googlegroups.com > . > > > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 48b51073-e3d5-4875-a16d-216fb12fa7fcn%40googlegroups.com. ------=_Part_74949_834180826.1790032992515 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Yes, SHA256 was a concern at the time, and quantum computers were a dist= ant thought, but he acknowledged that in certain circumstances we might nee= d to rewrite the chain. However, you are right: this is vanishingly unlikel= y to be approved, so I have thought more about it. I am suggesting that eit= her we legalize white-hat hacking and lock old coins so they can only be mo= ved to a lost property office after a certain time - that would be defined = as a white-hat act. I think a simple consensus vote could give that permiss= ion in the USA. That way, only someone with the right key can move coins, b= ut after a certain time, that key needs a second factor. A ZK proof of deri= vation from your seed would work, or, for extremely old coins, we would nee= d corroboration that can't be found uniquely on-chain and might require fur= ther evidence. This sort of locking soft fork would avoid a burn and buy ti= me for a clean migration. I have written this up as a BIP proposal, which I= 'll post soon.=C2=A0



On Monday, September 15, 2025 at 12:20:23= =E2=80=AFPM UTC-7 conduition wrote:
Hi James,

= Notice how satoshi is talking about replacing the hash function SHA256 in t= he context of blocks and proof-of-work, and that if SHA256 is broken we cou= ld walk the chain back a bit and then "continue from there with a new = hash function". He's saying the community can come to consensus on a new hash algo=C2=A0and then nodes continue operating under the sa= me decentralized PoW protocol from then onwards, just with a slightly crypt= ographic primitive underlying it.

He is most definitely not=C2=A0saying the community= should vest the power to mint new blocks in some trusted block-producing o= rganization. That would be more closely analogous to what QSAVE is proposin= g, and would likewise be a total reversal of the principles that Bitcoin wa= s founded on.

Unfortunately, a consensus hash algorithm switcheroo is much easier to = engineer than migrating the UTXO set to a new PQ secure signing primitive, = because with UTXOs we're talking about an authentication (ownership) pr= oblem, rather than a coordination (consensus) problem. As you know, the net= work can't just hot-swap=C2=A0signing algorithms for old UTXOs the same= way we can hot-swap hash algorithms for new blocks.

For the curious, here is the original thre= ad where Satoshi said these things.=C2=A0https://bitcointal= k.org/index.php?topic=3D191.0


regards,
c= onduition
On Friday, September 5th, 2025 at 9:45 AM, 'James T' via Bi= tcoin Development Mailing List <bitco...@googlegroups.com> wrote:
=20

If we are going to quote Satoshi, he imagined that some group of peo= ple=E2=80=94the consensus=E2=80=94could come together and agree on what the= chain should say if the underlying maths failed. =E2=80=9CIf SHA-256 becam= e completely broken, I think we could come to some agreement about what the= honest blockchain was before the trouble started, lock that in, and contin= ue from there with a new hash function.=E2=80=9D

This is exactly what I am proposing; that we come to some agreement a= bout what the honest blockchain. If ECSDA is compromised, the only way to f= ix it will be to reach a consensus, and that will require the labor of peop= le.

So far from being a non-negotiable point, this was anticipate= d from the beginning. I do agree with the sentiment. It would be great to h= ave a protocol that operated independently of any human involvement but, th= e very fact that we are having this debate means we are past that point. We= will have to decide which path to take and I think the QSAVE proposal does= the least harm and the most good.

Best,

James


On Tuesday, August= 19, 2025 at 3:54:01=E2=80=AFAM UTC-7 Javier Mateos wrote:
Hi James, thanks for opening this disc= ussion.

One point that is non-negotiable in Bitcoin is &= quot;embedding" in the code a group of people to arbitrate claims. Tha= t goes against de very essence of the network ("trustless") and w= as part of the reason Bitcoin was created.

While n= ot strictly canonical from Satoshi, his messages are clear: "what is n= eeded is an electronic payment system based on cryptographic proof instead = of trust..." and "lost coins only make everyone else's coins = worth slightly more..." Coin loss is an inherent risk of the system, b= ut that shouldn=C2=B4t be confused with designing a protocol that automatic= ally protects funds and transactions via human arbiters.

That= 's why I consider this (and other) debates about preparing Bitcoin to s= urvive in a potentially dangerous quantum enviroment valid, whether that ha= ppens in 5 years or 100. Sooner or later, upgrades will be needeed, but the= response must be technical and opt-in (migration to post-quantum signature= s, inheritable vaults, voluntary mechanisms), not a return to introducing = judges into consensus.

Best regards,
Javier Mateos

El lunes, 18 de agosto de 2025 a las 14:12:36 UTC-3, James T escribi=C3=B3= :
I am sug= gesting that Bitcoin elects people who can arbitrate reasonable claims. The= Bitcoin dev team proposing a burn solution is the same problem you articul= ate: a small group of people (80% of miners) voting to burn coins. I don= 9;t see a way around this fundamental problem. The keys will fail in the fu= ture; some human intervention is going to happen. Remember, if the burn hap= pens, tens of thousands of people will open safety deposit boxes full of Bi= tcoin addresses and find them zeroed out. Only our solution provides a solu= tion to this and preserves the Digital Gold promise.

We like to assume there is no human intervention in Bitcoin and it's= all algorithmic, but that's not true. There is an army of people worki= ng 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 welc= ome input, but it's really an engineering problem. Once Bitcoin keys ca= n no longer be relied on, what do we do to establish ownership? Deleting ow= nership is certainly one solution, but I just don't think it is a fair = one.

We are proposing our solution as either a har= d fork or a no-fork. Either way, we still have to solve the problem of a ro= om full of elected experts to adjudicate claims (obviously, they would be d= istributed 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= invested for the public good. This is then a race between white hat and bl= ack hat actors. BUT most laws will deter white hat actors because it might = be considered computer misuse. It would be really helpful if the Bitcoin co= nsensus said, "We favor white hat actors protecting Bitcoin". Alt= hough there are no Bitcoin terms and conditions or EULA, this would massive= ly protect white hats.

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

I apologize for the lack of te= chnical details at this point. We have a lot of code written, and I did mak= e a note to that effect in my submission, but that bit seems to have been c= ut off. The recovery process has to obey the law and be distributable world= wide, and be fair, and I think it is possible to do all that. Not simple, o= f course. In the meantime, there are plenty of best practices that can be i= mplemented to better protect and prepare the network, which I know are in p= rocess.

Best,


<= div>James T


On Friday, August 8, 2025 at 7:07:25=E2=80=AFPM = UTC-7 conduition wrote:
On Thursda= y, August 7, 2025 at 5:26:07=E2=80=AFPM UTC-7 James T wrote:

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

BIP: TBD<= /u>

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

Author: James Tagg =

Status: Draft

Type: Standards Tra= ck

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

Created:<= /u>

License: =

Abstract<= /u>

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

Motivation

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

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

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

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

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

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

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

Note on "Theft= ": 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.

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.

The Inheritance Vul= nerability Window

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.

Three outcomes are = possible:

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

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

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

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

Principles

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

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

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

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

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

6. Enable priority = recovery through quantum watermark system

Recovery Process=

Recovery Timing Mat= rix

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

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

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

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

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

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

Recovery Protocol

All recovery transa= ctions follow the same pattern:

1. Move vulnerable = coins to protective custody addresses

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

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

4. Quantum watermar= ks permit immediate return of funds

Consensus Layer<= /u>

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

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

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

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

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

Implementation Time= line

Phase 0: Launch - L= ive from Day One

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

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

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

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

- Technical specifi= cation development for advanced features

- Technical specifi= cation for backup chain

- Legal framework e= stablishment with states

- Coordination with= regulatory bodies for good-faith protections

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

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

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

- Smart contract de= ployment for fund management

- Advanced governan= ce system implementation

- Claim verificatio= n protocol enhancements

- Complete backup c= hain synchronization and cut over process

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

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

- Public notificati= on system deployment

- Recovery transact= ion staging

- Security audits o= f all systems

- Publish recovery = chain software

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

- Broadcast inten= t to recover specific UTXOs

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

- Publish recover= y transactions in mempool but not mine

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

- Execute recovery = per Recovery Timing Matrix

- Use Recovery Prot= ocol for all transactions

- Manage protective= custody with multi-signature addresses

- Process ownership= claims per Claim Verification Protocol

- Initiate fund ope= rations per Fund Architecture

Proposed Fund Archi= tecture

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

| Recovere= d Bitcoin |

| (Principal -= 100% Preserved) |

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

|<= u>

v<= u>

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

| Conservati= ve Strategies |

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

| * Lightning N= etwork Liquidity |

| * DeFi Lendin= g Protocols |

| * Bitcoin-bac= ked Stablecoins |

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

|<= u>

v<= u>

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

| Interest = Distribution |

| (Public G= ood Only) |

| * Open Source= Development |

| * Quantum Sec= urity Research |

| * Global Infr= astructure |

| * AI Safety &= amp; Alignment |

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

Claim Verification = Protocol

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

Prior to Break (Q-D= ay):

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

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

Post Break:<= u>

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

2. Required Evidenc= e:

- government-iss= ued identification

- Historical tra= nsaction knowledge

- Temporal patte= rn matching

- Social recover= y attestations

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

Three-tier Evidence= Hierarchy

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

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

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

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

Governance Structur= e

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

Core Governance Pri= nciples:

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

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

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

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

Governance Bodies:<= u>

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

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

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

Safeguards:<= u>

- Staggered terms t= o ensure continuity

- Public transparen= cy of all decisions

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

- Immutable smart c= ontracts for principal preservation

Rationale=

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

Technical Neutralit= y

QSAVE maintains imp= lementation flexibility:

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

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

- Liquidity-neutral= : Principal preservation prevents market disruption

Implementation Adva= ntages

- Transparent Opera= tions: All movements follow Recovery Protocol

- Decentralized Gov= ernance: See Governance Structure section

- Auditable Recover= y: See Claim Verification Protocol

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

Risk Mitigation<= /u>

The protocol addres= ses key operational risks:

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

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

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

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

Legal Framework Con= siderations

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

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

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

Legal clarification= and Jurisdiction choices need to be made.

The Sovereign Law P= aradox

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

Economic Impact<= /u>

Positive Effects=

- Removes quantum u= ncertainty from Bitcoin price

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

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

- Creates new model= for decentralized capital allocation

Neutral Effects<= /u>

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

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

- Interest generati= on creates minimal selling pressure

Appendix: Quantum V= ulnerability

Vulnerable Address = Categories

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

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

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

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

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

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

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

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

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

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

Quantum Risk=

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

Expert Consensus:

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

- Aggressive projec= tions: 2027-2035

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

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"

Regulatory Requirem= ents:

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

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

References

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--
You received this message because you are subscribed to a topic in the Goog= le Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/PjpaidcHX= 4A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+...@goog= legroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/e4c8c8e8-0ffe-42a6-905a-= 0859b2123f73n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/48b51073-e3d5-4875-a16d-216fb12fa7fcn%40googlegroups.com.
------=_Part_74949_834180826.1790032992515-- ------=_Part_74948_263735236.1790032992515--