From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 14 Jul 2025 12:06:26 -0700 Received: from mail-yb1-f192.google.com ([209.85.219.192]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ubOVM-0000Lz-4k for bitcoindev@gnusha.org; Mon, 14 Jul 2025 12:06:26 -0700 Received: by mail-yb1-f192.google.com with SMTP id 3f1490d57ef6-e8b80549b1dsf4853634276.2 for ; Mon, 14 Jul 2025 12:06:23 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1752519978; cv=pass; d=google.com; s=arc-20240605; b=HFiJ911su07wY3jxazBE6qQNH+NJsvQmeED/F6TlDlQ6Lo8XuJnmCJ03SwJCFyZfd6 nf0mGXMtXhAb5eUa/m1PFAGuzXpOlKfpM0LfVCDGpC4lqt9avqbiHZoHo4+ixuBwCAD9 Qw2VyNceKpW/Wsm+678upRwa4XWUseUUJYAyTjgbzRSuph4kg8FRNkLktZ4wv8GIou6k aag/p1ttojawKKgoqbeJvOmU9MUYYI5XfoZkjMRq2BLzOyWyRay9KXnqhOFlr37abjQT z4j6Tpx2V7yhxs4A7urktGyqTR50gDVYQQLOpwhkQvreje5Of8HXDG5L5mpbWTvgXXmK BPLw== 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=Go0CSoW2LEDg2nX/cXaqboHQ+PnTq8bbmU1pT9IK3aw=; fh=r7JPJx6TVUD/V3CIPOZrAaGlFAaFvG4qtuyGF3o5b2k=; b=LLpGeDqukFPtMAkYBxmp8zzZn4dbhep8Cr8ZDxeUbtDq992eoazeVsSvMkHMCpUUhk VCVbPD+xKtO09hf6RxW7b1HEz18jkWjhyrfmK3CF5U6ioHZ8+2//GBnJAgQyYLGCTbqZ UkZEAM872wycV+0Li7zilPGnE5fZeLddVw4rfDs8pCYKok7eeMY2S5UjVDWDTWn2JU6M ZH7Ynk7qwj7daLr3P+Ln1v16afLccQ7YW9QHF6LpefOE16PJmSsnXI+dm61d2eiC1DSz lldYEJC2gVstQ8DIHQPUz1d14OQskXLfFMoz6o6sPF+mOpeWFMaKwh4j4kfAvaPvBZk9 1HKQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=d8yI1yQM; spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=eth3rs@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=1752519978; x=1753124778; 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=Go0CSoW2LEDg2nX/cXaqboHQ+PnTq8bbmU1pT9IK3aw=; b=Ba8A3fBKep0VLKcMkSu2O600pxWXs7rEnIAy7a6jSNAXxWGT/HZc4oHyu4BnidgTIH Weu9L+mrq9juYOcBv6mxKRGfZMG5dKmaLFuEwbZgJq8ONI2qqI/Hxcz/yubXrLqYxeDH AbBUF1sO2iz0pKuX/Bzs3sNYWXy+Jncl+czWDvRbl31ozLuC3oKelu7PDBzduHhXziwg YRaRVwGejDBS4hZ322b9Y51TvBGnnaM+jKydbzBVVQT6njOpkp/kLydT7EzL6M6mGo/B yqtnRTzb/ijlBip5ZXUH3grb1gHZPD07pL7pzL164WQLDB7E/cqcq7iA/TrrVv/bOqr4 tEWg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752519978; x=1753124778; 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=Go0CSoW2LEDg2nX/cXaqboHQ+PnTq8bbmU1pT9IK3aw=; b=ZSwCsM0jzJ5EPhu6xOhPzujm7yP4YsGOtsxmX11vVk+CpPpE3+9jTVdhCJDMq3mbnk OBoQCSW1RLwwI/JowcKCllVRpfvgg59Ah4AyO4s1A+LdIgu+IM2sZ64MQMJw02P9XaQF 5RXRU6f2I+/tRjV5CIUa56Dtf8tKW4Hn05Oz1ZDjmSvObaq+k/pAuiO/bqpCTJt7xkvo dAJ6dFngflgV9ZlWCHM/3srR4hCWmDyPrJO7myO3kRwFvGkpe2UYUm8LlntWm+t/SEfD X1k/pQmvlwgLIkX4l3t7J28FtWtDLxaf5BrMv7teHQ5Rktr5zboOBi0hjgOtIa2rYcKf mSZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752519978; x=1753124778; 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=Go0CSoW2LEDg2nX/cXaqboHQ+PnTq8bbmU1pT9IK3aw=; b=rcYfygwQtgTbp5AIXLv6hUx6LkMfo0NlSuVdCZdJP2848GGkzd12go9kgKM9Bb/5r+ ygezhEJCmuRlLVvzokk8dY/o3Tch+xdi3DY0mAHfRiewJjBid3YAla7Fb9MV83DbSTqC r6EbrRyCFjEvFX0WI95hVC1mj4etTph4dFtFTi7NTaXchikgKPXYXWqjCkyNzJlEL/lJ JkX8oU/lePKoEXR4LLYr7FPxDQ/8fGOP7y9hLz5afrStzLIrhu5enYSiJFOfpiJiksQt TZ4Qn7KK05t2v+P4OSL1h/9PNV3H6/2hyJmfkIXjUz7X5zvKwjtEHbqYC8CwOLJ0tpv3 A0tA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWWoYcNOSp7C/znoBAjdAsIDIAZK4XorgGOZUms97fO0U1Uo8NZfdOvwEAngNRmgGSRIoaVRfuM/mWX@gnusha.org X-Gm-Message-State: AOJu0YxNIg279/0skII5l03G9Wa0ej5OsiHWjB1FkY+X/qdcSW+opaKV XmX6K6Ep5VcJxHdsm6op8BLriugpfX1RC/A0KkqOGrks3T9CE0kTvnBM X-Google-Smtp-Source: AGHT+IHI8dLBdhTCsSFvrXmz5ZTywvRGv5RTs1Gp+Ckt3S4iUG0IynIxIG/pJpAJ5MLVBSAj0+wlbw== X-Received: by 2002:a05:6902:1612:b0:e87:b880:7dee with SMTP id 3f1490d57ef6-e8b85ae5c6fmr14524910276.12.1752519977627; Mon, 14 Jul 2025 12:06:17 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdpZcDHMZPYmnS1/bwPvnIM+ezhU3oSOCB3mYehRqMThA== Received: by 2002:a25:b853:0:b0:e87:adad:c527 with SMTP id 3f1490d57ef6-e8b77970c92ls4667219276.1.-pod-prod-04-us; Mon, 14 Jul 2025 12:06:13 -0700 (PDT) X-Received: by 2002:a05:690c:f0f:b0:717:c765:4bee with SMTP id 00721157ae682-717d5dc6e8cmr219627307b3.20.1752519973654; Mon, 14 Jul 2025 12:06:13 -0700 (PDT) Received: by 2002:a05:600c:354e:b0:456:11e5:963 with SMTP id 5b1f17b1804b1-456134f0bcams5e9; Mon, 14 Jul 2025 09:08:41 -0700 (PDT) X-Received: by 2002:a05:600c:608f:b0:456:161c:3d77 with SMTP id 5b1f17b1804b1-456161c403fmr53298085e9.16.1752509318936; Mon, 14 Jul 2025 09:08:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1752509318; cv=none; d=google.com; s=arc-20240605; b=JfpjfVmg/WdJ0N91wETgVI32OVeoYVrJcZ+n3m10sWAkk7jqPcpePczKWeTuBKtHi7 vMC5VDboN95qd9/9+jWYIGZSyPfBCOpUtQwx9D/azAFdHvkDlsnuld9xoz3IhJqyxkLR eso9MkJdBa8Jf7qKNQ6StthYTQ9SxY6Cmq7zaBVMMPjWgFSbmovon2ei5QBaT+sd4LHc I8orBKjHpD+Y8urvZ0ybGnLxMyrSbAOcsHr86SvspnmUPTBGYF40MukpMlisxi5zcaqN XY5yOtG0d0MZafFRrex89+tr3Z0tKy6Fi1DpwAPRyqxfDvH5LZrsy8r2QqnC++zv2C9u Ymkw== 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=H1ZXwiHNxFawJXr1pG9Q/3jBzIxFCngbJaYfmK9W+P0=; fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=; b=ERZJm4SxeUmcsAhs4nCKhWuQSsSbYNJGklHdTcImtRdKBPLGI8W7nNQv6X7t55PgPK xMNgNpHlAJJU7iHTNdmqAwXeau8LmCvyRua94qt3wIc5k38dOHKILAKqgS8llHi3a7zJ s1Q7TaMls3MjpDwUnpF8TbrFfZ7GsovOUjpNZHkJ66F5E0tcByqGgc8k1VCC96B0HOuy PQ/OpUJ+tB3RiYI6GuLlD3/g1bBK56ZEM2kY9aFslMaQfdv+PYI9M0nOrlVfJf8ii8tA rO43JXBPJgUDaXYnImaHsrCd/0W7YZTUw0emv7QTRoDBZfoPWepRqr+Mk363t1Ji4qrk dtzA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=d8yI1yQM; spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com. [2a00:1450:4864:20::533]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-3b5e8df9f50si292683f8f.4.2025.07.14.09.08.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Jul 2025 09:08:38 -0700 (PDT) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) client-ip=2a00:1450:4864:20::533; Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-60700a745e5so9330265a12.3 for ; Mon, 14 Jul 2025 09:08:38 -0700 (PDT) X-Gm-Gg: ASbGncskEGneBnCYeRFj4bfLCBcXSPjU31PHZDpcHorCD4R/3h5UwwTJgxmJ26J01+A NzHrElVkUe1FNXP9RrvKvOzuxhjRUl3oBy6N+HWFpUQ49zRAIrXxnjil0X9g6DwsKi7Pg3+oFVj 7HR+Kb3qoQY1tpm5M1y5dyP5AVdrnL01SdAfUHj2ImJzMsi3vSZEa7aGByDq4K6Zbd21jETMkfo wdmfDA/0+leBdWMvE0FbNraKQPcGbdPdyOBKo8i2j5fObOGo/Q= X-Received: by 2002:a05:6402:50cd:b0:607:425c:3c23 with SMTP id 4fb4d7f45d1cf-611e76189aamr12186343a12.5.1752509317997; Mon, 14 Jul 2025 09:08:37 -0700 (PDT) MIME-Version: 1.0 References: <37ed2e5d-34cd-4391-84b8-5bcc6d42c617n@googlegroups.com> <4d9ce13e-466d-478b-ab4d-00404c80d620n@googlegroups.com> In-Reply-To: <4d9ce13e-466d-478b-ab4d-00404c80d620n@googlegroups.com> From: Ethan Heilman Date: Mon, 14 Jul 2025 12:08:01 -0400 X-Gm-Features: Ac12FXxD9JiFGJ7Wr8U3kchNEk_qJB3CIhgUl6gWCKT8qYOKbJYWyv4EpS1Prs4 Message-ID: Subject: Re: [bitcoindev] Re: A Post Quantum Migration Proposal To: Antoine Riard Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000005d69de0639e5df04" X-Original-Sender: eth3rs@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=d8yI1yQM; spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=eth3rs@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 (/) --0000000000005d69de0639e5df04 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I want to clarify two points: > Even if go all to upgrade to lattices-based schemes, we have no certainty that novels flaws won't be found, one can just go to see the modifications of the NIST-approved schemes in between their rounds of selection that we'll never reach something like "self-sovereign peace of mind"... The informational proposal for post-quantum signatures in BIP-360 has one lattice-based scheme and one hash-based scheme (SLH-DSA SPHINCS+). The intention of including a hash-based scheme is to ensure that there will always be at least one signature scheme in Bitcoin that is secure. Cryptographic hashes are considered one of the safest assumptions possible and are used throughout Bitcoin (merkle tree, PoW, TXID, etc...). Using P2QRH + SLH_DSA, you can have: - a tapleaf for SLH-DSA - and a tapleaf for a more efficient signature scheme (ML-DSA, Schnorr, whatever) Then no matter what happens to any of the other signature schemes, you can use that SLH-DSA tapleaf to spend safely. This strategy isn't just about quantum resistance but protecting against unexpected cryptanalytic breakthroughs. If I wanted to store Bitcoins in cold storage for 100 years, this is how I would do it. > This is especially worrying as if I'm understanding you correctly you're justifying this position as that somehow we should protect the price of the currency as an end in itself (i.e "Beyond its impact on price, ..."). It's unclear the price of bitcoin versus what fiat or hard asset (e.g oil) you have in mind. [...] To put it simply, even if a quantum attacker can tomorrow starts to steal vulnerable coins, 1 BTC will be always equal to 1 BTC. Full stop. I can't speak for Jameson, but let me put forward my own concern. If miners can buy much less electricity for 1-BTC this is a major problem for Bitcoin. If the price of electricity denominated in Bitcoin goes way up, miners will have to mine at a massive loss. Many will stop mining, then the block rate will go down and Bitcoin will appear to be less valuable (high fees, slow confirmation, panic), which makes mining even more of a loss, and so on. This also invites miners who have nothing left to lose to engage in mining attacks. One reason I believe a soft fork to freeze quantum vulnerable coins is likely, is that miners will be incentivized to mine on such a soft fork. The non-frozen chain will simply not be affordable to mine on and will be abandoned. In the moment of crisis, all someone has to do is create a client that does a soft fork freeze of quantum vulnerable coins and the miner will have no choice but to adopt it or stop mining. The worst time to do a soft fork like this would be in a moment of crisis. Note that such a death spiral and the incentives for a soft fork are possible prior to quantum attacks on Bitcoin. Merely the threat of quantum attacks and the widespread belief that Bitcoin will not freeze unspendable coins and thereby inflate the supply of spendable bitcoin. On Mon, Jul 14, 2025 at 10:09=E2=80=AFAM Antoine Riard wrote: > Hi Jameson, > > Thanks for your thoughts on this complex subject. > > First and foremost, I think your following statement: "Never before has > Bitcoin faced > an existential threat to its cryptographic primitives" is very myopic, > given that > cryptanalysts and number theorists are making progress every year in thei= r > works, and > each bitcoin cryptographic primitive has been and is constantly analyzed > to uncover > potential weaknesses. > > So in my view the quantum threat is a bit less specific that the image > you're painting > of it. Even if go all to upgrade to lattices-based schemes, we have no > certainty that > novels flaws won't be found, one can just go to see the modifications of > the NIST-approved > schemes in between their rounds of selection that we'll never reach > something like > "self-sovereign peace of mind"...Unless we start to forbid people of > practicing the > art of mathematics, practice which has been ongoing since Euclide and > Pythagore... > > I do concede that quantum is a bit different, as after all new physics > paradigm > do not happen often (Heisenberg published in the 20s iirc), though that's > in my > view the flaw of your reasoning as you're assuming some "post-quantum" > upgraded > state where bitcoin, as a community and a network, would be definitely > safe from > advances in applied science. At minima, in my understanding, you're > arguing this > time is different to justify extra-ordinary technical measures never seen > before, > namely the freezing of "vulnerable" coins. > > I'm worried this is opening a Pandora box, where we would introduce a > precedent > that it is legitimate as a community to technicaly confiscate some coins > of users, > without their _consents_, for extra-ordinary reasons. That's opening a > worms of > shenanigans in the future...There is no guarantee that this precedent won= 't > be leveraged in the future by any group of entities to justify future > upgrades > eroding one of the "fundamental property" you're yourself deeming as > valuable. > > This is especially worrying as if I'm understanding you correctly you're > justifying > this position as that somehow we should protect the price of the currency > as an end > in itself (i.e "Beyond its impact on price, ..."). It's unclear the price > of bitcoin > versus what fiat or hard asset (e.g oil) you have in mind. And in anyway, > as far > as I know, none of the bitcoin devs is seating on the board of the FED, > the ECB > or the BoJ... > > To put it simply, even if a quantum attacker can tomorrow starts to steal > vulnerable coins, 1 BTC will be always equal to 1 BTC. Full stop. In my > humble > opinion, let's not introduce the idea that, we, as a community of > stakeholders > and developers we have a positive "fiduciary" duty to act to maintain the > price > of bitcoin in some "monetary snake" with another class of assets... > > That's also the problem with game theory, all the matrices of analysis ar= e > based on some scale of utilitarism. See Von Neuman's Theory of Games, the > section on "The Notion of Utility". My subjective appreciation of the val= ue > of my coins might not be your subjective appreication of the value of you= r > coins. > > Now I do understand the perspective of the institutional holders, the > exchanges, > the custodians or any other industry providers, who might be in the full > uncertainty > about their business responsibilities in case of a quantum threat > affecting their > custodied coins. But, first legally speaking there is something call > "force majeure" > and in view of the quantum threat, which is a risk discussed far beyond > the bitcoin > industry, they should be able to shield themselves behind that. Secondly, > if there > is any futute upgrade "opt-in" only path a la BIP360, you can move your > funds or > the ones under custody under a PQC scheme like Dilthium or Falcon and be > good > without caring about what the others users are doing. Thirdly, if you're > an actor > in the industry like Coinbase and you're deeply concerned about how > extended maelstrom > on the price might affect the viability of your operations, it is unclear > to me why > you don't call MunichRe or any other company like that tomorrow to craft > and be > covered by specific insurance on quantum threats... > > To be frank, all those considerations on how "I cannot see how the > currency can > maintain any value at all in such a setting", is a strong red flag of low > time > preferences. It's not like we're used to strong volatility in bitcoin wit= h > the > almost 2 decades of operations of the network. In my view, it's more a > hint of > very high-exposition by some to a single class of asset, i.e bitcoin, > rather than wise > diversification... And a push to sacrify a "fundamental property" i.e > "conservatism" > in view of short-term concerns (i.e the stability of the currency price > along > a period of few years). > > Do not get me wrong, I'm certainly not of the school "let's reward quantu= m > attackers". Leveraging techical superiority and employing CRQRC to steal > vulnerable coins would be clearly a theft. But ethically, the best we can > do is > to have an opt-in upgrade path and be pro-active, by education and > outreach, > to have the maximum of coin owners upgrading to non-vulnerable addresses > types. > Then show the level of "fortitude" or "endurance" as a community in face > of price > fluctuations for a while, while seeing regularly old P2PK coins hacked. > Marcus > Aurelius can be bought for few bucks in most of decent libraries... > > I'm definitely on the "no old coins confiscation" position you're > underlighting: > > "I don't see why old coins should be confiscated. The better option is to > let > those with quantum computers free up old coins. While this might have an > inflationary impact on bitcoin's price, to use a turn of phrase, the > inflation > is transitory. Those with low time preference should support returning lo= st > coins to circulation". > > Notwhitstanding that I disagree with your position, one can only apprecia= te > the breadth and depth with which you're gathering and articulating all th= e > elements on this complex problem. > > Best, > Antoine > OTS hash: c064b43047bf3036faf098b5ac8e74930df63d25629f590a419522297940282= 6 > Le lundi 14 juillet 2025 =C3=A0 00:53:34 UTC+1, Tadge Dryja a =C3=A9crit = : > >> Hi >> >> While I generally agree that "freeze" beats "steal", and that a lot of >> lead time is good, I don't think this plan is viable. >> To me the biggest problem is that it ties activation of a PQ output type >> to *de*activation of EC output types. That would mean that someone who >> wants to keep using all the great stuff in libsecp256k1 should try to >> prevent BIP360 from being activated. >> >> Sure, there can be risks from CRQCs. But this proposal would go the >> other direction, disabling important functionality and even destroying >> coins preemptively, in anticipation of something that may never happen. >> >> Also, how do you define "quantum-vulnerable UTXO"? Would any P2PKH, or >> P2WPKH output count? Or only P2PKH / P2WPKH outputs where the public ke= y >> is already known? I can understand disabling spends from known-pubkey >> outputs, but for addresses where the public key has never been revealed, >> commit/reveal schemes (like the one I posted about & am working on a >> follow-up post for) should safely let people spend from those outputs >> indefinitely. >> >> With no evidence of a QRQC, I can see how there would be people who'd sa= y >> "We might never really know if a CRQC exists, so we need to disable EC >> spends out of caution" and others who'd say "Don't disable EC spends, si= nce >> that's destroying coins", and that could be a persistent disagreement. = But >> I hope if we did in fact have a proof that a CRQC has broken secp256k1, >> there would be significant agreement on freezing known-pubkey EC outputs= . >> >> -Tadge >> On Saturday, July 12, 2025 at 8:46:09=E2=80=AFPM UTC-4 Jameson Lopp wrot= e: >> >>> Building upon my earlier essay against allowing quantum recovery of >>> bitcoin >>> I >>> wish to formalize a proposal after several months of discussions. >>> >>> This proposal does not delve into the multitude of issues regarding 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 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/4d9ce13e-466d-478b-ab4d-0040= 4c80d620n%40googlegroups.com > > . > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CAEM%3Dy%2BX6YSFyTtqR%2BCuKzDV4a7_3WA41N%3DunSszOZFw75w5cNA%40mail.gmail.co= m. --0000000000005d69de0639e5df04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I want to clarify two points:

> Even if go all to upgrade to lattices-based schemes, we have no certainty t= hat novels flaws won't be found, one can just go to see the modificatio= ns of the NIST-approved schemes in between their rounds of selection that w= e'll never reach something like "self-sovereign peace of mind"= ;...

The=C2=A0informational proposal for post-quantum signatures in = BIP-360 has one lattice-based scheme and one hash-based scheme (SLH-DSA SPH= INCS+). The intention of including a hash-based scheme is to ensure that th= ere will always be at least one signature scheme in Bitcoin that is secure.= Cryptographic hashes are considered one of the safest assumptions possible= and are used throughout Bitcoin (merkle tree, PoW, TXID, etc...).

U= sing P2QRH + SLH_DSA, you can have:
- a tapleaf for SLH-DSA
- and a = tapleaf for a more efficient signature scheme (ML-DSA, Schnorr, whatever)
Then no matter what happens to any of the other signature schemes, yo= u can use that SLH-DSA tapleaf to spend safely. This strategy isn't jus= t about quantum resistance but protecting against unexpected cryptanalytic = breakthroughs. If I wanted to store Bitcoins in cold storage for 100 years,= this is how I would do it.

>=C2=A0 This is especially worrying as if I'm understanding you correctly you&#= 39;re justifying this position as that somehow we should protect the price = of the currency as an end in itself (i.e "Beyond its impact on price, = ..."). It's unclear the price of bitcoin versus what fiat or hard = asset (e.g oil) you have in mind. [...] To put it simply, even if a quantum= attacker can tomorrow starts to steal vulnerable coins, 1 BTC will be alwa= ys equal to 1 BTC. Full stop.

I can't speak for Jameson, but let= me put forward my own concern. If miners can buy much less electricity=C2= =A0for 1-BTC this is a major problem for Bitcoin. If the price of electrici= ty denominated in Bitcoin goes way up, miners will have to mine at a massiv= e loss. Many=C2=A0will stop mining, then the block rate will go down and Bi= tcoin will appear to be less valuable (high fees, slow confirmation, panic)= , which makes mining even more of a loss, and so on. This also invites mine= rs who have nothing left to lose to engage in mining attacks.

One re= ason I believe a soft fork to freeze quantum vulnerable coins is likely, is= that miners will be incentivized to mine on such a soft fork. The non-froz= en chain will simply not be affordable to mine on and will be abandoned. In= the moment of crisis, all someone has to do is create a client that does a= soft fork freeze of quantum vulnerable coins and the=C2=A0miner will have = no choice but to adopt it or stop mining. The worst time to do a soft fork = like this would be in a moment of crisis.

Note that such a death spi= ral and the incentives for a soft fork are possible prior to quantum attack= s on=C2=A0Bitcoin. Merely the threat of quantum attacks and the widespread = belief that Bitcoin will not freeze unspendable coins and thereby inflate t= he supply of spendable bitcoin.


On Mon, Jul 14= , 2025 at 10:09=E2=80=AFAM Antoine Riard <antoine.riard@gmail.com> wrote:
Hi Jameson,

Thanks for your thou= ghts on this complex subject.

First and foremost, I think your follo= wing statement: "Never before has Bitcoin faced
an existential thre= at to its cryptographic primitives" is very myopic, given that
cryp= tanalysts and number theorists are making progress every year in their work= s, and
each bitcoin cryptographic primitive has been and is constantly a= nalyzed to uncover
potential weaknesses.

So in my view the quantu= m threat is a bit less specific that the image you're painting
of it= . Even if go all to upgrade to lattices-based schemes, we have no certainty= that
novels flaws won't be found, one can just go to see the modifi= cations of the NIST-approved
schemes in between their rounds of selectio= n that we'll never reach something like
"self-sovereign peace o= f mind"...Unless we start to forbid people of practicing the
art of= mathematics, practice which has been ongoing since Euclide and Pythagore..= .

I do concede that quantum is a bit different, as after all new phy= sics paradigm
do not happen often (Heisenberg published in the 20s iirc)= , though that's in my
view the flaw of your reasoning as you're = assuming some "post-quantum" upgraded
state where bitcoin, as = a community and a network, would be definitely safe from
advances in app= lied science. At minima, in my understanding, you're arguing this
ti= me is different to justify extra-ordinary technical measures never seen bef= ore,
namely the freezing of "vulnerable" coins.

I'm= worried this is opening a Pandora box, where we would introduce a preceden= t
that it is legitimate as a community to technicaly confiscate some coi= ns of users,
without their _consents_, for extra-ordinary reasons. That= 's opening a worms of
shenanigans in the future...There is no guaran= tee that this precedent won't
be leveraged in the future by any grou= p of entities to justify future upgrades
eroding one of the "fundam= ental property" you're yourself deeming as valuable.

This i= s especially worrying as if I'm understanding you correctly you're = justifying
this position as that somehow we should protect the price of = the currency as an end
in itself (i.e "Beyond its impact on price, = ..."). It's unclear the price of bitcoin
versus what fiat or ha= rd asset (e.g oil) you have in mind. And in anyway, as far
as I know, no= ne of the bitcoin devs is seating on the board of the FED, the ECB
or th= e BoJ...

To put it simply, even if a quantum attacker can tomorrow s= tarts to steal
vulnerable coins, 1 BTC will be always equal to 1 BTC. Fu= ll stop. In my humble
opinion, let's not introduce the idea that, we= , as a community of stakeholders
and developers we have a positive "= ;fiduciary" duty to act to maintain the price
of bitcoin in some &q= uot;monetary snake" with another class of assets...

That's = also the problem with game theory, all the matrices of analysis are
base= d on some scale of utilitarism. See Von Neuman's Theory of Games, thesection on "The Notion of Utility". My subjective appreciation = of the value
of my coins might not be your subjective appreication of th= e value of your
coins.

Now I do understand the perspective of the= institutional holders, the exchanges,
the custodians or any other indus= try providers, who might be in the full uncertainty
about their business= responsibilities in case of a quantum threat affecting their
custodied = coins. But, first legally speaking there is something call "force maje= ure"
and in view of the quantum threat, which is a risk discussed f= ar beyond the bitcoin
industry, they should be able to shield themselves= behind that. Secondly, if there
is any futute upgrade "opt-in"= ; only path a la BIP360, you can move your funds or
the ones under custo= dy =C2=A0under a PQC scheme like Dilthium or Falcon and be good
without = caring about what the others users are doing. Thirdly, if you're an act= or
in the industry like Coinbase and you're deeply concerned about h= ow extended maelstrom
on the price might affect the viability of your op= erations, it is unclear to me why
you don't call MunichRe or any oth= er company like that tomorrow to craft and be
covered by specific insura= nce on quantum threats...

To be frank, all those considerations on h= ow "I cannot see how the currency can
maintain any value at all in = such a setting", is a strong red flag of low time
preferences. It&#= 39;s not like we're used to strong volatility in bitcoin with the
al= most 2 decades of operations of the network. In my view, it's more a hi= nt of
very high-exposition by some to a single class of asset, i.e bitco= in, rather than wise
diversification... And a push to sacrify a "fu= ndamental property" i.e "conservatism"
in view of short-t= erm concerns (i.e the stability of the currency price along
a period of = few years).

Do not get me wrong, I'm certainly not of the school= "let's reward quantum
attackers". Leveraging techical sup= eriority and employing CRQRC to steal
vulnerable coins would be clearly = a theft. But ethically, the best we can do is
to have an opt-in upgrade = path and be pro-active, by education and outreach,
to have the maximum o= f coin owners upgrading to non-vulnerable addresses types.
Then show the= level of "fortitude" or "endurance" as a community in = face of price
fluctuations for a while, while seeing regularly old P2PK = coins hacked. Marcus
Aurelius can be bought for few bucks in most of dec= ent libraries...

I'm definitely on the "no old coins confis= cation" position you're underlighting:

"I don't se= e why old coins should be confiscated. The better option is to let
those= with quantum computers free up old coins. While this might have an
infl= ationary impact on bitcoin's price, to use a turn of phrase, the inflat= ion
is transitory. Those with low time preference should support returni= ng lost
coins to circulation".

Notwhitstanding that I disagr= ee with your position, one can only appreciate
the breadth and depth wit= h which you're gathering and articulating all the
elements on this c= omplex problem.

Best,
Antoine
OTS hash: c064b43047bf3036faf098= b5ac8e74930df63d25629f590a4195222979402826
Le lundi 14 juillet 2025 =C3=A0 00:53:= 34 UTC+1, Tadge Dryja a =C3=A9crit=C2=A0:
Hi =C2=A0

While I generally agree that &q= uot;freeze" beats "steal", and that a lot of lead time is go= od, I don't think this plan is viable.
To me the biggest problem is = that it ties activation of a PQ output type to *de*activation of EC output = types.=C2=A0 That would mean that someone who wants to keep using all the g= reat stuff in libsecp256k1 should try to prevent BIP360 from being activate= d.

Sure, there can be risks from CRQCs.=C2=A0 But this proposal woul= d go the other direction, disabling important functionality and even destro= ying coins preemptively, in anticipation of something that may never happen= .

Also, how do you define "quantum-vulnerable UTXO"?=C2=A0= Would any P2PKH, or P2WPKH output count?=C2=A0 Or only P2PKH / P2WPKH outp= uts where the public key is already known?=C2=A0 I can understand disabling= spends from known-pubkey outputs, but for addresses where the public key h= as never been revealed, commit/reveal schemes (like the one I posted about = & am working on a follow-up post for) should safely let people spend fr= om those outputs indefinitely.

With no evidence of a QRQC, I can see= how there would be people who'd say "We might never really know i= f a CRQC exists, so we need to disable EC spends out of caution" and o= thers who'd say "Don't disable EC spends, since that's des= troying coins", and that could be a persistent disagreement.=C2=A0 But= I hope if we did in fact have a proof that a CRQC has broken secp256k1, th= ere would be significant agreement on freezing known-pubkey EC outputs.
=

-Tadge
On Saturday, July 12, 2025 at 8:46:09=E2=80=AFPM UTC= -4 Jameson Lopp wrote:

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

This proposal does not delve into the multitude of = issues regarding post quantum cryptography and trade-offs of different sche= mes, but rather is meant to specifically address the issues of incentivizin= g 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/Schnorr signatures. It turns quantu= m security into a private incentive: fail to upgrade and you will certainly lose access to you= r funds, creating a certainty where none previously existed.=C2=A0

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

  • Phase B: Renders ECDSA/Schn= orr spends invalid, preventing all spending of funds in quantum-vulnerable = UTXOs. This is triggered by a well-publicized flag-day roughly five years a= fter activation.

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

Motivation<= /h2>

We seek to secure the value of the UTX= O set and minimize in= centives 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 cryptogr= aphic primitives. A successful quantum attack on Bitcoin would result in si= gnificant economic disruption and damage across the entire ecosystem. Beyon= d its impact on price, the ability of miners to provide network security ma= y be significantly impacted.=C2=A0=C2=A0

  • = Accelerating quantum progress.=C2=A0<= /p>

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

  • Quantum algorithms are rapidly improving

    • The safety envelope is shrinking by dramatic increases in algo= rithms even if the pace of hardware improvements is slower. Algorithms are = improving up to 20X, = lowering the theoretical hardware requirements for breaking classical encry= ption.

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

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

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

    • Quantum attackers could comput= e the private key for known public keys then transfer all funds weeks or mo= nths later, in a covert bleed to not alert chain watchers. Q-Day may be onl= y known much later if the attack withholds broadcasting transactions in ord= er to postpone revealing their capabilities.

  • Private keys become public.=C2=A0=

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

  • Impossible to know motivations.=C2=A0

    • <= ul style=3D"margin-top:0px;margin-bottom:0px">

  • Prior to a quantum attack, it is = impossible to know the motivations of the attacker.=C2=A0 An economically m= otivated attacker will try to remain undetected for as long as possible, wh= ile a malicious attacker will attempt to destroy as much value as possible.= =C2=A0=C2=A0

  • Upgrade inertia.=C2=A0

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

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

    • Coordinating distributed groups is more= prone to delay, even if everyone has similar motivations. Historically, Bi= tcoin has been slow to adopt code changes, often taking multiple years to b= e approved.

    Benef= its 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<= /span>

    What Happens

    Time Horizon

    Phase A - Disallow spends t= o legacy script types

    Permitted sends are from legacy scripts to P2QRH scr= ipts

    Everyone holding or accepting BT= C.

    3 years after BIP-360 implementation

    Phase B =E2=80=93 Disallow spends from quant= um vulnerable outputs

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

    Everyone holding or accepting BTC.

    2 years after Phase A activation.

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

    =

    Users wi= th frozen quantum vulnerable funds and a HD wallet seed phrase can construc= t a quantum safe ZK proof to recover funds.

    Users who failed to migrate fu= nds before Phase B.

    TBD pending research, demand, and consensus.

    Rationale<= /span>

    • Even if Bitcoin is not a primary init= ial target of a cryptographically relevant quantum computer, widespread kno= wledge that such a computer exists and is capable of breaking Bitcoin=E2=80= =99s cryptography will damage faith in the network .=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">

      An attack on Bitcoin m= ay not be economically motivated - an attacker may be politically or malici= ously motivated and may attempt to destroy value and trust in Bitcoin rathe= r than extract value.=C2=A0 There is no way to know in advance how, when, o= r why an attack may occur.=C2=A0 A defensive position must be taken well in= advance of any attack.=C2=A0=C2=A0

    • Bitcoin=E2=80=99s current signatures (ECDSA/S= chnorr) will be a tantalizing target: any UTXO that has ever exposed its pu= blic key on-chain (roughly 25 % of all bitcoin) could be stolen by a crypto= graphically relevant quantum computer.

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

      1. Any proposal that allows for the quantum theft o= f =E2=80=9Clost=E2=80=9D bitcoin is creating a redistribution dilemma. Ther= e are 3 types of proposals:

        1. Allow anyone to steal vulnerable coins, benefitting those who reach quantu= m capability earliest.

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

        3. A= llow no one to steal vulnerable coins.

    • Minimizes attack= surface

      1. By disallowing n= ew spends to quantum vulnerable script types, we minimize the attack surfac= e with each new UTXO.=C2=A0=C2=A0

      2. Upgrades to Bitcoin have historically ta= ken many years; this will hasten and speed up the adoption of new quantum r= esistant script types.=C2=A0

      3. With a clear deadline, industry stakeholders = will more readily upgrade existing infrastructure to ensure continuity of s= ervices.=C2=A0=C2=A0

    • Minimizes loss of access to funds=C2=A0=

      1. If there is sufficient de= mand and research proves possible, submitting a ZK proof of knowledge of a = BIP-39 seed phrase corresponding to a public key hash or script hash would= provide a trustless means for legacy outputs to be spent in a quantum resi= stant manner, even after the sunset.=C2=A0=C2=A0

    <= br>

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

    This is not an offensive a= ttack, rather, it is defensive: our thesis is that the Bitcoin ecosystem wi= shes to defend itself and its interests against those who would prefer to d= o nothing and allow a malicious actor to destroy both value and trust.=C2= =A0=C2=A0


    "Lo= st coins only make everyone else's coins worth slightly more. Think of = it as a donation to everyone." - Satoshi Nakamoto
    <= br>

    If true, the corollary is:


    "Quantum recovered coins only make everyone el= se's coins worth less. Think of it as a theft from everyone."

    The timelines that we are proposing are mean= t to find the best balance between giving ample ability for account owners = to migrate while maintaining the integrity of the overall ecosystem to avoi= d catastrophic attacks.=C2=A0=C2=A0


    Backward Co= mpatibility

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


    Non-upgraded wallets can receive and = send bitcoin from non-upgraded and upgraded wallets until Phase A. After Ph= ase A, they can no longer receive from any other wallets and can only send = to upgraded wallets.=C2=A0 After Phase B, both senders and receivers will r= equire upgraded wallets.=C2=A0Phase C would likely require a loosening of c= onsensus rules (a hard fork) to allow vulnerable funds recovery via ZK proo= fs.

    --
    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/4d9ce13e-466d-478b-ab4d-00404c80d620n%40googlegrou= ps.com.

    --
    You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
    To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
    To view this discussion visit https://groups.google.= com/d/msgid/bitcoindev/CAEM%3Dy%2BX6YSFyTtqR%2BCuKzDV4a7_3WA41N%3DunSszOZFw= 75w5cNA%40mail.gmail.com.
    --0000000000005d69de0639e5df04--

    Stakeholde= r

    Incentive to Upgrade

    Miners

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

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

    =E2=80= =A2 A quantum attack on Bitcoin will significantly devalue both their hardw= are and Bitcoin as a whole.=C2=A0

    Institutional Holders

    =E2=80=A2 Fiduciary duty: failing to act to pre= vent a quantum attack on Bitcoin would violate the fiduciary duty to shareh= olders.=C2=A0=C2=A0

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

    Exchanges & Custodians

    =E2=80=A2 Concentrated risk: a quantum h= ack could bankrupt them overnight.

    =E2=80=A2 Early mi= gration is cheap relative to potential losses, potential lawsuits over impr= oper custody and reputational damage.

    Everyday Users

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

    <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:"Courier New",monospace;= color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;f= ont-variant-east-asian:normal;font-variant-alternates:normal;vertical-align= :baseline">=E2=80=A2 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 invites procrastination.

    Attackers

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