* [bitcoindev] [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
@ 2025-08-07 18:18 'Bitcoin Foundation' via Bitcoin Development Mailing List
2025-08-09 1:04 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
2025-08-20 17:14 ` [bitcoindev] " Murch
0 siblings, 2 replies; 9+ messages in thread
From: 'Bitcoin Foundation' via Bitcoin Development Mailing List @ 2025-08-07 18:18 UTC (permalink / raw)
To: 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* [bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
2025-08-07 18:18 [bitcoindev] [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin 'Bitcoin Foundation' via Bitcoin Development Mailing List
@ 2025-08-09 1:04 ` 'conduition' via Bitcoin Development Mailing List
2025-08-09 5:26 ` 'Bitcoin Foundation' via Bitcoin Development Mailing List
2025-08-20 17:14 ` [bitcoindev] " Murch
1 sibling, 1 reply; 9+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2025-08-09 1:04 UTC (permalink / raw)
To: 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* [bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
2025-08-09 1:04 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
@ 2025-08-09 5:26 ` 'Bitcoin Foundation' via Bitcoin Development Mailing List
2025-08-09 19:38 ` 'ArmchairCryptologist' via Bitcoin Development Mailing List
0 siblings, 1 reply; 9+ messages in thread
From: 'Bitcoin Foundation' via Bitcoin Development Mailing List @ 2025-08-09 5:26 UTC (permalink / raw)
To: 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
2025-08-09 5:26 ` 'Bitcoin Foundation' via Bitcoin Development Mailing List
@ 2025-08-09 19:38 ` 'ArmchairCryptologist' via Bitcoin Development Mailing List
2025-08-12 22:47 ` 'Bitcoin Foundation' via Bitcoin Development Mailing List
2025-08-20 20:07 ` Alex Pruden
0 siblings, 2 replies; 9+ messages in thread
From: 'ArmchairCryptologist' via Bitcoin Development Mailing List @ 2025-08-09 19:38 UTC (permalink / raw)
To: Bitcoin Development Mailing List, Bitcoin Foundation
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
2025-08-09 19:38 ` 'ArmchairCryptologist' via Bitcoin Development Mailing List
@ 2025-08-12 22:47 ` 'Bitcoin Foundation' via Bitcoin Development Mailing List
2025-08-20 20:15 ` 'ArmchairCryptologist' via Bitcoin Development Mailing List
2025-08-20 20:07 ` Alex Pruden
1 sibling, 1 reply; 9+ messages in thread
From: 'Bitcoin Foundation' via Bitcoin Development Mailing List @ 2025-08-12 22:47 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 4079 bytes --]
Dear ArmchairCryptologist,
We appreciate your engagement with our quantum resistance proposal.
Let us address your points with additional technical context:
*NIST Reference Documentation*The referenced blog post includes a link to
NIST Internal Report 8547 (Initial Public Draft) [0], which offers critical
guidance regarding the migration to post-quantum cryptographic standards.
We strongly recommend thorough review of this document by all stakeholders
evaluating quantum-resistant solutions.
*Pre-Quantum UTXO Sunset Policy*Regarding the migration of pre-quantum
UTXOs:
- Our current draft proposes freezing these outputs around 2033
- This timeline appears in the "Migration Path: Phased Implementation"
section (https://quantum-resistant-bitcoin.bitcoin.foundation)
- We explicitly designed this as an adjustable parameter
- Based on community feedback, we're prepared to extend this sunset
period beyond 2035
The proposed recovery mechanism provides optional pathways for legacy UTXOs
while maintaining network security.
We remain open to community input regarding the sunset period for
pre-quantum UTXOs. The current 2033 (block 1,327,121) proposal aligns
conservatively with NIST's recommendation to deprecate ECDSA by 2035 [0],
though we acknowledge reasonable arguments exist for adjusting this
timeline.
[0]: https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
On Tuesday, August 12, 2025 at 11:04:32 AM UTC+2 ArmchairCryptologist wrote:
>
> 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/eefdcf22-9609-4fb1-b8c4-3274dc7f1f2en%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 5845 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
2025-08-07 18:18 [bitcoindev] [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin 'Bitcoin Foundation' via Bitcoin Development Mailing List
2025-08-09 1:04 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
@ 2025-08-20 17:14 ` Murch
1 sibling, 0 replies; 9+ messages in thread
From: Murch @ 2025-08-20 17:14 UTC (permalink / raw)
To: bitcoindev
This proposal is highly reminiscent of Lopp et al’s "A Post Quantum
Migration Proposal"¹ previously discussed on this list².
If this document is explicitly intended as a competing proposal to Lopp
et al’s, this proposal would need to explicitly discuss shortcomings of
Lopp et al’s proposal in a Related Work section and clearly explain in
the Motivation and Rationale sections how this new proposal is an
improvement to substantiate that the publication of a second proposal is
meaningful. As it is currently presented, I don’t consider this proposal
a significant value-add due to duplicating work.
Regards,
Murch
¹ https://github.com/bitcoin/bips/pull/1895
²
https://gnusha.org/pi/bitcoindev/CADL_X_fpv-aXBxX+eJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q@mail.gmail.com/.
On 2025-08-07 11:18, 'Bitcoin Foundation' via Bitcoin Development
Mailing List wrote:
> 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
> <https://groups.google.com/d/msgid/bitcoindev/4d6ecde7-e959-4e6c-a0aa-867af8577151n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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/284507c2-b5d1-45a5-849f-408d3bf364a6%40murch.one.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
2025-08-09 19:38 ` 'ArmchairCryptologist' via Bitcoin Development Mailing List
2025-08-12 22:47 ` 'Bitcoin Foundation' via Bitcoin Development Mailing List
@ 2025-08-20 20:07 ` Alex Pruden
2025-08-21 20:21 ` 'Bitcoin Foundation' via Bitcoin Development Mailing List
1 sibling, 1 reply; 9+ messages in thread
From: Alex Pruden @ 2025-08-20 20:07 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 4378 bytes --]
I consider the recent work by Mosca et al to be the most up-to-date in
terms of research estimation:
https://www.sciencedirect.com/science/article/pii/S0167739X24004308
The estimate he provides is approximately an order of magnitude less work
required to break ECDSA (P-256) vs RSA-2048. Ironically, the longer
bit-lengths of RSA seem to actually contribute to post-quantum security,
even though the motivation for moving from RSA-1024 was to protect against
NFS and other classical attacks against shorter RSA instances.
Note that the resource estimation in the paper doesn't account for Gidney's
speedup, which was 20x reduction in qubits required. It's unclear whether
that same improvement factor could be applied here; as the Gidney paper
showed, the earliest CRQCs will probably be hardwired for certain circuits
for performance reasons. E.g. Gidney's circuit layout works for RSA-2048
and that's it. But the ideas he presents around error correction (e.g. the
yoked surface code) might apply more broadly, it's hard to say.
Also note that many of his assumptions are based on a superconducting
architecture, which generally have faster runtimes but lower stability (so
scaling is harder)
Other architectures like this one https://arxiv.org/pdf/2506.20660 from the
neutral atom community have slower runtimes but greater stability. But even
if you scale, it probably only works for targeted, long-range attacks vs
specific PKs as a CRQC.
Lots of variables to consider here in terms of estimating the timeline for
a CRQC, but the proactive approach is probably the right one, because (to
quote Gidney in his conclusion) we should "*prefer security to not be
contingent on progress being slow.*"
On Tuesday, August 12, 2025 at 3:04:32 AM UTC-6 ArmchairCryptologist wrote:
>
> 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/80005f10-e9af-4b4f-a05f-de2bd666d8ccn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6140 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
2025-08-12 22:47 ` 'Bitcoin Foundation' via Bitcoin Development Mailing List
@ 2025-08-20 20:15 ` 'ArmchairCryptologist' via Bitcoin Development Mailing List
0 siblings, 0 replies; 9+ messages in thread
From: 'ArmchairCryptologist' via Bitcoin Development Mailing List @ 2025-08-20 20:15 UTC (permalink / raw)
To: Bitcoin Foundation, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 7099 bytes --]
When it comes to the NIST recommendation for the deprecation timeline, there is now a (very) recent paper available, released on August 19th 2025 (i.e. yesterday as of this writing), which suggests the timeline should be moved up somewhat. This paper targets ECDLP and ECC in general, and secp256k1 as used in Bitcoin specifically. You can find this here:
https://arxiv.org/abs/2508.14011
Some key takeaways:
"When algorithmic curves and vendor trajectories are overlaid on this common ruler, the earliest inter-
sections appear in the late 2020s; more conservative crossings cluster in the early 2030s. We therefore
indicate a first plausible window for cryptanalytically relevant quantum computers (CRQCs) around
2027–2033. The endpoints move mainly with three levers: reliable magic-state supply at scale (dis-
tillation or cultivation), code distance sufficient for multi-hour jobs, and classical-control latency that
keeps pace with fast error-correction cycles. If any lever stalls, the window shifts to the right; if severalimprove together, it shifts to the left."
"The classical record remains consistent with Θ(2b/2) scaling for generic prime-field curves (Section 3);
constant-factor engineering wins have not changed the asymptotics. In parallel, logical-to-physical
translations suggest that credible ECC-256 attacks via Shor’s algorithm require mid-10^5 to low-10^6
noisy qubits under surface code assumptions, with cat-qubit architectures offering alternative overhead
tradeoffs (Section 4; [37, 39, 46]) by trading fewer physical qubits for an increased complexity of their
architecture. Overlaying algorithmic cost with public roadmaps yields a first plausible window forcryptanalytically relevant quantum computers in roughly 2027–2033, albeit with wide error bars."
The lower bound of the window seems highly optimistic to me when compared to the actual roadmaps for physical qubits provided by Google and IonQ (the most optimistic of the bunch) which are summarized on page 15, but targeting 2030 as an actual deadline for having quantum-resistant addresses ready for use is starting to look necessary. Even if the surface code assumptions that are relied upon to combine physical qubits into logical ones turn out to not hold water, and this ultimately means that the current approach to quantum computers is unworkable, if nothing else, it would to counter the inevitable FUD.
--
Best,
ArmchairCryptologist
On Monday, August 18th, 2025 at 7:12 PM, 'Bitcoin Foundation' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
> Dear ArmchairCryptologist,
>
> We appreciate your engagement with our quantum resistance proposal.
> Let us address your points with additional technical context:
>
> NIST Reference DocumentationThe referenced blog post includes a link to NIST Internal Report 8547 (Initial Public Draft) [0], which offers critical guidance regarding the migration to post-quantum cryptographic standards. We strongly recommend thorough review of this document by all stakeholders evaluating quantum-resistant solutions.
>
> Pre-Quantum UTXO Sunset PolicyRegarding the migration of pre-quantum UTXOs:
>
> - Our current draft proposes freezing these outputs around 2033
> - This timeline appears in the "Migration Path: Phased Implementation" section ([https://quantum-resistant-bitcoin.bitcoin.foundation](https://quantum-resistant-bitcoin.bitcoin.foundation/))
> - We explicitly designed this as an adjustable parameter
> - Based on community feedback, we're prepared to extend this sunset period beyond 2035
> The proposed recovery mechanism provides optional pathways for legacy UTXOs while maintaining network security.
>
> We remain open to community input regarding the sunset period for pre-quantum UTXOs. The current 2033 (block 1,327,121) proposal aligns conservatively with NIST's recommendation to deprecate ECDSA by 2035 [0], though we acknowledge reasonable arguments exist for adjusting this timeline.
>
> [0]: https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
>
> On Tuesday, August 12, 2025 at 11:04:32 AM UTC+2 ArmchairCryptologist wrote:
>
>>> 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/eefdcf22-9609-4fb1-b8c4-3274dc7f1f2en%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/-a-KFgZ_XFrN2mUZTauxRoD3H2f4Qhid-h1B2CcC0WgOxbJD-mfRvku_v-SOV7QcfAUpjgDO3kjJZvYnaNu1g0oXC9axoltclOgN628CMDc%3D%40protonmail.com.
[-- Attachment #2: Type: text/html, Size: 11573 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
2025-08-20 20:07 ` Alex Pruden
@ 2025-08-21 20:21 ` 'Bitcoin Foundation' via Bitcoin Development Mailing List
0 siblings, 0 replies; 9+ messages in thread
From: 'Bitcoin Foundation' via Bitcoin Development Mailing List @ 2025-08-21 20:21 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 10654 bytes --]
*Response to Murch:*
Thank you for your feedback. You are correct that the high-level goal of
achieving quantum resilience is shared between our proposal and the earlier
one from Lopp et al. (co-authored by the Pauli Group). However, the
critical differentiator lies not in the "what" but in the "when" and the
"why"—factors that fundamentally impact Bitcoin's security and stability.
The primary shortcoming of the Pauli Group proposal is its alarmist and
commercially motivated urgency, which pushes for an accelerated timeline
that is misaligned with the cautious, evidence-based approach of
international standards bodies. As the NIST Internal Report 8547 makes
clear, the transition to PQC is a massive undertaking that requires careful
coordination across the entire cryptographic ecosystem, with a realistic
target for completion set for 2035 [NIST.IR.8547.ipd, p.8, 18]. NIST
explicitly allows for the continued use of classical signatures for
authentication until quantum computers are actually available, advocating
for a managed transition that minimizes disruption [NIST.IR.8547.ipd, p.15].
The Pauli Group's timeline seems designed to create a false sense of
emergency, likely to benefit their commercial interests in promoting
specific solutions. In contrast, our BIP is structured around NIST's
well-reasoned 2035 horizon. This provides the entire Bitcoin
ecosystem—miners, wallet providers, exchanges, and users—with a realistic
and achievable schedule for a complete and secure migration. It avoids the
extreme risks of a rushed implementation, which could lead to critical
vulnerabilities, and instead fosters a deliberate, stable, and globally
coordinated upgrade. Our proposal is not a duplicate; it is a necessary
correction towards a timeline that prioritizes Bitcoin's long-term
cryptographic integrity over the speculative urgency of a private entity.
*Response to ArmchairCryptologist:*
Thank you for sharing the preprint by Dallaire-Demers et al., co-authored
by the Pauli Group. While their analysis of ECDLP challenges is a valuable
contribution to the field, their projected timeline for Cryptographically
Relevant Quantum Computers (CRQCs) in the 2027–2033 window is highly
speculative and built on a series of aggressive, unproven assumptions
regarding error correction and hardware scalability.
From a Bitcoin protocol perspective, our migration strategy must be
grounded in conservative, internationally-vetted standards, not optimistic
forecasts. The NIST Internal Report 8547 provides the definitive framework
for this transition. It explicitly states that the migration to
Post-Quantum Cryptography (PQC) is unprecedented in scale and will demand
substantial effort across diverse infrastructures, with a holistic target
for completion set for 2035 [NIST.IR.8547.ipd, p.8, 18]. This timeline is
not arbitrary; it is based on a comprehensive assessment of the immense
engineering challenges, the need for global standards coordination, and the
integration complexity across the entire cryptographic ecosystem—from
hardware modules and software libraries to network protocols and PKI
[NIST.IR.8547.ipd, p.12-13].
Furthermore, NIST cautions that migration timelines may vary based on use
case, but the 2035 target balances the urgency of the quantum threat with
the "practical challenges that different sectors face during this
transition" [NIST.IR.8547.ipd, p.18]. The Pauli Group's alarmist stance,
which suggests a much earlier doomsday scenario, appears commercially
motivated to push for a rushed adoption of their proposed standards. For
Bitcoin, a measured transition aligned with NIST's 2035 horizon ensures we
prioritize cryptographic integrity and ecosystem-wide stability over the
speculative and potentially self-serving timelines of private entities. Our
foundation's proposed BIP targets a full sunset of ECDSA by approximately
2035, a timeline that is both prudent and aligned with global standards
body guidance.
*Response to Alex Pruden:*
We appreciate you referencing the rigorous work by Gheorghiu and Mosca on
quantum resource estimation. Their findings are indeed important for
understanding the theoretical boundaries of quantum attacks. However, it is
critical to distinguish between asymptotic resource estimates and the
practical, engineering-heavy path to building a fault-tolerant CRQC.
NIST's transition plan, as outlined in IR 8547, is predicated on this very
distinction. The report emphasizes that the transition is starting now
precisely because of the "harvest now, decrypt later" threat, acknowledging
the risk to long-term data confidentiality [NIST.IR.8547.ipd, p.8].
However, for authentication—which is the primary function of digital
signatures in Bitcoin—the threat model is different. NIST states that
"authentication systems may continue to use quantum-vulnerable algorithms
until quantum computers... become available, at which point authentication
using these algorithms will need to be disabled" [NIST.IR.8547.ipd,
p.14-15]. This allows for a managed, rather than panicked, transition.
The 2035 target date for federal systems, referenced from NSM-10, is cited
in the NIST report as a primary goal, but it is presented with the
understanding that it must accommodate "legacy constraints or lower risk
profiles" and that flexibility is essential [NIST.IR.8547.ipd, p.18]. For a
decentralized system like Bitcoin, this flexibility is paramount. Rushing a
transition based on optimistic hardware projections introduces more risk
than it mitigates, potentially compromising security through improper
implementation. Therefore, the Bitcoin Foundation's strategy is to target a
full, ecosystem-wide transition by ~2035, ensuring a robust and thoroughly
vetted integration of a NIST-standardized PQC algorithm (like the
hash-based SLH-DSA in FIPS 205), in line with the comprehensive and
cautious approach advocated by NIST.
On Thursday, August 21, 2025 at 2:07:30 AM UTC+2 Alex Pruden wrote:
> I consider the recent work by Mosca et al to be the most up-to-date in
> terms of research estimation:
> https://www.sciencedirect.com/science/article/pii/S0167739X24004308
>
> The estimate he provides is approximately an order of magnitude less work
> required to break ECDSA (P-256) vs RSA-2048. Ironically, the longer
> bit-lengths of RSA seem to actually contribute to post-quantum security,
> even though the motivation for moving from RSA-1024 was to protect against
> NFS and other classical attacks against shorter RSA instances.
>
> Note that the resource estimation in the paper doesn't account for
> Gidney's speedup, which was 20x reduction in qubits required. It's unclear
> whether that same improvement factor could be applied here; as the Gidney
> paper showed, the earliest CRQCs will probably be hardwired for certain
> circuits for performance reasons. E.g. Gidney's circuit layout works for
> RSA-2048 and that's it. But the ideas he presents around error correction
> (e.g. the yoked surface code) might apply more broadly, it's hard to say.
>
> Also note that many of his assumptions are based on a superconducting
> architecture, which generally have faster runtimes but lower stability (so
> scaling is harder)
>
> Other architectures like this one https://arxiv.org/pdf/2506.20660 from
> the neutral atom community have slower runtimes but greater stability. But
> even if you scale, it probably only works for targeted, long-range attacks
> vs specific PKs as a CRQC.
>
> Lots of variables to consider here in terms of estimating the timeline for
> a CRQC, but the proactive approach is probably the right one, because (to
> quote Gidney in his conclusion) we should "*prefer security to not be
> contingent on progress being slow.*"
>
> On Tuesday, August 12, 2025 at 3:04:32 AM UTC-6 ArmchairCryptologist wrote:
>
>>
>> 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/ec2153e6-7cf5-400c-8964-e2a9269777a5n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 12941 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2025-08-22 22:05 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-08-07 18:18 [bitcoindev] [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin 'Bitcoin Foundation' via Bitcoin Development Mailing List
2025-08-09 1:04 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
2025-08-09 5:26 ` 'Bitcoin Foundation' via Bitcoin Development Mailing List
2025-08-09 19:38 ` 'ArmchairCryptologist' via Bitcoin Development Mailing List
2025-08-12 22:47 ` 'Bitcoin Foundation' via Bitcoin Development Mailing List
2025-08-20 20:15 ` 'ArmchairCryptologist' via Bitcoin Development Mailing List
2025-08-20 20:07 ` Alex Pruden
2025-08-21 20:21 ` 'Bitcoin Foundation' via Bitcoin Development Mailing List
2025-08-20 17:14 ` [bitcoindev] " Murch
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox