Delivery-date: Tue, 19 Aug 2025 14:12:02 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uoTcd-0004XA-Uq for bitcoindev@gnusha.org; Tue, 19 Aug 2025 14:12:02 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-3111d74dbefsf759146fac.1 for ; Tue, 19 Aug 2025 14:11:59 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1755637914; cv=pass; d=google.com; s=arc-20240605; b=X4c0xL4aIEajOalVPO9wmf8YJfU8rgh+QB9Iij1tlIt5B+WK2cqToeIince9QpvoTj ClgJt50G9T90X/zsKmf84RzKGcCSzzNskTKwQvNQvWyBvwhmMv4GEOq+2rSMSRtWhtBq 6daHJwQyMN0RattovUSkVcIujDOQnMpKgvxt3RPJbAEgDv0a+piqMsvB6TRo0AiaKAe/ AflqBg4g8QYZRBlX+upcA+i7m9xcdfez8+ssmoanRHP4/5ueKo6OLHewnu4q9dZ0AXkY LBNOp+oYWpb7Zxraf6S+FxcI3E7SDZwKaufIhSMEYT2G1shAtQsBdQFWfneHn4XP6EwP T6uQ== 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=rm+1oelxzj3JVMud86qPLwW3ql48OOJR8FMQEup3cPk=; fh=QmSTujeL4lS8rx2Wjjh96jUeogj3uFpa1wrFt6msak0=; b=hp5gwAkkF8sqm03uewBKkXAsmYSXM0cOfv4CoSht2hFhsZGQPhzlRwWNuFX6DlWzz0 /m9RW+NKqgMTf9TqTAA/t0pEn4oAHJozi8Lt+1j1xwUMtyxN6EISdr+08moLxUpUAtBf SyR4u6LT4nflLY2xluhzrZPrZhw9v5bho+25YZZRGLPLHQZRSiNXfP7cx/65jWgm1SLh FE/vSTjSd983uOT9O5pYMab33Da51zOMN/HWwOnHfXee8Hp006Dy8OGkxx1z6ar8ae0H 3a6b9bes6ALIAGrSZSDdB4wUooQdfMGwi6sBLHO6M7nfBlMb0jOssWGQqfDYbO3rNt9l +g8A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=HCKQ7rER; spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=saintwenhao@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1755637914; x=1756242714; 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=rm+1oelxzj3JVMud86qPLwW3ql48OOJR8FMQEup3cPk=; b=TBZKPsZAwvgnj7XWvJHHqeg9o6mS/r5YegYKHiRsE5GZSWrU16hpWmkHMSeMlcw4bI FTQ7LAwB9xb8oHU4Y7sVhaZMucxxsyiempoDbq2iv+H0muxj9wktWUEGQ7qUTv6mYdz8 WT/I7JgVHg3fC7l4w1XDe2R3FlXMmpT3Ma6vkbZ9raV0FXutblwc4dvjnUM8du6DdA+y hDKKj1FOiCSH2UP8B+klUuAFXhsl4+VpW6NPgR9c7PhdOn0YgVwgJY93IPmMqTulmdgN YYUpS+8Q+lqCzqw777m8KedeHt2Qa6xATvy3j5RZCY4jWQ9nwsyB9vpUw6jDa94bNPtN NGJg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1755637914; x=1756242714; 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=rm+1oelxzj3JVMud86qPLwW3ql48OOJR8FMQEup3cPk=; b=SWY5X4SqogpqyAIvIT2ufVTXvIASvcj7Dm3OHCKUrO6Odrrlqaoyc1QAPXOBHmFQsi UYEYGQ3ZsjyFcsyH5XJTLmFJ49ZIhc36AsawuchRETgt8tpe7+PQa5ig5KoAMYm7Q2+8 44lMGNTdRwwzdOoILFUdN8Qb8ZIluSrABDIfP3LKoiynyH2X3XeVArXRiuSed1Nqk8ri ln27LhrKw4ZLrPkncEf+4IbrxpYc5t7RVmFiPeS1BQ2cScf6TFBh2tlf72tqBM+U9tGN 46cPXhg24ZiwHB6WkysmShglt7gZReACf05NCMg//BVq34kV4QGJLeErrSPZEUppRIYa xnTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755637914; x=1756242714; 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=rm+1oelxzj3JVMud86qPLwW3ql48OOJR8FMQEup3cPk=; b=iv4Oc5dQdKCdlBDZSL1QjsnE9+Nr33ET78ZzkNDbJtYvgcILgv16WNd6f+YOnsECVn o8jYZHcgH/3a5+3KsdBpZkBsaGB8NKLmbmQF2hwwfMRISi3VogUTl/nXZj6u3LtzVRUC LTkfng1HIDHw7nV0zfRZY87bDFgI4D4j++AfKCzm7odBwik+z1902V3txO1lfoPC9nlX Ke9Wm88ThYP4Uus6SX49FYOsTv4EEtJo47tsJlqMY5+GMSaoxrEUa9jeienenwmKSSWQ aciGXcvc61Od3gUdCcT+BcwCD2jhPD3VIanX8TFR2ymhVmGfeSNnkHkUON4JddXcPlo9 0TWQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWxn4qzernEinQGh4iivWDGTSaifBQ/8LEAq2UOxZ7n1n8083FFKDaNhb/ZxdBpCV0XkmxXYhJu9wW7@gnusha.org X-Gm-Message-State: AOJu0Yz1xX5UWhc43spHz2FZ+C1n43OecQNnZhBi7PE9juMixKwu1MYe aA+piG9ioyP5Sx5OptFwZvDO+HJx6dIbuvvmez+JVg0BARgJmHF2Dx92 X-Google-Smtp-Source: AGHT+IHLrj5Lkj2PbDm/shXXF1r3Hv2RKa3Qul6p2TCZpsBRlZZChayzsC4MgT2aY2+wUlpJTg9gWQ== X-Received: by 2002:a05:6870:e89:b0:30b:ae4c:2e82 with SMTP id 586e51a60fabf-311218ceb1emr515414fac.12.1755637913482; Tue, 19 Aug 2025 14:11:53 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZco9aBXkCVZ39qezF5awpzj2e048nQE76THGEi+SQug5A== Received: by 2002:a05:687c:2bcc:b0:2ff:aac3:cfa7 with SMTP id 586e51a60fabf-31120cdd543ls61864fac.0.-pod-prod-00-us-canary; Tue, 19 Aug 2025 14:11:50 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXNlp5jHxjhdyUVhfezrFgjVhCAnlyZegmwSOw4YyisxDaaXyW40Mscjl9zNEvAbPKbYNuRIH1CmYd2@googlegroups.com X-Received: by 2002:a05:6808:4f64:b0:404:dbf3:5b0d with SMTP id 5614622812f47-4377167aeffmr629415b6e.3.1755637910318; Tue, 19 Aug 2025 14:11:50 -0700 (PDT) Received: by 2002:a05:600d:1b:b0:456:53b:5b5e with SMTP id 5b1f17b1804b1-45a27298062ms5e9; Tue, 19 Aug 2025 01:55:41 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWMwIdH6Kcg7ymb6zqstVMSKlWYCsN5f1f+yj8OIls8dJy6O+kjFDh4zKJ/Ap9cmxZKKYjqozkiXIDI@googlegroups.com X-Received: by 2002:a05:6000:4012:b0:3c0:7e02:67bb with SMTP id ffacd0b85a97d-3c0ecd26d18mr1283530f8f.63.1755593738967; Tue, 19 Aug 2025 01:55:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1755593738; cv=none; d=google.com; s=arc-20240605; b=jvmFxpylpesCe06QDtToehMxN3+q3O5v28hoPwb2lg2XIQABEqO9QQEYkWxKnI3EMv JezWe28ccp9ywVoprV2jCqpveV56LjzJ//EdyFB6GR14mNschneF2VOShQKkMvSjCBlX rRfDceKfnTktnlNwaxXRF3oFAig50WXv4Cboy8Tq43NlwXzMewtRwdyBQG1m0xVkwP4b A+cK3Kh6mCE+tqSSobkOcxKIV6gi/iJmkIhzUmHGOKAUUG6PCbGqFONEs6bfYxqmBfCs vWecLSoBjB9cssCPL4v+c5dM9NYv3b0a5GfJY233pcBWO/AWe6OFWmuJGr7GYbwkphZz ohKQ== 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=UbweMqTR978VMaInjTU/omVAPAr1gJa/PYETLnECt6w=; fh=11ChL6TMk5XBcQe4h21Hl1DFaMWMO8vA84FbmSJu/Hw=; b=KyrWDXCkfW/3UNez1DWR5tH72/Tl0mO69onwWHF0Y0HxQVBaK9z3hp9EMOxdfn7TmX voi+bZ1m+YN+uixi+W4gD6NF3X36sih2B6ODtr6jD0xikamFmtpcmnJ8aEVTYBy7U6rs Kcx27Ap8gpKEpBIUtjKtuWri5+sgc3k+8dWOczalsNKBGzwz+m32NiFMcTB1hrl6m61d Dsc/BIhCk/4lP9Br3QnlUJm2atek7smmYzy1c/JUYmqs7vLrCNEHaKHjW/I1ZnXQeRL7 gUaiz8eidnHr7GRlo1EnXRrvMLqBhoDUN5zsZFs7qCf6gReXD8DRRXRHkkCpR4dMuCPF CClQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=HCKQ7rER; spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=saintwenhao@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com. [2a00:1450:4864:20::532]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-3c076cf7858si44879f8f.5.2025.08.19.01.55.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Aug 2025 01:55:38 -0700 (PDT) Received-SPF: pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) client-ip=2a00:1450:4864:20::532; Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-6188b5b11b2so6314574a12.0 for ; Tue, 19 Aug 2025 01:55:38 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXiJ3g5VroKoJ9v9YLvQTmy6AGaEcVlxv7FS3y+Tgy5jRHMxmRD7w4WxF8mPHC1PVoSxtnjE/+3O6Oq@googlegroups.com X-Gm-Gg: ASbGncur3AMVUiMImaXTus/fOgY2vVYLg/etq+wkcVeTdJFTuhka3ebcer03vkoSv8d KWbK7c5Ruh/D6a2udBmGIhFGNrIYJPFfri3D+W1iu6TQXM3ti+QjCiRuLFrHWvtjghOtoHzcXMy kfW7eCh1AkXztmmgnz+yPYSVMtXMZ8yqIdR9RcteI4nPTzoLT9+qJkMZLLy6WJEwHkfR92xf+ML kgDLg== X-Received: by 2002:a05:6402:46c2:b0:615:c767:5b9e with SMTP id 4fb4d7f45d1cf-61a7e73009emr1380452a12.20.1755593738083; Tue, 19 Aug 2025 01:55:38 -0700 (PDT) MIME-Version: 1.0 References: <173b3bc4-7052-4e0e-9042-ca15cd5b0587n@googlegroups.com> In-Reply-To: From: Saint Wenhao Date: Tue, 19 Aug 2025 10:55:25 +0200 X-Gm-Features: Ac12FXxMKpRp1daRe7ckOn7XBIHbnhdAZ0tRu1VVF0P0aY-_vQupSMrvGP0fuLw Message-ID: Subject: Re: [bitcoindev] Re: A Post Quantum Migration Proposal To: Jameson Lopp Cc: Marc Johnson , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000020e178063cb4058d" X-Original-Sender: saintwenhao@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=HCKQ7rER; spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=saintwenhao@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --00000000000020e178063cb4058d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > how would currently locked funds be able to spend via a quantum safe signature scheme if they have not committed to a dual signature scheme? In ECDSA, we have two secp256k1 points in use: one is public key, another is R-value in the signature. If someone has some coins, then the public key cannot be changed, if it is present in the output Script. However, R-value can be freely picked by the signer, and can be set to anything. Which means, that users can commit to any quantum data, by hashing it, and forming a valid commitment in R-value. Which also means, that old nodes can see only ECDSA signatures, and public keys, while new, quantum-resistant nodes, can require R-value to commit to something. Then, in the first phase, when quantum commitments will be optional, users will use only ECDSA on-chain, but new, quantum nodes, will be able to see, what is committed to R-values behind signatures, and can store and process it. And later, when quantum signatures will be obligatory, then for each and every OP_CHECKSIG call, R-value of the old ECDSA signature will be forced to commit to a valid quantum signature. Which also means, that the new quantum data won't be restricted by the current block size limit, but rather by a combination of sigops limit, and a quantum commitment size limit (which can be set to different values, for different quantum proposals, depending on a particular signature scheme). pon., 18 sie 2025 o 19:12 Jameson Lopp napisa=C5= =82(a): > > > On Thu, Aug 7, 2025 at 7:26=E2=80=AFPM Marc Johnson > wrote: > >> Hi All! >> >> I'd first like to say thank you to James for the comprehensive proposal. >> The quantum threat is indeed existential, and I appreciate the detailed >> thinking that went into this migration plan. However, I=E2=80=99d like 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 >> >> . >> > -- > 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/CADL_X_cgqHUOU6V9%2BGsEKz--e= kxmgyYJwOg4BeLajAr_cTVN_g%40mail.gmail.com > > . > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CACgYNO%2B1tFwsd-V67fyCWv%3DWtAXp4V6RQhsTw8XpzYULF7u_UA%40mail.gmail.com. --00000000000020e178063cb4058d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> how would currently locked funds be able to spend via= a quantum safe signature scheme if they have not committed to a dual signa= ture scheme?

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

