path: root/41/3b23d23f3e323b4d1246a26995666830f1a144

Delivery-date: Fri, 08 Aug 2025 19:06:18 -0700
Received: from mail-ot1-f60.google.com ([209.85.210.60])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCL7RHHJZYJBBDW23LCAMGQEDLF2IVQ@googlegroups.com>)
	id 1ukYyP-0005jb-1U
	for bitcoindev@gnusha.org; Fri, 08 Aug 2025 19:06:18 -0700
Received: by mail-ot1-f60.google.com with SMTP id 46e09a7af769-7414c004848sf4949535a34.0
        for <bitcoindev@gnusha.org>; Fri, 08 Aug 2025 19:06:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1754705170; x=1755309970; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:x-original-sender
         :mime-version:subject:references:in-reply-to:message-id:to:from:date
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Fe8lGf5CuRDe/a9TsPeJz0zhkdlYz1EB2vKE5oW3JI8=;
        b=gTOfqi488iOZusFTmAXoTrdMYTagF1M1QEaCLW+haIqlk1d4XDkxpV+ZdYaHt9Ib10
         mdAoiEskpyyvYnzoMuErGBxmuFvIPlLOJOMVKRFpK92bdmN8UjQt6Gl0tEefUd7ESRFp
         LyfJR/E63iT7xLrn1rQhCu3YHFENXzai+3urbELISRbtQ8rMlJm9w1W1ZWU9yO1ALY2B
         RK7SZD9IsALEW8VQ97HFWm+2q0PtZxUkcXbB1Ps3UsfpUU4AVDVo5fcoGNZ3nqOCu7iw
         Nfk3AJHdfphIo2jQ4Oi3G1dIkq3lnh1jyg6wzWPSL/6ocZqSdb3VJjADkOKksbStOk3l
         vGYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1754705170; x=1755309970;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:x-original-sender
         :mime-version:subject:references:in-reply-to:message-id:to:from:date
         :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Fe8lGf5CuRDe/a9TsPeJz0zhkdlYz1EB2vKE5oW3JI8=;
        b=bvO26eamXdXV7I31vWnX8Mlvs+cTyx6mIsLWa8zj3kPi1hRHitAMKD8vU96QuJ0CJm
         TbQ15rCKXiiEovYfKjkp3SfFrlmvzpr57pKvdMM72lVyO7zSdXCse55sljI0T90HRh5P
         R589M50unXzwJlW0vQycR+GCFl8CRa+6T2kXsB5PV22S3n9SwRWJyHMFGc9dDNj1BV9w
         JyqPisBQ7A4rFfSAAMP+LAyNSxxoESfU2H/jyG9Gq6UK02jDP8Er753pMlG3BDr59ZVl
         MgS3XxcdzBtvky5YwjCJffo2NfJgz/RiCM9oYEuQLlPenAvv6EPDYRAZWwEeu9n054XX
         UwpA==
X-Forwarded-Encrypted: i=1; AJvYcCWWqOUwv4CxqFe3VfNKQ4uRLQEGOpTQBLxtwrNify25KqX/9HCv73OliOgSVOuy8ktVvj68mPgJTG3l@gnusha.org
X-Gm-Message-State: AOJu0Yz0uZFNNNR7RPHM+K+NmB7rtkaz+wGG4aTfsHx89sUZGDhJ/FcO
	t/WX9OSKfn2KMHip6E5kqUzIIaEIg5GD06zR8wIYBRdGbCb8PgM+aKW/
X-Google-Smtp-Source: AGHT+IET7MZ6jvMJEhTbRnvtGrTJJpBtGyB6qbcRP2RRkeyh3K09ZTndlVl052EYrR7gZidBMBYRMQ==
X-Received: by 2002:a05:6830:19f3:b0:741:c2be:c6f6 with SMTP id 46e09a7af769-7432c91d051mr2405368a34.22.1754705170505;
        Fri, 08 Aug 2025 19:06:10 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdYNemaby5T/zvLJy3vdI5iXfPiMJaFP8/vmBT7F5+pSw==
Received: by 2002:a05:6870:7057:b0:30b:85bc:4baf with SMTP id
 586e51a60fabf-30bfe40e974ls839689fac.0.-pod-prod-07-us; Fri, 08 Aug 2025
 19:06:06 -0700 (PDT)
