Subject: Re: [bitcoindev] Re: [BIP Proposal] No burn, Quantum Migration Proposal, Quantum Secure Asset Verification & Escrow (QSAVE)

From: "'conduition' via Bitcoin Development Mailing List" <[email-masked]>
Date: Tue, 19 Aug 2025 15:01:02 +0000

Hi James,

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

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

These tricks aren't perfect though: UTXOs belonging to bare-P2PK addresses, paper wallets, or brain wallets, which were generated without hardened BIP32 and have previously exposed pubkeys posted on-chain. For these UTXOs it is impossible (AFAIK) for anyone to distinguish an honest witness from a CRQC-attack witness. It is also hard to identify these addresses, because we can't tell just from looking at a public key whether it was generated from BIP32 or not. We can guess based on the key's earliest usage timestamp (before/after BIP32 introduction), but there is no rigorous mathematical test we can apply.

It's naive to say "only your solution" is the correct one.

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

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

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

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

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

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

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

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

regards,
conduition
On Monday, August 18th, 2025 at 11:12 AM, 'James T' via Bitcoin Development Mailing List <[email-masked]> wrote:

> I am suggesting that Bitcoin elects people who can arbitrate reasonable claims. The Bitcoin dev team proposing a burn solution is the same problem you articulate: a small group of people (80% of miners) voting to burn coins. I don't see a way around this fundamental problem. The keys will fail in the future; some human intervention is going to 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.
> 

> We like to assume there is no human intervention in Bitcoin and it's all algorithmic, but that's not true. There is an army of people working to 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? Deleting ownership is certainly one solution, but I just don't think it is a fair one.
> 

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

> In the no-fork solution, we encourage - maybe reward - white hat quantum 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 black 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 consensus said, "We favor white hat actors protecting Bitcoin". Although there are no Bitcoin terms and conditions or EULA, this would massively protect white hats.
> 

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

> I apologize for the lack of technical details at this point. We have a lot of code written, and I did make a note to that effect in my submission, but that bit seems to have been cut off. The recovery process has to obey the law and be distributable worldwide, and be fair, 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 PM UTC-7 conduition wrote:
> 

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

> > It sounds like something a corporate lawyer would cook up if asked how to solve the post-quantum-rescue problem. Not to say that legal opinions on quantum migration are unwanted. I'm sure there are interesting legal questions to be debated around the rights of property holders in case of a possible quantum-freeze. But this proposal at least is DOA because KYC cannot be the answer, for practical and ethical reasons.
> > 

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

> > regards,
> > conduition
> > On Thursday, August 7, 2025 at 5:26:07 PM UTC-7 James T wrote:
> > 

> > > This BIP Proposal is an alternative to QRAMP or a quantum winner-takes-all approach to the migration from a pre- to post quantum blockchain. It could be implemented as a hard fork OR as a consensus that quantum actors can legitimately move funds to safe addresses for protective custody and public good. It could even go forward with no consensuses at all since it is functionally equivalent to a quantum winner-takes-all at the protocol level.
> > > 

> > > BIP: TBD

> > > Title: Quantum Secure Asset Verification & Escrow (QSAVE)
> > > 

> > > Author: James Tagg

> > > Status: Draft

> > > Type: Standards Track

> > > Layer: Consensus (Consensus / Soft Fork / Hard Fork)
> > > 

> > > Created:

> > > License:

> > > Abstract

> > > This BIP proposes QSAVE (Quantum Secure Asset Verification & Escrow) - a non-sovereign wealth fund providing protective custody for Bitcoin vulnerable to quantum attack (see Appendix for detailed vulnerability assessment). QSAVE preserves 100% of the principal for rightful owners while using generated returns to fund the protocol and global public good. It provides an alternative to the QRAMP (Quantum Resistant Asset Migration Protocol) proposal (which makes coins unspendable) or taking no action (which allows quantum appropriation, which many view as theft). This proposal addresses coins that are dormant but acknowledges there may be coins that have quantum watermarks but have not migrated to quantum addresses. A separate BIP proposal will address this case.
> > > 

