From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 23 Aug 2025 10:58:07 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1upsVB-0006mP-8z for bitcoindev@gnusha.org; Sat, 23 Aug 2025 10:58:07 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-30cce54e5fcsf9463283fac.0 for ; Sat, 23 Aug 2025 10:58:04 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1755971879; cv=pass; d=google.com; s=arc-20240605; b=czIxLzeaJ/CvbAxq1UQ7I6gprsT3ADL8jjY4yXAbOeBeftyTinnnzBNYfAjAKk6TRx qZ/hNt5GcF+M56C3FfDE1pZO1cKqeof46EHGvbrnQhEufUTib8+uVIApp7Vw8PMdXflj tWWzzTCwebH9CxhbpNJDEhos9BDnqyArqECy3avmAZAH1W/5YT2tdp6LtVlnOE/014wN ZAPdq9b1rioOff2tX1+0WTtU2r6ysSyCF7/iGWa6Dx3z4F8uxTDzQeF03XdZScKHO89n zHwgF9D9Y+tIVelvJM0p9WknUtzTKC59bUl3QdrNHBwezjlSUkAqIYHWZg9T7jtlF333 wK5g== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=O0E8VixiHXTlZ8XqZ2zZFuY/8vb4JYT7g2aHewX/YcE=; fh=SlMHYZ4nVU0jJOw0Q26+bKvrA4sj5bfuu9wO5KakMw0=; b=FC1JvpVCm992wyEneU04z7QNGtGc2+ha/YTfkzWEA2NGdVfWVIwD03+6VWUpV6ZnJP NRTRjoI4YEADvOw0m82h7ENV9xGys0pN5NRaeAqdgjDmdP81r8tqH9QpfXynMcPlsUmc GkdXi1XiKH0VAFkx/hoO6Fz0vDJD3bsdTJPMjZsfJ5HzmuPRD40LuD6YZxwdGV+s5wgB WcDzN5QwFetLGLyDp5svQFElqAnZiplYh1BhVvavAQAuYS+6oWqGvMZ0902Dm2w9JSDE 7fc8Kwv6to4uxRRyHFTOztk/UIASlOKzKfiH+zPBq81Fp51nOXOtXq3scAOzCkjb7Ph0 vVKA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=kgc3ujNM; spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=saintwenhao@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1755971879; x=1756576679; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=O0E8VixiHXTlZ8XqZ2zZFuY/8vb4JYT7g2aHewX/YcE=; b=He9yjchHjI2LKS030f9JD2VMS2SUOU4VqKgEGW/HlyjaOBMzwBb1e2AtYHAUfXjiE+ ePsfFREz9uplVmUzZSWxArS7Yl+UpxCgNAr5ddhAEzCtuVCL3y7Xfwa7RguC/ubZirip bBMFTKmIh8hC0hMU8ZofYeP55BAcSlL8x/WYsw1OxvJz0USiRIJHYNe/WEjDLCizFfk3 Mw7NoJckfVCVvOv0shknCyOW0ndAm4l9bnoh5HzjUFxZRSyChSLCx5BzSbr9B3gDnuM0 SDMPoASyJu4hEbJXzE5jsP3aietpagLGsFZ5ClY1qB+cw8eivNUyPXGsEP8ahbj4UKBX wqnw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1755971879; x=1756576679; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=O0E8VixiHXTlZ8XqZ2zZFuY/8vb4JYT7g2aHewX/YcE=; b=gdKczPlGMdEQCfHpQ1vfXA0lFcIxNT3l3Dh2Wu71E4KovZJiA2J4gSPQfeXUBdZMvw VxKTq6EKGYvHRCugeywJEpg9ncNQZrCfNHNnuyqKOEYYQmZq7HjRZJJAEAdUWKm+rkz1 0Xpt9VNaYxhqBdUPcfOJtuFRbb+/Izx3zEZT5E1wSb9lSrmgs6M8Xs+vfXdjQfYIo6Ao VjHOkS4yeM1TmrveT6xHZ1v04qU9PDSUS/QzlI/XFFjNdqvIMURB5r99yZ5Va4/gOdKA C2+pmWzORVXuZFws0Zsqfz9hwYWCuJgmfKhwJM94/C30Xzdlf3KOBkNX6yS8VAfTICys eW+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755971879; x=1756576679; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=O0E8VixiHXTlZ8XqZ2zZFuY/8vb4JYT7g2aHewX/YcE=; b=fVd4JzUGtZsonxrT53JJyQdijt38dsFeJ/FdnyQC850j124rE2jN1U56aUH/eAvSH0 MStziOmKOZgBR1ZkjyWlOrecUIkamHJC5MDHCjlJyH8sNpmF/MiHVfxURhsZmLfmIrlq 4F0ttqoRj3uYG99rrsnIXRfGVOygCO99uRdrZhRjkacRxyFp6uOvMLWp1F3EH1aKtuWL U/iJG9LuE/is2OakNtC0+2RZFv/YW5bErmGC9Jge7ASwMQAsqlCCguFjnZRpNXaIHJbb LSrJj74tCjmnoUJ1+LudB3LhU062jVH2oseyKB9Zt/cBWJpofs02rBcUKftt/imX0lhx G/Xw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWoxXVs3bKTrNMBB6ypaYiM1gKru+SvpevvnOzRcbaysnNwZEroHAKHywJhPgq5gtYMUGGJsxVaH3AE@gnusha.org X-Gm-Message-State: AOJu0YwxAtVoP/GRh0axe6YuedfhJz1UOoXGFvRy1JK+iljyi9URp23d wnqImUEwBieb3Ej1CgWprbnFa10E21vpBZxhnKchU0HI59bxzptYnCR9 X-Google-Smtp-Source: AGHT+IEXvMaZubnYuLco784Izkk5xJR624uopZZGDVUCB/h36RFL61lXlZD/KJpKNpw7uwKJlRVE5w== X-Received: by 2002:a05:6870:2491:b0:30b:dd94:bfb3 with SMTP id 586e51a60fabf-314dce183camr3292535fac.25.1755971878343; Sat, 23 Aug 2025 10:57:58 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdi1ECHvFslWw8QEN4lvdDOlw6eiTsNOiJZIK/lpY3yPg== Received: by 2002:a05:6871:88d:b0:306:e7d7:f921 with SMTP id 586e51a60fabf-314c228fbb8ls1914113fac.1.-pod-prod-08-us; Sat, 23 Aug 2025 10:57:54 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCUhsVuDjjCrXPeYwRIsvq7VZ7IaMHid+opNPqFo8tS/21gieIN8GlbU/itgDHSq1fa178217BgodVTW@googlegroups.com X-Received: by 2002:a05:6808:3096:b0:437:75ea:6c8a with SMTP id 5614622812f47-43785306c51mr3099628b6e.50.1755971874353; Sat, 23 Aug 2025 10:57:54 -0700 (PDT) Received: by 2002:a05:600c:8212:b0:456:11e5:963 with SMTP id 5b1f17b1804b1-45b57169a15ms5e9; Sat, 23 Aug 2025 03:22:36 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXYB4deU5JOgK3K9iWB7QLPqgDzBr0p9DUkAuIOX/tWJX/iR93VidOUBY0EZsazTW6qF8EK7sIYf/1S@googlegroups.com X-Received: by 2002:a05:6000:400e:b0:3b7:9c79:3293 with SMTP id ffacd0b85a97d-3c5dce05162mr5538851f8f.58.1755944554601; Sat, 23 Aug 2025 03:22:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1755944554; cv=none; d=google.com; s=arc-20240605; b=GZbPeaJLBxMT0MMDxV0guexO3I2b/Q0Rpn6vmccpx7cTjIxO+U2Db45H0qu1jaZAiX OCFfKyp1eXRutz43QhdiNkwnm89vMdUjYWFdXGVKdUKjVj6NslQnfkJRLwSjfaalEQsS QjS272UKoJ32fi0Zpe4dx7UB/6k5RaszPG98NaHFcrxswYe5lGECj3t+y81aTVVJ9E73 qt884NWV2ffl59NoorbxVeruVFX7Y/PTyHAWNE3X/x3LwuAeL1ljgMtxZ/aSqCiUfekk PccMJ46+ZWGFVNv2USET/iNHtNa4pCu7ZHKWmw6nnZFNUNNERNJIS3D3/jTiRGkJqocZ R9OA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=ZT7wjpkPwYp2LD1vIcVemrDFId36m0a4RIcDoxov1qo=; fh=PgVsvvpAjFfhN2fH+B1QY4HEaMK5QaklkgcV/9dxtiA=; b=bqXsjLt3UY6VrPYARnd/gbWzY04qqNy7fnjoAT6dEqW2Z0A0u9aJnq3rKNsOxV4cg4 /bJx4r21A7wctj3vMH4ZwBiB6+B1BdBTAFztO6D8ch+E7OJDJ3zrojLPOuBSPqOcBCbC JVuBzwFLJWmcNVUdQDQHzeBmjbV0hjjys1kILoiCHo7M5w6F+nuyENHtr0jdZOqYsEhf kZZLqmE/PCTuUnJfboivhAvgbLHIcHVdNYhJmhPf1vEpQ9cEZHYKHv5DFqPkYe91TXMk HeClDEqz5/UDgll3TYcogvU7nu9/oorZjZzqqO8lsPlJ/RDgvvfD3h23TQilgz9axt8S J5+w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=kgc3ujNM; spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=saintwenhao@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com. [2a00:1450:4864:20::531]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-3c710d423e0si36489f8f.5.2025.08.23.03.22.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 Aug 2025 03:22:34 -0700 (PDT) Received-SPF: pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) client-ip=2a00:1450:4864:20::531; Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-6188b72b7caso3974443a12.2 for ; Sat, 23 Aug 2025 03:22:34 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXm8Iy0vQVLit0bKeaGqNfDEHhE4ZNwnlMKsQJsDgV3OJ1uKnDMRkSnBdkig5gZNTI+tYDkXlES4P3S@googlegroups.com X-Gm-Gg: ASbGncsHOj3Yhm3uJHOgJDvZCvIr3US6UA1wU17w9OZ12gIkAaCCt0ujaOXlcb2hM5D Ubgd0O3r4+XGzh1+v1z5T+f+0imF7UTHalZ4gS6Ir+6xXMX8J0Wtabf3Jbuddc9dkTfoOI7lK9g SJGm4D4YQa7TZG4eYAF9E/pccFCQhc6ApDK8mTXbZ2nu2cVqrZP3lac5Eyx+aQxdgXg5I9CAop5 LRXQQI= X-Received: by 2002:a05:6402:2712:b0:61a:9385:c77f with SMTP id 4fb4d7f45d1cf-61c1b712de8mr4279600a12.36.1755944553646; Sat, 23 Aug 2025 03:22:33 -0700 (PDT) MIME-Version: 1.0 References: <173b3bc4-7052-4e0e-9042-ca15cd5b0587n@googlegroups.com> In-Reply-To: From: Saint Wenhao Date: Sat, 23 Aug 2025 12:22:22 +0200 X-Gm-Features: Ac12FXyYpMLq8KEriNV50DWBqn3WbReOG0q7gSjhtjlk-sIyP92ZjITOdK0qaNI Message-ID: Subject: Re: [bitcoindev] Re: A Post Quantum Migration Proposal To: conduition Cc: Jameson Lopp , Marc Johnson , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000005d94be063d05b3a1" X-Original-Sender: saintwenhao@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=kgc3ujNM; spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=saintwenhao@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com 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: -0.5 (/) --0000000000005d94be063d05b3a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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. 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 napisa=C5=82(a): > If someone has some coins, then the public key cannot be changed, if it i= s > present in the output Script. However, R-value can be freely picked by th= e > 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 chosen by the signer, so the quantum attacker could > pick any arbitrary PQ signature data and commit it at spending time too. > > Lopp's point is that unless the output script has committed to a PQ publi= c > key in some way *prior* to a CRQC arriving, then 3rd party nodes can't > know whether a spend that occurs *after* a CRQC has appeared is genuine. > Any such commitments require positive action 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 use: one is public key, another > is R-value in the signature. If someone has some coins, then the public k= ey > cannot be changed, if it is present in the output Script. However, R-valu= e > 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 also means, that old nodes can see only ECDSA signatures, and publi= c > keys, while new, quantum-resistant nodes, can require R-value to commit t= o > something. Then, in the first phase, when quantum commitments will be > optional, users will use only ECDSA on-chain, but new, quantum nodes, wil= l > be able to see, what is committed to R-values behind signatures, and can > store and process it. > > 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. Which also means, that the new > quantum 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 (which can be set to different values, for different quantum > proposals, depending on a particular signature scheme). > > pon., 18 sie 2025 o 19:12 Jameson Lopp > napisa=C5=82(a): > >> >> >> On Thu, Aug 7, 2025 at 7:26=E2=80=AFPM Marc Johnson >> wrote: >> >>> 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 >>> thinking that went into this migration plan. However, I=E2=80=99d like = to >>> respectfully raise some concerns about the approach and share an >>> alternative perspective from work we=E2=80=99ve been doing in this spac= e. >>> >>> ## Concerns with the Forced Sunset Approach >>> >>> The proposal=E2=80=99s Phase B - rendering ECDSA/Schnorr spends invalid= - >>> essentially threatens users with permanent fund loss. This creates seve= ral >>> issues: >>> >>> 1. **Violation of Bitcoin=E2=80=99s Social Contract**: Satoshi=E2=80=99= s principle that >>> =E2=80=9Clost coins only make everyone else=E2=80=99s coins worth sligh= tly 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. >>> >>> 2. **The 25% Problem**: With ~5.25 million BTC having exposed public >>> keys, forcing these to become unspendable could create massive economic >>> disruption. Many of these may be genuinely lost coins, but some could b= e >>> long-term cold storage, inheritance situations, or users who simply mis= s >>> the migration window. >>> >>> 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. >>> >>> ## An Alternative Approach: Learning from Supernova >>> >>> Our team has been working on these exact problems and recently reached >>> production readiness with Supernova - a Bitcoin-inspired blockchain tha= t >>> implements quantum resistance from genesis. Rather than forced migratio= n, >>> we use a dual-signature scheme that might be instructive for Bitcoin: >>> >> >> 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 sch= eme >> if they have not committed to a dual signature scheme? In order to take >> advantage of this setup on Bitcoin, you just end up recreating 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 signatures only >>> >>> 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 >>> >>> ## Key Innovations Worth Considering >>> >>> 1. **Hybrid Signatures**: Instead of a hard cutoff, transactions can >>> require both classical and quantum signatures during transition. This >>> provides quantum security while maintaining compatibility. >>> >>> 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. >>> >>> 3. **No Coordination Required**: Users can independently decide when to >>> migrate without waiting for ecosystem-wide coordination. >>> >>> 4. **Proven Implementation**: We=E2=80=99ve demonstrated this works in >>> production, including the world=E2=80=99s first quantum-resistant Light= ning Network. >>> >>> ## A Cooperative Path Forward >>> >>> Rather than viewing this as competition, I see opportunity for >>> collaboration. Supernova could serve as a real-world testbed for quantu= m >>> migration strategies. We=E2=80=99ve already implemented: >>> >>> - NIST-standardized algorithms (Dilithium, SPHINCS+, Falcon) >>> - Quantum-resistant atomic swaps with Bitcoin >>> - Full Lightning Network with quantum HTLCs >>> - Zero-knowledge proofs for enhanced privacy >>> >>> Bitcoin could learn from our implementation experience, while we >>> continue to honor Bitcoin=E2=80=99s principles of decentralization and = sound money. >>> >>> ## Invitation to Explore >>> >>> For those interested in seeing quantum resistance in action today rathe= r >>> than waiting years, I invite you to explore Supernova. We=E2=80=99re la= unching 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 decentralized money. Whether through Bitcoin=E2=80=99s ev= entual >>> upgrade or alternatives 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/Carbon-Twelv= e-C12/supernova) >>> >>> >>> Would love to hear thoughts on the dual-signature approach and whether >>> something similar could work for Bitcoin without the harsh sunset >>> provisions. >>> >>> --- >>> >>> *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 qua= ntum >>> transition. These challenges affect us all.* >>> >>> On Sunday, July 20, 2025 at 11:56:48=E2=80=AFPM UTC+1 Boris Nagaev wrot= e: >>> >>>> Hi Jameson, hi all! >>>> >>>> I have a couple of ideas on how to preserve more funds during any kind >>>> of fork that constrains or blocks currently used spending scenarios. T= his >>>> applies to both freezing and commit/reveal schemes; the latter may res= ult >>>> 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 incrementally across the UTXO set*= . >>>> Instead of freezing or constraining all UTXOs at once, we split the UT= XO >>>> 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 ow= ners >>>> will be harmed. >>>> >>>> Another approach is to *provide a temporary opt-out option*. If >>>> someone finds themselves blocked, they would still have a limited time= to >>>> take an action, without requiring any extra knowledge, to get unblocke= d. >>>> This would help raise awareness. After being temporarily blocked and >>>> recovering their funds through the opt-out mechanism, the person would >>>> understand that they need to take further steps with their remaining c= oins >>>> to avoid being permanently blocked once the opt-out period ends. The a= ction >>>> to unblock the funds could be as simple as sending a transaction with >>>> OP_RETURN "opt-out ", which would enable the old acceptance rule= s for >>>> the transaction with that txid for a period of 2016 blocks. >>>> >>>> >>>> [1] https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/57bQJ3VSCQA= J >>>> In that scheme if the pubkey is leaked, anyone can post a valid >>>> commitment with a random TXID blocking the coin forever. >>>> >>>> Best, >>>> Boris >>>> >>>> On Saturday, July 12, 2025 at 9:46:09=E2=80=AFPM UTC-3 Jameson Lopp wr= ote: >>>> >>>> Building upon my earlier essay against allowing quantum recovery of >>>> bitcoin >>>> >>>> I wish to formalize a proposal after several months of discussions. >>>> >>>> This proposal does not delve into the multitude of issues regarding >>>> post quantum cryptography and trade-offs of different schemes, but rat= her >>>> is meant to specifically address the issues of incentivizing adoption = and >>>> migration of funds *after* consensus is established that it 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 (PQ) output >>>> type (P2QRH) and introduces a pre-announced sunset of legacy ECDSA/Sch= norr >>>> signatures. It turns quantum security into a private incentive: fail >>>> to upgrade and you will certainly lose access to your funds, creating = a >>>> certainty where none previously existed. >>>> >>>> - >>>> >>>> Phase A: Disallows sending of any funds to quantum-vulnerable >>>> addresses, hastening the adoption of P2QRH address types. >>>> - >>>> >>>> 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. >>>> - >>>> >>>> Phase C (optional): Pending further research and demand, a separate >>>> BIP proposing a fork to allow recovery of legacy UTXOs through ZK p= roof of >>>> possession of BIP-39 seed phrase. >>>> >>>> Motivation >>>> >>>> We seek to 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 threat posed by quantum computin= g is >>>> radically different from any other threat in Bitcoin=E2=80=99s history= . Never >>>> before has Bitcoin faced an existential threat to its cryptographic >>>> primitives. A successful quantum attack on Bitcoin would result in >>>> significant economic disruption and damage across the entire ecosystem= . >>>> Beyond its impact on price, the ability of miners to provide network >>>> security may be significantly impacted. >>>> >>>> - >>>> >>>> Accelerating quantum progress. >>>> - >>>> >>>> NIST ratified three production-grade PQ signature schemes in >>>> 2024; academic road-maps now estimate a cryptographically-releva= nt 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 hardware requirements for breaking clas= sical >>>> 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 may not know the attack is underway. >>>> - >>>> >>>> Quantum attackers could compute the private key for known 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 = the attack >>>> withholds broadcasting transactions in order to postpone reveali= ng their >>>> capabilities. >>>> - >>>> >>>> Private keys become public. >>>> - >>>> >>>> Assuming that quantum computers are able to maintain their >>>> current trajectories and overcome existing engineering obstacles= , there is >>>> a near certain chance that all P2PK (and other outputs with expo= sed >>>> pubkeys) private keys will be found and used to steal the funds. >>>> - >>>> >>>> Impossible to know motivations. >>>> - >>>> >>>> Prior to a quantum attack, it is impossible to know the >>>> motivations of the attacker. An economically motivated attacker = will try to >>>> remain undetected for as long as possible, while a malicious att= acker will >>>> attempt to destroy as much value as possible. >>>> - >>>> >>>> Upgrade inertia. >>>> - >>>> >>>> Coordinating wallets, exchanges, miners and custodians >>>> historically takes years. >>>> - >>>> >>>> The longer we postpone migration, the harder it becomes to >>>> coordinate wallets, exchanges, miners, and custodians. A clear, = time-boxed >>>> pathway is the only credible defense. >>>> - >>>> >>>> Coordinating distributed groups is more prone to delay, even if >>>> everyone has similar motivations. Historically, Bitcoin has been= slow to >>>> adopt code changes, often taking multiple years to be approved. >>>> >>>> Benefits at a Glance >>>> >>>> - >>>> >>>> Resilience: Bitcoin protocol remains secure for the foreseeable >>>> future without waiting for a last-minute emergency. >>>> - >>>> >>>> Certainty: Bitcoin users and stakeholders gain certainty that a >>>> plan is both in place and being implemented to effectively deal wit= h 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 migrate become >>>> unspendable, reducing supply, as Satoshi described >>>> . >>>> >>>> Specification >>>> >>>> Phase >>>> >>>> What Happens >>>> >>>> Who Must Act >>>> >>>> Time Horizon >>>> >>>> Phase A - Disallow spends to legacy script 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 spends from quantum vulnerable outputs >>>> >>>> At a preset block-height, nodes reject transactions that rely on >>>> ECDSA/Schnorr keys. >>>> >>>> Everyone holding or accepting BTC. >>>> >>>> 2 years after Phase A activation. >>>> >>>> Phase 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 funds. >>>> >>>> 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 >>>> cryptographically relevant quantum computer, widespread knowledge t= hat such >>>> a computer exists and is capable of breaking Bitcoin=E2=80=99s cryp= tography will >>>> damage faith in the network . >>>> - >>>> >>>> An attack on Bitcoin may not be economically motivated - an >>>> attacker may be politically or maliciously motivated and may attemp= t to >>>> destroy value and trust in Bitcoin rather than extract value. There= is no >>>> way to know in advance how, when, or why an attack may occur. A def= ensive >>>> position must be taken well in advance of any attack. >>>> - >>>> >>>> Bitcoin=E2=80=99s current signatures (ECDSA/Schnorr) will be a tant= alizing >>>> target: any UTXO that has ever exposed its public key on-chain (rou= ghly 25 >>>> % of all bitcoin) could be stolen by a cryptographically relevant q= uantum >>>> computer. >>>> - >>>> >>>> Existing Proposals are Insufficient. >>>> 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 propo= sals: >>>> 1. >>>> >>>> Allow anyone to steal vulnerable coins, benefitting those who >>>> reach quantum capability earliest. >>>> 2. >>>> >>>> Allow throttled theft of coins, which leads to RBF battles >>>> and ultimately miners subsidizing their revenue from lost coi= ns. >>>> 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 historically taken many years; this >>>> will hasten and speed up the adoption of new quantum resistant s= cript >>>> types. >>>> 3. >>>> >>>> With a clear deadline, industry stakeholders will more readily >>>> upgrade existing infrastructure to ensure continuity of services= . >>>> - >>>> >>>> Minimizes loss of access to funds >>>> 1. >>>> >>>> If there is sufficient demand and research proves possible, >>>> submitting a ZK proof of knowledge of a BIP-39 seed phrase corre= sponding to >>>> a public key hash or script hash would provide a trustless means= for legacy >>>> outputs to be spent in a quantum resistant manner, even after th= e 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 space 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 both = their >>>> hardware and Bitcoin as a whole. >>>> >>>> Institutional Holders >>>> >>>> =E2=80=A2 Fiduciary duty: failing to act to prevent a quantum attack o= n Bitcoin >>>> would violate the fiduciary duty to shareholders. >>>> >>>> =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to effectively mitig= ate emerging >>>> threats will prove Bitcoin to be an investment grade asset. >>>> >>>> Exchanges & Custodians >>>> >>>> =E2=80=A2 Concentrated risk: a quantum hack could bankrupt them overni= ght. >>>> >>>> =E2=80=A2 Early migration is cheap relative to potential losses, poten= tial >>>> lawsuits over improper custody and reputational damage. >>>> >>>> Everyday Users >>>> >>>> =E2=80=A2 Self-sovereign peace of mind. >>>> >>>> =E2=80=A2 Sunset date creates a clear deadline and incentive to improv= e their >>>> security rather than an open-ended =E2=80=9Csome day=E2=80=9D that inv= ites procrastination. >>>> >>>> Attackers >>>> >>>> =E2=80=A2 Economic incentive diminishes as sunset nears, stolen coins = cannot be >>>> spent after Q-day. >>>> >>>> Key Insight: As mentioned earlier, the proposal turns quantum security >>>> into a private incentive to upgrade. >>>> >>>> This is not an offensive attack, rather, it is defensive: our thesis i= s >>>> that the Bitcoin ecosystem wishes to defend itself and its interests >>>> against those who would prefer to do nothing and allow a malicious act= or to >>>> destroy both value and trust. >>>> >>>> >>>> "Lost coins only make everyone else's coins worth slightly more. 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 less. >>>> Think of it as a theft from everyone." >>>> >>>> >>>> The timelines that we are proposing are meant to find the best balance >>>> between giving ample ability for account owners to migrate while >>>> maintaining the integrity of the overall ecosystem to avoid catastroph= ic >>>> attacks. >>>> >>>> Backward Compatibility >>>> >>>> As a series of soft forks, older nodes will continue to operate withou= t >>>> modification. Non-upgraded nodes, however, will consider all post-quan= tum >>>> witness programs as anyone-can-spend scripts. They are strongly encour= aged >>>> to upgrade in order to fully validate the new programs. >>>> >>>> Non-upgraded wallets can receive and send bitcoin from non-upgraded an= d >>>> upgraded wallets until Phase A. After Phase A, they can no longer rece= ive >>>> from any other wallets and can only send to upgraded wallets. After Ph= ase >>>> B, both senders and receivers will require upgraded wallets. Phase C w= ould >>>> likely require a loosening of consensus rules (a hard fork) to allow >>>> vulnerable 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 email to bitcoindev+unsubscribe@googlegroups.com. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/173b3bc4-7052-4e0e-9042-ca= 15cd5b0587n%40googlegroups.com >>> . >>> >> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CADL_X_cgqHUOU6V9%2BGsEKz--= ekxmgyYJwOg4BeLajAr_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 > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CACgYNO%2B1tFwsd-V67fyCWv%3D= WtAXp4V6RQhsTw8XpzYULF7u_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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CACgYNOKz07-hU%2BbrB7NsGyD32wB6J-%2BO0PS1RMhCs%3DgWy-vNzg%40mail.gmail.com. --0000000000005d94be063d05b3a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> The ECDSA R value is chosen by the signer, so the qua= ntum attacker=20 could pick any arbitrary PQ signature data and commit it at spending=20 time too.