Which also means, th= at old nodes can see only ECDSA signatures, and public keys, while new, qua= ntum-resistant nodes, can require R-value to commit to something. Then, in = the first phase, when quantum commitments will be optional, users will use = only ECDSA on-chain, but new, quantum nodes, will be able to see, what is c= ommitted to R-values behind signatures, and can store and process it.
And later, when quantum signatures will be obligatory, then for each and = every OP_CHECKSIG call, R-value of the old ECDSA signature will be forced t= o commit to a valid quantum signature. Which also means, that the new quant= um data won't be restricted by the current block size limit, but rather= by a combination of sigops limit, and a quantum commitment size limit (whi= ch can be set to different values, for different quantum proposals, dependi= ng on a particular signature scheme).

pon., 18 sie 202= 5 o 19:12=C2=A0Jameson Lopp <j= ameson.lopp@gmail.com> napisa=C5=82(a):


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

## = Concerns with the Forced Sunset Approach

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

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

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

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

## An Alternative Approach: Learning from Supernova
=
Our team has been working on these exact problems and recently reached = production readiness with Supernova - a Bitcoin-inspired blockchain that im= plements quantum resistance from genesis. Rather than forced migration, we = use a dual-signature scheme that might be instructive for Bitcoin:

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


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

This approach:
- Never locks users out of = their funds
- Allows gradual, voluntary migration
- Maintains backwar= ds compatibility indefinitely
- Provides immediate protection for those = who want it

