[bitcoindev] [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin

[bitcoindev] [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin

['Bitcoin Foundation' via Bitcoin Development Mailing List]

[-- Attachment #1.1: Type: text/plain, Size: 7172 bytes --]

BIP: TBD
Layer: Consensus (soft fork)
Title: Quantum-Resistant Transition Framework for Bitcoin 
Author: Bitcoin Post-Quantum Working Group <pq-research@bitcoin.foundation>
Status: Draft 
Type: Standards Track 
Created: 2025-08-07
License: MIT
Requires: BIP-340, BIP-341

== ABSTRACT ==
This proposal defines a backward-compatible, time-bound migration path to 
quantum-resistant (QR) cryptography for Bitcoin. Through phased deprecation 
of ECDSA/Schnorr signatures and mandatory adoption of NIST-standardized 
post-quantum algorithms, it ensures Bitcoin's survival against quantum 
attacks while minimizing disruption to existing infrastructure.

== MOTIVATION ==
*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 
break 256-bit ECDSA in <8 hours
- STEALTH ATTACK VECTORS: Quantum adversaries could precompute keys and 
execute timed thefts during mempool propagation

*Fundamental ECDSA Vulnerability*
ECDSA security relies on the Elliptic Curve Discrete Logarithm Problem 
(ECDLP). Shor's quantum algorithm solves it in O((log n)³) time:
1. For secp256k1: n ≈ 2²⁵⁶
2. Classical security: 128-bit
3. Quantum security: 0-bit (broken by Shor)
4. Critical exposure: Any public key revealed becomes immediately 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 model

== SPECIFICATION ==
*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:
  • Proof of BIP-39 seed knowledge
  • Time-locked quantum-resistant scripts
- Requires separate BIP after 3+ years cryptanalysis

== RATIONALE ==
*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 
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²⁵⁶
  Quantum Security: 2¹²⁸
  Private Key: 128 bytes
  Public Key: 64 bytes
  Signature: 49,856 bytes

QUANTUM ATTACK RESISTANCE:
| Attack Type         | Standard Bitcoin | This System   | Security Factor |
|---------------------|------------------|---------------|-----------------|
| Shor's Algorithm    | Broken           | Not applicable| ∞               |
| Grover's Algorithm  | O(2¹²⁸)         | O(2⁵¹²)      | 2³⁸⁴ advantage  |
| Collision Search    | O(2⁸⁵)          | O(2⁸⁵)       | Equivalent      |

KEY SECURITY (SK 128 bytes):
- Private key entropy: 1024 bits (2¹⁰²⁴ possibilities)
- Quantum brute-force: √(2¹⁰²⁴) = 2⁵¹² ≈ 10¹⁵⁴ operations
- Time required at 1 quintillion ops/sec (10¹⁸): 10¹³⁶ seconds ≈ 3 × 10¹²⁸ 
years

SEED SECURITY (SEED 96 bytes):
- Possible seeds: 2⁷⁶⁸ ≈ 10²³¹  
- Quantum brute-force: √(2⁷⁶⁸) = 2³⁸⁴ ≈ 10¹¹⁵ operations  
- Time required at 1 billion ops/sec: 10¹⁰⁶ seconds ≈ 3 × 10⁹⁸ years

INFORMATION THEORETIC ADVANTAGES:
- Each signature reveals 4 bits of private key material
- After 20 signatures:
  • ECDSA: Private key fully compromised
  • SPHINCS+: 80 bits revealed (7.81% of key)
  • Security margin remains: 944 bits (92.19%)

== BACKWARD COMPATIBILITY ==
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

== DEPLOYMENT ==
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:
  • <70% exchange/wallet adoption
  • Fundamental flaws in NIST PQC standards

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

== REFERENCES ==
- SPHINCS+ Implementation: 
https://github.com/bitcoin-foundation/Quantum-Resistant-Bitcoin
- (FIPS 205) SLH-DSA: 
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf
- Schnorr Signatures: BIP-0340

== COPYRIGHT ==
MIT License

---


This BIP presents an alternative quantum-resistant migration approach, 
primarily distinguished by its extended transition timeline to facilitate 
more comprehensive ecosystem adaptation.

Key features:
- Includes reference implementation of SPHINCS+-SHAKE256f 
(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 visual 
polish. After incorporating feedback from this discussion, the final 
version will be published to GitHub with proper Markdown formatting.

Feedback welcome from wallet developers, exchanges, miners, and security 
researchers.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4d6ecde7-e959-4e6c-a0aa-867af8577151n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 8136 bytes --]

[bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin

['conduition' via Bitcoin Development Mailing List]

[-- Attachment #1.1: Type: text/plain, Size: 10629 bytes --]

I appreciate your enthusiasm for quantum resilience, but there are many 
things wrong with this proposal. 


- *"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 if you 
have been informed otherwise.
- *"0-bit security"* ROFL, what does that even mean? Also you have the 
wrong big-O complexity for Shor's algorithm [1]
- The 256-bit flavors of SLH-DSA are overkill. Bitcoin addresses are 
already fundamentally limited to 128 bits of security (a little less, 
actually) under a naive SHA256 or secp256k1 birthday attack. [2] Trying to 
add more is unnecessary, especially given the YUGE signatures required.
- This proposal completely ignores other promising 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 path 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 deterministically derived 
preimages, 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 = 2^64. For the math see this script [5].
- Your "SPHINCS+ implementation" is just a wrapper around the python 
'pyspx' package from PyPi with some encoding mechanisms sprinkled on 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-compliant with your own proposal.
- *"This BIP draft prioritizes technical accuracy over visual polish"*. I 
think i'll stop now.

If you're interested in meaningfully contributing to upgrading Bitcoin to 
be quantum resilient, I would suggest you stop trying to write your own 
spec single-handed, and start by reviewing BIP360 [7] and reading mailing 
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-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 PM UTC-7 Bitcoin Foundation wrote:

> BIP: TBD
> Layer: Consensus (soft fork)
> 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
>
> == ABSTRACT ==
> This proposal defines a backward-compatible, time-bound migration path to 
> quantum-resistant (QR) cryptography for Bitcoin. Through phased deprecation 
> of ECDSA/Schnorr signatures and mandatory adoption of NIST-standardized 
> post-quantum algorithms, it ensures Bitcoin's survival against quantum 
> attacks while minimizing disruption to existing infrastructure.
>
> == MOTIVATION ==
> *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 
> break 256-bit ECDSA in <8 hours
> - STEALTH ATTACK VECTORS: Quantum adversaries could precompute keys and 
> execute timed thefts during mempool propagation
>
> *Fundamental ECDSA Vulnerability*
> ECDSA security relies on the Elliptic Curve Discrete Logarithm Problem 
> (ECDLP). Shor's quantum algorithm solves it in O((log n)³) time:
> 1. For secp256k1: n ≈ 2²⁵⁶
> 2. Classical security: 128-bit
> 3. Quantum security: 0-bit (broken by Shor)
> 4. Critical exposure: Any public key revealed becomes immediately 
> 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 
> model
>
> == SPECIFICATION ==
> *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:
>   • Proof of BIP-39 seed knowledge
>   • Time-locked quantum-resistant scripts
> - Requires separate BIP after 3+ years cryptanalysis
>
> == RATIONALE ==
> *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 
> 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²⁵⁶
>   Quantum Security: 2¹²⁸
>   Private Key: 128 bytes
>   Public Key: 64 bytes
>   Signature: 49,856 bytes
>
> QUANTUM ATTACK RESISTANCE:
> | Attack Type         | Standard Bitcoin | This System   | Security Factor 
> |
>
> |---------------------|------------------|---------------|-----------------|
> | Shor's Algorithm    | Broken           | Not applicable| ∞               
> |
> | Grover's Algorithm  | O(2¹²⁸)         | O(2⁵¹²)      | 2³⁸⁴ advantage  |
> | Collision Search    | O(2⁸⁵)          | O(2⁸⁵)       | Equivalent      |
>
> KEY SECURITY (SK 128 bytes):
> - Private key entropy: 1024 bits (2¹⁰²⁴ possibilities)
> - Quantum brute-force: √(2¹⁰²⁴) = 2⁵¹² ≈ 10¹⁵⁴ operations
> - Time required at 1 quintillion ops/sec (10¹⁸): 10¹³⁶ seconds ≈ 3 × 10¹²⁸ 
> years
>
> SEED SECURITY (SEED 96 bytes):
> - Possible seeds: 2⁷⁶⁸ ≈ 10²³¹  
> - Quantum brute-force: √(2⁷⁶⁸) = 2³⁸⁴ ≈ 10¹¹⁵ operations  
> - Time required at 1 billion ops/sec: 10¹⁰⁶ seconds ≈ 3 × 10⁹⁸ years
>
> INFORMATION THEORETIC ADVANTAGES:
> - Each signature reveals 4 bits of private key material
> - After 20 signatures:
>   • ECDSA: Private key fully compromised
>   • SPHINCS+: 80 bits revealed (7.81% of key)
>   • Security margin remains: 944 bits (92.19%)
>
> == BACKWARD COMPATIBILITY ==
> 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
>
> == DEPLOYMENT ==
> 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:
>   • <70% exchange/wallet adoption
>   • Fundamental flaws in NIST PQC standards
>
> == STAKEHOLDER IMPACT ==
> Group           | Action Required               | Timeline
> ----------------|-------------------------------|-------------------
> Miners          | Upgrade nodes for QR rules    | Phase 1 activation
> Exchanges       | Implement QR withdrawals     | Within 18 months of Phase 
> 1
> Hardware Wallets| Firmware updates for QR sigs | Before Phase 2
> Light Clients   | SPV proofs for QR scripts    | Phase 3 readiness
>
> == REFERENCES ==
> - SPHINCS+ Implementation: 
> https://github.com/bitcoin-foundation/Quantum-Resistant-Bitcoin
> - (FIPS 205) SLH-DSA: 
> https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf
> - Schnorr Signatures: BIP-0340
>
> == COPYRIGHT ==
> MIT License
>
> ---
>
>
> This BIP presents an alternative quantum-resistant migration approach, 
> primarily distinguished by its extended transition timeline to facilitate 
> more comprehensive ecosystem adaptation.
>
> Key features:
> - Includes reference implementation of SPHINCS+-SHAKE256f 
> (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 visual 
> polish. After incorporating feedback from this discussion, the final 
> version will be published to GitHub with proper Markdown formatting.
>
> Feedback welcome from wallet developers, exchanges, miners, and security 
> researchers.
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/fff86606-d6ce-4319-a341-90e9c4eba49dn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 12453 bytes --]

[bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin

['Bitcoin Foundation' via Bitcoin Development Mailing List]

[-- Attachment #1.1: Type: text/plain, Size: 14025 bytes --]

 An astute observation. To clarify the quantum computing landscape: 
Google's current quantum processors do not possess 50 logical qubits, and 
even if they did, this would be insufficient to compromise ECDSA - let 
alone RSA-2048, which would require approximately 20 million noisy physical 
qubits for successful cryptanalysis [0].

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

Regarding SLH-DSA-SHAKE-256f (formerly SPHINCS+-SHAKE256f): this 
NIST-approved scheme provides a provable 256-bit security level (NIST Level 
5). While its 49,856-byte signature size may appear large, Bitcoin's 
architecture can readily accommodate this without protocol modifications - 
the technical details of which are beyond the scope of this discussion.

This BIP deliberately excludes non-NIST submissions like SQISign, which 
fails to meet basic security requirements upon examination. While ML-DSA 
(CRYSTALS-Dilithium) shows promise as a lattice-based alternative, its 
security depends on hardness assumptions that may not withstand future 
quantum advances.

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

Implementation 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 (FIPS 202 standard) [1]
3) The scheme benefits from 8+ years of cryptanalysis since its SHA-3 
standardization

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

This is currently a draft proposal - substantive technical feedback is 
welcomed and encouraged.

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

On Saturday, August 9, 2025 at 4:06:10 AM UTC+2 conduition wrote:

> I appreciate your enthusiasm for quantum resilience, but there are many 
> things wrong with this proposal. 
>
>
> - *"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 if 
> you have been informed otherwise.
> - *"0-bit security"* ROFL, what does that even mean? Also you have the 
> wrong big-O complexity for Shor's algorithm [1]
> - The 256-bit flavors of SLH-DSA are overkill. Bitcoin addresses are 
> already fundamentally limited to 128 bits of security (a little less, 
> actually) under a naive SHA256 or secp256k1 birthday attack. [2] Trying to 
> add more is unnecessary, especially given the YUGE signatures required.
> - This proposal completely ignores other promising 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 path 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 deterministically derived 
> preimages, 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 = 2^64. For the math see this script [5].
> - Your "SPHINCS+ implementation" is just a wrapper around the python 
> 'pyspx' package from PyPi with some encoding mechanisms sprinkled on 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-compliant with your own proposal.
> - *"This BIP draft prioritizes technical accuracy over visual polish"*. I 
> think i'll stop now.
>
> If you're interested in meaningfully contributing to upgrading Bitcoin to 
> be quantum resilient, I would suggest you stop trying to write your own 
> spec single-handed, and start by reviewing BIP360 [7] and reading mailing 
> 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-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 PM UTC-7 Bitcoin Foundation wrote:
>
>> BIP: TBD
>> Layer: Consensus (soft fork)
>> 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
>>
>> == ABSTRACT ==
>> This proposal defines a backward-compatible, time-bound migration path to 
>> quantum-resistant (QR) cryptography for Bitcoin. Through phased deprecation 
>> of ECDSA/Schnorr signatures and mandatory adoption of NIST-standardized 
>> post-quantum algorithms, it ensures Bitcoin's survival against quantum 
>> attacks while minimizing disruption to existing infrastructure.
>>
>> == MOTIVATION ==
>> *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 
>> break 256-bit ECDSA in <8 hours
>> - STEALTH ATTACK VECTORS: Quantum adversaries could precompute keys and 
>> execute timed thefts during mempool propagation
>>
>> *Fundamental ECDSA Vulnerability*
>> ECDSA security relies on the Elliptic Curve Discrete Logarithm Problem 
>> (ECDLP). Shor's quantum algorithm solves it in O((log n)³) time:
>> 1. For secp256k1: n ≈ 2²⁵⁶
>> 2. Classical security: 128-bit
>> 3. Quantum security: 0-bit (broken by Shor)
>> 4. Critical exposure: Any public key revealed becomes immediately 
>> 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 
>> model
>>
>> == SPECIFICATION ==
>> *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:
>>   • Proof of BIP-39 seed knowledge
>>   • Time-locked quantum-resistant scripts
>> - Requires separate BIP after 3+ years cryptanalysis
>>
>> == RATIONALE ==
>> *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 
>> 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²⁵⁶
>>   Quantum Security: 2¹²⁸
>>   Private Key: 128 bytes
>>   Public Key: 64 bytes
>>   Signature: 49,856 bytes
>>
>> QUANTUM ATTACK RESISTANCE:
>> | Attack Type         | Standard Bitcoin | This System   | Security 
>> Factor |
>>
>> |---------------------|------------------|---------------|-----------------|
>> | Shor's Algorithm    | Broken           | Not applicable| ∞             
>>   |
>> | Grover's Algorithm  | O(2¹²⁸)         | O(2⁵¹²)      | 2³⁸⁴ advantage  |
>> | Collision Search    | O(2⁸⁵)          | O(2⁸⁵)       | Equivalent      |
>>
>> KEY SECURITY (SK 128 bytes):
>> - Private key entropy: 1024 bits (2¹⁰²⁴ possibilities)
>> - Quantum brute-force: √(2¹⁰²⁴) = 2⁵¹² ≈ 10¹⁵⁴ operations
>> - Time required at 1 quintillion ops/sec (10¹⁸): 10¹³⁶ seconds ≈ 3 × 
>> 10¹²⁸ years
>>
>> SEED SECURITY (SEED 96 bytes):
>> - Possible seeds: 2⁷⁶⁸ ≈ 10²³¹  
>> - Quantum brute-force: √(2⁷⁶⁸) = 2³⁸⁴ ≈ 10¹¹⁵ operations  
>> - Time required at 1 billion ops/sec: 10¹⁰⁶ seconds ≈ 3 × 10⁹⁸ years
>>
>> INFORMATION THEORETIC ADVANTAGES:
>> - Each signature reveals 4 bits of private key material
>> - After 20 signatures:
>>   • ECDSA: Private key fully compromised
>>   • SPHINCS+: 80 bits revealed (7.81% of key)
>>   • Security margin remains: 944 bits (92.19%)
>>
>> == BACKWARD COMPATIBILITY ==
>> 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
>>
>> == DEPLOYMENT ==
>> 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:
>>   • <70% exchange/wallet adoption
>>   • Fundamental flaws in NIST PQC standards
>>
>> == STAKEHOLDER IMPACT ==
>> Group           | Action Required               | Timeline
>> ----------------|-------------------------------|-------------------
>> Miners          | Upgrade nodes for QR rules    | Phase 1 activation
>> Exchanges       | Implement QR withdrawals     | Within 18 months of 
>> Phase 1
>> Hardware Wallets| Firmware updates for QR sigs | Before Phase 2
>> Light Clients   | SPV proofs for QR scripts    | Phase 3 readiness
>>
>> == REFERENCES ==
>> - SPHINCS+ Implementation: 
>> https://github.com/bitcoin-foundation/Quantum-Resistant-Bitcoin
>> - (FIPS 205) SLH-DSA: 
>> https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf
>> - Schnorr Signatures: BIP-0340
>>
>> == COPYRIGHT ==
>> MIT License
>>
>> ---
>>
>>
>> This BIP presents an alternative quantum-resistant migration approach, 
>> primarily distinguished by its extended transition timeline to facilitate 
>> more comprehensive ecosystem adaptation.
>>
>> Key features:
>> - Includes reference implementation of SPHINCS+-SHAKE256f 
>> (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 
>> visual polish. After incorporating feedback from this discussion, the final 
>> version will be published to GitHub with proper Markdown formatting.
>>
>> Feedback welcome from wallet developers, exchanges, miners, and security 
>> researchers.
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6532d72c-fc2b-485a-9984-a9ade31e1760n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 18614 bytes --]

Re: [bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin

['ArmchairCryptologist' via Bitcoin Development Mailing List]

[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]

> An astute observation. To clarify the quantum computing landscape: Google's current quantum processors do not possess 50 logical qubits, and even if they did, this would be insufficient to compromise ECDSA - let alone RSA-2048, which would require approximately 20 million noisy physical qubits for successful cryptanalysis [0].

That paper is pretty old. There is a recent paper from a couple of months ago by the same author (Craig Gidney from Google Quantum AI) claiming that you could break RSA-2048 with around a million noisy qubits in about a week.

Paper: https://arxiv.org/pdf/2505.15917

Blog post: https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html

I can't say for sure whether this approach can be applied to ECDSA; I have seen claims before that it has less quantum resistance than RSA-2048, but I'm unsure if this is still considered to be the case. And while these papers are of course largely theoretical in nature since nothing close to the required amount of qubits exists at this point, I haven't seen anyone refute these claim at this point. These is still no hard evidence I'm aware of that a quantum computer capable of breaking ECDSA is inevitable, but given the rate of development, there could be some cause of concern.

Getting post-quantum addresses designed, implemented and activated by 2030 in accordance with the recommendations in this paper seems prudent to me, if this is at all possible. Deactivating inactive pre-quantum UTXOs with exposed public keys by 2035 should certainly be considered. But I still don't feel like deactivating pre-quantum UTXOs without exposed public keys in general is warranted, at least until a quantum computer capable of breaking public keys in the short time between they are broadcast and included in a block is known to exist - and even then, only if some scheme could be devised that still allows spending them using some additional cryptographic proof of ownership, ZKP or otherwise.

--
Best,
ArmchairCryptologist

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/1LDO_bQOdcKkNoKyyjfqLXAPUBVXSL667nAKDCNUfN2D7HEpDAkuFQrMubklIi1QdDI6BXdgB674g4uWYRlyQ5f-dlztDtnoEbIAlmrCg5M%3D%40protonmail.com.

[-- Attachment #2: Type: text/html, Size: 3628 bytes --]