X-Received: by 2002:a05:6808:1b0e:b0:41b:f2a0:28f7 with SMTP id 5614622812f47-43597ebad34mr3025102b6e.36.1754705166558;
        Fri, 08 Aug 2025 19:06:06 -0700 (PDT)
Received: by 2002:a05:690c:2605:b0:718:5fd:a4e7 with SMTP id 00721157ae682-71bf1a7df88ms7b3;
        Fri, 8 Aug 2025 18:04:28 -0700 (PDT)
X-Received: by 2002:a05:690c:3684:b0:71b:f83a:afa0 with SMTP id 00721157ae682-71bf83ab218mr48871147b3.22.1754701467488;
        Fri, 08 Aug 2025 18:04:27 -0700 (PDT)
Date: Fri, 8 Aug 2025 18:04:27 -0700 (PDT)
From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <fff86606-d6ce-4319-a341-90e9c4eba49dn@googlegroups.com>
In-Reply-To: <4d6ecde7-e959-4e6c-a0aa-867af8577151n@googlegroups.com>
References: <4d6ecde7-e959-4e6c-a0aa-867af8577151n@googlegroups.com>
Subject: [bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition Framework
 for Bitcoin
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_113900_1567383867.1754701467032"
X-Original-Sender: conduition@proton.me
X-Original-From: conduition <conduition@proton.me>
Reply-To: conduition <conduition@proton.me>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -1.0 (-)

------=_Part_113900_1567383867.1754701467032
Content-Type: multipart/alternative; 
	boundary="----=_Part_113901_1324720015.1754701467032"

------=_Part_113901_1324720015.1754701467032
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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


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

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

regards,
conduition


[0]: https://arxiv.org/pdf/quant-ph/0301141 (see section 6.2)
[1]: https://en.wikipedia.org/wiki/Shor%27s_algorithm
[2]: https://bitcoin.stackexchange.com/questions/118928/what-does-it-mean-t=
hat-the-security-of-bitcoin-public-keys-and-256-bit-ecdsa-is/
[3]: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf
[4]: https://sqisign.org/
[5]: https://gist.github.com/conduition/469725009397c08a2d40fb87c8ca7baa
[6]: https://pypi.org/project/PySPX/#history
[7]: https://github.com/bitcoin/bips/pull/1670
[8]: https://groups.google.com/g/bitcoindev/c/uEaf4bj07rE/m/0Facb-SvBwAJ


On Thursday, August 7, 2025 at 5:26:07=E2=80=AFPM UTC-7 Bitcoin Foundation =
wrote:

> BIP: TBD
> Layer: Consensus (soft fork)
> Title: Quantum-Resistant Transition Framework for Bitcoin=20
> Author: Bitcoin Post-Quantum Working Group <pq-re...@bitcoin.foundation>
> Status: Draft=20
> Type: Standards Track=20
> Created: 2025-08-07
> License: MIT
> Requires: BIP-340, BIP-341
>
> =3D=3D ABSTRACT =3D=3D
> This proposal defines a backward-compatible, time-bound migration path to=
=20
> quantum-resistant (QR) cryptography for Bitcoin. Through phased deprecati=
on=20
> of ECDSA/Schnorr signatures and mandatory adoption of NIST-standardized=
=20
> post-quantum algorithms, it ensures Bitcoin's survival against quantum=20
> attacks while minimizing disruption to existing infrastructure.
>
> =3D=3D MOTIVATION =3D=3D
> *Quantum Threat Assessment*
> - PUBLIC KEY EXPOSURE: 25% of Bitcoin's UTXO set (~$150B as of 2025) is=
=20
> vulnerable to Shor's algorithm due to exposed public keys (P2PK, reused=
=20
> addresses)
> - ALGORITHMIC ACCELERATION: Google's 2024 trapped-ion breakthrough=20
> demonstrated 99.99% gate fidelity with 50 logical qubits - sufficient to=
=20
> break 256-bit ECDSA in <8 hours
> - STEALTH ATTACK VECTORS: Quantum adversaries could precompute keys and=
=20
> execute timed thefts during mempool propagation
>
> *Fundamental ECDSA Vulnerability*
> ECDSA security relies on the Elliptic Curve Discrete Logarithm Problem=20
> (ECDLP). Shor's quantum algorithm solves it in O((log n)=C2=B3) time:
> 1. For secp256k1: n =E2=89=88 2=C2=B2=E2=81=B5=E2=81=B6
> 2. Classical security: 128-bit
> 3. Quantum security: 0-bit (broken by Shor)
> 4. Critical exposure: Any public key revealed becomes immediately=20
> vulnerable
>
> *Consequences of Inaction*
> - WEALTH DESTRUCTION: Single theft event could permanently erode trust
> - COORDINATION TRAP: Delayed action risks chaotic emergency hard forks
> - SYSTEMIC COLLAPSE: Quantum break would invalidate Bitcoin's security=20
> model
>
> =3D=3D SPECIFICATION =3D=3D
> *Phase 1: QR Adoption (0-2 years)*
> - Soft-fork activation of QR witness programs (SegWit v3+)
> - New outputs must use OP_CHECKSIG_PQ
> - Classical scripts marked as deprecated
>
> *Phase 2: Legacy Deprecation (5 years)*
> - Creating new classical UTXOs becomes non-standard
> - Wallets default to QR outputs with warnings for classical sends
> - Economic incentive: QR transactions get priority mempool treatment
>
> *Phase 3: Classical Sunset (Block 1,327,121 ~8 years)*
> - Consensus-enforced rejection of classical script spends
> - Frozen UTXOs permanently unspendable (supply reduction)
> - Emergency override: 95% miner vote can delay by 52-week increments
>
> *Phase 4: Recovery Mechanism (Optional)*
> - ZK-proof system for reclaiming frozen funds via:
>   =E2=80=A2 Proof of BIP-39 seed knowledge
>   =E2=80=A2 Time-locked quantum-resistant scripts
> - Requires separate BIP after 3+ years cryptanalysis
>
> =3D=3D RATIONALE =3D=3D
> *Why Phased Approach?*
> - MARKET CERTAINTY: Fixed timeline eliminates "wait-and-see" stagnation
> - PROGRESSIVE PRESSURE: Gradual restrictions avoid shock transitions
> - SUNK COST PRINCIPLE: Users ignoring 3+ years of warnings assume=20
> responsibility
>
> *Why Freeze Legacy UTXOs?*
> - Prevents quantum arms race for exposed coins
> - Preserves Bitcoin's "lost coins" scarcity principle
> - Avoids centralized redistribution committees
> - Eliminates moral hazard of rewarding late migrators
> - Reduces quantum attack surface
>
> *Algorithm Choice: SPHINCS+-SHAKE256f (SLH-DSA-SHAKE-256f)*
> SECURITY PARAMETERS:
>   n: 256
>   Hash: SHAKE256
>   Classical Security: 2=C2=B2=E2=81=B5=E2=81=B6
>   Quantum Security: 2=C2=B9=C2=B2=E2=81=B8
>   Private Key: 128 bytes
>   Public Key: 64 bytes
>   Signature: 49,856 bytes
>
> QUANTUM ATTACK RESISTANCE:
> | Attack Type         | Standard Bitcoin | This System   | Security Facto=
r=20
> |
>
> |---------------------|------------------|---------------|---------------=
--|
> | Shor's Algorithm    | Broken           | Not applicable| =E2=88=9E     =
         =20
