Delivery-date: Fri, 22 Aug 2025 15:05:57 -0700 Received: from mail-qt1-f184.google.com ([209.85.160.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1upZtS-0006qV-MT for bitcoindev@gnusha.org; Fri, 22 Aug 2025 15:05:57 -0700 Received: by mail-qt1-f184.google.com with SMTP id d75a77b69052e-4b10946ab41sf61291561cf.0 for ; Fri, 22 Aug 2025 15:05:54 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1755900348; cv=pass; d=google.com; s=arc-20240605; b=PWUj9XD6voAgsAFO6bKOjkXIlfCsON/ZOT7li1kVhCcA0whgcMp51zHUoGgijGGFjH kOshzSDoA127+kr2JTgphOFzY+tqgnhb3MWDem5UorBoGvJsoG5k3yNlAnaO49OhyZJV ONQTTmp1CkQLvpV4mvuicx7dRE/E6y6GdWlj4+Twa/ggwwrFfEvCK81qfVdA2gTvHrfN eG17tZbpkJPQjLyIDX/LSEqC4mVE0hiT/YVyqJvLIQhVU4bBe/r5WmPKDc86ex2CI+GI tsB0tSeWpcPG5EamGisXkk4SMtSkcxXTQgXcbBuNrpXN/7XjWUBuocQnp2GfuJ3wsT7b Ww3A== 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=ZYliD66L+2M2m3AodydHjxAyFCJZV6RrfyDLDp7pIWk=; fh=0Ds/5+QsMA9arv62If/zmPOmyQOqxONYq8XimHanGa0=; b=OCijgv17FKZ8GtlxtUwJA3S+v8+pzLKGhESWc978Ej8Sl7dFsW7MdEJueiFa9t/p6e N9ZlphNWaa4xkQYdi/83neYMHlJAMw0VMdJmzJnk1M23vTIq4TD9NcvcoG3xFgvyXwCa sgzK3YN69y7uoyKOSMcSTQFE8yH/r+30gIEjd0CUBwUwlde3TnIftXdek2ovfjaM1t4/ vbfSjHflQZdbnbIVyZQRIU7rwQEnZ+vuylPfAk74FUsE2az+lhucGcmVWiP+Vylit6vR 90s9v6ml1ZHaRzO2E2rTim7YHzH3vTAcOcufcnA60ip1GauQroini1eLdixiiHIF8tg6 QRNA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=ZW9mcYmn; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.29 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=1755900348; x=1756505148; 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=ZYliD66L+2M2m3AodydHjxAyFCJZV6RrfyDLDp7pIWk=; b=gMDaaL0fNiU1vQuX4nUSNG9gK+527BK+Ew5pyGVFiZf3CuPHL9NEjE9cQv4r399LNz D3yh1bnoJbrN5ijA7DbZ688KnL1DQxDp3O55Xo9fXMVX38O7ukcIbEuA+vobZEovvll0 QkL372BHPa5vBRztJ2GZ5QbbCECXV3DdZCbPGf4PWN+vcFxiw8ryKez9flQc8/Qo5j06 8isXZlZ1UnqopJap1R6mm2gDq94SOWKQ3RjOxMLLKWpjtEtPerIPLceHddmILjyrxp0S um0xW7hom+jVGUZ52nceblcJJiRevNcUQssOrtykugcTV6+CzwTm3Go2zFfU8FVfqcTf gerg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755900348; x=1756505148; 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=ZYliD66L+2M2m3AodydHjxAyFCJZV6RrfyDLDp7pIWk=; b=croQaOM30k3xRop0utXnFHGLewrU2lZ0VCKaMO04Xp3MnyP5rLSorZCZ7NO2wKVgH4 CMiOgzYIJy+zRQjDNZuiD2oCglNhfNz7SyEN6/gI96hkyA92+1MBV/zgusz/0h5tdDSj +GW7+PjrGgx6WJz80qP/9yaZJFKkeCWrxUWH5rmE7oRaHKHwxjvKmWT9PWxAgVI2ZSvy HcBtG3bHB6XJQTL4NXp8laN6BgosdVTI5dxeSuIM2g4EC4id5e+MMFj/CEC64s5sVhcq c2c9HEd+HqTYimhFu0aHlF7f6VdY78dmUci31EvOSH2bqBq7vrz911qrtgJvyCeV3Mk7 860Q== X-Forwarded-Encrypted: i=2; AJvYcCXM8S7ybCM4aTd9sIFRLJuvNkbR0oTm1ptmQNqSnCjaOOcTUNIqEf7QAXUAUjiW/PXi2DNy64nxo2DB@gnusha.org X-Gm-Message-State: AOJu0YyhuujSvon7CtpoZEZ2aPR4qYx2sSerouF4wysEWiP++5Wi9zC8 nPymjlxdhJa6xjOTHyLIuO9o64lndgBWB3ZrRiWg4R95cY3xBTDWObEZ X-Google-Smtp-Source: AGHT+IGn8SQUuS1qtT6yl6lwFVHu3sNH7+hpQMOG7UrXdF1RUkFO2CCBzDU7IZscgcL/DUedT9NVEQ== X-Received: by 2002:a05:622a:8c4:b0:4b0:6a89:7485 with SMTP id d75a77b69052e-4b2aaf14987mr63909251cf.19.1755900348052; Fri, 22 Aug 2025 15:05:48 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeEPjO40+wpfbudg7DwqE+SHy4Wkv3YGcIl7JGOFqRRMw== Received: by 2002:a05:622a:1355:b0:4b0:63a8:673 with SMTP id d75a77b69052e-4b29d8df5d0ls25455201cf.1.-pod-prod-00-us; Fri, 22 Aug 2025 15:05:42 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCW9U/28hvIQfbEqdvfXDD+HXCJyVzXbTph086QgaxyG0v3slRnjeZPJA2t1WLppYqsf39iHIVt2xeQn@googlegroups.com X-Received: by 2002:ac8:57d3:0:b0:4b2:8ac4:f09c with SMTP id d75a77b69052e-4b2a01314a2mr89164341cf.38.1755900342822; Fri, 22 Aug 2025 15:05:42 -0700 (PDT) Received: by 2002:a05:6504:f04:b0:2c0:aeab:e1f7 with SMTP id a1c4a302cd1d6-2c0d47cdc1dmsc7a; Fri, 22 Aug 2025 13:00:01 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCW0rhCrPuYNnrpwAMQulpzWmi6bdMUxQSpe+TXgucYLthlaxe8Lk9VCjd/DptmVHqES+OViK/Zs356P@googlegroups.com X-Received: by 2002:a05:6512:4617:b0:55e:64f:c0f8 with SMTP id 2adb3069b0e04-55f0ccd3821mr1194826e87.34.1755892799329; Fri, 22 Aug 2025 12:59:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1755892799; cv=none; d=google.com; s=arc-20240605; b=OpzOnUZATxHI37XfYygvXvKoU999kxpHsdwiEg9PKo9RjRuGZoS1e/0cHa3wmq70Tx kykBRc+Nl98W2hwkQzdqDTqkQ1YAenRbnotHz/lipaTLZNdYe/q4+K/BIOVsDbwxbD+C CzTvRUUC3UxaCUUDdhymydgl4InzOk5Vfrg6A10gzTL6jaHXcYWl7RNpepammq0frGde jq4pj2n1Tqgn1TErq3oVQgeQK7y8mtLZPxv7dPNb+YpWRjBT+q22HJSkvQZ50dT1z+Ty oNEf97HI4c35GdwX3AYn72f9Ck0Net2ehI6ceqmDHy1QesvT0QWBFenDGja9eAqCFEx6 UxaA== 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=x1K+TP155hDCImF4fplLg4UoPxu7w+5TaW5fICuQrG8=; fh=I4bnjYRpGdVsfDIeD/w7kPqXuiSHPf5UhzWGw0Jx6U0=; b=COKbJ8WJ1HumX0unFzHe5CU4LcMmPRSHBnU3vxmgL14Cv9Fd2HxHGd7IbD57yKydJl WQ9QsDHUwNtFyMn4dxfuKSadCIkx761btcyPPdCXHwpL5dZNzEtFJMczIH5nqHQLfumc bCcrdOz+dwaKUYVVXj6lH4c3/69CxTjyprI4LC657KC7GbWAb+W+xNB9+afZTHx5fZM4 aA/ycmbSrbiEhnUmjD/wsCvcmt8BKyvSBxB3g5Lick/5i/oVj28qNFlDeatjXWqcpXGs kY4GPwRZW/HzBOBjEzIcy1Zxsa5IlCgG5MXoLbIwHBRMQpHsn/lOYKZgKJwURItAPbG3 wBiw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=ZW9mcYmn; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.29 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch. [79.135.106.29]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-55f35c7a390si10210e87.5.2025.08.22.12.59.59 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Aug 2025 12:59:59 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.29 as permitted sender) client-ip=79.135.106.29; Date: Fri, 22 Aug 2025 19:59:53 +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: 944d72229a2c75c1b324d97fcc6967b042066c15 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------bbf34a47ca36a48e22d99a124f6dc54c13b02b90dd376818b6ef8182e3bffa3e"; 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=protonmail header.b=ZW9mcYmn; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.29 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) --------bbf34a47ca36a48e22d99a124f6dc54c13b02b90dd376818b6ef8182e3bffa3e Content-Type: multipart/mixed;boundary=---------------------ffc922152e5c3708e39dabd95adc92d1 -----------------------ffc922152e5c3708e39dabd95adc92d1 Content-Type: multipart/alternative;boundary=---------------------ad79ea749c561b1378cf57e1b8289bff -----------------------ad79ea749c561b1378cf57e1b8289bff Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > 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 t= o commit to a valid quantum signature. The ECDSA R value is chosen by the signer, so the quantum attacker could pi= ck 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 public = key in some way prior=C2=A0to a CRQC arriving, then 3rd party nodes can't k= now whether a spend that occurs after=C2=A0a CRQC has appeared is genuine. = Any such commitments require positive action by UTXO holders, i.e. a migrat= ion. regards, conduition On Tuesday, August 19th, 2025 at 3:11 PM, Saint Wenhao wrote: > > how would currently locked funds be able to spend via a quantum safe si= gnature 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, another= is R-value in the signature. If someone has some coins, then the public ke= y 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 mea= ns, that users can commit to any quantum data, by hashing it, and forming a= valid commitment in R-value. >=20 > 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 opt= ional, 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 store= 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 forced t= o commit to a valid quantum signature. Which also means, that the new quant= um 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 c= an be set to different values, for different quantum proposals, depending o= n a particular signature scheme). >=20 > pon., 18 sie 2025 o 19:12 Jameson Lopp napisa=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 propos= al. 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 alternativ= e 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 inval= id - essentially threatens users with permanent fund loss. This creates sev= eral 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=99s c= oins 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 Bitc= oin=E2=80=99s value proposition. > > >=20 > > > 2. **The 25% Problem**: With ~5.25 million BTC having exposed public = keys, forcing these to become unspendable could create massive economic dis= ruption. Many of these may be genuinely lost coins, but some could be long-= term cold storage, inheritance situations, or users who simply miss the mig= ration 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 impl= ementation 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 reache= d production readiness with Supernova - a Bitcoin-inspired blockchain that = implements quantum resistance from genesis. Rather than forced migration, w= e 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 curr= ently 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 advant= age of this setup on Bitcoin, you just end up recreating the migration prob= lem. > >=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 provi= des quantum security while maintaining compatibility. > > >=20 > > > 2. **Address Format Compatibility**: Our quantum addresses (snq1...) = coexist with standard addresses (sn1...), allowing users to choose their se= curity level per transaction rather than per wallet. > > >=20 > > > 3. **No Coordination Required**: Users can independently decide when = to migrate without waiting for ecosystem-wide coordination. > > >=20 > > > 4. **Proven Implementation**: We=E2=80=99ve demonstrated this works i= n production, including the world=E2=80=99s first quantum-resistant Lightni= ng Network. > > >=20 > > > ## A Cooperative Path Forward > > >=20 > > > Rather than viewing this as competition, I see opportunity for collab= oration. Supernova could serve as a real-world testbed for quantum migratio= n 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 cont= inue to honor Bitcoin=E2=80=99s principles of decentralization and sound mo= ney. > > >=20 > > > ## Invitation to Explore > > >=20 > > > For those interested in seeing quantum resistance in action today rat= her 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 c= ommunity. > > >=20 > > > The quantum threat is real, and we need multiple approaches to ensure= the future of decentralized money. Whether through Bitcoin=E2=80=99s event= ual 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/supernov= a) > > >=20 > > > Would love to hear thoughts on the dual-signature approach and whethe= r something similar could work for Bitcoin without the harsh sunset provisi= ons. > > >=20 > > > --- > > >=20 > > > *Note: While I represent the Supernova project, I=E2=80=99m also a lo= ng-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 Nagaev wr= ote: > > >=20 > > > > Hi Jameson, hi all! > > > >=20 > > > > I have a couple of ideas on how to preserve more funds during any k= ind of fork that constrains or blocks currently used spending scenarios. Th= is applies to both freezing and commit/reveal schemes; the latter may resul= t in lost funds if the public key is leaked. I realized that this also appl= ies to the commit/reveal scheme I proposed in another thread [1]. > > > >=20 > > > > The idea is to roll out such forks incrementally across the UTXO se= t. Instead of freezing or constraining all UTXOs at once, we split the UTXO= set into 256 groups deterministically (for example, by looking at the firs= t byte of the TXID) and apply the constraints over 256 days, processing one= group per day. Procrastinators will learn what is happening through word o= f mouth, act to save their funds, and only a small percentage of coin owner= s will be harmed. > > > >=20 > > > > Another approach is to provide a temporary opt-out option. If someo= ne finds themselves blocked, they would still have a limited time to take a= n action, without requiring any extra knowledge, to get unblocked. This wou= ld help raise awareness. After being temporarily blocked and recovering the= ir funds through the opt-out mechanism, the person would understand that th= ey need to take further steps with their remaining coins to avoid being per= manently blocked once the opt-out period ends. The action to unblock the fu= nds could be as simple as sending a transaction with OP_RETURN "opt-out ", which would enable the old acceptance rules for the transaction with = that txid for a period of 2016 blocks. > > > >=20 > > > >=20 > > > > [1] https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/57bQJ3VS= CQAJ > > > > In that scheme if the pubkey is leaked, anyone can post a valid com= mitment 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 recovery = of bitcoin I wish to formalize a proposal after several months of discussio= ns. > > > > >=20 > > > > > 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 consensus is established that it is prudent to 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) out= put type (P2QRH) and introduces a pre-announced sunset of legacy ECDSA/Schn= orr signatures. It turns quantum security into a private incentive: fail to= upgrade and you will certainly lose access to your funds, creating a certa= inty where none previously existed. > > > > >=20 > > > > > - Phase A: Disallows sending of any funds to quantum-vulnerable= 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 se= parate BIP proposing a fork to allow recovery of legacy UTXOs through ZK pr= oof of possession of BIP-39 seed phrase. > > > > > =20 > > > > >=20 > > > > > Motivation > > > > >=20 > > > > > We seek to secure the value of the UTXO set and minimize incentiv= es for quantum attacks. This proposal is radically different from any in Bi= tcoin=E2=80=99s history just as the threat posed by quantum computing is ra= dically different from any other threat in Bitcoin=E2=80=99s history. Never= before has Bitcoin faced an existential threat to its cryptographic primit= ives. A successful quantum attack on Bitcoin would result in significant ec= onomic disruption and damage across the entire ecosystem. Beyond its impact= on price, the ability of miners to provide network security may be signifi= cantly impacted. > > > > >=20 > > > > > - Accelerating quantum progress. > > > > > =20 > > > > > - NIST ratified three production-grade PQ signature schemes= in 2024; academic road-maps now estimate a cryptographically-relevant quan= tum computer as early as 2027-2030. [McKinsey] > > > > > =20 > > > > > - Quantum algorithms are rapidly improving > > > > > =20 > > > > > - 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 fo= r 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 known= public keys then transfer all funds weeks or months later, in a covert ble= ed to not alert chain watchers. Q-Day may be only known much later if the a= ttack withholds broadcasting transactions in order to postpone revealing th= eir capabilities. > > > > > =20 > > > > > - Private keys become public. > > > > > =20 > > > > > - Assuming that quantum computers are able to maintain thei= r current trajectories and overcome existing engineering obstacles, there i= s a near certain chance that all P2PK (and other outputs with exposed pubke= ys) 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 the m= otivations of the attacker. An economically motivated attacker will try to = remain undetected for as long as possible, while a malicious attacker will = attempt to destroy as much value as possible. > > > > > =20 > > > > > - Upgrade inertia. > > > > > =20 > > > > > - Coordinating wallets, exchanges, miners and custodians hi= storically takes years. > > > > > =20 > > > > > - The longer we postpone migration, the harder it becomes t= o coordinate wallets, exchanges, miners, and custodians. A clear, time-boxe= d pathway is the only credible defense. > > > > > =20 > > > > > - Coordinating distributed groups is more prone to delay, e= ven if everyone has similar motivations. Historically, Bitcoin has been slo= w 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 foreseeab= le 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 ecos= ystem (wallets, exchanges, hardware vendors). > > > > > =20 > > > > > - Supply Discipline: Abandoned keys that never migrate become u= nspendable, 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 outputs > > > > >=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 output= s via ZK Proof > > > > >=20 > > > > > Users with frozen quantum vulnerable funds and a HD wallet seed p= hrase 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 cryptogr= aphically relevant quantum computer, widespread knowledge that such a compu= ter exists and is capable of breaking Bitcoin=E2=80=99s cryptography will d= amage faith in the network . > > > > > =20 > > > > > - An attack on Bitcoin may not be economically motivated - an a= ttacker may be politically or maliciously motivated and may attempt to dest= roy value and trust in Bitcoin rather than extract value. There is no way t= o know in advance how, when, or why an attack may occur. A defensive positi= on 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-chai= n (roughly 25 % of all bitcoin) could be stolen by a cryptographically rele= vant 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, benefitting t= hose who reach quantum capability earliest. > > > > > =20 > > > > > 2. Allow throttled theft of coins, which leads to RBF ba= ttles 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 script ty= pes, we minimize the attack surface with each new UTXO. > > > > > =20 > > > > > 2. Upgrades to Bitcoin have historically taken many years; t= his will hasten and speed up the adoption of new quantum resistant script t= ypes. > > > > > =20 > > > > > 3. With a clear deadline, industry stakeholders will more re= adily 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 possibl= e, submitting a ZK proof of knowledge of a BIP-39 seed phrase corresponding= to a public key hash or script hash would provide a trustless means for le= gacy outputs to be spent in a quantum resistant manner, even after the suns= et. > > > > > =20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Stakeholder > > > > >=20 > > > > > Incentive to Upgrade > > > > >=20 > > > > > Miners > > > > >=20 > > > > > =E2=80=A2 Larger size PQ signatures along with incentive for user= s to migrate will create more demand for block space and thus higher fees c= ollected by miners. > > > > >=20 > > > > > =E2=80=A2 Post-Phase B, non-upgraded miners produce invalid block= s. > > > > >=20 > > > > > =E2=80=A2 A quantum attack on Bitcoin will significantly devalue = both their hardware and Bitcoin as a whole. > > > > >=20 > > > > > Institutional Holders > > > > >=20 > > > > > =E2=80=A2 Fiduciary duty: failing to act to prevent a quantum att= ack on Bitcoin would violate the fiduciary duty to shareholders. > > > > >=20 > > > > > =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to effectively = mitigate emerging threats will prove Bitcoin to be an investment grade asse= t. > > > > >=20 > > > > > Exchanges & Custodians > > > > >=20 > > > > > =E2=80=A2 Concentrated risk: a quantum hack could bankrupt them o= vernight. > > > > >=20 > > > > > =E2=80=A2 Early migration is cheap relative to potential losses, = 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 i= mprove 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, stolen c= oins cannot be spent after Q-day. > > > > >=20 > > > > > Key Insight: As mentioned earlier, the proposal turns quantum sec= urity into a private incentive to upgrade. > > > > >=20 > > > > > This is not an offensive attack, rather, it is defensive: our the= sis is that the Bitcoin ecosystem wishes to defend itself and its interests= against those who would prefer to do nothing and allow a malicious actor t= o 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 worth = less. Think of it as a theft from everyone." > > > > >=20 > > > > >=20 > > > > >=20 > > > > > The timelines that we are proposing are meant to find the best ba= lance between giving ample ability for account owners to migrate while main= taining the integrity of the overall ecosystem to avoid catastrophic attack= s. > > > > >=20 > > > > >=20 > > > > > Backward Compatibility > > > > >=20 > > > > > As a series of soft forks, older nodes will continue to operate w= ithout modification. Non-upgraded nodes, however, will consider all post-qu= antum witness programs as anyone-can-spend scripts. They are strongly encou= raged to upgrade in order to fully validate the new programs. > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Non-upgraded wallets can receive and send bitcoin from non-upgrad= ed and upgraded wallets until Phase A. After Phase A, they can no longer re= ceive from any other wallets and can only send to upgraded wallets. After P= hase 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 v= ulnerable funds recovery via ZK proofs. > > >=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/173b3bc4-7052-4e0e-9042-ca15cd5b0587n%40googlegroups.com. > >=20 > > -- > > You received this message because you are subscribed to the Google Grou= ps "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/bitcoin= dev/CADL_X_cgqHUOU6V9%2BGsEKz--ekxmgyYJwOg4BeLajAr_cTVN_g%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/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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= rCO-ee8FiX-prHxWh07O38oxSkVxhkV7vBbk7I0IS7RxqkJydKN9b_ubg_BWwdCzw0lkskcD0zd= yoJx6cr67cc-BQWS64snWYhex_2W7g6o%3D%40proton.me. -----------------------ad79ea749c561b1378cf57e1b8289bff Content-Type: multipart/related;boundary=---------------------660520a628ec0bec7cc89c747077393b -----------------------660520a628ec0bec7cc89c747077393b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If someone has some coins, then the public key cannot be change= d, if it is present in the output Script. However, R-value can be freely pi= cked by the signer, and can be set to anything.
...
And later, when quantum signatures w= ill 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.=

<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">The ECDSA R = value is chosen by the signer, so the quantum attacker could pick any arbit= rary PQ signature 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 pr= ior to a CRQC arriving, then 3rd party nodes can't know whether a = spend that occurs after a CRQC has appeared is genuine. Any suc= h commitments require positive action by UTXO holders, i.e. a migration.

regards,<= /div>
condui= tion
On Tuesday, August 19th, 2025 at 3:11 PM, Saint Wenhao <saintwen= hao@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 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 proposal.= The quantum threat is indeed existential, and I appreciate the detailed th= inking that went into this migration plan. However, I=E2=80=99d like to res= pectfully raise some concerns about the approach and share an alternative p= erspective from work we=E2=80=99ve been doing in this space.

## Conc= erns 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 several issues:

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=99s coins worth slightly mor= e=E2=80=9D becomes =E2=80=9Ccoins you don=E2=80=99t migrate in time are for= cibly lost.=E2=80=9D This fundamentally changes Bitcoin=E2=80=99s value pro= position.

2. **The 25% Problem**: With ~5.25 million BTC having expo= sed public keys, forcing these to become unspendable could create massive e= conomic disruption. Many of these may be genuinely lost coins, but some cou= ld be long-term cold storage, inheritance situations, or users who simply m= iss the migration window.

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

## An Alternative Approach: Learning from Supernova
Our team has been working on these exact problems and recently reached pro= duction readiness with Supernova - a Bitcoin-inspired blockchain that imple= ments 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 pr= oblem; 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 recreati= ng 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 signa= tures only

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

1. **Hybrid Signatures**= : Instead of a hard cutoff, transactions can require both classical and qua= ntum signatures during transition. This provides quantum security while mai= ntaining compatibility.

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

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

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

## A Cooperative Path Forward

Rather than viewing this as c= ompetition, 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+, F= alcon)
- 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 co= ntinue to honor Bitcoin=E2=80=99s principles of decentralization and sound = money.