In the current consensus? Yes. But it is possible to=20 require a particular value in the future. Or: a particular format, for=20 example by requiring DER signatures to take less than N bytes (also,=20 relative timelocks are possible, so that the smaller signature will be=20 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=20 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=20 always use time travel. If there is no consensus, then just timelock=20 every OP_CHECKSIG call to a few years, and think about it later. If=20 after few years, there is still no consensus, how to migrate funds, then timelock it again. Then, sooner or later, some consensus will be=20 reached. And if not, then people can still use OP_SIZE, to require a=20 given amount of Proof of Work, and if nothing is deployed, then pure=20 hashrate can still decide, who owns what, until people will agree on=20 something better.

pt., 22 sie 2025 o 21:59=C2=A0condui= tion <conduition@proton.me&g= t; napisa=C5=82(a):
If someo= ne 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.
...
And later, when quantum signa= tures 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 sig= nature.

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 = script has committed to a PQ public key in some way prior=C2=A0to a = CRQC arriving, then 3rd party nodes can't know whether a spend that occ= urs after=C2=A0a CRQC has appeared is genuine. Any such commitments = require positive action 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= , but rather by a combination of sigops limit, and a quantum commitment siz= e limit (which can be set to different values, for different quantum propos= als, depending on a particular signature scheme).

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


On Thu, Aug 7, 2025 at 7:26=E2=80=AFPM Ma= rc Johnson <marcjohnson518@gmail.com> wro= te:
Hi All!
<= br>I'd first like to say thank you to James for the comprehensive propo= sal. The quantum threat is indeed existential, and I appreciate the detaile= d thinking that went into this migration plan. However, I=E2=80=99d like to= respectfully raise some concerns about the approach and share an alternati= ve perspective from work we=E2=80=99ve been doing in this space.

## = Concerns with the Forced Sunset Approach

The proposal=E2=80=99s Phas= e B - rendering ECDSA/Schnorr spends invalid - essentially threatens users = with permanent fund loss. This creates several issues:

1. **Violatio= n of Bitcoin=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 = forcibly lost.=E2=80=9D This fundamentally changes Bitcoin=E2=80=99s value = proposition.

2. **The 25% Problem**: With ~5.25 million BTC having e= xposed public keys, forcing these to become unspendable could create massiv= e economic disruption. Many of these may be genuinely lost coins, but some = could be long-term cold storage, inheritance situations, or users who simpl= y miss the migration window.

3. **Timeline Risk**: The 5+ year timel= ine (3 years post-BIP-360 + 2 years) assumes smooth consensus and implement= ation. Given Bitcoin=E2=80=99s history, this could easily stretch to 7-10 y= ears, most likely pushing implementation past the 2027-2030 quantum timelin= e mentioned.

## An Alternative Approach: Learning from Supernova
=
Our team has been working on these exact problems and recently reached = production readiness with Supernova - a Bitcoin-inspired blockchain that im= plements 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 m= igration problem; how would currently locked funds be able to spend via a q= uantum 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 recreating the migration problem.


**Three Modes of Operation:**
- **L= egacy Mode**: ECDSA signatures only (Bitcoin-compatible)
- **Transition = Mode**: Both ECDSA and quantum signatures required
- **Quantum Mode**: Q= uantum signatures only

This approach:
- Never locks users out of = their funds
- Allows gradual, voluntary migration
- Maintains backwar= ds compatibility 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 class= ical and quantum signatures during transition. This provides quantum securi= ty while maintaining compatibility.

2. **Address Format Compatibilit= y**: Our quantum addresses (snq1...) coexist with standard addresses (sn1..= .), allowing users to choose their security level per transaction rather th= an per wallet.

3. **No Coordination Required**: Users can independen= tly decide when to migrate without waiting for ecosystem-wide coordination.=

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

## A Cooperative Path Forward

Rather than viewi= ng this as competition, I see opportunity for collaboration. Supernova coul= d serve as a real-world testbed for quantum migration strategies. We=E2=80= =99ve already implemented:

- NIST-standardized algorithms (Dilithium= , SPHINCS+, Falcon)
- Quantum-resistant atomic swaps with Bitcoin
- F= ull Lightning Network with quantum HTLCs
- Zero-knowledge proofs for enh= anced privacy

Bitcoin could learn from our implementation experience= , while we continue to honor Bitcoin=E2=80=99s principles of decentralizati= on and sound money.

## Invitation to Explore

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

The = quantum threat is real, and we need multiple approaches to ensure the futur= e of decentralized money. Whether through Bitcoin=E2=80=99s eventual upgrad= e or alternatives like Supernova, the important thing is that we act before= it=E2=80=99s too late.

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

Would love to hear tho= ughts on the dual-signature approach and whether something similar could wo= rk for Bitcoin without the harsh sunset provisions.

---

*Note= : While I represent the Supernova project, I=E2=80=99m also a long-time Bit= coin supporter who wants to see the entire ecosystem survive the quantum tr= ansition. These 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 preserve more funds during any kind of fork that constrains or b= locks currently used spending scenarios. This applies to both freezing and = commit/reveal schemes; the latter may result in lost funds if the public ke= y 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 su= ch forks incrementally across the UTXO set. Instead of freezing or cons= training all UTXOs at once, we split the UTXO set into 256 groups determini= stically (for example, by looking at the first byte of the TXID) and apply = the constraints over 256 days, processing one group per day. Procrastinator= s will learn what is happening through word of mouth, act to save their fun= ds, and only a small percentage of coin owners will be harmed.
Another approach is to provide a temporary opt-out option. If someone finds themselves blocked, they would still have a limited ti= me to take an action, without requiring any extra knowledge, to get unblock= ed. This would help raise awareness. After being temporarily blocked and re= covering their funds through the opt-out mechanism, the person would unders= tand that they need to take further steps with their remaining coins to avo= id being permanently blocked once the opt-out period ends. The action to un= block the funds could be as simple as sending a transaction with OP_RETURN = "opt-out <txid>", which would enable the old acceptance rul= es 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 commitment with a random TXID blocking the coin forever.

Best,
Boris

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

Buil= ding upon my earlier essay against allowing quantum recovery of bitcoin I wish to formalize a proposal after several months of discussions.

This proposal does not delve into the multitude of issues regardi= ng post quantum cryptography and trade-offs of different schemes, but rathe= r is meant to specifically address the issues of incentivizing adoption and= migration of funds after cons= ensus is established that it 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 implem= entation of post-quantum (PQ) output type (P2QRH) and introduces a pre-anno= unced sunset of legacy ECDSA/Schnorr signatures. It turns quantum security = into a private incentive: fail to upgrade and you will certainly lose access to your funds, cr= eating a certainty where none previously existed.

  • Phase A: Disallows sending of any f= unds to quantum-vulnerable addresses, hastening the adoption of P2QRH addre= ss types.

  • Phase B: Renders ECDSA/Schnorr spends inval= id, preventing all spending of funds in quantum-vulnerable UTXOs. This is t= riggered by a well-publicized flag-day roughly five years after activation.=

  • Phase C = (optional): Pending further research and dem= and, a separate BIP proposing a fork to allow recovery of legacy UTXOs thro= ugh ZK proof of possession of BIP-39 seed phrase.

Motivation

We seek to secure the value of the UTXO set and minimize incentives for quantum at= tacks. This proposal is radically different from any in Bitcoin=E2=80=99s h= istory just as the threat posed by quantum computing is radically different= from any other threat in Bitcoin=E2=80=99s history. Never before has Bitc= oin faced an existential threat to its cryptographic primitives. A successf= ul quantum attack on Bitcoin would result in significant economic disruptio= n and damage across the entire ecosystem. Beyond its impact on price, the a= bility of miners to provide network security may be significantly impacted.=

  • Accelerating quantum progress.<= 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">

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

  • Quantum algorith= ms are rapidly improving

    • The safety e= nvelope is shrinking by dramatic increases in algorithms even if the pace o= f hardware improvements is slower. Algorithms are improving up to 20X, lower= ing the theoretical hardware 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. <= /p>

  • We may not know the attack is underway.

    • Quantum attackers could compute the private key for know= n public keys then transfer all funds weeks or months later, in a covert bl= eed to not alert chain watchers. Q-Day may be only known much later if the = attack withholds broadcasting transactions in order to postpone revealing t= heir capabilities.

  • Private keys become public.

    • Assuming that quantum computers are able to mainta= in their current trajectories and overcome existing engineering obstacles, = there is a near certain chance that all P2PK (and other outputs with expose= d pubkeys) private keys will be found and used to steal the funds.

  • Impossi= ble to know motivations.

    • Prior to a quantum attack, it is impossible to know the motivations of th= e attacker. An economically motivated attacker will try to remain undetect= ed for as long as possible, while a malicious attacker will attempt to dest= roy as much value as possible.

  • Upgrade inertia.

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

    • The longer we postpone migration, the harder i= t becomes to coordinate wallets, exchanges, miners, and custodians. A clear= , time-boxed pathway is the only credible defense.

    • Coordinating distributed = groups is more prone to delay, even if everyone has similar motivations. Hi= storically, Bitcoin has been slow to adopt code changes, often taking multi= ple years to be approved.

Benefits at a Glance

  • Resilience: Bitcoin protoc= ol remains secure for the foreseeable future without waiting for a last-min= ute emergency.

  • Certainty: Bitcoin = users and stakeholders gain certainty that a plan is both in place and bein= g implemented to effectively deal with the threat of quantum theft of bitco= in.

  • Clarity: A single, publiciz= ed timeline aligns the entire ecosystem (wallets, exchanges, hardware vendo= rs).

  • Supply Discipline: Abandon= ed keys that never migrate become unspendable, reducing supply, as Satoshi described<= span style=3D"font-size:11pt;font-family:"Courier New",monospace;= background-color:transparent;font-variant-numeric:normal;font-variant-east-= asian:normal;font-variant-alternates:normal;vertical-align:baseline">.

Specification<= /span>

Phase

<= /span>

What Happens

= Who Must Act

Time Horizon

Phase A - Dis= allow spends to legacy script types

Permitted sends are from legacy sc= ripts to P2QRH scripts

Everyone h= olding or accepting BTC.

3 years after BIP-360 implementation

Phase B =E2=80=93 Disallow spends from quantum vulnerable outputs

=

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

Everyone holding or accepting BT= C.

2 years after Phase A activation.

Phase C =E2=80=93 Re-enable spend= s from quantum vulnerable outputs via ZK Proof

Users with frozen quant= um vulnerable funds and a HD wallet seed phrase can construct a quantum saf= e ZK proof to recover funds.

Users who failed to migrate funds before = Phase B.

TBD pending research, demand, and consensus.

Rationale

  • Even if Bitcoin is not a primary ini= tial target of a cryptographically relevant quantum computer, widespread kn= owledge that such a computer exists and is capable of breaking Bitcoin=E2= =80=99s cryptography will damage faith in the network .

    • An attack on Bitcoin may= not be economically motivated - an attacker may be politically or maliciou= sly motivated and may attempt to destroy value and trust in Bitcoin rather = than extract value. There is no way to know in advance how, when, or why a= n attack may occur. A defensive position must be taken well in advance of = any attack.

  • Bitcoin=E2=80=99s current signatures (ECDSA/Schnorr) will be a tant= alizing target: any UTXO that has ever exposed its public key on-chain (rou= ghly 25 % of all bitcoin) could be stolen by a cryptographically relevant q= uantum computer.

  • Existing Proposals = are Insufficient.

    1. =

      Any propos= al that allows for the quantum theft of =E2=80=9Clost=E2=80=9D bitcoin is c= reating a redistribution dilemma. There are 3 types of proposals:

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

      2. Allow throttled = theft of coins, which leads to RBF battles and ultimately miners subsidizin= g their revenue from lost coins.

      3. Allow no one to steal vulnerable coins.

  • Minimizes attack surface

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

      <= /li>
    2. =

      Upgrades t= o Bitcoin have historically taken many years; this will hasten and speed up= the adoption of new quantum resistant script types.

    3. With a clear deadlin= e, industry stakeholders will more readily upgrade existing infrastructure = to ensure continuity of services.

  • Minimizes loss of a= ccess to funds

      If there is suf= ficient demand and research proves possible, submitting a ZK proof of knowl= edge of a BIP-39 seed phrase corresponding to a public key hash or script = hash would provide a trustless means for legacy outputs to be spent in a qu= antum resistant manner, even after the sunset.

    • <= /ul>

    Stakeholder

    Incentive to Upgrade

    Miners

    =E2=80=A2 Larger = size PQ signatures along with incentive for users to migrate will create mo= re demand for block space and thus higher fees collected by miners.<= /p>

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

    =E2=80=A2 A quantum attack on Bitcoin will si= gnificantly devalue both their hardware and Bitcoin as a whole.

    =

    Institutional Holders

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

    =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to effectively miti= gate emerging threats will prove Bitcoin to be an investment grade asset.

    Exchanges & = Custodians

    =E2=80=A2 Concentrated risk: a quantum hack could bankrupt the= m overnight.

    =E2=80=A2 Early migration is cheap relat= ive to potential losses, potential lawsuits over improper custody and reput= ational damage.

    Everyday Users

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

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

    Attackers

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

    Key = Insight: As mentioned earlier, the proposal turns quantu= m security into a private incentive to= upgrade.

    This is not an offensi= ve attack, rather, it is defensive: our thesis is that the Bitcoin ecosyste= m wishes to defend itself 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 el= se's coins worth slightly more. Think of it as a donation to everyone.&= quot; - Satoshi Nakamoto

    If true, the co= rollary is:


    "Quantum recovered coin= s only make everyone else's coins worth less. Think of it as a theft fr= om everyone."

    The timelines that we= are proposing are meant to find the best balance between giving ample abil= ity for account owners to migrate while maintaining the integrity of the ov= erall ecosystem to avoid catastrophic attacks.


    Backward Compatibility

    As a series of soft for= ks, older nodes will continue to operate without modification. Non-upgraded= nodes, however, will consider all post-quantum witness programs as anyone-= can-spend scripts. They are strongly encouraged to upgrade in order to full= y validate the new programs.


    Non-upgraded wallets= can receive and send bitcoin from non-upgraded and upgraded wallets until = Phase A. After Phase A, they can no longer receive from any other wallets a= nd can only send to upgraded wallets. After Phase B, both senders and rece= ivers will require upgraded wallets. Phase C would likely require a looseni= ng of consensus rules (a hard fork) to allow vulnerable funds recovery via = ZK proofs.

--
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 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 &= quot;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 &= quot;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 &= 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.co= m/d/msgid/bitcoindev/CACgYNOKz07-hU%2BbrB7NsGyD32wB6J-%2BO0PS1RMhCs%3DgWy-v= Nzg%40mail.gmail.com.
--0000000000005d94be063d05b3a1--