> |
> | Grover's Algorithm  | O(2=C2=B9=C2=B2=E2=81=B8)         | O(2=E2=81=B5=
=C2=B9=C2=B2)      | 2=C2=B3=E2=81=B8=E2=81=B4 advantage  |
> | Collision Search    | O(2=E2=81=B8=E2=81=B5)          | O(2=E2=81=B8=E2=
=81=B5)       | Equivalent      |
>
> KEY SECURITY (SK 128 bytes):
> - Private key entropy: 1024 bits (2=C2=B9=E2=81=B0=C2=B2=E2=81=B4 possibi=
lities)
> - Quantum brute-force: =E2=88=9A(2=C2=B9=E2=81=B0=C2=B2=E2=81=B4) =3D 2=
=E2=81=B5=C2=B9=C2=B2 =E2=89=88 10=C2=B9=E2=81=B5=E2=81=B4 operations
> - Time required at 1 quintillion ops/sec (10=C2=B9=E2=81=B8): 10=C2=B9=C2=
=B3=E2=81=B6 seconds =E2=89=88 3 =C3=97 10=C2=B9=C2=B2=E2=81=B8=20
> years
>
> SEED SECURITY (SEED 96 bytes):
> - Possible seeds: 2=E2=81=B7=E2=81=B6=E2=81=B8 =E2=89=88 10=C2=B2=C2=B3=
=C2=B9 =20
> - Quantum brute-force: =E2=88=9A(2=E2=81=B7=E2=81=B6=E2=81=B8) =3D 2=C2=
=B3=E2=81=B8=E2=81=B4 =E2=89=88 10=C2=B9=C2=B9=E2=81=B5 operations =20
> - Time required at 1 billion ops/sec: 10=C2=B9=E2=81=B0=E2=81=B6 seconds =
=E2=89=88 3 =C3=97 10=E2=81=B9=E2=81=B8 years
>
> INFORMATION THEORETIC ADVANTAGES:
> - Each signature reveals 4 bits of private key material
> - After 20 signatures:
>   =E2=80=A2 ECDSA: Private key fully compromised
>   =E2=80=A2 SPHINCS+: 80 bits revealed (7.81% of key)
>   =E2=80=A2 Security margin remains: 944 bits (92.19%)
>
> =3D=3D BACKWARD COMPATIBILITY =3D=3D
> Phase | Legacy Wallets       | QR Wallets
> ------|---------------------|------------------------
> 1     | Full functionality  | Can receive/send both types
> 2     | Can only send to QR | Full functionality
> 3+    | Frozen funds        | Only QR transactions valid
>
> =3D=3D DEPLOYMENT =3D=3D
> Activation Mechanism:
> - Speedy Trial (BIP-8) with 18-month timeout
> - 90% miner signaling threshold
>
> Monitoring:
> - QR adoption metrics published quarterly
> - Sunset delay requires proof of:
>   =E2=80=A2 <70% exchange/wallet adoption
>   =E2=80=A2 Fundamental flaws in NIST PQC standards
>
> =3D=3D STAKEHOLDER IMPACT =3D=3D
> Group           | Action Required               | Timeline
> ----------------|-------------------------------|-------------------
> Miners          | Upgrade nodes for QR rules    | Phase 1 activation
> Exchanges       | Implement QR withdrawals     | Within 18 months of Phas=
e=20
> 1
> Hardware Wallets| Firmware updates for QR sigs | Before Phase 2
> Light Clients   | SPV proofs for QR scripts    | Phase 3 readiness
>
> =3D=3D REFERENCES =3D=3D
> - SPHINCS+ Implementation:=20
> https://github.com/bitcoin-foundation/Quantum-Resistant-Bitcoin
> - (FIPS 205) SLH-DSA:=20
> https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf
> - Schnorr Signatures: BIP-0340
>
> =3D=3D COPYRIGHT =3D=3D
> MIT License
>
> ---
>
>
> This BIP presents an alternative quantum-resistant migration approach,=20
> primarily distinguished by its extended transition timeline to facilitate=
=20
> more comprehensive ecosystem adaptation.
>
> Key features:
> - Includes reference implementation of SPHINCS+-SHAKE256f=20
> (SLH-DSA-SHAKE-256f)
> - Provides comparative analysis against Bitcoin's current ECDSA scheme
> - Detailed technical specifications:
> https://github.com/bitcoin-foundation/Quantum-Resistant-Bitcoin
>
> Formatting note: This BIP draft prioritizes technical accuracy over visua=
l=20
> polish. After incorporating feedback from this discussion, the final=20
> version will be published to GitHub with proper Markdown formatting.
>
> Feedback welcome from wallet developers, exchanges, miners, and security=
=20
> researchers.
>

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