## Key Innovations Worth Considering

1. **Hybrid = Signatures**: Instead of a hard cutoff, transactions can require both class= ical and quantum signatures during transition. This provides quantum securi= ty while maintaining compatibility.

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

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

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

## A Cooperative Path Forward

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

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

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

## Invitation to Explore

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

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

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

Would love to hear thoughts on the dual-signature approach = and whether something similar could work for Bitcoin without the harsh suns= et provisions.

---

*Note: While I represent the Supernova pro= ject, I=E2=80=99m also a long-time Bitcoin supporter who wants to see the e= ntire ecosystem survive the quantum transition. These challenges affect us = all.*

On Sunday, July 20, 2025 at 11:56:48=E2=80=AFPM UTC+1 Boris Nagaev wrot= e:
Hi Jameson, h= i 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 scenari= os. This applies to both freezing and commit/reveal schemes; the latter may= result in lost funds if the public key is leaked. I realized that this als= o applies to the commit/reveal scheme I proposed in another thread [1].
=
The idea is to roll out such forks incrementally across the UTX= O set. Instead of freezing or constraining all UTXOs at once, we split = the UTXO set into 256 groups deterministically (for example, by looking at = the first byte of the TXID) and apply the constraints over 256 days, proces= sing one group per day. Procrastinators will learn what is happening throug= h word of mouth, act to save their funds, and only a small percentage of co= in owners will be harmed.

