From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 09 Aug 2025 10:58:57 -0700 Received: from mail-qv1-f56.google.com ([209.85.219.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uknqJ-0007pu-Pv for bitcoindev@gnusha.org; Sat, 09 Aug 2025 10:58:57 -0700 Received: by mail-qv1-f56.google.com with SMTP id 6a1803df08f44-7075d48a15bsf62436966d6.3 for ; Sat, 09 Aug 2025 10:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1754762329; x=1755367129; 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=RJ8TaEsoQ9r31x8oR69g8x1oYBoOjeoWiZG2Ot1LBnk=; b=VfzH+fA4Cratxc0IpZtxj8QZfbEIA6f1HoYsoN/qztbhrgQ3qGWVI5XYqy20v/aEMo Pocow3BCLbHTdXZ/+3kegvHb3CpJ9QqBcTgThYlYrpD9gxgOKplsugDkMp2dvdBhly9k 56xC3nqK+BNufHRaTO0qZaH6B9Hyvl7vs+A16B+zYBHSRbLmdYECAeJbykT0BTQnl3G6 t2TH1HVT43vNY8J+nq9CX7YMT+It49JYLOFWjEcorMJk/X7jRrPEfVNddWrY5j2wguC3 EswMo3oXNomStakcoKjMDLqRkPtgA/9MIGmAjINXhXwAJbVYubGDP+xO6Tm707Thv4CU GzMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754762329; x=1755367129; 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=RJ8TaEsoQ9r31x8oR69g8x1oYBoOjeoWiZG2Ot1LBnk=; b=JxNSTccFs4Di2rKeSfJtot+7CfxOnlnLmvNQLAxIWgB6IKbFlfluSAtMVgn4f1aoQq 2DMP/DA0Oez7K8k4Bztjc2etuJFA6t0MIgr7Hb5Zh2QUFwcCyVsBh1b7J14t8Ajavg9I YZ/0EEUAHbib/fwLwPnYvqxRkriiKop3F5F0qkKZX8LC/555feOMcCg3jwFF6gU5lNqx HpYnUWv0ZYS5dogp7qYLMMPa56zpdHMEwPchnJQdmtj0PyhhmfEyZzuFe2nguie/4S0W /yZ3J0M/lD2mjzqTK6AVOeVdfGVMhUTwurtJhqXdXRDX/e0vCbtQjuHA7aLpCnZKnJ0F 2ywg== X-Forwarded-Encrypted: i=1; AJvYcCVSScnMIiSVVIviDGwjGqopMTrzKD8Dd4kKVEVA07k6RXLdKSodugksqjeUL47A2D63/7PDZ5eONinB@gnusha.org X-Gm-Message-State: AOJu0Yw5TLkiW2iKsm5W4w6Qwf+JBDDnY/IX/MxyHUvtR2pZA/waDbfE aPcv+NppZD+eojUDM6M7vblV+Wmhe3jRINrkLNJ8RtM61TTix4nFIlx5 X-Google-Smtp-Source: AGHT+IFAPFvYEKoghCUDtJoPvSoGVqklkk2DjwE755cCa0s26sJVPs453d+AJdXN7byoqqnQaCq8rw== X-Received: by 2002:a05:6214:c84:b0:707:ba4:a21e with SMTP id 6a1803df08f44-7099a1d06cemr108518006d6.1.1754762328610; Sat, 09 Aug 2025 10:58:48 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZd+oI8cfVd6ntuzM0d7Yx9eE63LzARTGJInoPbbzjChzA== Received: by 2002:a05:6214:528d:b0:707:2629:964c with SMTP id 6a1803df08f44-7098809df7dls37189306d6.0.-pod-prod-03-us; Sat, 09 Aug 2025 10:58:43 -0700 (PDT) X-Received: by 2002:a05:620a:2943:b0:7e6:5f1c:4d7f with SMTP id af79cd13be357-7e82c7d987cmr1030436885a.65.1754762323630; Sat, 09 Aug 2025 10:58:43 -0700 (PDT) Received: by 2002:a05:690c:2605:b0:718:5fd:a4e7 with SMTP id 00721157ae682-71bf1a7df88ms7b3; Fri, 8 Aug 2025 22:26:23 -0700 (PDT) X-Received: by 2002:a05:690c:a089:10b0:71b:f500:70c0 with SMTP id 00721157ae682-71bf5007437mr38992047b3.6.1754717182695; Fri, 08 Aug 2025 22:26:22 -0700 (PDT) Date: Fri, 8 Aug 2025 22:26:21 -0700 (PDT) From: "'Bitcoin Foundation' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <6532d72c-fc2b-485a-9984-a9ade31e1760n@googlegroups.com> In-Reply-To: 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_95780_1280259875.1754717181978" X-Original-Sender: contact@bitcoin.foundation X-Original-From: Bitcoin Foundation Reply-To: Bitcoin Foundation 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_95780_1280259875.1754717181978 Content-Type: multipart/alternative; boundary="----=_Part_95781_154984754.1754717181978" ------=_Part_95781_154984754.1754717181978 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable An astute observation. To clarify the quantum computing landscape:=20 Google's current quantum processors do not possess 50 logical qubits, and= =20 even if they did, this would be insufficient to compromise ECDSA - let=20 alone RSA-2048, which would require approximately 20 million noisy physical= =20 qubits for successful cryptanalysis [0]. The security implications are stark: ECDSA effectively provides zero=20 quantum resistance against Shor's algorithm when executed on a sufficiently= =20 large, fault-tolerant quantum computer. The draft BIP's statement regarding= =20 Shor's O((log n)=C2=B3) complexity is mathematically sound - I encourage=20 verification through standard academic references. Regarding SLH-DSA-SHAKE-256f (formerly SPHINCS+-SHAKE256f): this=20 NIST-approved scheme provides a provable 256-bit security level (NIST Level= =20 5). While its 49,856-byte signature size may appear large, Bitcoin's=20 architecture can readily accommodate this without protocol modifications -= =20 the technical details of which are beyond the scope of this discussion. This BIP deliberately excludes non-NIST submissions like SQISign, which=20 fails to meet basic security requirements upon examination. While ML-DSA=20 (CRYSTALS-Dilithium) shows promise as a lattice-based alternative, its=20 security depends on hardness assumptions that may not withstand future=20 quantum advances. The cryptographic community recognizes SLH-DSA's hash-based construction as= =20 uniquely resilient: its lowest security tier exceeds the strongest=20 configurations of many competing schemes. No known classical or quantum=20 attacks exist against its underlying Merkle tree constructions. For=20 Bitcoin's quantum-resistant future, SLH-DSA-SHAKE-256f represents the=20 optimal choice - adopting weaker or non-standardized alternatives would=20 necessitate repeated protocol upgrades, creating unacceptable technical=20 debt. Implementation notes: 1) The pyspx library remains fully valid - NIST merely rebranded SPHINCS+= =20 as SLH-DSA without algorithmic changes 2) SHAKE256's security derives from Keccak's extensively vetted sponge=20 construction (FIPS 202 standard) [1] 3) The scheme benefits from 8+ years of cryptanalysis since its SHA-3=20 standardization We have launched a dedicated website, Quantum-Resistant Bitcoin at=20 https://quantum-resistant-bitcoin.bitcoin.foundation, which provides a more= =20 comprehensive explanation of this BIP proposal. You may find additional=20 clarity and technical details there. The website will be iteratively=20 refined based on feedback from the Bitcoin Development Mailing List=20 discussion. Once finalized, it will be converted to Markdown format and=20 formally submitted to the bitcoin/bips GitHub repository. This is currently a draft proposal - substantive technical feedback is=20 welcomed and encouraged. [0] Reference to quantum resource estimates for RSA-2048 -=20 https://arxiv.org/pdf/1905.09749 [1] FIPS 202 SHA-3 Standard documentation -=20 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf=20 On Saturday, August 9, 2025 at 4:06:10=E2=80=AFAM UTC+2 conduition wrote: > 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= =20 > of logical qubits required to break 256-bit ECC discrete log is on the=20 > order of thousands or millions, and nobody is even close yet. AFAIK the= =20 > best known algorithm requires about 1536 qubits [0]. Please cite sources = if=20 > you 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 t= o=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=20 > time will cause a hard fork if we ever want to rescue them in the future.= =20 > This 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]:=20 > https://bitcoin.stackexchange.com/questions/118928/what-does-it-mean-that= -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 Foundatio= n 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 t= o=20 >> quantum-resistant (QR) cryptography for Bitcoin. Through phased deprecat= ion=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=20 >> Factor | >> >> |---------------------|------------------|---------------|--------------= ---| >> | 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 possib= ilities) >> - 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=20 >> 10=C2=B9=C2=B2=E2=81=B8 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=20 >> Phase 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 facilitat= e=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=20 >> visual polish. After incorporating feedback from this discussion, the fi= nal=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/= 6532d72c-fc2b-485a-9984-a9ade31e1760n%40googlegroups.com. ------=_Part_95781_154984754.1754717181978 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable An astute observation. To clarify the quantum computing landscape:=20 Google's current quantum processors do not possess 50 logical qubits,=20 and even if they did, this would be insufficient to compromise ECDSA -=20 let alone RSA-2048, which would require approximately 20 million noisy=20 physical qubits for successful cryptanalysis [0].

The security= =20 implications are stark: ECDSA effectively provides zero quantum=20 resistance against Shor's algorithm when executed on a sufficiently=20 large, fault-tolerant quantum computer. The draft BIP's statement=20 regarding Shor's O((log n)=C2=B3) complexity is mathematically sound - I=20 encourage verification through standard academic references.

Reg= arding SLH-DSA-SHAKE-256f (formerly SPHINCS+-SHAKE256f): this NIST-approved=20 scheme provides a provable 256-bit security level (NIST Level 5). While=20 its 49,856-byte signature size may appear large, Bitcoin's architecture=20 can readily accommodate this without protocol modifications - the=20 technical details of which are beyond the scope of this discussion.
This BIP deliberately excludes non-NIST submissions like SQISign, which=20 fails to meet basic security requirements upon examination. While ML-DSA (CRYSTALS-Dilithium) shows promise as a lattice-based alternative, its=20 security depends on hardness assumptions that may not withstand future=20 quantum advances.

The cryptographic community recognizes=20 SLH-DSA's hash-based construction as uniquely resilient: its lowest=20 security tier exceeds the strongest configurations of many competing=20 schemes. No known classical or quantum attacks exist against its=20 underlying Merkle tree constructions. For Bitcoin's quantum-resistant=20 future, SLH-DSA-SHAKE-256f represents the optimal choice - adopting=20 weaker or non-standardized alternatives would necessitate repeated=20 protocol upgrades, creating unacceptable technical debt.

Impleme= ntation notes:
1) The pyspx library remains fully valid - NIST merely = rebranded SPHINCS+ as SLH-DSA without algorithmic changes
2) SHAKE256'= s security derives from Keccak's extensively vetted sponge construction (FI= PS 202 standard) [1]
3) The scheme benefits from 8+ years of cryptanal= ysis since its SHA-3 standardization