------=_Part_113901_1324720015.1754701467032
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I appreciate your enthusiasm for quantum resilience, but there are many thi=
ngs wrong with this proposal.=C2=A0<br /><div><br /></div><div><br /></div>=
<div>- <i>"50 logical qubits - sufficient to break 256-bit ECDSA"</i> - The=
 number of logical qubits required to break 256-bit ECC discrete log is on =
the order of thousands or millions, and nobody is even close yet. AFAIK the=
 best known algorithm requires about 1536 qubits [0]. Please cite sources i=
f you have been informed otherwise.</div><div>- <i>"0-bit security"</i> ROF=
L, what does that even mean? Also you have the wrong big-O complexity for S=
hor's algorithm [1]</div><div>- The 256-bit flavors of SLH-DSA are overkill=
. Bitcoin addresses are already fundamentally limited to 128 bits of securi=
ty (a little less, actually) under a naive SHA256 or secp256k1 birthday att=
ack. [2] Trying to add more is unnecessary, especially given the YUGE signa=
tures required.</div><div>- This proposal completely ignores other promisin=
g new cryptographic signing algorithms like ML-DSA [3] and SQISign [4] whic=
h would be needed for low-latency resource-constrained environments like LN=
 nodes.</div><div>- Freezing UTXOs without some sort of unlocking path bake=