Another approach is to <= b>provide a temporary opt-out option. If someone finds themselves block= ed, they would still have a limited time to take an action, without requiri= ng any extra knowledge, to get unblocked. This would help raise awareness. = After being temporarily blocked and recovering their funds through the opt-= out mechanism, the person would understand that they need to take further s= teps with their remaining coins to avoid being permanently blocked once the= opt-out period ends.=C2=A0The action to unblock the funds could be as simp= le as sending a transaction with OP_RETURN "opt-out <txid>"= , which would enable the old acceptance rules for the transaction with that= txid for a period of 2016 blocks.


In that scheme if t= he 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 my earlier essay against allowing quantum recovery of bitcoin I wish to formalize a proposal after several months of discussio= ns.

This proposal does not delve into the multitude of issues re= garding post quantum cryptography and trade-offs of different schemes, but = rather is meant to specifically address the issues of incentivizing adoptio= n 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 i= mplementation of post-quantum (PQ) output type (P2QRH) and introduces a pre= -announced sunset of legacy ECDSA/Schnorr signatures. It turns quantum secu= rity into a private incentive: fail to upgrade and you will certainly lose access to your fund= s, creating a certainty where none previously existed.=C2=A0

  • Phase A: Disallows sendin= g of any funds to quantum-vulnerable addresses, hastening the adoption of P= 2QRH address types.

  • Phase B: Renders ECDSA/Schnorr sp= ends invalid, preventing all spending of funds in quantum-vulnerable UTXOs.= This is triggered by a well-publicized flag-day roughly five years after a= ctivation.

  • Phase C (optional): Pending further resear= ch and demand, a separate BIP proposing a fork to allow recovery of legacy = UTXOs through ZK proof of possession of BIP-39 seed phrase.=C2=A0=C2=A0

