Delivery-date: Mon, 15 Sep 2025 12:20:17 -0700 Received: from mail-oo1-f57.google.com ([209.85.161.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uyEkI-0007ou-BH for bitcoindev@gnusha.org; Mon, 15 Sep 2025 12:20:17 -0700 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-621cca96097sf2564280eaf.3 for ; Mon, 15 Sep 2025 12:20:14 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1757964008; cv=pass; d=google.com; s=arc-20240605; b=AOnFeICD624aPhffvkA2FVRbWGzHRQtMJY3P1Nh2mNS5Yy+lBdmmRYgLaGCosVB5yx DxvtKRugtV8p0hu6LyI6VD1GZ4qvmWFJ2fSwzoauD3XCtqmqZqUKT+M1nFhbLQtPAlJ8 Hl2zZrA9/M5mAHNQgILAEe5O8Z1M8izcFWmgFx9QLl6cCKSTUzuWvWt4RM47AkDNt7bH A9HPSK29udPPyjalwWyaqnpfQRADYqHyx/dz7Yzxme4lp8RCagb06/tE1cmbTMBbvNqW 84yUj5J9W69qcvU4Y/kk9fcfC1G+m52wkhVkJh7hMEn38CpxWX4Aq1ww4Doeg7aGuMoM Txvg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=75g5jCAKIsJxle3uFAdzcTu7bet/oMzJslIJ7jqxqEY=; fh=KAYY6IMHDatJlowA5fvJ16qMB48LdCeg9LN+HtPDVk0=; b=fUB7u38iR3MijXyy9sRATjriM9OaZnu72sckzbKZYWb+9xxGTRp7JPbdk76kNveHSt AwFuht9ta9Wd9QkORtGnNx+sHOR7rOnViybOks079/Y3gGft8JUff0CzWDfw2jA4/dyu sIJGZKkO5ZL9rlaUiwvAMEoYzHpHl2p/r9ZwuZmXEOIWAGQ6P+zFAPgbbUVGeueDGi0U iyf63Jn8kxNbYA3hLj1rhJ8bbdktCS1iMRjQXzXIXOsAYWLFUvAZIIU2QVJB6YI/DViB DqoCqnxDS5JtIDeXUAb/IAn5giRQNjmKzWXYVvct/deZwOGeLNgkH81Rswtygy0Uy64u 7LSQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=ddlcz5f7mna3tfqsmgyxire5ee.protonmail header.b=kDmDoqV9; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.16 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1757964008; x=1758568808; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=75g5jCAKIsJxle3uFAdzcTu7bet/oMzJslIJ7jqxqEY=; b=mjwHfO1oTvRG7BD3aR4bLCZ2XPpM4su1NQm/3FERG8iW92LL/dMYkQ8DVw+N/dYKSg 9KX+GyNYNyU3XtfV6ys0hrK7c6wnoPE6H1Df3hkYQQE50duTv3Icdll4KgXHagqVKzGv LDBADiUUBzcpBSUjn3Pu5KhDwI/y76wsyOu561BgQOfzQCuZvf0tvo9rfRE8zxnsb/uF uW8AY0tYWc0wFEz6EwubNHNzLGatgLXwiBstgLbpjH6BayoYRhfbsEbtGmtBz8y+Y7f3 IRIAcwOlhnjDKYf0mL/Wj3KQx8BBM7hdJzy7V/RU4PF6ONUsNXTHsvd/cU3xBVAkknRi UX9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757964008; x=1758568808; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=75g5jCAKIsJxle3uFAdzcTu7bet/oMzJslIJ7jqxqEY=; b=TsLJDy+ac6sxhjjjwfExnNj3Al32mVE4wyqtFuPhMV55ZWJvYFh/UYkFnZGtbIcD6b 5p1PeX2xRqik38YPtts8et1jhHiLD5x2vIHaoV0O0HClBizrIydKZEXFDQzsbfC5rGqf 1GvGxs6bTXCHqInHGWlO9vSXLHCCF3Laivl3hjc0MRtU5MDGMfOTItIwHi4eG6nHWT6t y8LEYoKopa+xN2vxs+Csj3rV2/0utwg6Gb5XjMCi/41suAP1LmBbK+45RzI1kJF/hdJM 5Ylp2OEGYjHJK8/Bx3Ompmon+HTQy/bkNiQllUOeU5C3lTuUbSVOM+oMKyPhdOtyIRPo nTOw== X-Forwarded-Encrypted: i=2; AJvYcCU1v9+IFCvzC+sqZnZcqjA3GW9xZr8AZBHg0NYRLgFMnkO+s0vpFHpMZaaHje+0fhqwRBYKfHkX7ZKo@gnusha.org X-Gm-Message-State: AOJu0YxpFZSf5EcVFOkKCiR6m5JDogfrL/SGK4HE/2H2vdWaJPhrK3QD JBuJnU5hQFitjBlLiF7EOIw/8MyiCF7+wMFVxzlxseZJ+6jTNKXfNPXO X-Google-Smtp-Source: AGHT+IGuTJsm5eM8XB353UBUmcMbU64v7QH5suDpIX6rfDUrCRaxnLyTlUAgvObsROPPudKgpWr78A== X-Received: by 2002:a05:6820:1687:b0:621:ad4d:8097 with SMTP id 006d021491bc7-621bedd833dmr7022173eaf.6.1757964007413; Mon, 15 Sep 2025 12:20:07 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZd7Y1+wJutjoTmjhJ9GtMzCBQbt5i5fgmic2cwh94+zPA== Received: by 2002:a05:6820:1f90:b0:621:a2f1:abe6 with SMTP id 006d021491bc7-621b45347c9ls1326011eaf.2.-pod-prod-08-us; Mon, 15 Sep 2025 12:20:03 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCV7ecQjMpy4k5IgDmpzZFoiWqJq5mnE0YXTxtvGZAvObG2em63Q1Y1OK+XGHXjrgWFE/CuNE/NpAfol@googlegroups.com X-Received: by 2002:a05:6808:130c:b0:43d:2cc3:2e07 with SMTP id 5614622812f47-43d2cc334f1mr1904345b6e.15.1757964003773; Mon, 15 Sep 2025 12:20:03 -0700 (PDT) Received: by 2002:ab3:489c:0:b0:2c3:d086:1a03 with SMTP id a1c4a302cd1d6-2c574737c7amsc7a; Mon, 15 Sep 2025 09:24:43 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWMhaMfpgOKwcx8bPMi+hBZ5a00uva7e5qkddJOLN5G3L6drel+1ki2T+6DqTZUugR2Wp835oRH7W0o@googlegroups.com X-Received: by 2002:a05:6512:1597:b0:55f:4ab0:79a7 with SMTP id 2adb3069b0e04-5704aa9fe9bmr4444988e87.7.1757953480452; Mon, 15 Sep 2025 09:24:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1757953480; cv=none; d=google.com; s=arc-20240605; b=NO5XRbsEAcrVvJn8xKyGDjPCD/cpFPbbwY7xxUNoZAS4SpDqhb7uiwG3qzx9DRuX8M CqHv9/V0byOQVbgGJ2+1hXq1SsfshetU5GHqLg/sKeTsYBoZHm/hAZjLPeeD9xl28qMa yD+LsSfADqhaTGzBvM4lJrb7SFXMMFz2GiK8A/tNTy1vz92B20FGOKxwftcTbcr2tOzp NTviPI5aiR+pBFbS6PWImu1gIVMtowJpLAJKq3tIT4rkLpCtAqOtSSuaojB1vtquUOso q798+R/hTvVj2pIofxoGFfoa/JVk+CBxz0p4rLD1kKAO3ksRxtW30lpavVxvdjyPhCGY oX4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=dXCOmGJxVJFfaSRPfgxqDV7ELEJbCN+/LCY6eSTizp0=; fh=I4bnjYRpGdVsfDIeD/w7kPqXuiSHPf5UhzWGw0Jx6U0=; b=dIm1GGfuCIFKPOzOgWoSGNsw6xrT3WUS6htUr0TFHH84YXSfHz8ELjkPLXm7KICj7x SgZKx0VwDtUO9QP9bIYuRr9DALsg5723E49s0LhF22sCBc0uloRQTZCodJQQ9s1uC2sy S6s+AXLC2OFe2+h87RQRDo/p1bi4g14wbCUV1a21hrPdjxDTCMJv+EPp0QUJ61ezQLq/ JqwwKa+ZgqwEuAiCkaOK+HnwSc1fFWG95LgJEl380lfRjunKoiQFBVzMumSXqsAq+WQw 2SaWWPUWU22jnK+mAMu8phnhgyR5/L3Xiz+NNLGRPkEBDBHWI8/r20PuyW0P0ndbymD8 YcKg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=ddlcz5f7mna3tfqsmgyxire5ee.protonmail header.b=kDmDoqV9; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.16 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch. [185.70.43.16]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5707b9a906fsi172833e87.7.2025.09.15.09.24.40 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Sep 2025 09:24:40 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.16 as permitted sender) client-ip=185.70.43.16; Date: Mon, 15 Sep 2025 16:24:34 +0000 To: Saint Wenhao From: "'conduition' via Bitcoin Development Mailing List" Cc: Jameson Lopp , Marc Johnson , Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: A Post Quantum Migration Proposal Message-ID: In-Reply-To: References: <173b3bc4-7052-4e0e-9042-ca15cd5b0587n@googlegroups.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 06184bf63e835ce11ca5727e4db227f18f55b79c MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------41fad5763bb4d923779218c9c0bde667513e16abad6b5bacb17a4ebb824c8098"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=ddlcz5f7mna3tfqsmgyxire5ee.protonmail header.b=kDmDoqV9; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.16 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------41fad5763bb4d923779218c9c0bde667513e16abad6b5bacb17a4ebb824c8098 Content-Type: multipart/mixed;boundary=---------------------531b48bcd5ca54255c46eac0460be52a -----------------------531b48bcd5ca54255c46eac0460be52a Content-Type: multipart/alternative;boundary=---------------------7f73f26c18c7b2deaf49f45520341338 -----------------------7f73f26c18c7b2deaf49f45520341338 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > In the current consensus? Yes. But it is possible to require a particular= value in the future. Or: a particular format, for example by requiring DER= signatures to take less than N bytes (also, relative timelocks are possibl= e, so that the smaller signature will be used, the lower timelock requireme= nts it would have). Sorry, I don't understand. How does any of this help to authenticate UTXO h= olders after a quantum computer appears?=C2=A0 > Also, we can always use time travel. If there is no consensus, then just = timelock every OP_CHECKSIG call to a few years, and think about it later. I= f after few years, there is still no consensus, how to migrate funds, then = timelock it again This seems like it makes everything worse, because it prevents people from = moving their funds to quantum-safe addresses, and gives the CRQC more time = to crack exposed public keys. > And if not, then people can still use OP_SIZE, to require a given amount = of Proof of Work, and if nothing is deployed, then pure hashrate can still = decide, who owns what, until people will agree on something better. Given how much of a hashrate advantage bitcoin miners have over typical use= rs, this would effectively just be a donation to the miners, distributed ac= cording to hashrate. It would disincentivize normal mining because miners c= ould make more money by cracking these PoW-locked coins than they could by = actually securing the network (by finding blocks). I don't think this is a = good option. regards, conduition On Saturday, August 23rd, 2025 at 10:57 AM, Saint Wenhao wrote: > > The ECDSA R value is chosen by the signer, so the quantum attacker coul= d pick any arbitrary PQ signature data and commit it at spending time too. >=20 > In the current consensus? Yes. But it is possible to require a particular= value in the future. Or: a particular format, for example by requiring DER= signatures to take less than N bytes (also, relative timelocks are possibl= e, so that the smaller signature will be used, the lower timelock requireme= nts it would have). >=20 > > Any such commitments require positive action by UTXO holders, i.e. a mi= gration. >=20 > No, because some public keys are exposed, and some of them are not. If th= ey are hidden behind some kind of hashed output, like P2PKH, then it is pos= sible to require committing to some kind of proof, because the public key c= an be unknown by the rest of the network. >=20 > Also, we can always use time travel. If there is no consensus, then just = timelock every OP_CHECKSIG call to a few years, and think about it later. I= f after few years, there is still no consensus, how to migrate funds, then = timelock it again. Then, sooner or later, some consensus will be reached. A= nd if not, then people can still use OP_SIZE, to require a given amount of = Proof of Work, and if nothing is deployed, then pure hashrate can still dec= ide, who owns what, until people will agree on something better. >=20 > pt., 22 sie 2025 o 21:59 conduition napisa=C5=82(a= ): >=20 > > > If someone has some coins, then the public key cannot be changed, if = it is present in the output Script. However, R-value can be freely picked b= y the signer, and can be set to anything. > >=20 > > > ... > >=20 > > > And later, when quantum signatures will be obligatory, then for each = and every OP_CHECKSIG call, R-value of the old ECDSA signature will be forc= ed to commit to a valid quantum signature. > >=20 > >=20 > > The ECDSA R value is chosen by the signer, so the quantum attacker coul= d pick any arbitrary PQ signature data and commit it at spending time too. > >=20 > > Lopp's point is that unless the output script has committed to a PQ pub= lic key in some way prior to a CRQC arriving, then 3rd party nodes can't kn= ow whether a spend that occurs after a CRQC has appeared is genuine. Any su= ch commitments require positive action by UTXO holders, i.e. a migration. > >=20 > > regards, > > conduition > > On Tuesday, August 19th, 2025 at 3:11 PM, Saint Wenhao wrote: > >=20 > > > > how would currently locked funds be able to spend via a quantum saf= e signature scheme if they have not committed to a dual signature scheme? > > >=20 > > > In ECDSA, we have two secp256k1 points in use: one is public key, ano= ther is R-value in the signature. If someone has some coins, then the publi= c key cannot be changed, if it is present in the output Script. However, R-= value can be freely picked by the signer, and can be set to anything. Which= means, that users can commit to any quantum data, by hashing it, and formi= ng a valid commitment in R-value. > > >=20 > > > Which also means, that old nodes can see only ECDSA signatures, and p= ublic keys, while new, quantum-resistant nodes, can require R-value to comm= it to something. Then, in the first phase, when quantum commitments will be= optional, users will use only ECDSA on-chain, but new, quantum nodes, will= be able to see, what is committed to R-values behind signatures, and can s= tore and process it. > > >=20 > > > And later, when quantum signatures will be obligatory, then for each = and every OP_CHECKSIG call, R-value of the old ECDSA signature will be forc= ed to commit to a valid quantum signature. Which also means, that the new q= uantum data won't be restricted by the current block size limit, but rather= by a combination of sigops limit, and a quantum commitment size limit (whi= ch can be set to different values, for different quantum proposals, dependi= ng on a particular signature scheme). > > >=20 > > > pon., 18 sie 2025 o 19:12 Jameson Lopp napis= a=C5=82(a): > > >=20 > > > >=20 > > > >=20 > > > > On Thu, Aug 7, 2025 at 7:26=E2=80=AFPM Marc Johnson wrote: > > > >=20 > > > > > Hi All! > > > > >=20 > > > > > I'd first like to say thank you to James for the comprehensive pr= oposal. The quantum threat is indeed existential, and I appreciate the deta= iled thinking that went into this migration plan. However, I=E2=80=99d like= to respectfully raise some concerns about the approach and share an altern= ative perspective from work we=E2=80=99ve been doing in this space. > > > > >=20 > > > > > ## Concerns with the Forced Sunset Approach > > > > >=20 > > > > > The proposal=E2=80=99s Phase B - rendering ECDSA/Schnorr spends i= nvalid - essentially threatens users with permanent fund loss. This creates= several issues: > > > > >=20 > > > > > 1. **Violation of Bitcoin=E2=80=99s Social Contract**: Satoshi=E2= =80=99s principle that =E2=80=9Clost coins only make everyone else=E2=80=99= s coins worth slightly more=E2=80=9D becomes =E2=80=9Ccoins you don=E2=80= =99t migrate in time are forcibly lost.=E2=80=9D This fundamentally changes= Bitcoin=E2=80=99s value proposition. > > > > >=20 > > > > > 2. **The 25% Problem**: With ~5.25 million BTC having exposed pub= lic keys, forcing these to become unspendable could create massive economic= disruption. Many of these may be genuinely lost coins, but some could be l= ong-term cold storage, inheritance situations, or users who simply miss the= migration window. > > > > >=20 > > > > > 3. **Timeline Risk**: The 5+ year timeline (3 years post-BIP-360 = + 2 years) assumes smooth consensus and implementation. Given Bitcoin=E2=80= =99s history, this could easily stretch to 7-10 years, most likely pushing = implementation past the 2027-2030 quantum timeline mentioned. > > > > >=20 > > > > > ## An Alternative Approach: Learning from Supernova > > > > >=20 > > > > > Our team has been working on these exact problems and recently re= ached production readiness with Supernova - a Bitcoin-inspired blockchain t= hat implements quantum resistance from genesis. Rather than forced migratio= n, we use a dual-signature scheme that might be instructive for Bitcoin: > > > >=20 > > > >=20 > > > > I don't see how this solves Bitcoin's migration problem; how would = currently locked funds be able to spend via a quantum safe signature scheme= if they have not committed to a dual signature scheme? In order to take ad= vantage of this setup on Bitcoin, you just end up recreating the migration = problem. > > > >=20 > > > >=20 > > > > >=20 > > > > > **Three Modes of Operation:** > > > > > - **Legacy Mode**: ECDSA signatures only (Bitcoin-compatible) > > > > > - **Transition Mode**: Both ECDSA and quantum signatures required > > > > > - **Quantum Mode**: Quantum signatures only > > > > >=20 > > > > > This approach: > > > > > - Never locks users out of their funds > > > > > - Allows gradual, voluntary migration > > > > > - Maintains backwards compatibility indefinitely > > > > > - Provides immediate protection for those who want it > > > > >=20 > > > > > ## Key Innovations Worth Considering > > > > >=20 > > > > > 1. **Hybrid Signatures**: Instead of a hard cutoff, transactions = can require both classical and quantum signatures during transition. This p= rovides quantum security while maintaining compatibility. > > > > >=20 > > > > > 2. **Address Format Compatibility**: Our quantum addresses (snq1.= ..) coexist with standard addresses (sn1...), allowing users to choose thei= r security level per transaction rather than per wallet. > > > > >=20 > > > > > 3. **No Coordination Required**: Users can independently decide w= hen to migrate without waiting for ecosystem-wide coordination. > > > > >=20 > > > > > 4. **Proven Implementation**: We=E2=80=99ve demonstrated this wor= ks in production, including the world=E2=80=99s first quantum-resistant Lig= htning Network. > > > > >=20 > > > > > ## A Cooperative Path Forward > > > > >=20 > > > > > Rather than viewing this as competition, I see opportunity for co= llaboration. Supernova could serve as a real-world testbed for quantum migr= ation strategies. We=E2=80=99ve already implemented: > > > > >=20 > > > > > - NIST-standardized algorithms (Dilithium, SPHINCS+, Falcon) > > > > > - Quantum-resistant atomic swaps with Bitcoin > > > > > - Full Lightning Network with quantum HTLCs > > > > > - Zero-knowledge proofs for enhanced privacy > > > > >=20 > > > > > Bitcoin could learn from our implementation experience, while we = continue to honor Bitcoin=E2=80=99s principles of decentralization and soun= d money. > > > > >=20 > > > > > ## Invitation to Explore > > > > >=20 > > > > > For those interested in seeing quantum resistance in action today= rather than waiting years, I invite you to explore Supernova. We=E2=80=99r= e launching our public testnet soon and would value feedback from the Bitco= in community. > > > > >=20 > > > > > The quantum threat is real, and we need multiple approaches to en= sure the future of decentralized money. Whether through Bitcoin=E2=80=99s e= ventual upgrade or alternatives like Supernova, the important thing is that= we act before it=E2=80=99s too late. > > > > >=20 > > > > > The code is open source, and we welcome technical review: [github= .com/Carbon-Twelve-C12/supernova](https://github.com/Carbon-Twelve-C12/supe= rnova) > > > > >=20 > > > > > Would love to hear thoughts on the dual-signature approach and wh= ether something similar could work for Bitcoin without the harsh sunset pro= visions. > > > > >=20 > > > > > --- > > > > >=20 > > > > > *Note: While I represent the Supernova project, I=E2=80=99m also = a long-time Bitcoin supporter who wants to see the entire ecosystem survive= the quantum transition. These challenges affect us all.* > > > > >=20 > > > > > On Sunday, July 20, 2025 at 11:56:48=E2=80=AFPM UTC+1 Boris Nagae= v wrote: > > > > >=20 > > > > > > Hi Jameson, hi all! > > > > > >=20 > > > > > > I have a couple of ideas on how to preserve more funds during a= ny kind of fork that constrains or blocks currently used spending scenarios= . This applies to both freezing and commit/reveal schemes; the latter may r= esult in lost funds if the public key is leaked. I realized that this also = applies to the commit/reveal scheme I proposed in another thread [1]. > > > > > >=20 > > > > > > The idea is to roll out such forks incrementally across the UTX= O set. Instead of freezing or constraining all UTXOs at once, we split the = UTXO set into 256 groups deterministically (for example, by looking at the = first byte of the TXID) and apply the constraints over 256 days, processing= one group per day. Procrastinators will learn what is happening through wo= rd of mouth, act to save their funds, and only a small percentage of coin o= wners will be harmed. > > > > > >=20 > > > > > > Another approach is to provide a temporary opt-out option. If s= omeone finds themselves blocked, they would still have a limited time to ta= ke an action, without requiring any extra knowledge, to get unblocked. This= would help raise awareness. After being temporarily blocked and recovering= their funds through the opt-out mechanism, the person would understand tha= t they need to take further steps with their remaining coins to avoid being= permanently blocked once the opt-out period ends. The action to unblock th= e funds could be as simple as sending a transaction with OP_RETURN "opt-out= ", which would enable the old acceptance rules for the transaction w= ith that txid for a period of 2016 blocks. > > > > > >=20 > > > > > >=20 > > > > > > [1] https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/57bQ= J3VSCQAJ > > > > > > In that scheme if the pubkey is leaked, anyone can post a valid= commitment with a random TXID blocking the coin forever. > > > > > >=20 > > > > > > Best, > > > > > > Boris > > > > > >=20 > > > > > > On Saturday, July 12, 2025 at 9:46:09=E2=80=AFPM UTC-3 Jameson = Lopp wrote: > > > > > >=20 > > > > > > > Building upon my earlier essay against allowing quantum recov= ery of bitcoin I wish to formalize a proposal after several months of discu= ssions. > > > > > > >=20 > > > > > > > This proposal does not delve into the multitude of issues reg= arding post quantum cryptography and trade-offs of different schemes, but r= ather is meant to specifically address the issues of incentivizing adoption= and migration of funds after consensus is established that it is prudent t= o do so. > > > > > > >=20 > > > > > > > As such, this proposal requires P2QRH as described in BIP-360= or potential future proposals. > > > > > > >=20 > > > > > > > Abstract > > > > > > >=20 > > > > > > > This proposal follows the implementation of post-quantum (PQ)= output type (P2QRH) and introduces a pre-announced sunset of legacy ECDSA/= Schnorr signatures. It turns quantum security into a private incentive: fai= l to upgrade and you will certainly lose access to your funds, creating a c= ertainty where none previously existed. > > > > > > >=20 > > > > > > > - Phase A: Disallows sending of any funds to quantum-vulner= able addresses, hastening the adoption of P2QRH address types. > > > > > > > =20 > > > > > > > - Phase B: Renders ECDSA/Schnorr spends invalid, preventing= all spending of funds in quantum-vulnerable UTXOs. This is triggered by a = well-publicized flag-day roughly five years after activation. > > > > > > > =20 > > > > > > > - Phase C (optional): Pending further research and demand, = a separate BIP proposing a fork to allow recovery of legacy UTXOs through Z= K proof of possession of BIP-39 seed phrase. > > > > > > > =20 > > > > > > >=20 > > > > > > > Motivation > > > > > > >=20 > > > > > > > We seek to secure the value of the UTXO set and minimize ince= ntives for quantum attacks. This proposal is radically different from any i= n Bitcoin=E2=80=99s history just as the threat posed by quantum computing i= s radically different from any other threat in Bitcoin=E2=80=99s history. N= ever before has Bitcoin faced an existential threat to its cryptographic pr= imitives. A successful quantum attack on Bitcoin would result in significan= t economic disruption and damage across the entire ecosystem. Beyond its im= pact on price, the ability of miners to provide network security may be sig= nificantly impacted. > > > > > > >=20 > > > > > > > - Accelerating quantum progress. > > > > > > > =20 > > > > > > > - NIST ratified three production-grade PQ signature sch= emes in 2024; academic road-maps now estimate a cryptographically-relevant = quantum computer as early as 2027-2030. [McKinsey] > > > > > > > =20 > > > > > > > - Quantum algorithms are rapidly improving > > > > > > > =20 > > > > > > > - The safety envelope is shrinking by dramatic increase= s in algorithms even if the pace of hardware improvements is slower. Algori= thms are improving up to 20X, lowering the theoretical hardware requirement= s for breaking classical encryption. > > > > > > > =20 > > > > > > > - Bitcoin=E2=80=99s exposed public keys. > > > > > > > =20 > > > > > > > - Roughly 25% of all bitcoin have revealed a public key= on-chain; those UTXOs could be stolen with sufficient quantum power. > > > > > > > =20 > > > > > > > - We may not know the attack is underway. > > > > > > > =20 > > > > > > > - Quantum attackers could compute the private key for k= nown public keys then transfer all funds weeks or months later, in a covert= bleed to not alert chain watchers. Q-Day may be only known much later if t= he attack withholds broadcasting transactions in order to postpone revealin= g their capabilities. > > > > > > > =20 > > > > > > > - Private keys become public. > > > > > > > =20 > > > > > > > - Assuming that quantum computers are able to maintain = their current trajectories and overcome existing engineering obstacles, the= re is a near certain chance that all P2PK (and other outputs with exposed p= ubkeys) private keys will be found and used to steal the funds. > > > > > > > =20 > > > > > > > - Impossible to know motivations. > > > > > > > =20 > > > > > > > - Prior to a quantum attack, it is impossible to know t= he motivations of the attacker. An economically motivated attacker will try= to remain undetected for as long as possible, while a malicious attacker w= ill attempt to destroy as much value as possible. > > > > > > > =20 > > > > > > > - Upgrade inertia. > > > > > > > =20 > > > > > > > - Coordinating wallets, exchanges, miners and custodian= s historically takes years. > > > > > > > =20 > > > > > > > - The longer we postpone migration, the harder it becom= es to coordinate wallets, exchanges, miners, and custodians. A clear, time-= boxed pathway is the only credible defense. > > > > > > > =20 > > > > > > > - Coordinating distributed groups is more prone to dela= y, even if everyone has similar motivations. Historically, Bitcoin has been= slow to adopt code changes, often taking multiple years to be approved. > > > > > > > =20 > > > > > > >=20 > > > > > > > Benefits at a Glance > > > > > > >=20 > > > > > > > - Resilience: Bitcoin protocol remains secure for the fores= eeable future without waiting for a last-minute emergency. > > > > > > > =20 > > > > > > > - Certainty: Bitcoin users and stakeholders gain certainty = that a plan is both in place and being implemented to effectively deal with= the threat of quantum theft of bitcoin. > > > > > > > =20 > > > > > > > - Clarity: A single, publicized timeline aligns the entire = ecosystem (wallets, exchanges, hardware vendors). > > > > > > > =20 > > > > > > > - Supply Discipline: Abandoned keys that never migrate beco= me unspendable, reducing supply, as Satoshi described. > > > > > > > =20 > > > > > > >=20 > > > > > > > Specification > > > > > > >=20 > > > > > > > Phase > > > > > > >=20 > > > > > > > What Happens > > > > > > >=20 > > > > > > > Who Must Act > > > > > > >=20 > > > > > > > Time Horizon > > > > > > >=20 > > > > > > > Phase A - Disallow spends to legacy script types > > > > > > >=20 > > > > > > > Permitted sends are from legacy scripts to P2QRH scripts > > > > > > >=20 > > > > > > > Everyone holding or accepting BTC. > > > > > > >=20 > > > > > > > 3 years after BIP-360 implementation > > > > > > >=20 > > > > > > > Phase B =E2=80=93 Disallow spends from quantum vulnerable out= puts > > > > > > >=20 > > > > > > > At a preset block-height, nodes reject transactions that rely= on ECDSA/Schnorr keys. > > > > > > >=20 > > > > > > > Everyone holding or accepting BTC. > > > > > > >=20 > > > > > > > 2 years after Phase A activation. > > > > > > >=20 > > > > > > > Phase C =E2=80=93 Re-enable spends from quantum vulnerable ou= tputs via ZK Proof > > > > > > >=20 > > > > > > > Users with frozen quantum vulnerable funds and a HD wallet se= ed phrase can construct a quantum safe ZK proof to recover funds. > > > > > > >=20 > > > > > > > Users who failed to migrate funds before Phase B. > > > > > > >=20 > > > > > > > TBD pending research, demand, and consensus. > > > > > > >=20 > > > > > > > Rationale > > > > > > >=20 > > > > > > > - Even if Bitcoin is not a primary initial target of a cryp= tographically relevant quantum computer, widespread knowledge that such a c= omputer exists and is capable of breaking Bitcoin=E2=80=99s cryptography wi= ll damage faith in the network . > > > > > > > =20 > > > > > > > - An attack on Bitcoin may not be economically motivated - = an attacker may be politically or maliciously motivated and may attempt to = destroy value and trust in Bitcoin rather than extract value. There is no w= ay to know in advance how, when, or why an attack may occur. A defensive po= sition must be taken well in advance of any attack. > > > > > > > =20 > > > > > > > - Bitcoin=E2=80=99s current signatures (ECDSA/Schnorr) will= be a tantalizing target: any UTXO that has ever exposed its public key on-= chain (roughly 25 % of all bitcoin) could be stolen by a cryptographically = relevant quantum computer. > > > > > > > =20 > > > > > > > - Existing Proposals are Insufficient. > > > > > > > =20 > > > > > > > 1. Any proposal that allows for the quantum theft of =E2= =80=9Clost=E2=80=9D bitcoin is creating a redistribution dilemma. There are= 3 types of proposals: > > > > > > > =20 > > > > > > > 1. Allow anyone to steal vulnerable coins, benefitti= ng those who reach quantum capability earliest. > > > > > > > =20 > > > > > > > 2. Allow throttled theft of coins, which leads to RB= F battles and ultimately miners subsidizing their revenue from lost coins. > > > > > > > =20 > > > > > > > 3. Allow no one to steal vulnerable coins. > > > > > > > =20 > > > > > > > - Minimizes attack surface > > > > > > > =20 > > > > > > > 1. By disallowing new spends to quantum vulnerable scrip= t types, we minimize the attack surface with each new UTXO. > > > > > > > =20 > > > > > > > 2. Upgrades to Bitcoin have historically taken many year= s; this will hasten and speed up the adoption of new quantum resistant scri= pt types. > > > > > > > =20 > > > > > > > 3. With a clear deadline, industry stakeholders will mor= e readily upgrade existing infrastructure to ensure continuity of services. > > > > > > > =20 > > > > > > > - Minimizes loss of access to funds > > > > > > > =20 > > > > > > > 1. If there is sufficient demand and research proves pos= sible, submitting a ZK proof of knowledge of a BIP-39 seed phrase correspon= ding to a public key hash or script hash would provide a trustless means fo= r legacy outputs to be spent in a quantum resistant manner, even after the = sunset. > > > > > > > =20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > Stakeholder > > > > > > >=20 > > > > > > > Incentive to Upgrade > > > > > > >=20 > > > > > > > Miners > > > > > > >=20 > > > > > > > =E2=80=A2 Larger size PQ signatures along with incentive for = users to migrate will create more demand for block space and thus higher fe= es collected by miners. > > > > > > >=20 > > > > > > > =E2=80=A2 Post-Phase B, non-upgraded miners produce invalid b= locks. > > > > > > >=20 > > > > > > > =E2=80=A2 A quantum attack on Bitcoin will significantly deva= lue both their hardware and Bitcoin as a whole. > > > > > > >=20 > > > > > > > Institutional Holders > > > > > > >=20 > > > > > > > =E2=80=A2 Fiduciary duty: failing to act to prevent a quantum= attack on Bitcoin would violate the fiduciary duty to shareholders. > > > > > > >=20 > > > > > > > =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to effectiv= ely mitigate emerging threats will prove Bitcoin to be an investment grade = asset. > > > > > > >=20 > > > > > > > Exchanges & Custodians > > > > > > >=20 > > > > > > > =E2=80=A2 Concentrated risk: a quantum hack could bankrupt th= em overnight. > > > > > > >=20 > > > > > > > =E2=80=A2 Early migration is cheap relative to potential loss= es, potential lawsuits over improper custody and reputational damage. > > > > > > >=20 > > > > > > > Everyday Users > > > > > > >=20 > > > > > > > =E2=80=A2 Self-sovereign peace of mind. > > > > > > >=20 > > > > > > > =E2=80=A2 Sunset date creates a clear deadline and incentive = to improve their security rather than an open-ended =E2=80=9Csome day=E2=80= =9D that invites procrastination. > > > > > > >=20 > > > > > > > Attackers > > > > > > >=20 > > > > > > > =E2=80=A2 Economic incentive diminishes as sunset nears, stol= en coins cannot be spent after Q-day. > > > > > > >=20 > > > > > > > Key Insight: As mentioned earlier, the proposal turns quantum= security into a private incentive to upgrade. > > > > > > >=20 > > > > > > > This is not an offensive attack, rather, it is defensive: our= thesis is that the Bitcoin ecosystem wishes to defend itself and its inter= ests against those who would prefer to do nothing and allow a malicious act= or to destroy both value and trust. > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > > "Lost coins only make everyone else's coins worth slightly = more. Think of it as a donation to everyone." - Satoshi Nakamoto > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > If true, the corollary is: > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > > "Quantum recovered coins only make everyone else's coins wo= rth less. Think of it as a theft from everyone." > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > The timelines that we are proposing are meant to find the bes= t balance between giving ample ability for account owners to migrate while = maintaining the integrity of the overall ecosystem to avoid catastrophic at= tacks. > > > > > > >=20 > > > > > > >=20 > > > > > > > Backward Compatibility > > > > > > >=20 > > > > > > > As a series of soft forks, older nodes will continue to opera= te without modification. Non-upgraded nodes, however, will consider all pos= t-quantum witness programs as anyone-can-spend scripts. They are strongly e= ncouraged to upgrade in order to fully validate the new programs. > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > Non-upgraded wallets can receive and send bitcoin from non-up= graded and upgraded wallets until Phase A. After Phase A, they can no longe= r receive from any other wallets and can only send to upgraded wallets. Aft= er Phase B, both senders and receivers will require upgraded wallets. Phase= C would likely require a loosening of consensus rules (a hard fork) to all= ow vulnerable funds recovery via ZK proofs. > > > > >=20 > > > > > -- > > > > > You received this message because you are subscribed to the Googl= e 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/b= itcoindev/173b3bc4-7052-4e0e-9042-ca15cd5b0587n%40googlegroups.com. > > > >=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, s= end an email to bitcoindev+unsubscribe@googlegroups.com. > > > > To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/CADL_X_cgqHUOU6V9%2BGsEKz--ekxmgyYJwOg4BeLajAr_cTVN_g%40mail.gmail.= com. > > >=20 > > > -- > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+unsubscribe@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/CACgYNO%2B1tFwsd-V67fyCWv%3DWtAXp4V6RQhsTw8XpzYULF7u_UA%40mail.gmail.= com. >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/CACgYNOKz07-hU%2BbrB7NsGyD32wB6J-%2BO0PS1RMhCs%3DgWy-vNzg%40mail.gmail.co= m. --=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/= HlXjtfc1W4JccDWxTGiyfJC9lUvDh27nzE20yljBE6bJ35RaDC9NEwwcWNiasVkhsvS7hh0dvxX= jReYLWL6ZSkayM8mCB45kzyMAOguPk8E%3D%40proton.me. -----------------------7f73f26c18c7b2deaf49f45520341338 Content-Type: multipart/related;boundary=---------------------46039296221990024896da67d4b67d06 -----------------------46039296221990024896da67d4b67d06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In th= e current consensus? Yes. But it is possible to require a particular value in the future. Or: a particular format, for example by requiring DER signatures to take less than N bytes (also, relative timelocks are possible, so that the smaller signature will be used, the lower timelock requirements it would have).

Sorry, I don't understand. How does any of this help to authenticate UTXO = holders after a quantum computer appears? 

Also, we can always use time travel. I= f there is no consensus, then just timelock every OP_CHECKSIG call to a few= years, and think about it later. If after few years, there is still no con= sensus, how to migrate funds, then timelock it again

Th= is seems like it makes everything worse, because it prevents people from mo= ving their funds to quantum-safe addresses, and gives the CRQC more time to= crack exposed public keys.

= And if not, then people can st= ill use OP_SIZE, to require a given amount of Proof of Work, and if nothing= is deployed, then pure hashrate can still decide, who owns what, until peo= ple will agree on something better.

Given how much of a hashrate advantage bitcoin miners have over typi= cal users, this would effectively just be a donation to the miners, distrib= uted according to hashrate. It would disincentivize normal mining because m= iners could make more money by cracking these PoW-locked coins than they co= uld by actually securing the network (by finding blocks). I don't think thi= s is a good option.

regards,<= /div>
conduition
On Saturday, August 23rd, 2025 at 10:57 AM, Saint Wenhao <saintw= enhao@gmail.com> wrote:
> The ECDSA R value is chosen by the signer= , so the quantum attacker could pick any arbitrary PQ signature data and commit it at spending time too.

In the current consensus? Yes. But it is possible to require a particular value in the future. Or: a particular format, for example by requiring DER signatures to take less than N bytes (also, relative timelocks are possible, so that the smaller signature will be used, the lower timelock requirements it would have).

> Any such = commitments require positive action by UTXO holders, i.e. a migration.
<= br>No, because some public keys are exposed, and some of them are not. If they are hidden behind some kind of hashed output, like P2PKH, then it is possible to require committing to some kind of proof, because the public key can be unknown by the rest of the network.

Also, we can always use time travel. If there is no consensus, then just timelock every OP_CHECKSIG call to a few years, and think about it later. If after few years, there is still no consensus, how to migrate funds, then timelock it again. Then, sooner or later, some consensus will be reached. And if not, then people can still use OP_SIZE, to require a given amount of Proof of Work, and if nothing is deployed, then pure hashrate can still decide, who owns what, until people will agree on something better.

pt., 22 sie 2025 o 21:59 conduition = <conduition@proton.me> napisa=C5=82(a):
If someone has some coins, then the public key cann= ot be changed, if it is present in the output Script. However, R-value can = be freely picked by the signer, and can be set to anything.
...
And later, when quantum signatures will be obligatory, then for each and= every OP_CHECKSIG call, R-value of the old ECDSA signature will be forced = to commit to a valid quantum signature.

The ECDSA R value is c= hosen by the signer, so the quantum attacker could pick any arbitrary PQ si= gnature data and commit it at spending time too.

Lopp's point is that unless the output scri= pt has committed to a PQ public key in some way prior to a CRQC arri= ving, then 3rd party nodes can't know whether a spend that occurs after<= /i> a CRQC has appeared is genuine. Any such commitments require positive a= ction by UTXO holders, i.e. a migration.

regards,
conduition
On Tuesday, August 19th, 2025 at 3:11 PM, Saint Wenhao <saintwenhao@gmail.com> wrote:
> how would currently locked funds be able = to spend via a quantum safe signature scheme if they have not committed to = a dual signature scheme?

In ECDSA, we have two secp256k1 points in u= se: one is public key, another is R-value in the signature. If someone has = some coins, then the public key cannot be changed, if it is present in the = output Script. However, R-value can be freely picked by the signer, and can= be set to anything. Which means, that users can commit to any quantum data= , by hashing it, and forming a valid commitment in R-value.

Which al= so means, that old nodes can see only ECDSA signatures, and public keys, wh= ile new, quantum-resistant nodes, can require R-value to commit to somethin= g. Then, in the first phase, when quantum commitments will be optional, use= rs will use only ECDSA on-chain, but new, quantum nodes, will be able to se= e, what is committed to R-values behind signatures, and can store and proce= ss it.

And later, when quantum signatures will be obligatory, then f= or each and every OP_CHECKSIG call, R-value of the old ECDSA signature will= be forced to commit to a valid quantum signature. Which also means, that t= he new quantum data won't be restricted by the current block size limit, bu= t rather by a combination of sigops limit, and a quantum commitment size li= mit (which can be set to different values, for different quantum proposals,= depending on a particular signature scheme).

pon., 18 sie 2025 o 19:12 Jame= son Lopp <jameson.lopp@gmail.com> napisa=C5= =82(a):


On Thu, Aug 7, 2025 at 7:26=E2=80=AFPM Marc J= ohnson <marcjohnson518@gmail.com> wrote:<= br>
Hi All!

I= 'd first like to say thank you to James for the comprehensive proposal. The= quantum threat is indeed existential, and I appreciate the detailed thinki= ng that went into this migration plan. However, I=E2=80=99d like to respect= fully raise some concerns about the approach and share an alternative persp= ective from work we=E2=80=99ve been doing in this space.

## Concerns= with the Forced Sunset Approach

The proposal=E2=80=99s Phase B - re= ndering ECDSA/Schnorr spends invalid - essentially threatens users with per= manent fund loss. This creates several issues:

1. **Violation of Bit= coin=E2=80=99s Social Contract**: Satoshi=E2=80=99s principle that =E2=80= =9Clost coins only make everyone else=E2=80=99s coins worth slightly more= =E2=80=9D becomes =E2=80=9Ccoins you don=E2=80=99t migrate in time are forc= ibly lost.=E2=80=9D This fundamentally changes Bitcoin=E2=80=99s value prop= osition.

2. **The 25% Problem**: With ~5.25 million BTC having expos= ed public keys, forcing these to become unspendable could create massive ec= onomic disruption. Many of these may be genuinely lost coins, but some coul= d be long-term cold storage, inheritance situations, or users who simply mi= ss the migration window.

3. **Timeline Risk**: The 5+ year timeline = (3 years post-BIP-360 + 2 years) assumes smooth consensus and implementatio= n. Given Bitcoin=E2=80=99s history, this could easily stretch to 7-10 years= , most likely pushing implementation past the 2027-2030 quantum timeline me= ntioned.

## An Alternative Approach: Learning from Supernova

= Our team has been working on these exact problems and recently reached prod= uction readiness with Supernova - a Bitcoin-inspired blockchain that implem= ents quantum resistance from genesis. Rather than forced migration, we use = a dual-signature scheme that might be instructive for Bitcoin:

I don't see how this solves Bitcoin's migration pro= blem; how would currently locked funds be able to spend via a quantum safe = signature scheme if they have not committed to a dual signature scheme? In = order to take advantage of this setup on Bitcoin, you just end up recreatin= g the migration problem.


**Three Modes of Operation:**
- **Legacy Mode**:= ECDSA signatures only (Bitcoin-compatible)
- **Transition Mode**: Both = ECDSA and quantum signatures required
- **Quantum Mode**: Quantum signat= ures only

This approach:
- Never locks users out of their funds- Allows gradual, voluntary migration
- Maintains backwards compatibil= ity indefinitely
- Provides immediate protection for those who want it
## Key Innovations Worth Considering

1. **Hybrid Signatures**:= Instead of a hard cutoff, transactions can require both classical and quan= tum signatures during transition. This provides quantum security while main= taining compatibility.

2. **Address Format Compatibility**: Our quan= tum addresses (snq1...) coexist with standard addresses (sn1...), allowing = users to choose their security level per transaction rather than per wallet= .

3. **No Coordination Required**: Users can independently decide wh= en to migrate without waiting for ecosystem-wide coordination.

4. **= Proven Implementation**: We=E2=80=99ve demonstrated this works in productio= n, including the world=E2=80=99s first quantum-resistant Lightning Network.=

## A Cooperative Path Forward

Rather than viewing this as co= mpetition, I see opportunity for collaboration. Supernova could serve as a = real-world testbed for quantum migration strategies. We=E2=80=99ve already = implemented:

- NIST-standardized algorithms (Dilithium, SPHINCS+, Fa= lcon)
- Quantum-resistant atomic swaps with Bitcoin
- Full Lightning = Network with quantum HTLCs
- Zero-knowledge proofs for enhanced privacy<= br>
Bitcoin could learn from our implementation experience, while we con= tinue to honor Bitcoin=E2=80=99s principles of decentralization and sound m= oney.

## Invitation to Explore

For those interested in seeing= quantum resistance in action today rather than waiting years, I invite you= to explore Supernova. We=E2=80=99re launching our public testnet soon and = would value feedback from the Bitcoin community.

The quantum threat= is real, and we need multiple approaches to ensure the future of decentral= ized money. Whether through Bitcoin=E2=80=99s eventual upgrade or alternati= ves like Supernova, the important thing is that we act before it=E2=80=99s = too late.

The code is open source, and we welcome technical review: = [github.com/Carbon-Twelve-C12/supernova](https://github.com/C= arbon-Twelve-C12/supernova)

Would love to hear thoughts on the d= ual-signature approach and whether something similar could work for Bitcoin= without the harsh sunset provisions.

---

*Note: While I repr= esent the Supernova project, I=E2=80=99m also a long-time Bitcoin supporter= who wants to see the entire ecosystem survive the quantum transition. Thes= e challenges affect us all.*

On Sunday, July 20, 2025 at 11:56:48=E2=80=AFPM = UTC+1 Boris Nagaev wrote:
Hi Jameson, hi all!

I have a couple of ideas on how to pr= eserve more funds during any kind of fork that constrains or blocks current= ly used spending scenarios. This applies to both freezing and commit/reveal= schemes; the latter may result in lost funds if the public key is leaked. = I realized that this also applies to the commit/reveal scheme I proposed in= another thread [1].

The idea is to roll out such forks incr= ementally across the UTXO set. Instead of freezing or constraining all = UTXOs at once, we split the UTXO set into 256 groups deterministically (for= example, by looking at the first byte of the TXID) and apply the constrain= ts over 256 days, processing one group per day. Procrastinators will learn = what is happening through word of mouth, act to save their funds, and only = a small percentage of coin owners will be harmed.

= Another approach is to provide a temporary opt-out option. If someon= e finds themselves blocked, they would still have a limited time to take an= action, without requiring any extra knowledge, to get unblocked. This woul= d help raise awareness. After being temporarily blocked and recovering thei= r funds through the opt-out mechanism, the person would understand that the= y need to take further steps with their remaining coins to avoid being perm= anently blocked once the opt-out period ends. The action to unblock the fun= ds could be as simple as sending a transaction with OP_RETURN "opt-out <= txid>", which would enable the old acceptance rules for the transaction = with that txid for a period of 2016 blocks.


=
In that scheme if the pubkey is leaked, anyone can post a valid commit= ment with a random TXID blocking the coin forever.

Best= ,
Boris

On Saturday, Jul= y 12, 2025 at 9:46:09=E2=80=AFPM UTC-3 Jameson Lopp wrote:

Building upon my earlier essa= y against allowing quantu= m recovery of bitcoin I wish to formalize a= proposal after several months of discussions.

This proposal doe= s not delve into the multitude of issues regarding post quantum cryptograph= y and trade-offs of different schemes, but rather is meant to specifically = address the issues of incentivizing adoption and migration of funds = after consensus is established that i= t is prudent to do so.

As such, this proposal requires P2QRH as described in BIP-360 or= potential future proposals.

Abstract

This proposal follows the implementation of post-quantum (P= Q) output type (P2QRH) and introduces a pre-announced sunset of legacy ECDS= A/Schnorr signatures. It turns quantum security into a private incentive: fail to upgrade an= d you will certainly lose access to your funds, creating a certainty where = none previously existed.

  • Phase A:<= span style=3D"font-size:11pt;background-color:transparent;font-variant-nume= ric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;ve= rtical-align:baseline"> Disallows sending of any funds to quantum-vulnerabl= e addresses, hastening the adoption of P2QRH address types.

    • =

  • Phase B: Renders ECDSA/Schnorr spends invalid, preventing all spendi= ng of funds in quantum-vulnerable UTXOs. This is triggered by a well-public= ized flag-day roughly five years after activation.

  • Phase C (optional): Pending further research and demand, a separate BIP pro= posing a fork to allow recovery of legacy UTXOs through ZK proof of possess= ion of BIP-39 seed phrase.

Motivation

We seek t= o secure the value of the UTXO set and minimize incentives for quantum attacks. This proposal is= radically different from any in Bitcoin=E2=80=99s history just as the thre= at posed by quantum computing is radically different from any other threat = in Bitcoin=E2=80=99s history. Never before has Bitcoin faced an existentia= l threat to its cryptographic primitives. A successful quantum attack on Bi= tcoin would result in significant economic disruption and damage across the= entire ecosystem. Beyond its impact on price, the ability of miners to pro= vide network security may be significantly impacted.

  • Accelerating quantum progress.

    • NIST ratified three production-grade PQ signature sch= emes in 2024; academic road-maps now estimate a cryptographically-relevant = quantum computer as early as 2027-2030. [McKinsey]

  • Quantum algorithms are rapidly improving=

    • The safety envelope is shrinking by = dramatic increases in algorithms even if the pace of hardware improvements = is slower. Algorithms are improving up to 20X, lowering the theoretical hard= ware requirements for breaking classical encryption.

  • Bitcoin=E2=80=99s= exposed public keys.

    • = Roughly 25% of all bitcoin have revealed a public key on-chain; those UTXOs= could be stolen with sufficient quantum power.

    • =

  • We ma= y not know the attack is underway.

    • Q= uantum attackers could compute the private key for known public keys then t= ransfer all funds weeks or months later, in a covert bleed to not alert cha= in watchers. Q-Day may be only known much later if the attack withholds bro= adcasting transactions in order to postpone revealing their capabilities.

  • = Private keys become public.

    • Assuming that quantum computers are able to maintain their current tra= jectories and overcome existing engineering obstacles, there is a near cert= ain chance that all P2PK (and other outputs with exposed pubkeys) private k= eys will be found and used to steal the funds.

    • Impossible to know motivati= ons.

    • Prior to a quantu= m attack, it is impossible to know the motivations of the attacker. An eco= nomically motivated attacker will try to remain undetected for as long as p= ossible, while a malicious attacker will attempt to destroy as much value a= s possible.

  • Upgrade inertia.

    <= ul style=3D"margin-top:0px;margin-bottom:0px">

  • Coordinating wallets, exchanges, miners and custodians historically= takes years.

  • The longer we postpone migration, the harder it becomes to coordi= nate wallets, exchanges, miners, and custodians. A clear, time-boxed pathwa= y is the only credible defense.

  • Coordinating distributed groups is more prone = to delay, even if everyone has similar motivations. Historically, Bitcoin h= as been slow to adopt code changes, often taking multiple years to be appro= ved.

Benef= its at a Glance

  • Resilience: Bitcoin protocol remains secure for= the foreseeable future without waiting for a last-minute emergency.=

  • Certainty: Bitcoin users and stakeholder= s gain certainty that a plan is both in place and being implemented to effe= ctively deal with the threat of quantum theft of bitcoin.

    • =

  • Clarity: A single, publicized timeline aligns the= entire ecosystem (wallets, exchanges, hardware vendors).

    • Supply Discipline: Abandoned keys that never migra= te become unspendable, reducing supply, as Satoshi described.

Specification

Phase

Wh= at Happens

Who Must Act

Time Horizon

Phase A - Disallow spends to legacy scr= ipt types

Permitted sends are from legacy scripts to P2QRH scripts

Everyone holding or accepting BTC.

3 years after BIP-360 implementation

Phase B =E2=80=93 Disallow spend= s from quantum vulnerable outputs

At a preset block-height, nodes reje= ct transactions that rely on ECDSA/Schnorr keys.

Ev= eryone holding or accepting BTC.

2 years after Phas= e A activation.

Pha= se C =E2=80=93 Re-enable spends from quantum vulnerable = outputs via ZK Proof

Users with frozen quantum vulnerable funds and a = HD wallet seed phrase can construct a quantum safe ZK proof to recover fund= s.

Users who failed to migrate funds before Phase B.

=

TBD pending = research, demand, and consensus.

Rationale

  • Even if Bitcoin is not a primary initial target of a cryptogra= phically relevant quantum computer, widespread knowledge that such a comput= er exists and is capable of breaking Bitcoin=E2=80=99s cryptography will da= mage faith in the network .

  • <= span style=3D"font-size:11pt;background-color:transparent;font-variant-nume= ric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;ve= rtical-align:baseline">An attack on Bitcoin may not be economically motivat= ed - an attacker may be politically or maliciously motivated and may attemp= t to destroy value and trust in Bitcoin rather than extract value. There i= s no way to know in advance how, when, or why an attack may occur. A defen= sive position must be taken well in advance of any attack.

  • Bitcoin=E2=80=99s cu= rrent signatures (ECDSA/Schnorr) will be a tantalizing target: any UTXO tha= t has ever exposed its public key on-chain (roughly 25 % of all bitcoin) co= uld be stolen by a cryptographically relevant quantum computer.

    <= /li>

  • Existing Proposals are Insufficient.

    1. Any proposal that allows for the = quantum theft of =E2=80=9Clost=E2=80=9D bitcoin is creating a redistributio= n dilemma. There are 3 types of proposals:

      1. Allow anyone to steal vulnerable coins, benefitting those who = reach quantum capability earliest.

      2. Allow throttled theft of coins, which l= eads to RBF battles and ultimately miners subsidizing their revenue from lo= st coins.

      3. Allow no one to steal vulnerable coins.

  • Minimizes attack surface

    1. By disallowing new spends to quantum vulnerable script types, we minimize = the attack surface with each new UTXO.

    2. Upgrades to Bitcoin have historic= ally taken many years; this will hasten and speed up the adoption of new qu= antum resistant script types.

    3. With a clear deadline, industry stakeholder= s will more readily upgrade existing infrastructure to ensure continuity of= services.

  • Minimizes loss of access to funds <= /p>

    1. If there is sufficient demand and rese= arch proves possible, submitting a ZK proof of knowledge of a BIP-39 seed p= hrase corresponding to a public key hash or script hash would provide a tr= ustless means for legacy outputs to be spent in a quantum resistant manner,= even after the sunset.


Stakeholder

Incentive to Upgrade

Miners

=E2=80=A2 Larger size PQ signatures along= with incentive for users to migrate will create more demand for block spac= e and thus higher fees collected by miners.

=E2=80= =A2 Post-Phase B, non-upgraded miners produce invalid blocks.

=E2=80=A2 A quantum attack on Bitcoin will significantly devalue b= oth their hardware and Bitcoin as a whole.

Institutional Holders

=E2=80=A2 Fiduciary du= ty: failing to act to prevent a quantum attack on Bitcoin would violate the= fiduciary duty to shareholders.

=E2=80=A2 Demonstr= ating Bitcoin=E2=80=99s ability to effectively mitigate emerging threats wi= ll prove Bitcoin to be an investment grade asset.

<= span style=3D"min-height:52pt">

Exchanges & Custodians

=E2=80=A2 C= oncentrated risk: a quantum hack could bankrupt them overnight.

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:"Courier New",monospace;= color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;f= ont-variant-east-asian:normal;font-variant-alternates:normal;vertical-align= :baseline">=E2=80=A2 Early migration is cheap relative to potential losses,= potential lawsuits over improper custody and reputational damage.

Everyday Users

=E2=80= =A2 Self-sovereign peace of mind.

=E2=80=A2 Sunset da= te creates a clear deadline and incentive to improve their security rather = than an open-ended =E2=80=9Csome day=E2=80=9D that invites procrastination.=

Attacke= rs

=E2=80=A2 Economic incentive diminishes as sunset nears, stolen coins= cannot be spent after Q-day.

<= p dir=3D"ltr" style=3D"line-height:1.38;text-align:justify;margin-top:12pt;= margin-bottom:12pt">Key Insight: As mentioned earlier, the proposal turns quantum security into a private incentive to upgrade.

This is not an offensive attack, rather, it i= s defensive: our thesis is that the Bitcoin ecosystem wishes to defend itse= lf and its interests against those who would prefer to do nothing and allow= a malicious actor to destroy both value and trust.


"Lost coins only make everyone else's coins worth slightly mo= re. Think of it as a donation to everyone." - Satoshi Nakamoto

If true, the corollary is:


"Quantum recovered coins only make everyone else's coins worth le= ss. Think of it as a theft from everyone."

The timelines that we are proposing are meant to find the best balance b= etween giving ample ability for account owners to migrate while maintaining= the integrity of the overall ecosystem to avoid catastrophic attacks.


Backward Compatibility

As a series of soft forks, older nodes will continue to operate without mo= dification. Non-upgraded nodes, however, will consider all post-quantum wit= ness programs as anyone-can-spend scripts. They are strongly encouraged to = upgrade in order to fully validate the new programs.


Non-upgraded wallets can receive and send bitcoin from non-upgraded a= nd upgraded wallets until Phase A. After Phase A, they can no longer receiv= e from any other wallets and can only send to upgraded wallets. After Phas= e B, both senders and receivers will require upgraded wallets. Phase C woul= d likely require a loosening of consensus rules (a hard fork) to allow vuln= erable funds recovery via ZK proofs.

--
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@googl= egroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/173b3bc4-7052-4e0e-9042-ca15cd5b0587n%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 e= mail to bitcoindev+unsubscribe@googl= egroups.com.
To view this discussion visit https://grou= ps.google.com/d/msgid/bitcoindev/CADL_X_cgqHUOU6V9%2BGsEKz--ekxmgyYJwOg4BeL= ajAr_cTVN_g%40mail.gmail.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 e= mail to bitcoindev+unsubscribe@googl= egroups.com.
To view this discussion visit https://gr= oups.google.com/d/msgid/bitcoindev/CACgYNO%2B1tFwsd-V67fyCWv%3DWtAXp4V6RQhs= Tw8XpzYULF7u_UA%40mail.gmail.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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://= groups.google.com/d/msgid/bitcoindev/CACgYNOKz07-hU%2BbrB7NsGyD32wB6J-%2BO0= PS1RMhCs%3DgWy-vNzg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/HlXjtf= c1W4JccDWxTGiyfJC9lUvDh27nzE20yljBE6bJ35RaDC9NEwwcWNiasVkhsvS7hh0dvxXjReYLW= L6ZSkayM8mCB45kzyMAOguPk8E%3D%40proton.me.
-----------------------46039296221990024896da67d4b67d06-- -----------------------7f73f26c18c7b2deaf49f45520341338-- -----------------------531b48bcd5ca54255c46eac0460be52a Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------531b48bcd5ca54255c46eac0460be52a-- --------41fad5763bb4d923779218c9c0bde667513e16abad6b5bacb17a4ebb824c8098 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmjIPbEJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmfbEB0yQ+aJapIr+GU33BJy1EMBbIguvJaYppXf 7W7KCxYhBEdIka0CMtrLdg13a3gpbO2E9rPFAACg1QEA+m27Z9MiwgGxgCo2 Xqkl+6r6JelNNtqcfTU08jrNHQUA/2pVQu9kpAQzLRl5H2c8lXntGKVz27KR jy0PbQvdrP0F =S56G -----END PGP SIGNATURE----- --------41fad5763bb4d923779218c9c0bde667513e16abad6b5bacb17a4ebb824c8098--