d-in ahead of time will cause a hard fork if we ever want to rescue them in=
 the future. This has been discussed on prior threads. [8]</div><div>- <i>"=
Each signature reveals 4 bits of private key material"</i>, that is not how=
 SLH-DSA works. Each signature reveals some deterministically derived preim=
ages, and commits to them in a carefully chosen chain of OTS certification =
signatures. The algorithm guarantees the probability of successful forgery =
stays below a certain threshold for up to `m` messages. In NIST SLH-DSA, m =
=3D 2^64. For the math see this script [5].</div><div>- Your "SPHINCS+ impl=
ementation" is just a wrapper around the python 'pyspx' package from PyPi w=
ith some encoding mechanisms sprinkled on top. The `pyspx` module was last =
updated three years ago [6] and SLH-DSA was only fully standardized two yea=
rs ago, so your code is actually non-compliant with your own proposal.</div=
><div>- <i>"This BIP draft prioritizes technical accuracy over visual polis=
h"</i>. I think i'll stop now.</div><div><br /></div><div>If you're interes=
ted in meaningfully contributing to upgrading Bitcoin to be quantum resilie=
nt, I would suggest you stop trying to write your own spec single-handed, a=
nd start by reviewing BIP360 [7] and reading mailing list archives on post =
quantum upgrade proposals. There have been many...</div><div><br /></div><d=
iv>regards,</div><div>conduition</div><div><br /></div><div><br /></div><di=
v>[0]:=C2=A0https://arxiv.org/pdf/quant-ph/0301141 (see section 6.2)</div><=
div>[1]:=C2=A0https://en.wikipedia.org/wiki/Shor%27s_algorithm</div><div>[2=
]:=C2=A0https://bitcoin.stackexchange.com/questions/118928/what-does-it-mea=
n-that-the-security-of-bitcoin-public-keys-and-256-bit-ecdsa-is/</div><div>=
[3]:=C2=A0https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf</div><di=
v>[4]:=C2=A0https://sqisign.org/</div><div>[5]:=C2=A0https://gist.github.co=
m/conduition/469725009397c08a2d40fb87c8ca7baa</div><div>[6]:=C2=A0https://p=
ypi.org/project/PySPX/#history</div><div>[7]:=C2=A0https://github.com/bitco=
in/bips/pull/1670</div><div>[8]:=C2=A0https://groups.google.com/g/bitcoinde=
v/c/uEaf4bj07rE/m/0Facb-SvBwAJ</div><div><br /></div><div><br /></div><div =
class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Thursday, A=
ugust 7, 2025 at 5:26:07=E2=80=AFPM UTC-7 Bitcoin Foundation wrote:<br/></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-l=
eft: 1px solid rgb(204, 204, 204); padding-left: 1ex;">BIP: TBD<br>Layer: C=
onsensus (soft fork)<br>Title: Quantum-Resistant Transition Framework for B=
itcoin <br>Author: Bitcoin Post-Quantum Working Group &lt;pq-re...@bitcoin.=
foundation&gt;<br>Status: Draft <br>Type: Standards Track <br>Created: 2025=
-08-07<br>License: MIT<br>Requires: BIP-340, BIP-341<br><br>=3D=3D ABSTRACT=
 =3D=3D<br>This proposal defines a backward-compatible, time-bound migratio=