Motivation

We seek to secure the value of the UTXO s= et and minimize incen= tives for quantum attacks. This proposal is radically different from any in= Bitcoin=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.=C2= =A0 Never before has Bitcoin faced an existential threat to its cryptograph= ic primitives. A successful quantum attack on Bitcoin would result in signi= ficant economic disruption and damage across the entire ecosystem. Beyond i= ts impact on price, the ability of miners to provide network security may b= e significantly impacted.=C2=A0=C2=A0

  • Acc= elerating quantum progress.=C2=A0

    =

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

    • Quantum algorithms are rapidly improving

      • The safety envelope is shrinking by dramatic increases in algorithms = even if the pace of hardware improvements is slower. Algorithms are improving up to 20X, lowerin= g the theoretical hardware requirements for breaking classical encryption.<= /span>

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

      • <= 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">Roughly 25% of all bitcoin have revealed a public ke= y on-chain; those UTXOs 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 known public keys then transfer all funds weeks or months l= ater, in a covert bleed to not alert chain watchers. Q-Day may be only know= n much later if the attack withholds broadcasting transactions in order to = postpone revealing their capabilities.

    • Private keys become public.=C2=A0=

      • Assuming that quantum c= omputers are able to maintain their current trajectories and overcome exist= ing engineering obstacles, there is a near certain chance that all P2PK (an= d other outputs with exposed pubkeys) private keys will be found and used t= o steal the funds.

    • Impossible to know motivations.=C2=A0

      • Prior to a quantum attack, it is impossib= le to know the motivations of the attacker.=C2=A0 An economically motivated= attacker will try to remain undetected for as long as possible, while a ma= licious attacker will attempt to destroy as much value as possible.=C2=A0= =C2=A0

    • Upgrade inertia.=C2=A0

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

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

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

Benefit= s at a Glance
    <= li dir=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;font-family:Ari= al,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant-nu= meric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;= vertical-align:baseline;white-space:pre-wrap">

    Resilience: Bitcoin protocol remains secure for t= he 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 effec= tively deal with the threat of quantum theft of bitcoin.=C2=A0=C2=A0=

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

  • Supply Discipline: Abandoned keys that n= ever migrate become unspendable, reducing supply, as Satoshi described.=C2=A0=C2=A0

Specification

Phase

Wh= at Happens

Who Must Act

Time Horizon

Phase A - Disallow spends to legacy scr= ipt types

Permitted sends are from legacy scripts to P2QRH scripts

Everyone holding or accepting BTC.

3 years after BIP-360 implementation

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

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

Everyone holding or accepting BTC.

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

2 years after= Phase A activation.

