From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 07 Aug 2025 17:26:15 -0700 Received: from mail-qt1-f183.google.com ([209.85.160.183]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ukAw1-0001In-OG for bitcoindev@gnusha.org; Thu, 07 Aug 2025 17:26:15 -0700 Received: by mail-qt1-f183.google.com with SMTP id d75a77b69052e-4af22e50c00sf39428541cf.1 for ; Thu, 07 Aug 2025 17:26:13 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1754612767; cv=pass; d=google.com; s=arc-20240605; b=BDMXFG629YqFGRRW0Zj3jTngZlD4/PbKXjszRfNYcorSrPhWp5o5BmBDBNhwxuu1cA zS4dgacDjAo9hxzm75EQ5hW5cnElNvy+2k3Kn5OFajkDUi3eSjgnQwDMFsZWuBIh/5XU Ivk9KzKAgBsumlmFuycLip2b+1w6I4g+m8jQuB+VGe5LZ/E398AR7nDs9vCqmRsl+mt6 dxpPBQprF1pV71GiF1GT+Mt9fCJMKPOwDzqJuJRo12iw4LaCj46NIJB2GOZB1d6TIY0f B6u8snEQqS6KB76L8OfwctIWU4GEwX1NHmtE4OgNKkCk9UzJSujUDSUPdqraxfIvHXvX dcyg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version :content-language:accept-language:message-id:date:thread-index :thread-topic:subject:to:from:dkim-signature; bh=xiGSAEaJJwzPj+kUl2wAp7ZJbneYpEKtXPRi/W2mdNI=; fh=43SVIeCcvVEjLQawShzkA8C+03B9O4Cka0fIS+LWeWs=; b=UIVqBj7Q4EhNPnIg3FvkUbDoyOHSQ2bo51TjUZxb/qAnY+zNmsF57yIXk0FWV04MxM dDGJtJHEgXYd2b49GDBr5Jy1rGR6NOmvetEG89GpTZUlQoZxNhwde86Q0wtSfXTQZmX/ Pb2dU4PQv2ecU6C8v7ZiEcdBZf0cOoN2qx1F/SycBPMPl3epWfxi29A5xIdIcJpRcUlW T9uWluS5hdOZi65geRLHbKthXMxGPiCPKza2JooWhL5IR/wBz1mQ/07aNiUdGm641AMO 4JJlfCnL/82OW64wSLF/81D0ahzAJjV7QSFaPmYE6NAIA5fOXQHV972GDU/jvCPi4rpz P0EQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@googlemail.com header.s=20230601 header.b=mryXxWx0; spf=pass (google.com: domain of tagg.james@googlemail.com designates 2607:f8b0:4864:20::112e as permitted sender) smtp.mailfrom=tagg.james@googlemail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1754612767; x=1755217567; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :content-language:accept-language:message-id:date:thread-index :thread-topic:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=xiGSAEaJJwzPj+kUl2wAp7ZJbneYpEKtXPRi/W2mdNI=; b=ujm91lo0H8LQHeVs6NUe5bK3E/a2dkMhl9CG3GjDabA5lZJUM+gq2KaQNljUkAes4W tflv4h1YtJh24LQtM5Sk5NBjV6iY8d41cwuWzqOg9J+WFoCm6S7AvqAehONqmHijCStx KDbSTDwl2n5fN+3ocroQFUGFV2MK3v0f0aPrqPBsvFbSl4dIzCnFaijpHIYWJ6NkFRLo rb5GVK+KHtm4/tH3rZ9onaenNBKN8tmOMFXoH14CU81z+2g2wMpJm1MC6gyZVAzkATUZ x0D6f5o5eBIxRMSI4bPEAr0k19bj1Jk6dKP543tnSFZPkgdPh6/fcLH12hrRAjSTRYMn Wt1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754612767; x=1755217567; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :content-language:accept-language:message-id:date:thread-index :thread-topic:subject:to:from:x-beenthere:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=xiGSAEaJJwzPj+kUl2wAp7ZJbneYpEKtXPRi/W2mdNI=; b=DifexOPO7GYfghKWiqo3im5nQhFeAJmp2LU64KHmn3cSQS9qLM4QqfWSmZiRQQDcaU YlitEGv6eIheZTFG3q+RukdK7+Nry2wyOV6hwit0hzlJNcjfYmL1AtgnaFjRtCoGjjHp djtXd0fedt+qfdLU8Q7OzY8xipcAS3qaHvT7Ks5LUa6N9oT5rIau6pDkXjPzV5wf3XlL dfoUHbiufzDI/mhVK0CFDueQWygK8wOjNnQZOPP3z5ibjqWxHb3B5Pl4rsQyT+v1V62o U3TVnbCN43Vk39XT+4i++sKY/QYegYibVz6JNGnBgAJaOtjuU8Yx8vRzM9FTjD4XGixm 1k5g== X-Forwarded-Encrypted: i=2; AJvYcCV0TPHGwTf4/p1PishSTSHjKyF6mG8Y5G6u35zaV2ugpr+1AH2PNC3d0rpL/BfHFHAfyoCc0a4O9rly@gnusha.org X-Gm-Message-State: AOJu0YzEqNO9HTpHrR28TFjLBQUo2LYosFfg55/EATFl+lJmxTfI2h96 p2oiuj/Ko0OLLFG/fp6wbs/7nFvt6X81oj5CaoyhJNKMxAQ/LMTSy1qp X-Google-Smtp-Source: AGHT+IEBiYwvWDvzAUcTFZGF0BwEdM26injz4SJW4KtNmWiOsEPZngedAosb9xyADUpmiDiVI16Bpw== X-Received: by 2002:a05:622a:1a10:b0:4b0:6614:c9be with SMTP id d75a77b69052e-4b0aec6ef7fmr20239431cf.13.1754612766942; Thu, 07 Aug 2025 17:26:06 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZci1/mr7AZvRmVguPPfpPaf9urOTNTz002uaDVGXMnjdA== Received: by 2002:a05:622a:1116:b0:4a5:a87e:51cf with SMTP id d75a77b69052e-4b0a0698f7cls25218511cf.1.-pod-prod-07-us; Thu, 07 Aug 2025 17:26:01 -0700 (PDT) X-Received: by 2002:a05:620a:31a2:b0:7e8:2c22:8e01 with SMTP id af79cd13be357-7e82c72583bmr178618185a.36.1754612760981; Thu, 07 Aug 2025 17:26:00 -0700 (PDT) Received: by 2002:a05:6808:2384:b0:3f9:f009:458e with SMTP id 5614622812f47-433f0a4254bmsb6e; Mon, 4 Aug 2025 14:18:15 -0700 (PDT) X-Received: by 2002:a05:6e02:b:b0:3e2:aafc:a7f with SMTP id e9e14a558f8ab-3e416122d83mr230869845ab.7.1754342294690; Mon, 04 Aug 2025 14:18:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1754342294; cv=none; d=google.com; s=arc-20240605; b=lPjKCA+2gY2Kc1buUpkiACc+gScrqW1HG4Sx1QcH7wtzhLUXEFp96Ss571S55tnAB1 qaBTfZNjPmdSp5cbOOJnLg3a9UU/Dkr46lqEsqJgpe+IqKlqOVLoGOrWeYhED0Uko1GZ mtDtLEq5cXIf2sIpERrBuX4Pfy0U+2TdkkSxgr8AtoxqEd1qMv0C0rS6UL/OK+ld7IIn EZyrNjD3xLLcInTLFBAwvHJDq9xpfkG+sWqlV6eboxcyyl9heNfOZJGgjqKu9omuGIwd RKuFd+3vG6ixxKHFzW7xbqYco9ItiBrQp3MYnFR5qOw38IY0fBGYoYUvKYpSWGDyszPG 61rQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:content-language:accept-language:message-id:date :thread-index:thread-topic:subject:to:from:dkim-signature; bh=cLmmyDGSr8x5q1s22iijicxsj9nJMUi+vLrW3wAHbW8=; fh=lhFSo2W/mHC0QoJ9oNg3A35n0DTltt3CQl1/0RggJlk=; b=FxFRqVpcFgOwmxcqQWqGx4yigcJDXmDlMYUePiJO3qRtpAb49kE245PGDYPpyAwXxa lzjJ/uroSMT7z9ZZJgi85DiGxeVguwnXewO2TZj7F4J2jpXMjgPYgOLZ33hYQ/n2I8O7 eyLo9cJqq5hXR7Jw6C9vDoQPG9I6+3AwJHApHe0Oa0gXIeQjoFDJTTRgtZpHysBs70UV NzLktGJ0OTrSLAmvzoGe8+i75tTHJAyEBxD9sKcLwIIbYAyxjX4/+nAWLNP7/cKigIxK UVvVSp8x12dwjGDgC6lncCZeG/646NynxYr1raLhdfjqDosqy+bP/8ThN2ks4zOznw9t fIpA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@googlemail.com header.s=20230601 header.b=mryXxWx0; spf=pass (google.com: domain of tagg.james@googlemail.com designates 2607:f8b0:4864:20::112e as permitted sender) smtp.mailfrom=tagg.james@googlemail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com; dara=pass header.i=@googlegroups.com Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com. [2607:f8b0:4864:20::112e]) by gmr-mx.google.com with ESMTPS id 8926c6da1cb9f-50a55d5de5fsi427829173.2.2025.08.04.14.18.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Aug 2025 14:18:14 -0700 (PDT) Received-SPF: pass (google.com: domain of tagg.james@googlemail.com designates 2607:f8b0:4864:20::112e as permitted sender) client-ip=2607:f8b0:4864:20::112e; Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-71a38e35674so21410437b3.3 for ; Mon, 04 Aug 2025 14:18:14 -0700 (PDT) X-Gm-Gg: ASbGnctw+LTH6MDyoFCOIYHTTz8ptxSWVxvDpDezzHv0oGOmQr5g2IEn+fQwBhuFNwE gcIOh1AYb3K45Am1v4sXT5J6SQA18biQkHlpdN0quYC6sK1MEAM1mgOPXFdD/XG1vfTaZHs82Wl 1wNgpSCXjCUFs3jkhFqtXXBvevD7n9E6plX6pE7CaJRSJ33ylqsi5F0dFXcJJmhVVeIaP1ed1lA 25L4iO5NssMKYK4BYtADyzJqbPj3pyqq/PpLDj3yto7C19VEMOmabZq36s2H7hz/CGbdLSc7N6X wTD1xZxHU00h3e90JpIyHm7cQH5dhhvi6HnXuWq2BaheV1MGgP4xr5hgOsnCXaR52r86t0Cfi3v 3QEV6sfL5wHZLNYOsDdP1upuM8h9Xh42B4ekaApCWVNNSHUwspNxutYxRfDchTa+VEPhZtLeepn d4zwKc882YbKWV X-Received: by 2002:a05:690c:60c1:b0:71a:2093:3558 with SMTP id 00721157ae682-71b7ed843e9mr120129017b3.10.1754342293090; Mon, 04 Aug 2025 14:18:13 -0700 (PDT) Received: from SN6PR12MB2735.namprd12.prod.outlook.com ([2603:1036:805:67::5]) by smtp.gmail.com with ESMTPSA id 00721157ae682-71ba7634498sm6656107b3.58.2025.08.04.14.18.12 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Aug 2025 14:18:12 -0700 (PDT) From: "'James T' via Bitcoin Development Mailing List" To: "bitcoindev@googlegroups.com" Subject: [bitcoindev] [BIP Proposal] No burn, Quantum Migration Proposal, Quantum Secure Asset Verification & Escrow (QSAVE) Thread-Topic: [BIP Proposal] No burn, Quantum Migration Proposal, Quantum Secure Asset Verification & Escrow (QSAVE) Thread-Index: AQHcBYHg9BbpV953UUWZgCs2oc6A9w== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Mon, 4 Aug 2025 21:18:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 x-ms-reactions: allow Content-Type: multipart/alternative; boundary="_000_SN6PR12MB2735280A252DD62231D1320AA523ASN6PR12MB2735namp_" MIME-Version: 1.0 X-Original-Sender: tagg.james@googlemail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@googlemail.com header.s=20230601 header.b=mryXxWx0; spf=pass (google.com: domain of tagg.james@googlemail.com designates 2607:f8b0:4864:20::112e as permitted sender) smtp.mailfrom=tagg.james@googlemail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com; dara=pass header.i=@googlegroups.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 (+) --_000_SN6PR12MB2735280A252DD62231D1320AA523ASN6PR12MB2735namp_ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 leg= itimately move funds to safe addresses for protective custody and public go= od. It could even go forward with no consensuses at all since it is functio= nally 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 no= n-sovereign wealth fund providing protective custody for Bitcoin vulnerable= to quantum attack (see Appendix for detailed vulnerability assessment). QS= AVE preserves 100% of the principal for rightful owners while using generat= ed returns to fund the protocol and global public good. It provides an alte= rnative to the QRAMP (Quantum Resistant Asset Migration Protocol) proposal = (which makes coins unspendable) or taking no action (which allows quantum a= ppropriation, which many view as theft). This proposal addresses coins that= are dormant but acknowledges there may be coins that have quantum watermar= ks 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 supp= ly) have exposed public keys vulnerable to quantum attack (see Appendix: Qu= antum 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 implementin= g best practices such as always sending change to fresh addresses. However,= some portion will inevitably remain unprotected when quantum computers arr= ive 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 rema= ining vulnerable coins face two equally problematic outcomes: 1. Quantum appropriation: First actors with quantum computers take the coin= s 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 ow= nership rights and puts dormant capital to work for humanity. Note on "Theft": Bitcoin's protocol operates purely through cryptographic p= roofs, without built-in concepts of ownership or theft=E2=80=94these are le= gal constructs that vary by jurisdiction. The community holds divergent vie= ws: some consider using advanced technology to derive private keys as legit= imate within Bitcoin's rules, while others view it as unethical appropriati= on of others' funds. QSAVE addresses both perspectives: If quantum key derivation is considered = fair game, then racing to secure vulnerable coins before malicious actors i= s 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 preserve= s 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 col= d storage as inheritance for her grandchildren, with keys secured in a safe= deposit box. She doesn't follow Bitcoin news and remains unaware of quantu= m threats. She passes away and by the time her heirs discover the wallet, q= uantum 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 e= vidence (will, keys, proof of box opening) This illustrates why we cannot assume dormant equals lost and why protectiv= e custody is the only approach that preserves legitimate ownership rights. = The inability to distinguish between lost coins and stored coins is the fun= damental 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 generat= ed 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-bas= ed migration | Hard fork implementation | | Q-Day (Quantum Day) | When quantum computers arrive | White-hat rec= overy race | No protocol changes needed | | Emergency Cut-over | Catastrophic quantum break | Parallel chai= n migration | Rapid consensus response | | Overlapping M/Q-Day | Both processes active | Concurrent mi= grations | 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 informati= on 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 Tim= ing Matrix above): No Action: PQP (Post Quantum Pay) wallet technology - purely commercial/use= r layer Consensus: Community endorsement strengthens legal position for white-hat r= ecovery 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 avai= lable databases of all exposed private keys (similar to existing databases = of classically compromised keys), possession of the private key alone is in= sufficient. 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 e= valuate ownership claims with staking and slashing to prevent fraud and par= tial time based awards in case of partial proof. Evidence strength: - Tier 1: Cryptographic proofs with verifiable pre-break timestamps (signat= ures in pre-quantum blocks and similar immutable records) - Tier 2: Third-party records (exchange logs, bankruptcy filings, probate r= ulings, trustee statements) - Tier 3: Supporting materials (affidavits, chain-of-inheritance, media cov= erage, witness declarations) Governance Structure The QSAVE fund requires robust decentralized governance to ensure proper st= ewardship of recovered assets. The governance framework must balance effici= ency with decentralization while maintaining absolute commitment to princip= al preservation. Core Governance Principles: - Quadratic Voting: Reduces influence of large stakeholders while maintaini= ng democratic participation - Multi-Council Structure: Separates technical, allocation, and audit funct= ions 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 addr= essing quantum vulnerability. Unlike binary approaches (burn or allow appro= priation), QSAVE introduces a third path that aligns with Bitcoin's core pr= inciples 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 ET= F 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 respon= se - 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 cont= inuity Legal Framework Considerations The recovery process aligns with established legal principles in many juris= dictions. Under precedents like People v. Jennings (NY 1986), temporary cus= tody without intent to permanently deprive does not constitute larceny. Thi= s is analogous to moving lost property to a lost & found =E2=80=94 a univer= sally accepted practice despite technically involving "taking without permi= ssion." In the United States alone, over 400 million items are moved to lost & foun= d departments annually without legal consequence. QSAVE applies this same p= rinciple to digital assets vulnerable to quantum attack, providing a protec= tive 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 t= o 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 disadvant= age. Bad actors operating from jurisdictions with weak or non-existent cryp= tocurrency regulations can exploit quantum vulnerabilities with impunity, w= hile good-faith actors in law-compliant states remain paralyzed by legal un= certainty. This creates a systematic wealth transfer from citizens of law-a= biding nations to criminal organizations and rogue states. The strongest pr= operty laws paradoxically create the weakest defense against quantum theft.= Jurisdictions are developing good faith exemptions to their computer secur= ity 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 Vulnerabl= e | 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 =3D 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 t= han 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 t= heoretically be broken by a quantum computer with 1 million noisy qubits ru= nning 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 bein= g 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-Quantu= m 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", S= eptember 7, 2022. https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FA= Q_.PDF 3. Google Quantum AI - "Quantum Advantage in Error Correction", Nature, 202= 5. Demonstrated 99.85% reduction in required quantum resources. 4. Jensen Huang - "Nvidia CEO says quantum computing is at an inflection po= int", Channel News Asia, June 11, 2025. https://www.channelnewsasia.com/business/nvidia-ceo-says-quantum-computi= ng-inflection-point-5174861 5. Global Risk Institute - "Quantum Threat Timeline 2025: Executive Perspec= tives 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=3DDhYO1Jxmano 7. Satoshi Nakamoto - BitcoinTalk Forum post, 2010. "If it happens graduall= y, we can transition to something stronger." https://bitcointalk.org/index.php?topic=3D3120.0 8. FIPS 204 - "Module-Lattice-Based Digital Signature Standard", August 202= 4. 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 comp= uting risk to Bitcoin holdings, 2024. 11. Mosca, M. - "Quantum Threat Timeline," University of Waterloo, 2023. Estimates 2035-2040 timeline for quantum threats to cryptography. --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= SN6PR12MB2735280A252DD62231D1320AA523A%40SN6PR12MB2735.namprd12.prod.outloo= k.com. --_000_SN6PR12MB2735280A252DD62231D1320AA523ASN6PR12MB2735namp_ Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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=

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