> > > Motivation

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

> > > With sufficient education and proactive migration, a significant portion of the 2-4M BTC in reused addresses could be moved to quantum-safe addresses before the threat materializes. Modern wallets are increasingly implementing best practices such as always sending change to fresh addresses. However, some portion will inevitably remain unprotected when 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, the remaining vulnerable coins face two equally problematic outcomes:
> > > 

> > > 1. Quantum appropriation: First actors with quantum computers take the coins
> > > 

> > > 2. Forced burning: The community burns coins preventatively (by making them unspendable), breaking 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—these are legal constructs that vary by jurisdiction. The community holds divergent views: some consider using advanced technology to derive private keys as legitimate within Bitcoin's rules, while others view it as unethical appropriation of others' funds.
> > > 

> > > QSAVE addresses both perspectives: If quantum key derivation is considered fair game, then racing 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 balances property rights with Bitcoin's algorithmic nature. Either way, protective custody preserves coins for their rightful owners rather than allowing them to be stolen or destroyed.
> > > 

> > > The Inheritance Vulnerability Window
> > > 

> > > Consider the "Auntie Alice's Bitcoin" scenario: Alice stores Bitcoin in cold storage as inheritance for her grandchildren, with keys secured in a safe deposit box. She doesn't follow Bitcoin news and remains unaware of quantum threats. She passes away and by the time her heirs discover the wallet, quantum computers capable of deriving private keys have emerged.
> > > 

> > > Three outcomes are possible:
> > > 

> > > 1. Without protection: Quantum actors take the grandchildren's inheritance
> > > 

> > > 2. With burning: The 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 why we cannot assume dormant equals lost and why protective custody is the only approach that preserves legitimate ownership rights. The inability to distinguish between lost coins and stored coins is the fundamental reason protective custody is essential.
> > > 

> > > Principles

> > > 1. Preserve the principal - 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 shocks by keeping principal locked while only using generated returns
> > > 

> > > 4. Generate returns for the benefit of humanity through conservative 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 migration | Hard fork implementation |
> > > 

> > > | Q-Day (Quantum Day) | When quantum computers arrive | White-hat recovery race | No protocol changes needed |
> > > 

> > > | Emergency Cut-over | Catastrophic quantum break | Parallel chain migration | Rapid consensus response |
> > > 

> > > | Overlapping M/Q-Day | Both processes active | Concurrent migrations | 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 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 Recovery Timing Matrix above):
> > > 

> > > No Action: PQP (Post Quantum Pay) wallet technology - purely commercial/user layer
> > > 

> > > Consensus: Community endorsement strengthens legal position for white-hat recovery
> > > 

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

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