We have launched a dedicated website, Quantum-Resistant Bitcoin at=20 https://quantum-resistant-bitcoin.bitcoin.foundation, which provides a=20 more comprehensive explanation of this BIP proposal. You may find=20 additional clarity and technical details there. The website will be=20 iteratively refined based on feedback from the Bitcoin Development=20 Mailing List discussion. Once finalized, it will be converted to=20 Markdown format and formally submitted to the bitcoin/bips GitHub=20 repository.

This is currently a draft proposal - substantive tec= hnical feedback is welcomed and encouraged.

[0] Reference to qua= ntum resource estimates for RSA-2048 - https://arxiv.org/pdf/1905.09749
[1] FIPS 202 SHA-3 Standard documentation - https://nvlpubs.nist.gov/nist= pubs/FIPS/NIST.FIPS.202.pdf

On Saturday, August 9, 2025 at 4:06:10=E2=80=AFAM UTC+2 conduition wrote= :
I appreciat= e your enthusiasm for quantum resilience, but there are many things wrong w= ith this proposal.=C2=A0


- "5= 0 logical qubits - sufficient to break 256-bit ECDSA" - The number= of logical qubits required to break 256-bit ECC discrete log is on the ord= er of thousands or millions, and nobody is even close yet. AFAIK the best k= nown algorithm requires about 1536 qubits [0]. Please cite sources if you h= ave been informed otherwise.
- "0-bit security" = ROFL, what does that even mean? Also you have the wrong big-O complexity fo= r Shor's algorithm [1]
- The 256-bit flavors of SLH-DSA are o= verkill. Bitcoin addresses are already fundamentally limited to 128 bits of= security (a little less, actually) under a naive SHA256 or secp256k1 birth= day attack. [2] Trying to add more is unnecessary, especially given the YUG= E signatures required.
- This proposal completely ignores other p= romising new cryptographic signing algorithms like ML-DSA [3] and SQISign [= 4] which would be needed for low-latency resource-constrained environments = like LN nodes.
- Freezing UTXOs without some sort of unlocking pa= th baked-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 deterministica= lly derived preimages, and commits to them in a carefully chosen chain of O= TS certification signatures. The algorithm guarantees the probability of su= ccessful 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].
- Yo= ur "SPHINCS+ implementation" is just a wrapper around the python = 'pyspx' package from PyPi with some encoding mechanisms sprinkled o= n top. The `pyspx` module was last updated three years ago [6] and SLH-DSA = was only fully standardized two years ago, so your code is actually non-com= pliant with your own proposal.
- "This BIP draft prioriti= zes technical accuracy over visual polish". I think i'll stop = now.