Author: James Tagg =

Status: Draft<= /o:p>

Type: Standards Tra= ck

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

Created:=

License:

 

Abstract=

 

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

 

Motivation

 

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

 

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

 

- Owners who don't = follow Bitcoin news

- Forgotten wallets= discovered years later

- Cold storage assu= med long term safe

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

- Users who procras= tinate or underestimate the threat

 

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

 

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

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

 

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

 

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

 

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

 

The Inheritance Vul= nerability Window

 

Consider the "= 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 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 &nb= sp;            =     | Timing        =             &nb= sp;   | Method        &nb= sp;           | Requireme= nts            =    |

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

| M-Day (Migration = Day)     | Pre-Q-Day with Hard Fork   &n= bsp;  | Consensus-based migration | Hard fork implementation &nbs= p; |

| Q-Day (Quantum Da= y)       | When quantum computers arrive | Wh= ite-hat recovery race   | No protocol changes needed |=

| Emergency Cut-ove= r        | Catastrophic quantum break&nb= sp;   | Parallel chain migration  | Rapid consensus response=    |

| Overlapping M/Q-D= ay       | Both processes active  &= nbsp;      | Concurrent migrations  &nbs= p;  | Mempool competition        |<= o:p>

 

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

 

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

 

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

 

Consensus: Communit= y endorsement strengthens legal position for white-hat recovery<= /span>

 

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

 

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

 

