Delivery-date: Mon, 18 Aug 2025 10:12:47 -0700 Received: from mail-qt1-f190.google.com ([209.85.160.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uo3PW-0005Fm-Ub for bitcoindev@gnusha.org; Mon, 18 Aug 2025 10:12:47 -0700 Received: by mail-qt1-f190.google.com with SMTP id d75a77b69052e-4b109c5ac7asf117689091cf.3 for ; Mon, 18 Aug 2025 10:12:42 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1755537157; cv=pass; d=google.com; s=arc-20240605; b=jX7Bfqht+dmdE2xu/DAuxfsspQvyDiyGwerqF5gwwjTwNPIMvgMUciQ/AjNOc2DRlh m99nO8ftCTzDXvacr+UsZcYBgfbEG3MhMjPagC/3oqqxCwwD3siBDQj0wefrJ2YJ3ayv iY5KyQLA0+iDpndqOzcY5wj9au9IQJ0nwwKFFvkVhEnb96GN9ejVEpqRIcJQNB7VhMSO wiQ4Ucpsrh8JUBar9JVbF0/rJwaNqgqsut2pkhk3Edt7jCRG6g6eJvSks5p6ku+jSXvL MucGPHkx6ZbwJL3it/CT4gQN3jYxH9UT6t5HWhXZvM3zDr+sags1PKSAbp2DOXXUdGIi nVUQ== 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=5f1+B4xwLIoMg+nDw9JILgnVjEX2DrFx92Bz7f7MNuo=; fh=x7G379cWVtod9bQAfWQpZZUhZQoFbJB8Ros8DuW2eYA=; b=Zd8YLUazHZvPBhgBBU9+ByBq8SorZfUjoSMWKrFtzLcjEZi1LLX08dCM8HSQMAcWrG /6hKDb+D6u5AANB592LilZqO6wsVjEYk3ffm60GjEedlFPwy0L64JY5iNyJVr3tR7N1D 1aKOAYplypYfMZNoFsaSUHHOTtRPIE8mF2LGKkrw1xqcaQllIGFHqQB4SaMJ79Y74s3Q wqK8O1dVsN8xLY4oNTchHnJbeKWpZkvRibsGwQyYqDV+B88K7qPXzPXRHGhvZYYGyXi+ +yRpkP+FZQetjCCE5V+gbjYEhGTPvDme+NJ/QgTFPIDFTm1rlWzO76IIkwBGrApvzWHv Fq/Q==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=amHZFuXB; spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) smtp.mailfrom=jameson.lopp@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=1755537156; x=1756141956; 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=5f1+B4xwLIoMg+nDw9JILgnVjEX2DrFx92Bz7f7MNuo=; b=NnGsEltluHz/FP3Uz7BI5mXQJabnn+tAjzronVDkTnsZ28v0xob4n98NIx4IKxUG7s 5Eumw4VgyiAQsuf6PqQN+ol32CNKCC9OUakrNr8G0PrZFgusJ6td82uChzzw8aRqsL4R cjjk3447TqbLUqHY51MZl3KFN2lmStsZuZHXqlZQAXVcoDYBy28BWvk4rtd0+MDnNBX7 EmeyepQam4KHLHuFkmCsvAO/CGsNnCABcg/WhUR4xDiaRl1wsLfChX3VXp7TnDEO+A5D u7VV3LRnl04UNn9prL9SkQmY3vK4Zx3O6jLBGKJaEfVekFqk+MMuwCUqtSmETo8T5Is1 tyQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1755537156; x=1756141956; 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=5f1+B4xwLIoMg+nDw9JILgnVjEX2DrFx92Bz7f7MNuo=; b=BMo6dFMGFrlRB46Sg5NNXI6XoGQ39OeDpG800wKEnazoQfNUZ3RfKAR5a8vvWtso2+ Vr2HbBfPNJdzMJgHIh4h9fKDmueeHFMI2vxl7dDsI84KKBEg1Fo6kgmjONYop12Jev6h JG7QydgWr5Q1YmEFv9CaMAcYdrib4cRmdZXTWEja0yF3WQA9D1+mzcNFMisjV/LWmE2Q rDC8rKjmK4zefVsr8tS0l02GWhYRuoLhLwwcJIH4oOcK1lywa4SVF2JRtiMgxkg8TVjN sxFBWaRa1NJ9MnxdbT+EQZcM2+qaACX8+sd0d1O+obD7SbId656+DwhdH4PDg6pb1MMH dO+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755537156; x=1756141956; 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=5f1+B4xwLIoMg+nDw9JILgnVjEX2DrFx92Bz7f7MNuo=; b=SkDczcrD/wdsI9sQMLXFMOOWae+1AU+1jpIvgZRXV0k0fdPWnQQsO/JLxuFptNI47c hMYYM5UqGCMstyDGvnhIKn4itOb5wC5RauWRbpCg0NVp5qPXOWu9OGdxN/6fRfFd1EeC pgIgYFhttog3hCgNSmDI14SX/QKCJX/NcI2B5cpClZ8mJQ6nhAPMfSMbBqlbJSvyhDCG eWrVl/UteLHE6tvMl5iV65VfXuAXnJcsyy0NB1RkoOUO87nVzT4KGGQhpUawqq/msa7G 9TSaAnp1LMXYycU9lhQPG9j3+dODt77LULIM0MeSARjR2aiClYgQE21Pon3f4VSutVY3 hk2g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUJ66hNHRyQRAPoa8cx4KX5W1B2cXl2B3+D7scPcj26hrEvJyNPCAF40ZD+g/XZw/lhEeFSdOgejgME@gnusha.org X-Gm-Message-State: AOJu0YyBiefubvxH6WrdYYf2aUPBwzmt1i5jd6+hoHpvBPMtWUji5CZy muB3sbEtFwm0C3WmhnYb044CsyONODiZaK3qQFCzQVOUWyBk1PoorZng X-Google-Smtp-Source: AGHT+IHdWtsvbWKmYbtB+EM8tliii1lWjwuHT78lnk1uFQsO+AInd1w73Hqe5lFzaceyrfjDu8NGGQ== X-Received: by 2002:a05:622a:5e1a:b0:4b0:863b:f4e5 with SMTP id d75a77b69052e-4b11e23ba75mr118792101cf.33.1755537156376; Mon, 18 Aug 2025 10:12:36 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfYdVAl2WLnGE7Pps6RtT4sEjJmITJZXUaiH/KHM9BxgQ== Received: by 2002:a05:622a:102:b0:4b0:9c1e:fca1 with SMTP id d75a77b69052e-4b1099e98b9ls75802141cf.0.-pod-prod-01-us; Mon, 18 Aug 2025 10:12:31 -0700 (PDT) X-Received: by 2002:a05:620a:2987:b0:7e8:2197:23e5 with SMTP id af79cd13be357-7e87e12a652mr1691564985a.50.1755537151021; Mon, 18 Aug 2025 10:12:31 -0700 (PDT) Received: by 2002:a05:600c:8b71:b0:456:ce4:c44e with SMTP id 5b1f17b1804b1-459f521d826ms5e9; Tue, 12 Aug 2025 07:57:08 -0700 (PDT) X-Received: by 2002:a05:6000:178f:b0:3b7:8dd7:55ad with SMTP id ffacd0b85a97d-3b900b7aeafmr14633944f8f.39.1755010624983; Tue, 12 Aug 2025 07:57:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1755010624; cv=none; d=google.com; s=arc-20240605; b=hV9SpkxojJFot/PXcsLeiCnUbSeH+xTl/1GUfEAgjXZUpb1hAkKuMZuU/B+M08Euh6 svzpuZMHd8iJ9syVJo6naZ04nRPZEFFIaTkdKs7EHN1YnovZDEDnbUzEOWztIemBHv56 uP3TOIQxiHGY/Q8+0uVwMaESLdbcddwcVyveEX7SvL3LjjvQkpXHH58NDU/TqnEMx1BM 3GK6ByVH1L1uf0u6TQccvIB69XsnhamoGpwkQoSRqv5r8jitqEQgaP5ZHoNb/wlaqN+Y VpFERa3aIXOiFLKWvls4xt5M0kfpybDJZkAeWpUSLyxmbHN9ms7A472ZnjgdL47SKjDB rLIg== 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=Wp2fx2QAAyV+kqKFZDRHFVNhV+v7sxnOwXHI9yeDKfc=; fh=x9jsc6Q+VdoxZPMZSAnSsrPY3Nj5gzKzpmXVKm2X0bQ=; b=j77q8+EHSedJ/KLABih+0bRD8QK83ujESDS/kszxRu15f2vhVIFT9KyUL6P29ppJX1 rKKXYk4FkFVk7OKrx/Y/RwBu7Xz3a/xySfv5JLpUKkP5E1iqgdPmPcuhd+xFETuuwgir 5EP7tnyghifBDQl9O8QiEZJMyFhwNaTgGoSgd8ckcG6lb64hDJK1SCjSc24PwfiJip5X fJDep+MIZoQytA1muUeDppyCoPCmANHG7RhDhcFAL3sR4jGv2DU0eGaJIz7KReVDXrRx laKAQcgkQcWl7U7VJlXp7nckrzO35u9kNKGZI7O6/vAZ5joOh1Sxc4eAMCWM0d7NwVKR Jo1A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=amHZFuXB; spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com. [2a00:1450:4864:20::230]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-45a119dd3b3si383315e9.1.2025.08.12.07.57.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Aug 2025 07:57:04 -0700 (PDT) Received-SPF: pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) client-ip=2a00:1450:4864:20::230; Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-33243562752so39166121fa.3 for ; Tue, 12 Aug 2025 07:57:04 -0700 (PDT) X-Gm-Gg: ASbGncvsqAw/RxNePBQ40bI9lagF6KV2L2lDyqnUwnY6DBgt+TCAYNNWtRenHSKcVEU exI7V9dyyRuMDNYNnssOrnMExOVF+xPVVEytL6qNIgjLscbrnU2SYXPtpfN+cuExsVVOcKOKNAe y5SCV/AMA2VA6G+Xo76loaxmTILnrnXC+0hMynNeFU+zfS/detgk6Kk58gvfc5cOinIOOU4oYSx FZzFns= X-Received: by 2002:a05:651c:31d2:b0:32c:e253:20cc with SMTP id 38308e7fff4ca-333e50bab5dmr360781fa.11.1755010623441; Tue, 12 Aug 2025 07:57:03 -0700 (PDT) MIME-Version: 1.0 References: <173b3bc4-7052-4e0e-9042-ca15cd5b0587n@googlegroups.com> In-Reply-To: <173b3bc4-7052-4e0e-9042-ca15cd5b0587n@googlegroups.com> From: Jameson Lopp Date: Tue, 12 Aug 2025 09:56:51 -0500 X-Gm-Features: Ac12FXyo4Y-vRa6ZWjliBY-zUOTQe_tovzgM7qFrsEvCSCn7epd1FbP5G55T0h0 Message-ID: Subject: Re: [bitcoindev] Re: A Post Quantum Migration Proposal To: Marc Johnson Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000c9904f063c2c401b" X-Original-Sender: jameson.lopp@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=amHZFuXB; spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) smtp.mailfrom=jameson.lopp@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 (/) --000000000000c9904f063c2c401b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 space. > > ## 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 severa= l > 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 slightl= y 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 be > long-term cold storage, inheritance situations, or users who simply miss > 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 that > implements 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 problem; how would currently locked funds be able to spend via a quantum safe signature scheme if they have not committed to a dual signature scheme? In order to take 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 their > 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 pr= oduction, > including the world=E2=80=99s first quantum-resistant Lightning 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 quantum > 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 rather > than waiting years, I invite you to explore Supernova. We=E2=80=99re laun= ching 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 eventual= 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-Twelve-= 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-t= ime > Bitcoin supporter who wants to see the entire ecosystem survive the quant= um > transition. 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 o= f >> fork that constrains or blocks currently used spending scenarios. This >> 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 >> 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 UTXO >> set into 256 groups deterministically (for example, by looking at the fi= rst >> byte of the TXID) and apply the constraints over 256 days, processing on= e >> 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 owne= rs >> 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 a= n >> action, without requiring any extra knowledge, to get unblocked. This wo= uld >> 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 >> permanently blocked once the opt-out period ends. The action to unblock = the >> funds could be as simple as sending a transaction with OP_RETURN "opt-ou= t >> ", which would enable the old acceptance rules for the transaction >> with that txid for a period of 2016 blocks. >> >> >> [1] https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/57bQJ3VSCQAJ >> 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 wrot= e: >> >> 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 rather 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 typ= e >> (P2QRH) and introduces a pre-announced 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, 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 pro= of 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 Bitcoi= n=E2=80=99s >> history just as the threat posed by quantum computing is radically >> different from any other threat in Bitcoin=E2=80=99s history. Never bef= ore has >> Bitcoin faced an existential threat to its cryptographic primitives. A >> successful quantum attack on Bitcoin would result in significant economi= c >> 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-relevant quant= um >> 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. Al= gorithms >> are improving up to 20X >> , >> lowering the theoretical hardware requirements for breaking classi= cal >> 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 bl= eed to >> not alert chain watchers. Q-Day may be only known much later if th= e attack >> withholds broadcasting transactions in order to postpone revealing= 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 exposed pubke= ys) >> 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 w= ill try >> to remain undetected for as long as possible, while a malicious at= tacker >> 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, ti= me-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 s= low 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 with the t= hreat >> 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 Z= K 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 tha= t such >> a computer exists and is capable of breaking Bitcoin=E2=80=99s crypto= graphy 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 attempt to destro= y >> value and trust in Bitcoin rather than extract value. There is no wa= y to >> know in advance how, when, or why an 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 tantal= izing >> target: any UTXO that has ever exposed its public key on-chain (rough= ly 25 >> % of all bitcoin) could be stolen by a cryptographically relevant qua= ntum >> 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 proposa= ls: >> 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 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 historically taken many years; this will >> hasten and speed up the adoption of new quantum resistant script t= ypes. >> 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 corresp= onding to >> a public key hash or script hash would provide a trustless means f= or 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 mi= grate >> will create more demand for block space and thus higher fees collected b= y >> 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 th= eir >> hardware and Bitcoin as a whole. >> >> Institutional Holders >> >> =E2=80=A2 Fiduciary duty: failing to act to prevent a quantum attack on = Bitcoin >> would violate the fiduciary duty to shareholders. >> >> =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to effectively mitigat= e emerging >> threats will prove Bitcoin to be an investment grade asset. >> >> Exchanges & Custodians >> >> =E2=80=A2 Concentrated risk: a quantum hack could bankrupt them overnigh= t. >> >> =E2=80=A2 Early migration is cheap relative to potential losses, potenti= al >> 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 improve = their >> security rather than an open-ended =E2=80=9Csome day=E2=80=9D that invit= es procrastination. >> >> Attackers >> >> =E2=80=A2 Economic incentive diminishes as sunset nears, stolen coins ca= nnot 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 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= to >> destroy both value and trust. >> >> >> "Lost coins only make everyone else's coins worth slightly more. Think o= f >> 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 catastrophic >> attacks. >> >> Backward Compatibility >> >> As a series of soft forks, older nodes will continue to operate without >> modification. Non-upgraded nodes, however, will consider all post-quantu= m >> witness programs as anyone-can-spend scripts. They are strongly encourag= ed >> to upgrade in order to fully 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 receiv= e >> from any other wallets and can only send to upgraded wallets. After Pha= se >> B, both senders and receivers will require upgraded wallets. Phase C wou= ld >> 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-ca15= cd5b0587n%40googlegroups.com > > . > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail 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. --000000000000c9904f063c2c401b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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