n path to quantum-resistant (QR) cryptography for Bitcoin. Through phased d=
eprecation of ECDSA/Schnorr signatures and mandatory adoption of NIST-stand=
ardized post-quantum algorithms, it ensures Bitcoin&#39;s survival against =
quantum attacks while minimizing disruption to existing infrastructure.<br>=
<br>=3D=3D MOTIVATION =3D=3D<br>*Quantum Threat Assessment*<br>- PUBLIC KEY=
 EXPOSURE: 25% of Bitcoin&#39;s UTXO set (~$150B as of 2025) is vulnerable =
to Shor&#39;s algorithm due to exposed public keys (P2PK, reused addresses)=
<br>- ALGORITHMIC ACCELERATION: Google&#39;s 2024 trapped-ion breakthrough =
demonstrated 99.99% gate fidelity with 50 logical qubits - sufficient to br=
eak 256-bit ECDSA in &lt;8 hours<br>- STEALTH ATTACK VECTORS: Quantum adver=
saries could precompute keys and execute timed thefts during mempool propag=
ation<br><br>*Fundamental ECDSA Vulnerability*<br>ECDSA security relies on =
the Elliptic Curve Discrete Logarithm Problem (ECDLP). Shor&#39;s quantum a=
lgorithm solves it in O((log n)=C2=B3) time:<br>1. For secp256k1: n =E2=89=
=88 2=C2=B2=E2=81=B5=E2=81=B6<br>2. Classical security: 128-bit<br>3. Quant=
um security: 0-bit (broken by Shor)<br>4. Critical exposure: Any public key=
 revealed becomes immediately vulnerable<br><br>*Consequences of Inaction*<=
br>- WEALTH DESTRUCTION: Single theft event could permanently erode trust<b=
r>- COORDINATION TRAP: Delayed action risks chaotic emergency hard forks<br=
>- SYSTEMIC COLLAPSE: Quantum break would invalidate Bitcoin&#39;s security=
 model<br><br>=3D=3D SPECIFICATION =3D=3D<br>*Phase 1: QR Adoption (0-2 yea=
rs)*<br>- Soft-fork activation of QR witness programs (SegWit v3+)<br>- New=
 outputs must use OP_CHECKSIG_PQ<br>- Classical scripts marked as deprecate=
d<br><br>*Phase 2: Legacy Deprecation (5 years)*<br>- Creating new classica=
l UTXOs becomes non-standard<br>- Wallets default to QR outputs with warnin=
gs for classical sends<br>- Economic incentive: QR transactions get priorit=
y mempool treatment<br><br>*Phase 3: Classical Sunset (Block 1,327,121 ~8 y=
ears)*<br>- Consensus-enforced rejection of classical script spends<br>- Fr=
ozen UTXOs permanently unspendable (supply reduction)<br>- Emergency overri=
de: 95% miner vote can delay by 52-week increments<br><br>*Phase 4: Recover=
y Mechanism (Optional)*<br>- ZK-proof system for reclaiming frozen funds vi=
a:<br>=C2=A0 =E2=80=A2 Proof of BIP-39 seed knowledge<br>=C2=A0 =E2=80=A2 T=
ime-locked quantum-resistant scripts<br>- Requires separate BIP after 3+ ye=
ars cryptanalysis<br><br>=3D=3D RATIONALE =3D=3D<br>*Why Phased Approach?*<=
br>- MARKET CERTAINTY: Fixed timeline eliminates &quot;wait-and-see&quot; s=
tagnation<br>- PROGRESSIVE PRESSURE: Gradual restrictions avoid shock trans=
itions<br>- SUNK COST PRINCIPLE: Users ignoring 3+ years of warnings assume=
 responsibility<br><br>*Why Freeze Legacy UTXOs?*<br>- Prevents quantum arm=
s race for exposed coins<br>- Preserves Bitcoin&#39;s &quot;lost coins&quot=
; scarcity principle<br>- Avoids centralized redistribution committees<br>-=
 Eliminates moral hazard of rewarding late migrators<br>- Reduces quantum a=