Implementation Time= line

 

Phase 0: Launch - L= ive from Day One

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

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

 

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

- Community discuss= ion and refinement (while QD3 registrations continue)

- 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)<= o:p>

 

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 = intent to recover specific UTXOs

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

  - Publish re= covery 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

 

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

|   =        Recovered Bitcoin   &nb= sp;          |

|   =    (Principal - 100% Preserved)     &nbs= p; |

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

   &= nbsp;           &nbs= p; |

   &= nbsp;           &nbs= p; v

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

|   =      Conservative Strategies    &nb= sp;     |

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

|   =   * Lightning Network Liquidity       |<= o:p>

|   =   * DeFi Lending Protocols       &n= bsp;    |

|   =   * Bitcoin-backed Stablecoins      &nbs= p; |

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

   &= nbsp;           &nbs= p; |

   &= nbsp;           &nbs= p; v

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

|   =       Interest Distribution    = ;       |

|   =       (Public Good Only)    &n= bsp;         |

|   =   * Open Source Development       &= nbsp;   |

|   =   * Quantum Security Research       = ;  |

|   =   * Global Infrastructure       &nb= sp;     |

|   =   * AI Safety & 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:

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:

   - gove= rnment-issued identification

   - Hist= orical transaction knowledge

   - Temp= oral pattern matching

   - Soci= al recovery 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:<= o:p>

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

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

 

