Delivery-date: Mon, 18 Aug 2025 10:12:45 -0700 Received: from mail-qt1-f188.google.com ([209.85.160.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uo3PX-0005Fo-02 for bitcoindev@gnusha.org; Mon, 18 Aug 2025 10:12:45 -0700 Received: by mail-qt1-f188.google.com with SMTP id d75a77b69052e-4b10993f679sf101592881cf.0 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=TGhqmukgQmgN5S14nvlwETTRRDgVZAi+2+rveLuMhxsT5T1/rilT6Af0J15PZ9S9A2 UH3zr9IklcsUgqNzDWmXzkxv7Fe7xjZNh6PvHxdoGULcVUVotVJbLybx0sLvJwtSpfCx oGj2aMBHVOm22641Pa+qofBhwZGOuCLfwEZ2rt90BKqWGvSWNZi30c/ptAuKkk17IGiD bZozWJDUvQCIQffHbNtvf5APiczo01a+tVMxSY0YXYr+wrt1+bDluCe4oW+VP8FCNEJw ZKbO/PIDTnrXm9JwNJ87FcW0hvG06wOJrvXRVpW05Lzk30JLI4SD8yIbxXr45AAdKfx5 mBYg== 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=Jj0kajufb+hVdfD9LxiiRST07xDK0ORruFCGJ1qwQSg=; fh=XDA0IjwebCFRfPgb7zqnO0cjinv3m1NCsbxLQbgK/4M=; b=UsOFS0QmI2wFdHAMD4OdruN68juvy3p3uAwx1+dBz4TDfZtOrXGH7YvWqbo/1vS04J maDk28J9Hb5jP4hPhEXHILaUl7yx12LxkeVvSyIc9RgaeD55/Y9kXBjG0yYp9wRhlv/R aaVdGGf58PX8iqQqfCS4cfTKEEOy26wW1GdLCERuFRjKjOvj2Hx4PeoXO0tQSoVaTPHb 1huEpcywpa1Mg0xG7unx8GyxoLcog9hGOkBlqDoqKwF5iOpyRTEq7ZsQG8ch3ngpdosY 7HG2dbExcjlYYcn4HRQFac3Kh6+K3QgbGORDT9p5LX2UvkyOGTuOuGLFc8kX1B7aQkdr 5y1A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=RYp3NLRb; spf=pass (google.com: domain of marcjohnson518@gmail.com designates 2607:f8b0:4864:20::1136 as permitted sender) smtp.mailfrom=marcjohnson518@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=Jj0kajufb+hVdfD9LxiiRST07xDK0ORruFCGJ1qwQSg=; b=uSp50V46b+aVU7IaTEtjT9ZPzqBYblWyzgcYQ4W76hFs4r2ni3PCQwYsWv+JUdnnB/ btG3U5O7wnSbU/GGUyf75m/k7gAdcfdhLke8eWKS3kAlZGBS2H6z7ZdoXQrAjCM8TcWJ WnOj/C7yMfb5U9YItuzCyDifZaLi9qtbfBeWfmy114UyhNCH6yJtOZXvVSSons656EtF mZ+3wai9Rwq2qJkxmMgyI99cHt1mFUxiV4wv4ZU+FyFQockCHe6RW1hn878VRb2MBcmu 5M4famSBMrV2kFrIgkmVm8YTJfxlZbZPCqdUpBQrfXGRWyiowczwRXQ8rqxojMFSVrCp MC7g== 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=Jj0kajufb+hVdfD9LxiiRST07xDK0ORruFCGJ1qwQSg=; b=XR5FwGr4H7sHsHP1CZS5bTh4zb6sQN406hGXi1rV+nD1tWvOrO8xUKpLtvPz2BgPoj sJDs0X16NW4abF5BYAl7TjkTeSljz7JFYCvzOley/uTwj1lzna/0HF7P3rFo8KosATN3 nd3LFoHsogSi3jFKWi6zNXHEb+gKEoR6Oqbaq2hE5cYmSdYfVlavq0RJA7Z9d7yl1V39 YfLPwSZE//Cz0LIQw+Fc4J2o5xg+Q5UX1wWF+cR+mXLelxofy6MjZeMTZD/bfsmce8M8 sRcgPpdsP7pl2LZBi4rr9UFd1038tQWSGdwvdWw+E/w6BfAWwCTZZDo1J96ISO6eHffi 0Jsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755537157; x=1756141957; 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=Jj0kajufb+hVdfD9LxiiRST07xDK0ORruFCGJ1qwQSg=; b=rUrX2sNpcsZHQoodRXiT0bJr1C8qY7yqLoLwKjKOw3EKrC5Cf5XPTzOb5ZN9Dr6E2Q ZjZbfxRmgY1XfBimq8oIkqVIAlfxdGZ0w51QFfzfxH8VB0Na9N2atP6sgPiDxkWxvanz /Iv4Z1E4oSsS80b0cpIeq9UkW+i/DYslZnHfaXm77kSCK5btN5/8gEG1CkLq6hW5IN5W jFP1ek/aWMsdKnN3UgYGwOZ57f5yUQvputwIKuT40rIO8YdW3TBluAYxbWCbnbHAexUD 4SJePlLUWJzM20Mg7OmmmuMQsBDInHRyhOJRYnZ3Os6XPY/J+RLuN3nvp9Zq2yBbmzTq ec6g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXpNIhm8ycozJ0fmRbjWnxrJjcq0T5d5NQ24/ByoSRQwmdicXksAvuOxXnY2ZHaQK3tErs5RTZ1SlKX@gnusha.org X-Gm-Message-State: AOJu0YxY+bfRnRimpORWljJtIaXU/gAhdCaIGQA/siIh1VfEWUgG/5sz Ma4M0LQC6stPYDzLaCChEJ1csW0eNvI2porJRGnLLGi0AsUdvJJUbIRq X-Google-Smtp-Source: AGHT+IEUH6POitUnSEiHPhoGOUkRWZA9MYv21JAUe1FZyrO3J9fMUs2jkEEWHEy53nxUZXUTBzsMHQ== X-Received: by 2002:a05:622a:58c3:b0:4b0:64f9:decf with SMTP id d75a77b69052e-4b11e218326mr183495791cf.41.1755537156280; Mon, 18 Aug 2025 10:12:36 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfcqZDcjmb1VKhvKP/hFjcgCc2GfzrXdUhystavME4uFA== Received: by 2002:a05:622a:30d:b0:4a9:e227:30b with SMTP id d75a77b69052e-4b109b67628ls78522041cf.1.-pod-prod-02-us; Mon, 18 Aug 2025 10:12:31 -0700 (PDT) X-Received: by 2002:a05:620a:450c:b0:7e6:9664:2270 with SMTP id af79cd13be357-7e87e0124d0mr1606714685a.23.1755537151022; Mon, 18 Aug 2025 10:12:31 -0700 (PDT) Received: by 2002:a05:6808:66d8:b0:3f9:f009:458e with SMTP id 5614622812f47-435f72ef89fmsb6e; Sat, 16 Aug 2025 11:40:49 -0700 (PDT) X-Received: by 2002:a17:902:fc8e:b0:23f:cd4d:a91a with SMTP id d9443c01a7336-2446d8b5f2fmr95505975ad.30.1755369648163; Sat, 16 Aug 2025 11:40:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1755369648; cv=none; d=google.com; s=arc-20240605; b=DcdcLAZNGHfn4ayzvRVX/BQOc4+8cWOaZawrGKn54cvMqjiKTie33QIZXnwcMsG0aD ubODb2cB2dHjy73byILynt/A89pGMP8hd20287lIBGLy4NVR3PU/Rgd9oBsj0cDfVKdp 807V+4IO+6Tx3GH/q4Ck1Q+blwMlg6Li7B2J2w2M2sBKKFQm7WinCyOEzZ9SfTHshkvf Oc953msL+2BJmBa7FxpCFd+GlFujXbnReT7fZ5B3Yb+g/Waml9dv7CMziHmoMX1NWjg9 RUPj6r/Y7Ef6kde0UNWFL52IoRDw/LvGlzQzgeCBp/siy/1G2bVJK7aS8uNDDryusauT D6zA== 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=geXgkM6INsIQrUKitq8dBZyJwA6SjfdqfW/1clDU1k4=; fh=dEDbYMbbYyDNRr1LOwMlw2+lJDEDNk0XskwzeS3uI5o=; b=kCiArlpasQ1eSHUF2CUCY5Po0slfC30Lp2Qw/QVruYHglKaszn0/fS1mbp7jonIHH2 EkQlhTxTWldM+kjVhFJ8HDyrzKzlyDDk7j3vzBtrkKYDhkOBjjcNWm2aO1nJSaNkuU0m OIAUraGO+p4hpAd65AgRPPr0/03tUqQ6JK8HTzF7M28l7eErhFPqQy3UpzaCtDuszxtx /VLvvmhXCsFD/ApmV5A2hpyR0XhjixyLXwQAh1Zu3ZKFibZwrjLgaGed2oqcvGILtPwI ohxK+mMBFFmvL9ihLE9hTPOWIXvfofQOwX5oIdSqUQq6QcnGQQ2sBurJJzXnM9/FsFNt lLNw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=RYp3NLRb; spf=pass (google.com: domain of marcjohnson518@gmail.com designates 2607:f8b0:4864:20::1136 as permitted sender) smtp.mailfrom=marcjohnson518@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com. [2607:f8b0:4864:20::1136]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-2446cb74e02si1710155ad.2.2025.08.16.11.40.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 Aug 2025 11:40:48 -0700 (PDT) Received-SPF: pass (google.com: domain of marcjohnson518@gmail.com designates 2607:f8b0:4864:20::1136 as permitted sender) client-ip=2607:f8b0:4864:20::1136; Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-71d608e34b4so23432437b3.3 for ; Sat, 16 Aug 2025 11:40:47 -0700 (PDT) X-Gm-Gg: ASbGncvl+IzeoV2lHnKj3AeQ0xuJDfb98bHgg18EXnxXSALTuhfkMtIQ9JaOL9P7nvZ VccsDhAvYK0pLWGQeUaSGHXVHY0qzngPrd7AQz4tCfmJVWxYJSjCvTXgkLrdx3hNuFgSzaXP3/m rHqFOVYopGTFilKmc0dxa+fGZOTmcMfcW15zlyZitfq9salB2NbtxRYNnNcvW5eEVSgr4Kp1ijQ YoxoYc= X-Received: by 2002:a05:690c:7001:b0:71b:f755:bbc1 with SMTP id 00721157ae682-71e6de249e4mr73243737b3.31.1755369646928; Sat, 16 Aug 2025 11:40:46 -0700 (PDT) MIME-Version: 1.0 References: <173b3bc4-7052-4e0e-9042-ca15cd5b0587n@googlegroups.com> In-Reply-To: From: Marc Johnson Date: Sat, 16 Aug 2025 19:40:35 +0100 X-Gm-Features: Ac12FXxN3PI4kK0BCMqSGag0PPppOBm13NZ5EGpsUQTO0AcAiZdWH63TG9NGS3Y Message-ID: Subject: Re: [bitcoindev] Re: A Post Quantum Migration Proposal To: Jameson Lopp Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000413a97063c7fd8d3" X-Original-Sender: marcjohnson518@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=RYp3NLRb; spf=pass (google.com: domain of marcjohnson518@gmail.com designates 2607:f8b0:4864:20::1136 as permitted sender) smtp.mailfrom=marcjohnson518@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 (/) --000000000000413a97063c7fd8d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jameson, You're absolutely right that the dual-signature approach I suggested doesn't eliminate Bitcoin's migration problem - but it does transform it into a more manageable one. Let me attempt to clarify: At it's core, what I'm suggesting is an approach to how we handle the transition period, not whether migration is needed. *What Dual Signatures Actually Solve:* The dual-signature approach addresses three specific issues with the forced sunset: 1. No Permanent Loss Deadline: Users who miss initial migration windows aren't permanently locked out. During the transition period, they can st= ill move funds by providing both signatures. 2. Gradual Security Upgrade: Rather than a binary "migrate or lose everything," users can operate with increasing security levels: - Continue using ECDSA (accepting quantum risk) - Use both signatures (quantum-resistant but backwards compatible) - Eventually transition to quantum-only 3. Market-Driven vs Forced Migration: Instead of protocol-enforced deadlines, market forces (exchange requirements, user preference) drive adoption. *How This Could Work for Bitcoin:* A potential implementation path: - Phase 1: Enable quantum-resistant output types (like BIP-360) - Phase 2: Implement dual-signature validation for new transactions - Phase 3: Allow "transition transactions" where exposed-pubkey UTXOs can be spent with additional quantum proofs - Phase 4: Gradually increase economic incentives for quantum migration (fee discounts, priority processing) The critical difference: No Phase B cutoff where funds become permanently unspendable. *The Key Question:* Perhaps the core question isn't "how do we eliminate the migration problem?" but rather "how do we make migration as safe and flexible as possible?" Your sunset approach prioritizes network security through forced migration. The dual-signature approach prioritizes user sovereignty through optional migration. Both have trade-offs. But given BTC's history with soft forks and the principle that "not your keys, not your coins" shouldn't become "not migrated in time, not your coins," perhaps we should explore approaches that preserve user optionality even if they increase implementation complexity. What do you think about a hybrid approach - sunset for clearly abandoned coins (no movement in 10+ years) but dual-signature support for active-but-unmigrated funds? Best, Marc On Tue, Aug 12, 2025 at 3:57=E2=80=AFPM Jameson Lopp wrote: > > > 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 t= o >> 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 sever= al >> 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 slight= ly 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 sche= me > 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 >> production, including the world=E2=80=99s first quantum-resistant Lightn= ing 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 continu= e >> to honor Bitcoin=E2=80=99s principles of decentralization and sound mone= y. >> >> ## 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 lau= nching our >> public testnet soon and would value feedback from the Bitcoin community. >> >> The quantum threat is real, and we need multiple approaches to ensure th= e >> future of decentralized money. Whether through Bitcoin=E2=80=99s eventua= l upgrade >> or alternatives like Supernova, the important thing is that we act befor= e >> 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-= time >> Bitcoin supporter who wants to see the entire ecosystem survive the quan= tum >> 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. Th= is >>> applies to both freezing and commit/reveal schemes; the latter may resu= lt >>> 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 UTX= O >>> set into 256 groups deterministically (for example, by looking at the f= irst >>> byte of the TXID) and apply the constraints over 256 days, processing o= ne >>> group per day. Procrastinators will learn what is happening through wor= d of >>> mouth, act to save their funds, and only a small percentage of coin own= ers >>> will be harmed. >>> >>> Another approach is to *provide a temporary opt-out option*. If someone >>> finds themselves blocked, they would still have a limited time to take = an >>> action, without requiring any extra knowledge, to get unblocked. This w= ould >>> help raise awareness. After being temporarily blocked and recovering th= eir >>> funds through the opt-out mechanism, the person would understand that t= hey >>> 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-o= ut >>> ", which would enable the old acceptance rules for the transactio= n >>> 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 wro= te: >>> >>> 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 pos= t >>> 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 >>> 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 >>> 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 pr= oof 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 Bitco= in=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 be= fore has >>> Bitcoin faced an existential threat to its cryptographic primitives. A >>> successful quantum attack on Bitcoin would result in significant econom= ic >>> 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-relevan= t 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. A= lgorithms >>> are improving up to 20X >>> , >>> lowering the theoretical hardware requirements for breaking class= ical >>> 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 b= leed to >>> not alert chain watchers. Q-Day may be only known much later if t= he attack >>> withholds broadcasting transactions in order to postpone revealin= g their >>> capabilities. >>> - >>> >>> 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 expos= ed >>> pubkeys) private keys will be found and used to steal the funds. >>> - >>> >>> Impossible to know motivations. >>> - >>> >>> Prior to a quantum attack, it is impossible to know the >>> motivations of the attacker. An economically motivated attacker = will try >>> to remain undetected for as long as possible, while a malicious a= ttacker >>> 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, t= ime-boxed >>> pathway is the only credible defense. >>> - >>> >>> Coordinating distributed groups is more prone to delay, even if >>> everyone has similar motivations. Historically, Bitcoin has been = slow to >>> adopt code changes, often taking multiple years to be approved. >>> >>> Benefits at a Glance >>> >>> - >>> >>> Resilience: Bitcoin protocol remains secure for the foreseeable >>> future without waiting for a last-minute emergency. >>> - >>> >>> Certainty: Bitcoin users and stakeholders gain certainty that a plan >>> is both in place and being implemented to effectively deal 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 migrate become >>> unspendable, reducing supply, as Satoshi described >>> . >>> >>> Specification >>> >>> Phase >>> >>> What Happens >>> >>> Who Must Act >>> >>> Time Horizon >>> >>> Phase A - Disallow spends to legacy script types >>> >>> Permitted sends are from legacy scripts to P2QRH scripts >>> >>> Everyone holding or accepting BTC. >>> >>> 3 years after BIP-360 implementation >>> >>> Phase B =E2=80=93 Disallow spends from quantum vulnerable outputs >>> >>> At a preset block-height, nodes reject transactions that rely on >>> ECDSA/Schnorr keys. >>> >>> Everyone holding or accepting BTC. >>> >>> 2 years after Phase A activation. >>> >>> Phase C =E2=80=93 Re-enable spends from quantum vulnerable outputs via = ZK Proof >>> >>> Users with frozen quantum vulnerable funds and a HD wallet seed phrase >>> can construct a quantum safe ZK proof to recover funds. >>> >>> Users who failed to migrate funds before Phase B. >>> >>> TBD pending research, demand, and consensus. >>> Rationale >>> >>> - >>> >>> Even if Bitcoin is not a primary initial target of a >>> cryptographically relevant quantum computer, widespread knowledge th= at such >>> a computer exists and is capable of breaking Bitcoin=E2=80=99s crypt= ography 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 destr= oy >>> value and trust in Bitcoin rather than extract value. There is no w= ay to >>> know in advance how, when, or why an attack may occur. A defensive >>> position must be taken well in advance of any attack. >>> - >>> >>> Bitcoin=E2=80=99s current signatures (ECDSA/Schnorr) will be a tanta= lizing >>> target: any UTXO that has ever exposed its public key on-chain (roug= hly 25 >>> % of all bitcoin) could be stolen by a cryptographically relevant qu= antum >>> 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 propos= als: >>> 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 = types. >>> 3. >>> >>> With a clear deadline, industry stakeholders will more readily >>> upgrade existing infrastructure to ensure continuity of services. >>> - >>> >>> Minimizes loss of access to funds >>> 1. >>> >>> If there is sufficient demand and research proves possible, >>> submitting a ZK proof of knowledge of a BIP-39 seed phrase corres= ponding 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. >>> >>> >>> Stakeholder >>> >>> Incentive to Upgrade >>> >>> Miners >>> >>> =E2=80=A2 Larger size PQ signatures along with incentive for users to m= igrate >>> will create more demand for block space and thus higher fees collected = by >>> miners. >>> >>> =E2=80=A2 Post-Phase B, non-upgraded miners produce invalid blocks. >>> >>> =E2=80=A2 A quantum attack on Bitcoin will significantly devalue both t= heir >>> 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 mitiga= te emerging >>> threats will prove Bitcoin to be an investment grade asset. >>> >>> Exchanges & Custodians >>> >>> =E2=80=A2 Concentrated risk: a quantum hack could bankrupt them overnig= ht. >>> >>> =E2=80=A2 Early migration is cheap relative to potential losses, potent= ial >>> 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 invi= tes procrastination. >>> >>> Attackers >>> >>> =E2=80=A2 Economic incentive diminishes as sunset nears, stolen coins c= annot 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 acto= r to >>> destroy both value and trust. >>> >>> >>> "Lost coins only make everyone else's coins worth slightly more. Think >>> of it as a donation to everyone." - Satoshi Nakamoto >>> >>> >>> If true, the corollary is: >>> >>> >>> "Quantum recovered coins only make everyone else's coins worth less. >>> Think of it as a theft from everyone." >>> >>> >>> The timelines that we are proposing are meant to find the best balance >>> between giving ample ability for account owners to migrate while >>> maintaining the integrity of the overall ecosystem to avoid catastrophi= c >>> 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-quant= um >>> witness programs as anyone-can-spend scripts. They are strongly encoura= ged >>> 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 recei= ve >>> from any other wallets and can only send to upgraded wallets. After Ph= ase >>> B, both senders and receivers will require upgraded wallets. Phase C wo= uld >>> 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 Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/173b3bc4-7052-4e0e-9042-ca1= 5cd5b0587n%40googlegroups.com >> >> . >> > --=20 M: +1-646-541-2108 W: marcjohnson.xyz --=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/= CACH3BCRuGfsggczAp2iO%2Bt4BcnAXvTEGUmO%2Bi3mK%3DzzOAY04gQ%40mail.gmail.com. --000000000000413a97063c7fd8d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jameson,
You're absolutely right that the dual-signature approach I suggested d= oesn't eliminate Bitcoin's migration problem - but it does transfor= m it into a more manageable one. Let me attempt to clarify:

At it= 9;s core, what I'm suggesting is an approach to how we handle the trans= ition period, not whether migration is needed.

What Dual Signatur= es Actually Solve:

The dual-signature approach addresses three s= pecific issues with the forced sunset:
  1. No Permanent Loss Deadline: Users who miss initial migration window= s aren't permanently locked out. During the transition period, they can= still move funds by providing both signatures.

  2. Gradual Sec= urity Upgrade: Rather than a binary "migrate or lose everything,"= users can operate with increasing security levels:
    • Continue us= ing ECDSA (accepting quantum risk)
    • Use both signatures (quantum-res= istant but backwards compatible)
    • Eventually transition to quantum-o= nly

  3. Market-Driven vs Forced Migration: Instead of prot= ocol-enforced deadlines, market forces (exchange requirements, user prefere= nce) drive adoption.

How This Could Work for Bitc= oin:

A potential implementation path:

  • Phase 1: En= able quantum-resistant output types (like BIP-360)
  • Phase 2: Impleme= nt dual-signature validation for new transactions
  • Phase 3: Allow &q= uot;transition transactions" where exposed-pubkey UTXOs can be spent w= ith additional quantum proofs
  • Phase 4: Gradually increase economic = incentives for quantum migration (fee discounts, priority processing)
    • <= /ul>

    The critical difference: No Phase B cutoff where funds become pe= rmanently unspendable.

    The Key Question:

    Perhaps the core question isn't= "how do we eliminate the migration problem?" but rather "ho= w do we make migration as safe and flexible as possible?" Your sunset = approach prioritizes network security through forced migration. The dual-si= gnature approach prioritizes user sovereignty through optional migration.
    Both have trade-offs. But given BTC's history with soft forks and= the principle that "not your keys, not your coins" shouldn't= become "not migrated in time, not your coins," perhaps we should= explore approaches that preserve user optionality even if they increase im= plementation complexity.

    What do you think about a hybrid approach -= sunset for clearly abandoned coins (no movement in 10+ years) but dual-sig= nature support for active-but-unmigrated funds?

    Best,
    Marc
<= /div>
On Tue, Aug 12, 2025 at 3:57=E2=80=AFPM Jameson Lopp &= lt;jameson.lopp@gmail.com>= wrote:


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

I'd first like to say thank you to= James for the comprehensive proposal. The quantum threat is indeed existen= tial, and I appreciate the detailed thinking that went into this migration = plan. However, I=E2=80=99d like to respectfully raise some concerns about t= he approach and share an alternative perspective from work we=E2=80=99ve be= en doing in this space.

## Concerns with the Forced Sunset Approach<= br>
The proposal=E2=80=99s Phase B - rendering ECDSA/Schnorr spends inva= lid - essentially threatens users with permanent fund loss. This creates se= veral issues:

1. **Violation of Bitcoin=E2=80=99s Social Contract**:= Satoshi=E2=80=99s principle that =E2=80=9Clost coins only make everyone el= se=E2=80=99s coins worth slightly more=E2=80=9D becomes =E2=80=9Ccoins you = don=E2=80=99t migrate in time are forcibly lost.=E2=80=9D This fundamentall= y changes Bitcoin=E2=80=99s value proposition.

2. **The 25% Problem*= *: With ~5.25 million BTC having exposed public keys, forcing these to beco= me unspendable could create massive economic disruption. Many of these may = be genuinely lost coins, but some could be long-term cold storage, inherita= nce situations, or users who simply miss the migration window.

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

## An Alternative App= roach: Learning from Supernova

Our team has been working on these ex= act problems and recently reached production readiness with Supernova - a B= itcoin-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 s= ee how this solves Bitcoin's migration problem; how would currently loc= ked 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 th= is setup on Bitcoin, you just end up recreating the migration problem.


**Thr= ee Modes of Operation:**
- **Legacy Mode**: ECDSA signatures only (Bitco= in-compatible)
- **Transition Mode**: Both ECDSA and quantum signatures = required
- **Quantum Mode**: Quantum signatures only

This approac= h:
- Never locks users out of their funds
- Allows gradual, voluntary= migration
- Maintains backwards compatibility indefinitely
- Provide= s immediate protection for those who want it

## Key Innovations Wort= h Considering

1. **Hybrid Signatures**: Instead of a hard cutoff, tr= ansactions can require both classical and quantum signatures during transit= ion. This provides quantum security while maintaining compatibility.
2. **Address Format Compatibility**: Our quantum addresses (snq1...) coexi= st with standard addresses (sn1...), allowing users to choose their securit= y level per transaction rather than per wallet.

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

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

## A Cooperative = Path Forward

Rather than viewing this as competition, I see opportun= ity for collaboration. Supernova could serve as a real-world testbed for qu= antum migration strategies. We=E2=80=99ve already implemented:

- NIS= T-standardized algorithms (Dilithium, SPHINCS+, Falcon)
- Quantum-resist= ant atomic swaps with Bitcoin
- Full Lightning Network with quantum HTLC= s
- Zero-knowledge proofs for enhanced privacy

Bitcoin could lear= n from our implementation experience, while we continue to honor Bitcoin=E2= =80=99s principles of decentralization and sound money.

## Invitatio= n to Explore

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

The quantum threat is real, and we need mul= tiple approaches to ensure the future of decentralized money. Whether throu= gh Bitcoin=E2=80=99s eventual upgrade or alternatives like Supernova, the i= mportant 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 thou= ghts on the dual-signature approach and whether something similar could wor= k for Bitcoin without the harsh sunset provisions.

---

*Note:= While I represent the Supernova project, I=E2=80=99m also a long-time Bitc= oin supporter who wants to see the entire ecosystem survive the quantum tra= nsition. These challenges affect us all.*

On Sunday, July 20, 2025 at 11:56:4= 8=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 bl= ocks currently used spending scenarios. This applies to both freezing and c= ommit/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 suc= h forks incrementally across the UTXO set. Instead of freezing or const= raining all UTXOs at once, we split the UTXO set into 256 groups determinis= tically (for example, by looking at the first byte of the TXID) and apply t= he constraints over 256 days, processing one group per day. Procrastinators= will learn what is happening through word of mouth, act to save their fund= s, and only a small percentage of coin owners will be harmed.
Another approach is to provide a temporary opt-out option. If someone finds themselves blocked, they would still have a limited tim= e to take an action, without requiring any extra knowledge, to get unblocke= d. This would help raise awareness. After being temporarily blocked and rec= overing their funds through the opt-out mechanism, the person would underst= and that they need to take further steps with their remaining coins to avoi= d being permanently blocked once the opt-out period ends.=C2=A0The action t= o unblock the funds could be as simple as sending a transaction with OP_RET= URN "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 forever.
=
Best,
Boris

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

Building upon m= y earlier essay against allowing quantum reco= very of bitcoin I wish to formalize a propo= sal 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 addres= s the issues of incentivizing adoption and migration of funds = after consensus is established that it is p= rudent to do so.

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

Abstract= This proposal follows the implementation of post-quantum (PQ) o= utput type (P2QRH) and introduces a pre-announced sunset of legacy ECDSA/Sc= hnorr 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 p= reviously existed.=C2=A0

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

    • <= li dir=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;font-family:&qu= ot;Courier New",monospace;color:rgb(0,0,0);background-color:transparen= t;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-a= lternates:normal;vertical-align:baseline;white-space:pre-wrap">

    Phase B: Renders ECDSA/Schnorr spends invalid, preventing all spendin= g of funds in quantum-vulnerable UTXOs. This is triggered by a well-publici= zed flag-day roughly five years after activation.

  • Phase C (optional): Pending further research and demand, a separate BIP propo= sing a fork to allow recovery of legacy UTXOs through ZK proof of possessio= n 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 attacks. This p= roposal is radically different from any in Bitcoin=E2=80=99s history just a= s the threat posed by quantum computing is radically different from any oth= er threat in Bitcoin=E2=80=99s history.=C2=A0 Never before has Bitcoin face= d an existential threat to its cryptographic primitives. A successful quant= um attack on Bitcoin would result in significant economic disruption and da= mage across the entire ecosystem. Beyond its impact on price, the ability o= f miners to provide network security may be significantly impacted.=C2=A0= =C2=A0

  • Accelerating quantum progress.=C2=A0

    • NIST ratified three = production-grade PQ signature schemes in 2024; academic road-maps now estim= ate a cryptographically-relevant quantum computer as early as 2027-2030. [<= /span>McKinsey= ]

  • Quantum algorithms are rapidl= y improving

    • The safety envelope is sh= rinking by dramatic increases in algorithms even if the pace of hardware im= provements is slower. Algorithms are improving up to 20X, lowering the theoretical hardware requ= irements for breaking classical encryption.

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

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

    • =

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

    • Quantum attackers could compute the private key for known public keys t= hen transfer all funds weeks or months later, in a covert bleed to not aler= t chain watchers. Q-Day may be only known much later if the attack withhold= s broadcasting transactions in order to postpone revealing their capabiliti= es.

  • Private keys become public.=C2=A0

    • Assuming that quantum computers are able to maintain their c= urrent trajectories and overcome existing engineering obstacles, 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 kno= w motivations.=C2=A0

      • Pri= or to a quantum attack, it is impossible to know the motivations of the att= acker.=C2=A0 An economically motivated attacker will try to remain undetect= ed for as long as possible, while a malicious attacker will attempt to dest= roy as much value as possible.=C2=A0=C2=A0

    • Upgrade inertia.=C2=A0

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

      • The longer we postpone migrati= on, the harder it becomes to coordinate wallets, exchanges, miners, and cus= todians. A clear, time-boxed pathway is the only credible defense.

      • Coordinatin= g distributed groups is more prone to delay, even if everyone has similar m= otivations. Historically, Bitcoin has been slow to adopt code changes, ofte= n taking multiple years to be approved.

    Benefits at a Glance

    • Resilience:<= /span> Bitcoin protocol remains secure for the foreseeable future without waitin= g for a last-minute emergency.

    • Certa= inty: Bitcoin users and stakeholders gain certainty that a plan is both i= n place and being implemented to effectively deal with the threat of quantu= m theft of bitcoin.=C2=A0=C2=A0

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

    • Suppl= y Discipline: Abandoned keys that never migrate become unspendable, reduc= ing supply, as Satoshi described.= =C2=A0=C2=A0

    Specif= ication

    Phas= e

    What Happens

    Who Must Act

    Time Horizon=

    Phase A - <= 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">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 implement= ation

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

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

    Everyone ho= lding or accepting BTC.

    2 years after Phase A activation.

    Phase C =E2=80=93 Re-enable spends from quantum vulnerable outputs via ZK Proof<= /p>

    Us= ers with frozen quantum vulnerable funds and a HD wallet seed phrase can co= nstruct a quantum safe ZK proof to recover funds.

    Users who failed to = migrate funds before Phase B.

    TBD pending research, demand, and consen= sus.

    Rationale

    • Even if Bitcoin= is not a primary initial target of a cryptographically relevant quantum co= mputer, widespread knowledge that such a computer exists and is capable of = breaking Bitcoin=E2=80=99s cryptography will damage faith in the network .= =C2=A0

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

      • <= li dir=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;font-family:&qu= ot;Courier New",monospace;color:rgb(0,0,0);background-color:transparen= t;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-a= lternates:normal;vertical-align:baseline;white-space:pre-wrap">

      Bitcoin=E2=80=99s curr= ent signatures (ECDSA/Schnorr) will be a tantalizing target: any UTXO that = has ever exposed its public key on-chain (roughly 25 % of all bitcoin) coul= d be stolen by a cryptographically relevant quantum computer.

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

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

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

        2. Allow throttled theft of coins, w= hich leads to RBF battles and ultimately miners subsidizing their revenue f= rom lost coins.

        3. Allow no one to steal vulnerable coins.

      2. Minimizes attack surface

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

        2. Upgrades to Bitc= oin have historically taken many years; this will hasten and speed up the a= doption of new quantum resistant script types.=C2=A0

        3. With a clear deadline= , industry stakeholders will more readily upgrade existing infrastructure t= o ensure continuity of services.=C2=A0=C2=A0

      3. =

        Minimizes = loss of access to funds=C2=A0

        1. I= f 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 h= ash 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


    Stakeholder

    Incentive to U= pgrade

    Min= ers

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

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

    =E2=80=A2 A quantum at= tack on Bitcoin will significantly devalue both their hardware and Bitcoin = as a whole.=C2=A0

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

    Institutional Holders

    =E2=80=A2 Fiduciary duty: failing to act to prev= ent a quantum attack on Bitcoin would violate the fiduciary duty to shareho= lders.=C2=A0=C2=A0

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

    Exchanges & Custodians

    =E2=80=A2 Concentrated ris= k: a quantum hack could bankrupt them overnight.

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

    Everyday Users

    =E2=80=A2 Self-sover= eign peace of mind.

    =E2=80=A2 Sunset date creates a c= lear deadline and incentive to improve their security rather than an open-e= nded =E2=80=9Csome day=E2=80=9D that invites procrastination.

    Attackers

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

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

    This is not an offensive attack, rather, it is defen= sive: 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 mali= cious actor to destroy both value and trust.=C2=A0=C2=A0


    =
    "Lost coins only make everyone else's coins wor= th slightly more. Think of it as a donation to everyone." - Satoshi Na= kamoto

    If true, the corollary is:=


    <= /span>

    "Quantum recovered coins only make everyo= ne 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 ow= ners to migrate while maintaining the integrity of the overall ecosystem to= avoid catastrophic attacks.=C2=A0=C2=A0


    Back= ward Compatibility

    As a series of soft forks, olde= r nodes will continue to operate without modification. Non-upgraded nodes, = however, will consider all post-quantum witness programs as anyone-can-spen= d scripts. They are strongly encouraged to upgrade in order to fully valida= te the new programs.


    Non-upgraded wallets can rec= eive and send bitcoin from non-upgraded and upgraded wallets until Phase A.= After Phase A, they can no longer receive from any other wallets and can o= nly send to upgraded wallets.=C2=A0 After Phase B, both senders and receive= rs will require upgraded wallets.=C2=A0Phase C would likely require a loose= ning of consensus rules (a hard fork) to allow vulnerable funds recovery vi= a 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.


--
M: +1-646-541-2108

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.co= m/d/msgid/bitcoindev/CACH3BCRuGfsggczAp2iO%2Bt4BcnAXvTEGUmO%2Bi3mK%3DzzOAY0= 4gQ%40mail.gmail.com.
--000000000000413a97063c7fd8d3--