ttack surface<br><br>*Algorithm Choice: SPHINCS+-SHAKE256f (SLH-DSA-SHAKE-2=
56f)*<br>SECURITY PARAMETERS:<br>=C2=A0 n: 256<br>=C2=A0 Hash: SHAKE256<br>=
=C2=A0 Classical Security: 2=C2=B2=E2=81=B5=E2=81=B6<br>=C2=A0 Quantum Secu=
rity: 2=C2=B9=C2=B2=E2=81=B8<br>=C2=A0 Private Key: 128 bytes<br>=C2=A0 Pub=
lic Key: 64 bytes<br>=C2=A0 Signature: 49,856 bytes<br><br>QUANTUM ATTACK R=
ESISTANCE:<br>| Attack Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Standard Bitcoin =
| This System =C2=A0 | Security Factor |<br>|---------------------|--------=
----------|---------------|-----------------|<br>| Shor&#39;s Algorithm =C2=
=A0 =C2=A0| Broken =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Not applicable| =E2=
=88=9E =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>| Grover&#39;s=
 Algorithm =C2=A0| O(2=C2=B9=C2=B2=E2=81=B8) =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =
O(2=E2=81=B5=C2=B9=C2=B2) =C2=A0 =C2=A0 =C2=A0| 2=C2=B3=E2=81=B8=E2=81=B4 a=
dvantage =C2=A0|<br>| Collision Search =C2=A0 =C2=A0| O(2=E2=81=B8=E2=81=B5=
) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| O(2=E2=81=B8=E2=81=B5) =C2=A0 =C2=A0 =
=C2=A0 | Equivalent =C2=A0 =C2=A0 =C2=A0|<br><br>KEY SECURITY (SK 128 bytes=
):<div>- Private key entropy: 1024 bits (2=C2=B9=E2=81=B0=C2=B2=E2=81=B4 po=
ssibilities)<br>- Quantum brute-force: =E2=88=9A(2=C2=B9=E2=81=B0=C2=B2=E2=
=81=B4) =3D 2=E2=81=B5=C2=B9=C2=B2 =E2=89=88 10=C2=B9=E2=81=B5=E2=81=B4 ope=
rations<br>- Time required at 1 quintillion ops/sec (10=C2=B9=E2=81=B8): 10=
=C2=B9=C2=B3=E2=81=B6 seconds =E2=89=88 3 =C3=97 10=C2=B9=C2=B2=E2=81=B8 ye=
ars</div><div><br>SEED SECURITY (SEED 96 bytes):<br>- Possible seeds: 2=E2=
=81=B7=E2=81=B6=E2=81=B8 =E2=89=88 10=C2=B2=C2=B3=C2=B9 =C2=A0<br>- Quantum=
 brute-force: =E2=88=9A(2=E2=81=B7=E2=81=B6=E2=81=B8) =3D 2=C2=B3=E2=81=B8=
=E2=81=B4 =E2=89=88 10=C2=B9=C2=B9=E2=81=B5 operations =C2=A0<br>- Time req=
uired at 1 billion ops/sec: 10=C2=B9=E2=81=B0=E2=81=B6 seconds =E2=89=88 3 =
=C3=97 10=E2=81=B9=E2=81=B8 years<br><br>INFORMATION THEORETIC ADVANTAGES:<=
br>- Each signature reveals 4 bits of private key material<br>- After 20 si=
gnatures:<br>=C2=A0 =E2=80=A2 ECDSA: Private key fully compromised<br>=C2=
=A0 =E2=80=A2 SPHINCS+: 80 bits revealed (7.81% of key)<br>=C2=A0 =E2=80=A2=
 Security margin remains: 944 bits (92.19%)<br><br>=3D=3D BACKWARD COMPATIB=
ILITY =3D=3D<br>Phase | Legacy Wallets =C2=A0 =C2=A0 =C2=A0 | QR Wallets<br=
>------|---------------------|------------------------<br>1 =C2=A0 =C2=A0 |=
 Full functionality =C2=A0| Can receive/send both types<br>2 =C2=A0 =C2=A0 =