If you're interested in meaningfully cont= ributing to upgrading Bitcoin to be quantum resilient, I would suggest you = stop trying to write your own spec single-handed, and start by reviewing BI= P360 [7] and reading mailing list archives on post quantum upgrade proposal= s. There have been many...

regards,
cond= uition


[6]:=C2=A0https://pypi.org/project/PySPX/#history


On Thursday, August 7, = 2025 at 5:26:07=E2=80=AFPM UTC-7 Bitcoin Foundation wrote:
BIP: TBD
Layer: Consensus (soft for= k)
Title: Quantum-Resistant Transition Framework for Bitcoin
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 pr= oposal defines a backward-compatible, time-bound migration path to quantum-= resistant (QR) cryptography for Bitcoin. Through phased deprecation of ECDS= A/Schnorr signatures and mandatory adoption of NIST-standardized post-quant= um algorithms, it ensures Bitcoin's survival against quantum attacks wh= ile minimizing disruption to existing infrastructure.

=3D=3D MOTIVAT= ION =3D=3D
*Quantum Threat Assessment*
- PUBLIC KEY EXPOSURE: 25% of = Bitcoin's UTXO set (~$150B as of 2025) is vulnerable to Shor's algo= rithm 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 break 256-bit ECDSA = in <8 hours
- STEALTH ATTACK VECTORS: Quantum adversaries could preco= mpute keys and execute timed thefts during mempool propagation