Re-enable spends from quantum vulner= able outputs via ZK Proof

Users with frozen quantum vulnerable funds a= nd 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 pen= ding research, demand, and consensus.

Rationale

  • Even if Bitcoin is not a primary initial target of a cryp= tographically relevant quantum computer, widespread knowledge that such a c= omputer exists and is capable of breaking Bitcoin=E2=80=99s cryptography wi= ll damage faith in the network .=C2=A0

  • An attack on Bitcoin may not be economical= ly motivated - an attacker may be 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 position must be taken well in advance of any atta= ck.=C2=A0=C2=A0

  • Bitcoin=E2=80=99s current signatures (ECDSA/Schnorr) will be a ta= ntalizing target: any UTXO that has ever exposed its public key on-chain (r= oughly 25 % of all bitcoin) could be stolen by a cryptographically relevant= quantum computer.

  • Existing Proposal= s 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 redistribution dilemma. There are 3 types of proposal= s:

      1. Allow anyone to steal vulnera= ble coins, benefitting those who reach quantum capability earliest.<= /p>

      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 vulnerab= le coins.

  • Minimizes attack surface

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

    2. Upgrades to Bitcoin have historically taken many years; this w= ill hasten and speed up the adoption of new quantum resistant script types.= =C2=A0

    3. With a clear deadline, industry stakeholders will more readily upgr= ade existing infrastructure to ensure continuity of services.=C2=A0=C2=A0

  • Minimizes loss of access to funds=C2=A0

    1. If there is sufficient demand and research prov= es possible, submitting a ZK proof of knowledge of a BIP-39 seed phrase cor= responding to a public key hash or script hash would provide a trustless m= eans for legacy outputs to be spent in a quantum resistant manner, even aft= er the sunset.=C2=A0=C2=A0


Stakeholder

Incentive to Upgrade

Miners

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

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

=

= =E2=80=A2 A quantum attack on Bitcoin will significantly devalu= e both their hardware and Bitcoin as a whole.=C2=A0

Institutional Holders

=E2=80=A2 Fidu= ciary duty: failing to act to prevent a quantum attack on Bitcoin would vio= late the fiduciary duty to shareholders.=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 & Custo= dians

=E2=80=A2 Concentrated risk: a quantum hack could bankrupt them ove= rnight.

=E2=80=A2 Early migration is cheap relative t= o potential losses, potential lawsuits over improper custody and reputation= al damage.

Ever= yday Users

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

=E2=80=A2 Sunset date creates a clear deadline and incentive to improve th= eir 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 ne= ars, stolen coins cannot be spent after Q-day.

Key Insigh= t: As mentioned earlier, the proposal turns quantum secu= rity into a private incentive to upgra= de.=C2=A0=C2=A0

This is not an off= ensive attack, rather, it is defensive: our thesis is that the Bitcoin ecos= ystem wishes to defend itself and its interests against those who would pre= fer to do nothing and allow a malicious actor to destroy both value and tru= st.=C2=A0=C2=A0


"Lost coins only ma= ke everyone else's coins worth slightly more. Think of it as a donation= to everyone." - Satoshi Nakamoto

If true, the corollary is:


"Quantu= m recovered coins only make everyone else's coins worth less. Think of = it as a theft from everyone."

The t= imelines that we are proposing are meant to find the best balance between g= iving ample ability for account owners to migrate while maintaining the int= egrity of the overall ecosystem to avoid catastrophic attacks.=C2=A0=C2=A0<= /span>


Backward Compatibility

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


Non-upgraded wallets can receive and send bitcoin from non-upgraded a= nd upgraded wallets until Phase A. After Phase A, they can no longer receiv= e from any other wallets and can only send to upgraded wallets.=C2=A0 After= Phase B, both senders and receivers will require upgraded wallets.=C2=A0Ph= ase C would 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 &= 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https:= //groups.google.com/d/msgid/bitcoindev/CADL_X_cgqHUOU6V9%2BGsEKz--ekxmgyYJw= Og4BeLajAr_cTVN_g%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/CACgYNO%2B1tFwsd-V67fyCWv%3DWtAXp4V6RQhsTw8XpzYULF7u_UA%= 40mail.gmail.com.
--00000000000020e178063cb4058d--