I'd first like to say = thank you to James for the comprehensive proposal. The quantum threat is in= deed existential, and I appreciate the detailed thinking that went into thi= s migration plan. However, I=E2=80=99d like to respectfully raise some conc= erns about the approach and share an alternative perspective from work we= =E2=80=99ve been doing in this space.

## Concerns with the Forced Su= nset Approach

The proposal=E2=80=99s Phase B - rendering ECDSA/Schno= rr spends invalid - essentially threatens users with permanent fund loss. T= his creates several issues:

1. **Violation of Bitcoin=E2=80=99s Soci= al Contract**: Satoshi=E2=80=99s principle that =E2=80=9Clost coins only ma= ke 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 T= his fundamentally changes Bitcoin=E2=80=99s value proposition.

2. **= The 25% Problem**: With ~5.25 million BTC having exposed public keys, forci= ng these to become unspendable could create massive economic disruption. Ma= ny of these may be genuinely lost coins, but some could be long-term cold s= torage, inheritance situations, or users who simply miss the migration wind= ow.

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 pushi= ng implementation past the 2027-2030 quantum timeline mentioned.

## = An Alternative Approach: Learning from Supernova

Our team has been w= orking on these exact problems and recently reached production readiness wi= th Supernova - a Bitcoin-inspired blockchain that implements quantum resist= ance from genesis. Rather than forced migration, we use a dual-signature sc= heme that might be instructive for Bitcoin:

=
I don't see how this solves Bitcoin's migration problem; how w= ould currently locked funds be able to spend via a quantum safe signature s= cheme if they have not committed to a dual signature scheme? In order to ta= ke advantage of this setup on Bitcoin, you just end up recreating the migra= tion problem.


**Three Modes of Operation:**
- **Legacy Mode**: ECDSA si= gnatures 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
- Allow= s gradual, voluntary migration
- Maintains backwards compatibility indef= initely
- 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 signa= tures during transition. This provides quantum security while maintaining c= ompatibility.

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

= 3. **No Coordination Required**: Users can independently decide when to mig= rate without waiting for ecosystem-wide coordination.

4. **Proven Im= plementation**: We=E2=80=99ve demonstrated this works in production, includ= ing the world=E2=80=99s first quantum-resistant Lightning Network.

#= # A Cooperative Path Forward

Rather than viewing this as competition= , I see opportunity for collaboration. Supernova could serve as a real-worl= d testbed for quantum migration strategies. We=E2=80=99ve already implement= ed:

- NIST-standardized algorithms (Dilithium, SPHINCS+, Falcon)
= - Quantum-resistant atomic swaps with Bitcoin
- Full Lightning Network w= ith quantum HTLCs
- Zero-knowledge proofs for enhanced privacy