*Fund= amental ECDSA Vulnerability*
ECDSA security relies on the Elliptic Curve= Discrete Logarithm Problem (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-bi= t (broken by Shor)
4. Critical exposure: Any public key revealed becomes= immediately vulnerable

*Consequences of Inaction*
- WEALTH DESTR= UCTION: Single theft event could permanently erode trust
- COORDINATION = TRAP: Delayed action risks chaotic emergency hard forks
- SYSTEMIC COLLA= PSE: Quantum break would invalidate Bitcoin's security model

=3D= =3D SPECIFICATION =3D=3D
*Phase 1: QR Adoption (0-2 years)*
- Soft-fo= rk 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 n= on-standard
- Wallets default to QR outputs with warnings for classical = sends
- Economic incentive: QR transactions get priority mempool treatme= nt

*Phase 3: Classical Sunset (Block 1,327,121 ~8 years)*
- Conse= nsus-enforced rejection of classical script spends
- Frozen UTXOs perman= ently unspendable (supply reduction)
- Emergency override: 95% miner vot= e can delay by 52-week increments

*Phase 4: Recovery Mechanism (Opti= onal)*
- ZK-proof system for reclaiming frozen funds via:
=C2=A0 =E2= =80=A2 Proof of BIP-39 seed knowledge
=C2=A0 =E2=80=A2 Time-locked quant= um-resistant scripts
- Requires separate BIP after 3+ years cryptanalysi= s

=3D=3D RATIONALE =3D=3D
*Why Phased Approach?*
- MARKET CERT= AINTY: Fixed timeline eliminates "wait-and-see" stagnation
- P= ROGRESSIVE PRESSURE: Gradual restrictions avoid shock transitions
- SUNK= COST PRINCIPLE: Users ignoring 3+ years of warnings assume responsibility<= br>
*Why Freeze Legacy UTXOs?*
- Prevents quantum arms race for expos= ed coins
- Preserves Bitcoin's "lost coins" scarcity princ= iple
- Avoids centralized redistribution committees
- Eliminates mora= l hazard of rewarding late migrators
- Reduces quantum attack surface
*Algorithm Choice: SPHINCS+-SHAKE256f (SLH-DSA-SHAKE-256f)*
SECURIT= Y 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 Security: 2=C2=B9=C2= =B2=E2=81=B8
=C2=A0 Private Key: 128 bytes
=C2=A0 Public Key: 64 byte= s
=C2=A0 Signature: 49,856 bytes

QUANTUM ATTACK RESISTANCE:
| = 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| Br= oken =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 advantage =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 | Equ= ivalent =C2=A0 =C2=A0 =C2=A0|

KEY SECURITY (SK 128 bytes):
- Pri= vate key entropy: 1024 bits (2=C2=B9=E2=81=B0=C2=B2=E2=81=B4 possibilities)=
- 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 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 =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 required at 1 bi= llion 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 si= gnature reveals 4 bits of private key material
- After 20 signatures:=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 marg= in remains: 944 bits (92.19%)

=3D=3D BACKWARD COMPATIBILITY =3D=3DPhase | Legacy Wallets =C2=A0 =C2=A0 =C2=A0 | QR Wallets
------|------= ---------------|------------------------
1 =C2=A0 =C2=A0 | Full function= ality =C2=A0| Can receive/send both types
2 =C2=A0 =C2=A0 | Can only sen= d to QR | Full functionality
3+ =C2=A0 =C2=A0| Frozen funds =C2=A0 =C2= =A0 =C2=A0 =C2=A0| Only QR transactions valid

=3D=3D DEPLOYMENT =3D= =3D
Activation Mechanism:
- Speedy Trial (BIP-8) with 18-month timeou= t
- 90% miner signaling threshold

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

=3D=3D STAKEHOLDER IMPACT =3D=3D
Grou= p =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 activation
Exc= hanges =C2=A0 =C2=A0 =C2=A0 | Implement QR withdrawals =C2=A0 =C2=A0 | With= in 18 months of Phase 1
Hardware Wallets| Firmware updates for QR sigs |= Before Phase 2
Light Clients =C2=A0 | SPV proofs for QR scripts =C2=A0 = =C2=A0| Phase 3 readiness

=3D=3D REFERENCES =3D=3D
= - Schnorr Signatures: BIP-0340

=3D=3D COPYRIGHT =3D=3D
MIT Licens= e

---


This BIP presents an alternative = quantum-resistant migration approach, primarily distinguished by its extend= ed transition timeline to facilitate more comprehensive ecosystem adaptatio= n.

Key features:
- Includes reference implementation of SPHINCS+-= SHAKE256f (SLH-DSA-SHAKE-256f)
- Provides comparative analysis against B= itcoin's current ECDSA scheme
- Detailed technical specifications:https://github.com/bitcoin-foundation/Quantum= -Resistant-Bitcoin

Formatting note: This BIP draft prioritizes t= echnical accuracy over visual polish.=C2=A0After incorporating feedback fro= m this discussion, the final version will be published to GitHub with prope= r Markdown formatting.

Feedback welcome from wallet developer= s, 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/6532d72c-fc2b-485a-9984-a9ade31e1760n%40googlegroups.com.
------=_Part_95781_154984754.1754717181978-- ------=_Part_95780_1280259875.1754717181978--