## Invitation to Explore

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

The quantum threa= t is real, and we need multiple approaches to ensure the future of decentra= lized money. Whether through Bitcoin=E2=80=99s eventual upgrade or alternat= ives 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-Twelve-C12/supernova)

Would love to hear thoughts on the = dual-signature approach and whether something similar could work for Bitcoi= n without the harsh sunset provisions.

---

*Note: While I rep= resent the Supernova project, I=E2=80=99m also a long-time Bitcoin supporte= r who wants to see the entire ecosystem survive the quantum transition. The= se 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@goo= glegroups.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@goo= glegroups.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@googlegroups.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.com/d/msgid/bitcoindev/rCO-ee= 8FiX-prHxWh07O38oxSkVxhkV7vBbk7I0IS7RxqkJydKN9b_ubg_BWwdCzw0lkskcD0zdyoJx6c= r67cc-BQWS64snWYhex_2W7g6o%3D%40proton.me.
-----------------------660520a628ec0bec7cc89c747077393b-- -----------------------ad79ea749c561b1378cf57e1b8289bff-- -----------------------ffc922152e5c3708e39dabd95adc92d1 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== -----------------------ffc922152e5c3708e39dabd95adc92d1-- --------bbf34a47ca36a48e22d99a124f6dc54c13b02b90dd376818b6ef8182e3bffa3e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmiozCYJkHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmd4S0z6EsYeDwJt3bWiFUDAYlJmgHpSjbAYTv9F h+jv0BYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAA6bQD/W87px5+TyCd9X4m1 DG2NQUKqZ9ca7BaACE+8Fr/SThEA/15UjtkenHaRgqzJHPeTM451VAlxvf4d naj0FoOE4QcP =Jxqx -----END PGP SIGNATURE----- --------bbf34a47ca36a48e22d99a124f6dc54c13b02b90dd376818b6ef8182e3bffa3e--