Safeguards:

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

- 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

 

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.<= o:p>

 

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

 

Legal clarification= and Jurisdiction choices need to be made.

 

The Sovereign Law P= aradox

 

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

 

Economic Impact

 

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

- 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 &nb= sp;            | Add= ress Type     | Key Status | Quantum Vulnerable | Est. = BTC (M) | Recovery Priority | Notes      &nbs= p;            &= nbsp;          |

|------------------= -----|------------------|------------|--------------------|--------------|-= ------------------|------------------------------------|<= /p>

| P2PK Outputs = ;         | P2PK   &= nbsp;         | Various  =   | Yes          &nb= sp;     | 1.9-2.0      | Criti= cal          | Directly expose= d public keys       |

| Taproot (All)&nbs= p;        | P2TR    =          | Various   = ; | Yes           &n= bsp;    | 0.5-1        | = Critical          | ALL Taproo= t addresses exposed      |

| Reused P2PKH (spe= nt)  | P2PKH         &nbs= p;  | Various    | Yes     &nb= sp;          | 2-4  =         | High    &n= bsp;         | Spent =3D pubkey rev= ealed            |

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

| Unused P2PKH = ;         | P2PKH   =          | Various   = ; | No           &nb= sp;     | 6-8       =    | Protected         | = Hash only; quantum-safe        &nbs= p;   |

| Unused P2WPKH&nbs= p;        | P2WPKH   &nbs= p;       | Various    | No&nbs= p;            &= nbsp;   | 4-6        &nbs= p; | Protected         | Modern saf= e until spent          &n= bsp; |

| Script Hash =           | P2SH/P2WSH &n= bsp;     | Various    | Mostly No &= nbsp;        | 3-4   &nbs= p;      | Protected     &= nbsp;   | Generally safe (depends on script) |<= /p>

| Total Vulnerable&= nbsp;     |       &n= bsp;          |  &nb= sp;         | Yes   =              | = 3.5-5.5M     |       = ;            | 17-28= % of supply          &nbs= p;        |

 

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

 

Recent Technical Ad= vances:

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

- Jensen Huang (NVI= DIA CEO): Shifted to optimistic stance, stating quantum computing is "= reaching an inflection point" and we're "within reach of being ab= le 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.

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

   Specif= ies 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 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.<= /span>

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

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.goo= gle.com/d/msgid/bitcoindev/SN6PR12MB2735280A252DD62231D1320AA523A%40SN6PR12= MB2735.namprd12.prod.outlook.com.
--_000_SN6PR12MB2735280A252DD62231D1320AA523ASN6PR12MB2735namp_--