> > > Implementation 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 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 (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 patterns if there is any doubt/dispute on Q-Day date
> > > 

> > > Post Break:

> > > 1. Identity Verification: Since quantum computers will create publicly available databases of all exposed private keys (similar to existing databases of classically compromised keys), possession of the private key 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 becomes meaningless as proof of ownership since quantum-derived key databases will be publicly available.
> > > 

> > > Three-tier Evidence Hierarchy
> > > 

> > > The claim verification process employs a three-tier evidence hierarchy to evaluate ownership claims with staking and slashing to prevent fraud and partial time based awards in case of partial proof. Evidence strength:
> > > 

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

> > > - Tier 2: Third-party records (exchange logs, bankruptcy filings, probate rulings, trustee statements)
> > > 

> > > - Tier 3: Supporting materials (affidavits, chain-of-inheritance, media coverage, witness declarations)
> > > 

> > > Governance Structure

> > > The QSAVE fund requires robust decentralized governance to ensure proper stewardship of recovered assets. The governance framework must balance efficiency with decentralization while maintaining absolute commitment to principal preservation.
> > > 

> > > Core Governance Principles:
> > > 

> > > - Quadratic Voting: Reduces influence of large stakeholders while maintaining democratic participation
> > > 

> > > - Multi-Council Structure: Separates technical, allocation, and audit functions to prevent capture
> > > 

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

> > > - Emergency Procedures: Supermajority (75%) required for emergency actions; freeze of recovery process can be executed by authorized individuals until quarum can be established.
> > > 

> > > Governance Bodies:

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

> > > - Allocation Council: Manages distribution of generated returns to for the public good thru charitable donation, impact investing or research funding.
> > > 

> > > - Audit Council: Provides independent oversight and transparency 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 for addressing quantum vulnerability. Unlike binary approaches (burn or allow appropriation), QSAVE introduces a third path that aligns with Bitcoin's core principles while solving practical challenges.
> > > 

> > > Technical Neutrality

> > > QSAVE maintains implementation flexibility:
> > > 

> > > - Fork-neutral: Works with or without protocol changes (see Recovery Timing Matrix)
> > > 

> > > - Price-neutral: Markets have already priced quantum risk (per BlackRock ETF disclosures)
> > > 

> > > - Liquidity-neutral: Principal preservation prevents market disruption
> > > 

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

> > > - Legal Clarity: Aligns with established lost & found precedents
> > > 

> > > - Governance Capture: Quadratic voting and mandatory principal preservation constraints
> > > 

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

> > > Legal Framework Considerations
> > > 

> > > The recovery process aligns with established legal principles in many jurisdictions. Under precedents 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 — a universally accepted practice despite technically involving "taking without permission."
> > > 

> > > In the United States alone, over 400 million items are moved to lost & found departments annually without legal consequence. QSAVE applies this same principle to digital assets vulnerable to quantum attack, providing a protective custody mechanism that preserves ownership rights.
> > > 

> > > Furthermore, the U.S. Department of Justice's policy on good-faith security research provides additional legal clarity for recovery operators 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 disadvantage. Bad actors operating from jurisdictions with weak or non-existent cryptocurrency regulations can exploit quantum vulnerabilities with impunity, while good-faith actors in law-compliant states remain paralyzed 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 developing good faith exemptions to their computer security laws and these will need to accelerate.
> > > 

> > > Economic Impact

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

> > > 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. 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 (spent) | P2PKH | Various | Yes | 2-4 | High | Spent = pubkey revealed |
> > > 

> > > | Reused P2WPKH (spent) | 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 be accelerating:
> > > 

> > > Expert Consensus:

> > > - Conservative estimates (NIST IR 8413): 2035-2050
> > > 

> > > - Aggressive projections: 2027-2035
> > > 

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

> > > Recent Technical Advances:
> > > 

> > > - 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 week (20-fold decrease from previous estimate)
> > > 

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

> > > Regulatory Requirements:

> > > - U.S. National Security Systems must use quantum-resistant algorithms for new acquisitions after January 1, 2027 (NSA CNSA 2.0)
> > > 

> > > - Given 1-5 year government procurement cycles, blockchain proposals today must be quantum-proof
> > > 

> > > References

> > > 1. NIST IR 8413 - "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 - "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 AI - "Quantum Advantage in Error Correction", Nature, 2025.
> > > 

> > > Demonstrated 99.85% reduction in required quantum resources.
> > > 

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

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

> > > 5. Global Risk Institute - "Quantum Threat Timeline 2025: Executive Perspectives on Barriers to Action", 2025.
> > > 

> > > https://globalriskinstitute.org/publication/quantum-threat-timeline-2025-executive-perspectives-on-barriers-to-action/
> > > 

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

> > > https://www.youtube.com/watch?v=DhYO1Jxmano
> > > 

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

> > > https://bitcointalk.org/index.php?topic=3120.0
> > > 

> > > 8. FIPS 204 - "Module-Lattice-Based Digital Signature Standard", 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 quantum computing risk to Bitcoin holdings, 2024.
> > > 

> > > 11. Mosca, M. - "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 the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2e635098-a8f5-43d6-b8e9-5971ba8ba218n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2gC13oDaC58JAFFSQ0qBve4whtVS0W5oVLNuxaWEfBFvYzTt_rHAhU6Asdb33xwK3mm6DZ6xuK83N8crsEdryPvxH5DaY6J1uRJXdiNg2TA%3D%40proton.me.