From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 08 Aug 2025 19:06:18 -0700 Received: from mail-ot1-f60.google.com ([209.85.210.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ukYyP-0005jb-1U for bitcoindev@gnusha.org; Fri, 08 Aug 2025 19:06:18 -0700 Received: by mail-ot1-f60.google.com with SMTP id 46e09a7af769-7414c004848sf4949535a34.0 for ; Fri, 08 Aug 2025 19:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1754705170; x=1755309970; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=Fe8lGf5CuRDe/a9TsPeJz0zhkdlYz1EB2vKE5oW3JI8=; b=gTOfqi488iOZusFTmAXoTrdMYTagF1M1QEaCLW+haIqlk1d4XDkxpV+ZdYaHt9Ib10 mdAoiEskpyyvYnzoMuErGBxmuFvIPlLOJOMVKRFpK92bdmN8UjQt6Gl0tEefUd7ESRFp LyfJR/E63iT7xLrn1rQhCu3YHFENXzai+3urbELISRbtQ8rMlJm9w1W1ZWU9yO1ALY2B RK7SZD9IsALEW8VQ97HFWm+2q0PtZxUkcXbB1Ps3UsfpUU4AVDVo5fcoGNZ3nqOCu7iw Nfk3AJHdfphIo2jQ4Oi3G1dIkq3lnh1jyg6wzWPSL/6ocZqSdb3VJjADkOKksbStOk3l vGYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754705170; x=1755309970; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Fe8lGf5CuRDe/a9TsPeJz0zhkdlYz1EB2vKE5oW3JI8=; b=bvO26eamXdXV7I31vWnX8Mlvs+cTyx6mIsLWa8zj3kPi1hRHitAMKD8vU96QuJ0CJm TbQ15rCKXiiEovYfKjkp3SfFrlmvzpr57pKvdMM72lVyO7zSdXCse55sljI0T90HRh5P R589M50unXzwJlW0vQycR+GCFl8CRa+6T2kXsB5PV22S3n9SwRWJyHMFGc9dDNj1BV9w JyqPisBQ7A4rFfSAAMP+LAyNSxxoESfU2H/jyG9Gq6UK02jDP8Er753pMlG3BDr59ZVl MgS3XxcdzBtvky5YwjCJffo2NfJgz/RiCM9oYEuQLlPenAvv6EPDYRAZWwEeu9n054XX UwpA== X-Forwarded-Encrypted: i=1; AJvYcCWWqOUwv4CxqFe3VfNKQ4uRLQEGOpTQBLxtwrNify25KqX/9HCv73OliOgSVOuy8ktVvj68mPgJTG3l@gnusha.org X-Gm-Message-State: AOJu0Yz0uZFNNNR7RPHM+K+NmB7rtkaz+wGG4aTfsHx89sUZGDhJ/FcO t/WX9OSKfn2KMHip6E5kqUzIIaEIg5GD06zR8wIYBRdGbCb8PgM+aKW/ X-Google-Smtp-Source: AGHT+IET7MZ6jvMJEhTbRnvtGrTJJpBtGyB6qbcRP2RRkeyh3K09ZTndlVl052EYrR7gZidBMBYRMQ== X-Received: by 2002:a05:6830:19f3:b0:741:c2be:c6f6 with SMTP id 46e09a7af769-7432c91d051mr2405368a34.22.1754705170505; Fri, 08 Aug 2025 19:06:10 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdYNemaby5T/zvLJy3vdI5iXfPiMJaFP8/vmBT7F5+pSw== Received: by 2002:a05:6870:7057:b0:30b:85bc:4baf with SMTP id 586e51a60fabf-30bfe40e974ls839689fac.0.-pod-prod-07-us; Fri, 08 Aug 2025 19:06:06 -0700 (PDT) X-Received: by 2002:a05:6808:1b0e:b0:41b:f2a0:28f7 with SMTP id 5614622812f47-43597ebad34mr3025102b6e.36.1754705166558; Fri, 08 Aug 2025 19:06:06 -0700 (PDT) Received: by 2002:a05:690c:2605:b0:718:5fd:a4e7 with SMTP id 00721157ae682-71bf1a7df88ms7b3; Fri, 8 Aug 2025 18:04:28 -0700 (PDT) X-Received: by 2002:a05:690c:3684:b0:71b:f83a:afa0 with SMTP id 00721157ae682-71bf83ab218mr48871147b3.22.1754701467488; Fri, 08 Aug 2025 18:04:27 -0700 (PDT) Date: Fri, 8 Aug 2025 18:04:27 -0700 (PDT) From: "'conduition' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <4d6ecde7-e959-4e6c-a0aa-867af8577151n@googlegroups.com> References: <4d6ecde7-e959-4e6c-a0aa-867af8577151n@googlegroups.com> Subject: [bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_113900_1567383867.1754701467032" X-Original-Sender: conduition@proton.me X-Original-From: conduition Reply-To: conduition 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.0 (-) ------=_Part_113900_1567383867.1754701467032 Content-Type: multipart/alternative; boundary="----=_Part_113901_1324720015.1754701467032" ------=_Part_113901_1324720015.1754701467032 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I appreciate your enthusiasm for quantum resilience, but there are many=20 things wrong with this proposal.=20 - *"50 logical qubits - sufficient to break 256-bit ECDSA"* - The number of= =20 logical qubits required to break 256-bit ECC discrete log is on the order= =20 of thousands or millions, and nobody is even close yet. AFAIK the best=20 known algorithm requires about 1536 qubits [0]. Please cite sources if you= =20 have been informed otherwise. - *"0-bit security"* ROFL, what does that even mean? Also you have the=20 wrong big-O complexity for Shor's algorithm [1] - The 256-bit flavors of SLH-DSA are overkill. Bitcoin addresses are=20 already fundamentally limited to 128 bits of security (a little less,=20 actually) under a naive SHA256 or secp256k1 birthday attack. [2] Trying to= =20 add more is unnecessary, especially given the YUGE signatures required. - This proposal completely ignores other promising new cryptographic=20 signing algorithms like ML-DSA [3] and SQISign [4] which would be needed=20 for low-latency resource-constrained environments like LN nodes. - Freezing UTXOs without some sort of unlocking path baked-in ahead of time= =20 will cause a hard fork if we ever want to rescue them in the future. This= =20 has been discussed on prior threads. [8] - *"Each signature reveals 4 bits of private key material"*, that is not=20 how SLH-DSA works. Each signature reveals some deterministically derived=20 preimages, and commits to them in a carefully chosen chain of OTS=20 certification signatures. The algorithm guarantees the probability of=20 successful forgery stays below a certain threshold for up to `m` messages.= =20 In NIST SLH-DSA, m =3D 2^64. For the math see this script [5]. - Your "SPHINCS+ implementation" is just a wrapper around the python=20 'pyspx' package from PyPi with some encoding mechanisms sprinkled on top.= =20 The `pyspx` module was last updated three years ago [6] and SLH-DSA was=20 only fully standardized two years ago, so your code is actually=20 non-compliant with your own proposal. - *"This BIP draft prioritizes technical accuracy over visual polish"*. I= =20 think i'll stop now. If you're interested in meaningfully contributing to upgrading Bitcoin to= =20 be quantum resilient, I would suggest you stop trying to write your own=20 spec single-handed, and start by reviewing BIP360 [7] and reading mailing= =20 list archives on post quantum upgrade proposals. There have been many... regards, conduition [0]: https://arxiv.org/pdf/quant-ph/0301141 (see section 6.2) [1]: https://en.wikipedia.org/wiki/Shor%27s_algorithm [2]: https://bitcoin.stackexchange.com/questions/118928/what-does-it-mean-t= hat-the-security-of-bitcoin-public-keys-and-256-bit-ecdsa-is/ [3]: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf [4]: https://sqisign.org/ [5]: https://gist.github.com/conduition/469725009397c08a2d40fb87c8ca7baa [6]: https://pypi.org/project/PySPX/#history [7]: https://github.com/bitcoin/bips/pull/1670 [8]: https://groups.google.com/g/bitcoindev/c/uEaf4bj07rE/m/0Facb-SvBwAJ On Thursday, August 7, 2025 at 5:26:07=E2=80=AFPM UTC-7 Bitcoin Foundation = wrote: > BIP: TBD > Layer: Consensus (soft fork) > Title: Quantum-Resistant Transition Framework for Bitcoin=20 > Author: Bitcoin Post-Quantum Working Group > Status: Draft=20 > Type: Standards Track=20 > Created: 2025-08-07 > License: MIT > Requires: BIP-340, BIP-341 > > =3D=3D ABSTRACT =3D=3D > This proposal defines a backward-compatible, time-bound migration path to= =20 > quantum-resistant (QR) cryptography for Bitcoin. Through phased deprecati= on=20 > of ECDSA/Schnorr signatures and mandatory adoption of NIST-standardized= =20 > post-quantum algorithms, it ensures Bitcoin's survival against quantum=20 > attacks while minimizing disruption to existing infrastructure. > > =3D=3D MOTIVATION =3D=3D > *Quantum Threat Assessment* > - PUBLIC KEY EXPOSURE: 25% of Bitcoin's UTXO set (~$150B as of 2025) is= =20 > vulnerable to Shor's algorithm due to exposed public keys (P2PK, reused= =20 > addresses) > - ALGORITHMIC ACCELERATION: Google's 2024 trapped-ion breakthrough=20 > demonstrated 99.99% gate fidelity with 50 logical qubits - sufficient to= =20 > break 256-bit ECDSA in <8 hours > - STEALTH ATTACK VECTORS: Quantum adversaries could precompute keys and= =20 > execute timed thefts during mempool propagation > > *Fundamental ECDSA Vulnerability* > ECDSA security relies on the Elliptic Curve Discrete Logarithm Problem=20 > (ECDLP). Shor's quantum algorithm solves it in O((log n)=C2=B3) time: > 1. For secp256k1: n =E2=89=88 2=C2=B2=E2=81=B5=E2=81=B6 > 2. Classical security: 128-bit > 3. Quantum security: 0-bit (broken by Shor) > 4. Critical exposure: Any public key revealed becomes immediately=20 > vulnerable > > *Consequences of Inaction* > - WEALTH DESTRUCTION: Single theft event could permanently erode trust > - COORDINATION TRAP: Delayed action risks chaotic emergency hard forks > - SYSTEMIC COLLAPSE: Quantum break would invalidate Bitcoin's security=20 > model > > =3D=3D SPECIFICATION =3D=3D > *Phase 1: QR Adoption (0-2 years)* > - Soft-fork activation of QR witness programs (SegWit v3+) > - New outputs must use OP_CHECKSIG_PQ > - Classical scripts marked as deprecated > > *Phase 2: Legacy Deprecation (5 years)* > - Creating new classical UTXOs becomes non-standard > - Wallets default to QR outputs with warnings for classical sends > - Economic incentive: QR transactions get priority mempool treatment > > *Phase 3: Classical Sunset (Block 1,327,121 ~8 years)* > - Consensus-enforced rejection of classical script spends > - Frozen UTXOs permanently unspendable (supply reduction) > - Emergency override: 95% miner vote can delay by 52-week increments > > *Phase 4: Recovery Mechanism (Optional)* > - ZK-proof system for reclaiming frozen funds via: > =E2=80=A2 Proof of BIP-39 seed knowledge > =E2=80=A2 Time-locked quantum-resistant scripts > - Requires separate BIP after 3+ years cryptanalysis > > =3D=3D RATIONALE =3D=3D > *Why Phased Approach?* > - MARKET CERTAINTY: Fixed timeline eliminates "wait-and-see" stagnation > - PROGRESSIVE PRESSURE: Gradual restrictions avoid shock transitions > - SUNK COST PRINCIPLE: Users ignoring 3+ years of warnings assume=20 > responsibility > > *Why Freeze Legacy UTXOs?* > - Prevents quantum arms race for exposed coins > - Preserves Bitcoin's "lost coins" scarcity principle > - Avoids centralized redistribution committees > - Eliminates moral hazard of rewarding late migrators > - Reduces quantum attack surface > > *Algorithm Choice: SPHINCS+-SHAKE256f (SLH-DSA-SHAKE-256f)* > SECURITY PARAMETERS: > n: 256 > Hash: SHAKE256 > Classical Security: 2=C2=B2=E2=81=B5=E2=81=B6 > Quantum Security: 2=C2=B9=C2=B2=E2=81=B8 > Private Key: 128 bytes > Public Key: 64 bytes > Signature: 49,856 bytes > > QUANTUM ATTACK RESISTANCE: > | Attack Type | Standard Bitcoin | This System | Security Facto= r=20 > | > > |---------------------|------------------|---------------|---------------= --| > | Shor's Algorithm | Broken | Not applicable| =E2=88=9E = =20 > | > | Grover's Algorithm | O(2=C2=B9=C2=B2=E2=81=B8) | O(2=E2=81=B5= =C2=B9=C2=B2) | 2=C2=B3=E2=81=B8=E2=81=B4 advantage | > | Collision Search | O(2=E2=81=B8=E2=81=B5) | O(2=E2=81=B8=E2= =81=B5) | Equivalent | > > KEY SECURITY (SK 128 bytes): > - Private key entropy: 1024 bits (2=C2=B9=E2=81=B0=C2=B2=E2=81=B4 possibi= lities) > - Quantum brute-force: =E2=88=9A(2=C2=B9=E2=81=B0=C2=B2=E2=81=B4) =3D 2= =E2=81=B5=C2=B9=C2=B2 =E2=89=88 10=C2=B9=E2=81=B5=E2=81=B4 operations > - Time required at 1 quintillion ops/sec (10=C2=B9=E2=81=B8): 10=C2=B9=C2= =B3=E2=81=B6 seconds =E2=89=88 3 =C3=97 10=C2=B9=C2=B2=E2=81=B8=20 > years > > SEED SECURITY (SEED 96 bytes): > - Possible seeds: 2=E2=81=B7=E2=81=B6=E2=81=B8 =E2=89=88 10=C2=B2=C2=B3= =C2=B9 =20 > - Quantum brute-force: =E2=88=9A(2=E2=81=B7=E2=81=B6=E2=81=B8) =3D 2=C2= =B3=E2=81=B8=E2=81=B4 =E2=89=88 10=C2=B9=C2=B9=E2=81=B5 operations =20 > - Time required at 1 billion ops/sec: 10=C2=B9=E2=81=B0=E2=81=B6 seconds = =E2=89=88 3 =C3=97 10=E2=81=B9=E2=81=B8 years > > INFORMATION THEORETIC ADVANTAGES: > - Each signature reveals 4 bits of private key material > - After 20 signatures: > =E2=80=A2 ECDSA: Private key fully compromised > =E2=80=A2 SPHINCS+: 80 bits revealed (7.81% of key) > =E2=80=A2 Security margin remains: 944 bits (92.19%) > > =3D=3D BACKWARD COMPATIBILITY =3D=3D > Phase | Legacy Wallets | QR Wallets > ------|---------------------|------------------------ > 1 | Full functionality | Can receive/send both types > 2 | Can only send to QR | Full functionality > 3+ | Frozen funds | Only QR transactions valid > > =3D=3D DEPLOYMENT =3D=3D > Activation Mechanism: > - Speedy Trial (BIP-8) with 18-month timeout > - 90% miner signaling threshold > > Monitoring: > - QR adoption metrics published quarterly > - Sunset delay requires proof of: > =E2=80=A2 <70% exchange/wallet adoption > =E2=80=A2 Fundamental flaws in NIST PQC standards > > =3D=3D STAKEHOLDER IMPACT =3D=3D > Group | Action Required | Timeline > ----------------|-------------------------------|------------------- > Miners | Upgrade nodes for QR rules | Phase 1 activation > Exchanges | Implement QR withdrawals | Within 18 months of Phas= e=20 > 1 > Hardware Wallets| Firmware updates for QR sigs | Before Phase 2 > Light Clients | SPV proofs for QR scripts | Phase 3 readiness > > =3D=3D REFERENCES =3D=3D > - SPHINCS+ Implementation:=20 > https://github.com/bitcoin-foundation/Quantum-Resistant-Bitcoin > - (FIPS 205) SLH-DSA:=20 > https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf > - Schnorr Signatures: BIP-0340 > > =3D=3D COPYRIGHT =3D=3D > MIT License > > --- > > > This BIP presents an alternative quantum-resistant migration approach,=20 > primarily distinguished by its extended transition timeline to facilitate= =20 > more comprehensive ecosystem adaptation. > > Key features: > - Includes reference implementation of SPHINCS+-SHAKE256f=20 > (SLH-DSA-SHAKE-256f) > - Provides comparative analysis against Bitcoin's current ECDSA scheme > - Detailed technical specifications: > https://github.com/bitcoin-foundation/Quantum-Resistant-Bitcoin > > Formatting note: This BIP draft prioritizes technical accuracy over visua= l=20 > polish. After incorporating feedback from this discussion, the final=20 > version will be published to GitHub with proper Markdown formatting. > > Feedback welcome from wallet developers, exchanges, miners, and security= =20 > researchers. > --=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/= fff86606-d6ce-4319-a341-90e9c4eba49dn%40googlegroups.com. ------=_Part_113901_1324720015.1754701467032 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I appreciate your enthusiasm for quantum resilience, but there are many thi= ngs wrong with this proposal.=C2=A0


=
- "50 logical qubits - sufficient to break 256-bit ECDSA" - The= number of logical qubits required to break 256-bit ECC discrete log is on = the order of thousands or millions, and nobody is even close yet. AFAIK the= best known algorithm requires about 1536 qubits [0]. Please cite sources i= f you have been informed otherwise.
- "0-bit security" ROF= L, what does that even mean? Also you have the wrong big-O complexity for S= hor's algorithm [1]
- The 256-bit flavors of SLH-DSA are overkill= . Bitcoin addresses are already fundamentally limited to 128 bits of securi= ty (a little less, actually) under a naive SHA256 or secp256k1 birthday att= ack. [2] Trying to add more is unnecessary, especially given the YUGE signa= tures required.
- This proposal completely ignores other promisin= g new cryptographic signing algorithms like ML-DSA [3] and SQISign [4] whic= h would be needed for low-latency resource-constrained environments like LN= nodes.
- Freezing UTXOs without some sort of unlocking path bake= d-in ahead of time will cause a hard fork if we ever want to rescue them in= the future. This has been discussed on prior threads. [8]
- "= Each signature reveals 4 bits of private key material", that is not how= SLH-DSA works. Each signature reveals some deterministically derived preim= ages, and commits to them in a carefully chosen chain of OTS certification = signatures. The algorithm guarantees the probability of successful forgery = stays below a certain threshold for up to `m` messages. In NIST SLH-DSA, m = =3D 2^64. For the math see this script [5].
- Your "SPHINCS+ impl= ementation" is just a wrapper around the python 'pyspx' package from PyPi w= ith some encoding mechanisms sprinkled on top. The `pyspx` module was last = updated three years ago [6] and SLH-DSA was only fully standardized two yea= rs ago, so your code is actually non-compliant with your own proposal.
- "This BIP draft prioritizes technical accuracy over visual polis= h". I think i'll stop now.

If you're interes= ted in meaningfully contributing to upgrading Bitcoin to be quantum resilie= nt, I would suggest you stop trying to write your own spec single-handed, a= nd start by reviewing BIP360 [7] and reading mailing list archives on post = quantum upgrade proposals. There have been many...

regards,
conduition


[0]:=C2=A0https://arxiv.org/pdf/quant-ph/0301141 (see section 6.2)<= div>[1]:=C2=A0https://en.wikipedia.org/wiki/Shor%27s_algorithm
[2= ]:=C2=A0https://bitcoin.stackexchange.com/questions/118928/what-does-it-mea= n-that-the-security-of-bitcoin-public-keys-and-256-bit-ecdsa-is/
= [3]:=C2=A0https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf
[4]:=C2=A0https://sqisign.org/
[5]:=C2=A0https://gist.github.co= m/conduition/469725009397c08a2d40fb87c8ca7baa
[6]:=C2=A0https://p= ypi.org/project/PySPX/#history
[7]:=C2=A0https://github.com/bitco= in/bips/pull/1670
[8]:=C2=A0https://groups.google.com/g/bitcoinde= v/c/uEaf4bj07rE/m/0Facb-SvBwAJ


On Thursday, A= ugust 7, 2025 at 5:26:07=E2=80=AFPM UTC-7 Bitcoin Foundation wrote:
BIP: TBD
Layer: C= onsensus (soft fork)
Title: Quantum-Resistant Transition Framework for B= itcoin
Author: Bitcoin Post-Quantum Working Group <pq-re...@bitcoin.= foundation>
Status: Draft
Type: Standards Track
Created: 2025= -08-07
License: MIT
Requires: BIP-340, BIP-341

=3D=3D ABSTRACT= =3D=3D
This proposal defines a backward-compatible, time-bound migratio= n path to quantum-resistant (QR) cryptography for Bitcoin. Through phased d= eprecation of ECDSA/Schnorr signatures and mandatory adoption of NIST-stand= ardized post-quantum algorithms, it ensures Bitcoin's survival against = quantum attacks while minimizing disruption to existing infrastructure.
=
=3D=3D MOTIVATION =3D=3D
*Quantum Threat Assessment*
- PUBLIC KEY= EXPOSURE: 25% of Bitcoin's UTXO set (~$150B as of 2025) is vulnerable = to Shor's algorithm due to exposed public keys (P2PK, reused addresses)=
- ALGORITHMIC ACCELERATION: Google's 2024 trapped-ion breakthrough = demonstrated 99.99% gate fidelity with 50 logical qubits - sufficient to br= eak 256-bit ECDSA in <8 hours
- STEALTH ATTACK VECTORS: Quantum adver= saries could precompute keys and execute timed thefts during mempool propag= ation

*Fundamental ECDSA Vulnerability*
ECDSA security relies on = the Elliptic Curve Discrete Logarithm Problem (ECDLP). Shor's quantum a= lgorithm solves it in O((log n)=C2=B3) time:
1. For secp256k1: n =E2=89= =88 2=C2=B2=E2=81=B5=E2=81=B6
2. Classical security: 128-bit
3. Quant= um security: 0-bit (broken by Shor)
4. Critical exposure: Any public key= revealed becomes immediately vulnerable

*Consequences of Inaction*<= br>- WEALTH DESTRUCTION: Single theft event could permanently erode trust- COORDINATION TRAP: Delayed action risks chaotic emergency hard forks- SYSTEMIC COLLAPSE: Quantum break would invalidate Bitcoin's security= model

=3D=3D SPECIFICATION =3D=3D
*Phase 1: QR Adoption (0-2 yea= rs)*
- Soft-fork activation of QR witness programs (SegWit v3+)
- New= outputs must use OP_CHECKSIG_PQ
- Classical scripts marked as deprecate= d

*Phase 2: Legacy Deprecation (5 years)*
- Creating new classica= l UTXOs becomes non-standard
- Wallets default to QR outputs with warnin= gs for classical sends
- Economic incentive: QR transactions get priorit= y mempool treatment

*Phase 3: Classical Sunset (Block 1,327,121 ~8 y= ears)*
- Consensus-enforced rejection of classical script spends
- Fr= ozen UTXOs permanently unspendable (supply reduction)
- Emergency overri= de: 95% miner vote can delay by 52-week increments

*Phase 4: Recover= y Mechanism (Optional)*
- ZK-proof system for reclaiming frozen funds vi= a:
=C2=A0 =E2=80=A2 Proof of BIP-39 seed knowledge
=C2=A0 =E2=80=A2 T= ime-locked quantum-resistant scripts
- Requires separate BIP after 3+ ye= ars cryptanalysis

=3D=3D RATIONALE =3D=3D
*Why Phased Approach?*<= br>- MARKET CERTAINTY: Fixed timeline eliminates "wait-and-see" s= tagnation
- PROGRESSIVE PRESSURE: Gradual restrictions avoid shock trans= itions
- SUNK COST PRINCIPLE: Users ignoring 3+ years of warnings assume= responsibility

*Why Freeze Legacy UTXOs?*
- Prevents quantum arm= s race for exposed coins
- Preserves Bitcoin's "lost coins"= ; scarcity principle
- Avoids centralized redistribution committees
-= Eliminates moral hazard of rewarding late migrators
- Reduces quantum a= ttack surface

*Algorithm Choice: SPHINCS+-SHAKE256f (SLH-DSA-SHAKE-2= 56f)*
SECURITY PARAMETERS:
=C2=A0 n: 256
=C2=A0 Hash: SHAKE256
= =C2=A0 Classical Security: 2=C2=B2=E2=81=B5=E2=81=B6
=C2=A0 Quantum Secu= rity: 2=C2=B9=C2=B2=E2=81=B8
=C2=A0 Private Key: 128 bytes
=C2=A0 Pub= lic Key: 64 bytes
=C2=A0 Signature: 49,856 bytes

QUANTUM ATTACK R= ESISTANCE:
| Attack Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Standard Bitcoin = | This System =C2=A0 | Security Factor |
|---------------------|--------= ----------|---------------|-----------------|
| Shor's Algorithm =C2= =A0 =C2=A0| Broken =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Not applicable| =E2= =88=9E =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| Grover's= Algorithm =C2=A0| O(2=C2=B9=C2=B2=E2=81=B8) =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = O(2=E2=81=B5=C2=B9=C2=B2) =C2=A0 =C2=A0 =C2=A0| 2=C2=B3=E2=81=B8=E2=81=B4 a= dvantage =C2=A0|
| Collision Search =C2=A0 =C2=A0| O(2=E2=81=B8=E2=81=B5= ) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| O(2=E2=81=B8=E2=81=B5) =C2=A0 =C2=A0 = =C2=A0 | Equivalent =C2=A0 =C2=A0 =C2=A0|

KEY SECURITY (SK 128 bytes= ):
- Private key entropy: 1024 bits (2=C2=B9=E2=81=B0=C2=B2=E2=81=B4 po= ssibilities)
- Quantum brute-force: =E2=88=9A(2=C2=B9=E2=81=B0=C2=B2=E2= =81=B4) =3D 2=E2=81=B5=C2=B9=C2=B2 =E2=89=88 10=C2=B9=E2=81=B5=E2=81=B4 ope= rations
- Time required at 1 quintillion ops/sec (10=C2=B9=E2=81=B8): 10= =C2=B9=C2=B3=E2=81=B6 seconds =E2=89=88 3 =C3=97 10=C2=B9=C2=B2=E2=81=B8 ye= ars

SEED SECURITY (SEED 96 bytes):
- Possible seeds: 2=E2= =81=B7=E2=81=B6=E2=81=B8 =E2=89=88 10=C2=B2=C2=B3=C2=B9 =C2=A0
- Quantum= brute-force: =E2=88=9A(2=E2=81=B7=E2=81=B6=E2=81=B8) =3D 2=C2=B3=E2=81=B8= =E2=81=B4 =E2=89=88 10=C2=B9=C2=B9=E2=81=B5 operations =C2=A0
- Time req= uired at 1 billion ops/sec: 10=C2=B9=E2=81=B0=E2=81=B6 seconds =E2=89=88 3 = =C3=97 10=E2=81=B9=E2=81=B8 years

INFORMATION THEORETIC ADVANTAGES:<= br>- Each signature reveals 4 bits of private key material
- After 20 si= gnatures:
=C2=A0 =E2=80=A2 ECDSA: Private key fully compromised
=C2= =A0 =E2=80=A2 SPHINCS+: 80 bits revealed (7.81% of key)
=C2=A0 =E2=80=A2= Security margin remains: 944 bits (92.19%)

=3D=3D BACKWARD COMPATIB= ILITY =3D=3D
Phase | Legacy Wallets =C2=A0 =C2=A0 =C2=A0 | QR Wallets------|---------------------|------------------------
1 =C2=A0 =C2=A0 |= Full functionality =C2=A0| Can receive/send both types
2 =C2=A0 =C2=A0 = | Can only send to QR | Full functionality
3+ =C2=A0 =C2=A0| Frozen fund= s =C2=A0 =C2=A0 =C2=A0 =C2=A0| Only QR transactions valid

=3D=3D DEP= LOYMENT =3D=3D
Activation Mechanism:
- Speedy Trial (BIP-8) with 18-m= onth timeout
- 90% miner signaling threshold

Monitoring:
- QR = adoption metrics published quarterly
- Sunset delay requires proof of:=C2=A0 =E2=80=A2 <70% exchange/wallet adoption
=C2=A0 =E2=80=A2 Fun= damental flaws in NIST PQC standards

=3D=3D STAKEHOLDER IMPACT =3D= =3D
Group =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Action Required =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Timeline
----------------|--= -----------------------------|-------------------
Miners =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| Upgrade nodes for QR rules =C2=A0 =C2=A0| Phase 1 act= ivation
Exchanges =C2=A0 =C2=A0 =C2=A0 | Implement QR withdrawals =C2=A0= =C2=A0 | Within 18 months of Phase 1
Hardware Wallets| Firmware updates= for QR sigs | Before Phase 2
Light Clients =C2=A0 | SPV proofs for QR s= cripts =C2=A0 =C2=A0| Phase 3 readiness

=3D=3D REFERENCES =3D=3D- SPHINCS+ Implementation: https://github.com/= bitcoin-foundation/Quantum-Resistant-Bitcoin
- (FIPS 205)=C2=A0SLH-D= SA: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf<= /a>


Feedback welcome from wa= llet developers, exchanges, miners, and security researchers.

--
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/fff86606-d6ce-4319-a341-90e9c4eba49dn%40googlegroups.com.
------=_Part_113901_1324720015.1754701467032-- ------=_Part_113900_1567383867.1754701467032--