Bi= tcoin 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 rather than waiting years, I invite you to explo= re Supernova. We=E2=80=99re launching our public testnet soon and would val= ue feedback from the Bitcoin community.

The quantum threat is real,= and we need multiple approaches to ensure the future of decentralized mone= y. Whether through Bitcoin=E2=80=99s eventual 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/s= upernova](https://github.com/Carbon-Twelve-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 surviv= e the quantum transition. 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 blocks currently used spending scenarios. This applies to bo= th 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 commi= t/reveal scheme I proposed in another thread [1].

The idea is t= o roll out such forks incrementally 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 constraints over 256 days, processing one group per day= . Procrastinators will learn what is happening through word of mouth, act t= o save their funds, and only a small percentage of coin owners will be harm= ed.

Another approach is to provide a temporary = opt-out option. If someone finds themselves blocked, they would still h= ave a limited time to take an action, without requiring any extra knowledge= , to get unblocked. This would help raise awareness. After being temporaril= y blocked and recovering their funds through the opt-out mechanism, the per= son would understand that they need to take further steps with their remain= ing coins to avoid being permanently blocked once the opt-out period ends.= =C2=A0The action to unblock the funds could be as simple as sending a trans= action 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 commitment with a random TXID blocking the coin for= ever.

Best,
Boris

On Saturday, July 12, 2025 at 9:46:09=E2=80=AFPM UTC-3 Jameso= n Lopp wrote:
<= p dir=3D"ltr" style=3D"line-height:1.44;background-color:rgb(255,255,255);m= argin-top:12pt;margin-bottom:0pt;padding:0pt 0pt 12pt">Building upon my earlier essay against allow= ing quantum recovery of bitcoin I wish to f= ormalize 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 rather is meant to s= pecifically address the issues of incentivizing adoption and migration of f= unds after consensus is establ= ished that it is prudent to do so.

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

Abstrac= t

This proposal follows the implementation of po= st-quantum (PQ) output type (P2QRH) and introduces a pre-announced sunset o= f legacy ECDSA/Schnorr 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.=C2=A0

  • = Phase A: Disallows sending of any funds to q= uantum-vulnerable addresses, hastening the adoption of P2QRH address types.=

  • Phase B:= Renders ECDSA/Schnorr spends invalid, preve= nting 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 se= parate BIP proposing a fork to allow recovery of legacy UTXOs through ZK pr= oof of possession of BIP-39 seed phrase.=C2=A0=C2=A0

Motivation

We seek to secure the value of the UTXO set and minimize incentives for quantum a= ttacks. This proposal is radically different from any in Bitcoin=E2=80=99s = history just as the threat posed by quantum computing is radically differen= t from any other threat in Bitcoin=E2=80=99s history.=C2=A0 Never before ha= s Bitcoin faced an existential threat to its cryptographic primitives. A su= ccessful quantum attack on Bitcoin would result in significant economic dis= ruption and damage across the entire ecosystem. Beyond its impact on price,= the ability of miners to provide network security may be significantly imp= acted.=C2=A0=C2=A0

  • Accelerating quantum p= rogress.=C2=A0

    • NIST ratif= ied three production-grade PQ signature schemes in 2024; academic road-maps= now estimate a cryptographically-relevant quantum computer as early as 202= 7-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, lowering the theoretical = hardware requirements for breaking classical encryption.

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

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

    • We may not know the attack is underway.=C2=A0

      • 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.=C2=A0

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

    • = Impossible to know motivations.=C2=A0

      • Prior to a quantum attack, it is impossible to know the motiv= ations of the attacker.=C2=A0 An economically motivated attacker will try t= o remain undetected for as long as possible, while a malicious attacker wil= l attempt to destroy as much value as possible.=C2=A0=C2=A0

        • =
    • <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" r= ole=3D"presentation">Upgrade inerti= a.=C2=A0

      • Coordinating wal= lets, 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 d= efense.

      • Coordinating distributed groups is more prone to delay, even if everyo= ne has similar motivations. Historically, Bitcoin has been slow to adopt co= de changes, often taking multiple years to be approved.

      Benefits at a Glance

      • Resilience: Bitcoin protocol remains secure for the foreseeable futur= e 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 with the = threat of quantum theft of bitcoin.=C2=A0=C2=A0

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

      • = Supply Discipline: Abandoned keys that never migrate become un= spendable, reducing supply, as Satoshi de= scribed.=C2=A0=C2=A0

      Specification

      Phase

      What Happens

      =

      Who Must Act

      = Time Horizon

      Phase = A - Disallow spends to legacy script types

      Permitte= d sends are from legacy scripts to P2QRH scripts

      Eve= ryone holding or accepting BTC.

      3 years after BIP-3= 60 implementation

      P= hase B =E2=80=93 Disallow spends from quantum vulnerable= outputs

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

      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 phras= e can construct a quantum safe ZK proof to recover funds.

      =

      Users who fa= iled to migrate funds before Phase B.

      TBD pending research, demand, an= d consensus.

      = Rationale
      • Even if= Bitcoin is not a primary initial target of a cryptographically relevant qu= antum computer, widespread knowledge that such a computer exists and is cap= able of breaking Bitcoin=E2=80=99s cryptography will damage faith in the ne= twork .=C2=A0

      • An attack on Bitcoin may not be economically motivated - an attacke= r may be politically or maliciously motivated and may attempt to destroy va= lue and trust in Bitcoin rather than extract value.=C2=A0 There is no way t= o know in advance how, when, or why an attack may occur.=C2=A0 A defensive = position must be taken well in advance of any attack.=C2=A0=C2=A0

      • Bitcoin=E2=80= =99s current signatures (ECDSA/Schnorr) will be a tantalizing target: any U= TXO that has ever exposed its public key on-chain (roughly 25 % of all bitc= oin) could be stolen by a cryptographically relevant quantum computer.

      • Existing Proposals are Insufficient.= =C2=A0=C2=A0

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

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

          2. Allow throttled theft of co= ins, which leads to RBF battles and ultimately miners subsidizing their rev= enue from lost coins.

          3. <= 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">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.=C2=A0=C2=A0

        2. <= p dir=3D"ltr" style=3D"line-height:1.38;text-align:justify;margin-top:0pt;m= argin-bottom:0pt" role=3D"presentation">Upgrades to= Bitcoin have historically taken many years; this will hasten and speed up = the adoption of new quantum resistant script types.=C2=A0

          3. With a clear dea= dline, industry stakeholders will more readily upgrade existing infrastruct= ure to ensure continuity of services.=C2=A0=C2=A0

        • =

      • Minim= izes loss of access to funds=C2=A0

        1. If there is sufficient demand and research proves possible, 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 legacy outputs = to be spent in a quantum resistant manner, even after the sunset.=C2=A0=C2= =A0


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

      Stakeholder

      Incentiv= e to Upgrade

      <= span style=3D"border-width:1pt;border-style:solid;border-color:rgb(0,0,0);v= ertical-align:middle;padding:5pt;overflow:hidden">

      Miners

      =

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

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

      =E2=80=A2 A quan= tum attack on Bitcoin will significantly devalue both their hardware and Bi= tcoin as a whole.=C2=A0

      Institutional Holders

      =E2=80=A2 Fiduciary duty: failing to act t= o prevent a quantum attack on Bitcoin would violate the fiduciary duty to s= hareholders.=C2=A0=C2=A0

      =E2=80=A2 Demonstrating Bitc= oin=E2=80=99s ability to effectively mitigate emerging threats will prove B= itcoin to be an investment grade asset.

      Exchanges & Custodians

      =E2=80=A2 Concentrate= d risk: a quantum hack could bankrupt them overnight.

      =E2=80=A2 Early migration is cheap relative to potential losses, potential= lawsuits over improper custody and reputational damage.

      <= /span>

      Everyday Users

      <= span style=3D"border-width:1pt;border-style:solid;border-color:rgb(0,0,0);v= ertical-align:top;padding:5pt;overflow:hidden">

      =E2=80=A2 Self-s= overeign peace of mind.

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

      Attackers

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

      Key Insight: As ment= ioned earlier, the proposal turns quantum security into a private incentive to upgrade.=C2=A0= =C2=A0

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


      =

      "Lost coins only make everyone else's coins= worth slightly more. Think of it as a donation to everyone." - Satosh= i Nakamoto

      If true, the corollary is:

      <= br>

      "Quantum recovered coins only make ev= eryone else's coins worth less. Think of it as a theft from everyone.&q= uot;

      The timelines that we are proposing= are meant to find the best balance between giving ample ability for accoun= t owners to migrate while maintaining the integrity of the overall ecosyste= m to avoid catastrophic attacks.=C2=A0=C2=A0


      Backward Compatibility

      As a series of soft forks,= older nodes will continue to operate without modification. Non-upgraded no= des, however, will consider all post-quantum witness programs as anyone-can= -spend scripts. They are strongly encouraged to upgrade in order to fully v= alidate the new programs.


      Non-upgraded wallets ca= n receive and send bitcoin from non-upgraded and upgraded wallets until Pha= se A. After Phase A, they can no longer receive from any other wallets and = can only send to upgraded wallets.=C2=A0 After Phase B, both senders and re= ceivers will require upgraded wallets.=C2=A0Phase C would likely require a = loosening of consensus rules (a hard fork) to allow vulnerable funds recove= ry 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@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/173b3bc4-7052-4e0e-9042-ca15cd5b0587n%40googlegrou= ps.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/CADL_X_cgqHUOU6V9%2BGsEKz--ekxmgyYJwOg4BeLajAr_cTVN_g%40ma= il.gmail.com.
--000000000000c9904f063c2c401b--