| Can only send to QR | Full functionality<br>3+ =C2=A0 =C2=A0| Frozen fund=
s =C2=A0 =C2=A0 =C2=A0 =C2=A0| Only QR transactions valid<br><br>=3D=3D DEP=
LOYMENT =3D=3D<br>Activation Mechanism:<br>- Speedy Trial (BIP-8) with 18-m=
onth timeout<br>- 90% miner signaling threshold<br><br>Monitoring:<br>- QR =
adoption metrics published quarterly<br>- Sunset delay requires proof of:<b=
r>=C2=A0 =E2=80=A2 &lt;70% exchange/wallet adoption<br>=C2=A0 =E2=80=A2 Fun=
damental flaws in NIST PQC standards<br><br>=3D=3D STAKEHOLDER IMPACT =3D=
=3D<br>Group =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Action Required =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Timeline<br>----------------|--=
-----------------------------|-------------------<br>Miners =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0| Upgrade nodes for QR rules =C2=A0 =C2=A0| Phase 1 act=
ivation<br>Exchanges =C2=A0 =C2=A0 =C2=A0 | Implement QR withdrawals =C2=A0=
 =C2=A0 | Within 18 months of Phase 1<br>Hardware Wallets| Firmware updates=
 for QR sigs | Before Phase 2<br>Light Clients =C2=A0 | SPV proofs for QR s=
cripts =C2=A0 =C2=A0| Phase 3 readiness<br><br>=3D=3D REFERENCES =3D=3D<div=
>- SPHINCS+ Implementation: <a href=3D"https://github.com/bitcoin-foundatio=
n/Quantum-Resistant-Bitcoin" target=3D"_blank" rel=3D"nofollow" data-safere=
directurl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/=
bitcoin-foundation/Quantum-Resistant-Bitcoin&amp;source=3Dgmail&amp;ust=3D1=
754784423018000&amp;usg=3DAOvVaw3D1Zw8J769rTfGDzh_rMAv">https://github.com/=
bitcoin-foundation/Quantum-Resistant-Bitcoin</a><br>- (FIPS 205)=C2=A0SLH-D=
SA: <a href=3D"https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf" ta=
rget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google=
.com/url?hl=3Den&amp;q=3Dhttps://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.2=
05.pdf&amp;source=3Dgmail&amp;ust=3D1754784423019000&amp;usg=3DAOvVaw0UzcqN=
kCNeQ64aFs2hgo-J">https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf<=
/a></div><div>- Schnorr Signatures: BIP-0340<br><br>=3D=3D COPYRIGHT =3D=3D=
<br>MIT License<br><br>---</div><div><br></div><div><br>This BIP presents a=
n alternative quantum-resistant migration approach, primarily distinguished=
 by its extended transition timeline to facilitate more comprehensive ecosy=
stem adaptation.<br><br>Key features:<br>- Includes reference implementatio=
n of SPHINCS+-SHAKE256f (SLH-DSA-SHAKE-256f)<br>- Provides comparative anal=
ysis against Bitcoin&#39;s current ECDSA scheme<br>- Detailed technical spe=
cifications:<br><a href=3D"https://github.com/bitcoin-foundation/Quantum-Re=
sistant-Bitcoin" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D=
"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/bitcoin-foun=
dation/Quantum-Resistant-Bitcoin&amp;source=3Dgmail&amp;ust=3D1754784423019=
000&amp;usg=3DAOvVaw30a9QQmsv11zWLeHA1pjt9">https://github.com/bitcoin-foun=
dation/Quantum-Resistant-Bitcoin</a><br><br>Formatting note: This BIP draft=
 prioritizes technical accuracy over visual polish.=C2=A0After incorporatin=
g feedback from this discussion, the final version will be published to Git=
Hub with proper Markdown formatting.</div><div><br>Feedback welcome from wa=
llet developers, exchanges, miners, and security researchers.<br></div></di=
v></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/fff86606-d6ce-4319-a341-90e9c4eba49dn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/fff86606-d6ce-4319-a341-90e9c4eba49dn%40googlegroups.com</a>.<br />

------=_Part_113901_1324720015.1754701467032--

------=_Part_113900_1567383867.1754701467032--