From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 14 Jul 2025 07:10:06 -0700 Received: from mail-yb1-f186.google.com ([209.85.219.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ubJsa-0007Kq-3O for bitcoindev@gnusha.org; Mon, 14 Jul 2025 07:10:05 -0700 Received: by mail-yb1-f186.google.com with SMTP id 3f1490d57ef6-e819c3f8861sf5244819276.3 for ; Mon, 14 Jul 2025 07:10:03 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1752502198; cv=pass; d=google.com; s=arc-20240605; b=DA/6JTVKL4Wb2nVMurHK52qKCUekaHeZ+meHCFWJwVAeqdHx9R6D7sxIByqxdVBN5o JveZzREaACQEWAVOYfwqaRJ2lHh7r7P51HNx3Qow0m797O2l07GwdqcSjBWf5xSBT05l Ag2Ep6pztdfBYxoSOWZcH4SUSD71fiRAiceBCnHN8M0l6m8ZXZnHixH8FIdLcEC1tJd3 srODlJ26RJNV6/k/Nfdb/7/3QT6OGv/BcLxK4zWdqwnUIFAAraJbsmzJdPqVcAK5BD2d jmJBs6H/8OtN/O26Cx9yHscneZFmFsPa7UI5IuQ56i5TC4IadEknq/nRKBewUgCsOpYW AMaw== 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=zQYi7tjR8fQkQOVPXJBYlQu6hG2f4C8KmfbpGcRvzRw=; fh=NIb4D6CEzepNR6DfGUyKWQNHg1/sbgzqcI+tmc6bdlQ=; b=KN6z0JQvgICdQ9baMJl4UfjX6XH4kiar6ki6yDDWjKGCWFCDE3cycDYogocDCIgrXI rpfbUg6hXbQhvQvpSLmfyqvm41P19vmuc3lXmCBqV53zpLmqPZMUnYVVlE2YXWeOa/8x 2jyNGx+EvHB9NnTBVq6+OfV71BqBa4wH/61CKE3ukM9sPjPrTh6cMWk8vtiyNwBU6ycJ ZBacMLUtngKZXvIXW36D9cZ4/EryxJLeVS1ENxqiTyiQ+L0wnALJesZQYpfI7/czU9RX xyG3tcJeOUuDX+HmclaKcJjvQVcQnoYZ2YOGbVuAG1sg0uv5qR1A8hua/XyQuvswoyFB syMg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=YwGowIaW; spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::22c as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1752502198; x=1753106998; 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=zQYi7tjR8fQkQOVPXJBYlQu6hG2f4C8KmfbpGcRvzRw=; b=nD32z9db4yJz4PLQnd7OfbFk//3M9YfUThWaZ/AcaGSOqJbQnavXLZQecTHkZcwyOx LvNvOlzA2qP6uOQqnOZIKG6lFfmGJ2/XJlq2zIvHqBDrKLjzY56Y+0gcgljLq3vHPEEa /zMIFs10wFq1WhqnZN9LBVPI1FcMS4tFZxVsR/W5lUVi5mK3BrPIBQ8Yxq7J6haBjuTO XVFhGqcugoUjXeq2fBXZfFdwXQs2Sx2rvbzL5853ZdT5aM3K+LVf0Zm9YtUCUdp7VKSQ shd4TGYeSKAUEAWLTsSxBVS3/6pHpsgykpnFDdXU21k9ikmR2ZBtBPEstzIkCsexuKgl dpEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752502198; x=1753106998; 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=zQYi7tjR8fQkQOVPXJBYlQu6hG2f4C8KmfbpGcRvzRw=; b=LZB05Onqr+KgScmawsxo8nzK00opWunXXpcr21J8MYrZIMbKn4qf5JTC3Kxnink94G 6lZWD+ci1oHXKtRkdxDU7HyxId2fOhLJUNs9KaBjXGzqLQMKpDA8uSgx5kdtoCmsE/wD LzMmLmw0hbZSAo4HCZy3VkHoknNSO0k4y1BuMKG0dp1JIvvpZpgMxeehqeMf8KzGacpH x9mYQvQliVuu2OYArIpIQUkVXWhOSCFTQljHLBNzKTdM4Xz4RxKerIdzFprLyJujlsso fP+YWgXxtxyIqZKQ311I9KGWO7/5X/a9NExsCgMltGctr1GQwv4EmbRHg66Ye25m8iro 4zvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752502198; x=1753106998; 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=zQYi7tjR8fQkQOVPXJBYlQu6hG2f4C8KmfbpGcRvzRw=; b=WBor7erO0Wu/ReC1qqW+VWOb5USfAer0UbzNiiMN5TtqB/EgXXTRPo2df+YcQ94Ncn ny6oetBM9IZygkMEyQyupshVyu6lsqSBGduaqhGaJLN54lxMbE39E5A1KHW3D6xUDe6R OAtiYD3KPILkFwCy1XLVqKvExi6JprJ4I8MEGkVp04lTRCUHdPelyBaDHgYtEnmHpvx/ 29ZTVN1VMshsoeYZafbWULONVXqs64jwl5PtrQu31mEr9sRUxkiD2+DyDJf6kt9M9Ig3 RwOL3ryuE1oXd631VYQTAtT8B3LsjEKvOfJZieudqNqARqROtiicZs64pD6U9tqMotgT xL3Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCW0Mh3G/eF+/zj0Ja5psesi0jc1eEaTyNS3OuW8hjz6yLhtIFkBWckXCX5oUmfapMKL+yGf8YkUFIBB@gnusha.org X-Gm-Message-State: AOJu0YwskP5AhxCaB3+dPR4tjRaDs3xRLZdu411cSC/Z3zYwxhX0zwW7 5SmZ/FJhmanAnQdEJ8MRb+jqS0qidwdqszzi2OyhTH7Gj7obu3gGBd8b X-Google-Smtp-Source: AGHT+IGeQ5Tpk6KYmEfRjTyaDirOOBFq48yaY/ZJzjqFyKF5TdTTylnqdtOhb4zdpGzpxBX7jC01hw== X-Received: by 2002:a05:6902:2684:b0:e81:cab6:6db5 with SMTP id 3f1490d57ef6-e8b85abf40bmr14246150276.8.1752502197881; Mon, 14 Jul 2025 07:09:57 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZf7gtjSMH0xSbTctuzhPYQXC+eHZN1w2UmpYx4B+49frQ== Received: by 2002:a25:dd06:0:b0:e7d:cd62:3589 with SMTP id 3f1490d57ef6-e8b7799efc7ls4837018276.2.-pod-prod-04-us; Mon, 14 Jul 2025 07:09:53 -0700 (PDT) X-Received: by 2002:a05:690c:350e:b0:70e:7a67:b4b5 with SMTP id 00721157ae682-717d5dc7ca9mr186770617b3.22.1752502193638; Mon, 14 Jul 2025 07:09:53 -0700 (PDT) Received: by 2002:a50:ee10:0:b0:609:bcd7:3415 with SMTP id 4fb4d7f45d1cf-6123cd1719cmsa12; Mon, 14 Jul 2025 06:50:33 -0700 (PDT) X-Received: by 2002:a05:6402:348b:b0:607:116e:108d with SMTP id 4fb4d7f45d1cf-611e848c00emr10735220a12.21.1752501031246; Mon, 14 Jul 2025 06:50:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1752501031; cv=none; d=google.com; s=arc-20240605; b=XonJiuoQKcDgbJ4KxUydoKy4RCBUuOPY+q6igjBcNnkW8D+GbCc6nJ38+FU4KSHhys zBZGxGr4ZNEkyNeSdM6In6E11XeSt1zQjoOqyPi9Udb5+HeJHEMqe9wRMVSIjSN0PYcF 54G3bb4DKqa0cmVG1iy9LMrv7kwqSOoluxhQ9XcBm4F7ri/UXDaTgtxdtYhr+0Sc201t eorKipaeCT11H43u+B1cIo+WGPSmf8cyHPBW4QIORfHsE0eTQxTepiwwZ4uZd5PXWvmL lKuXMCqO07x2fqrhKqL1mPD10Mwl7pDiZ2u4BGZEoE+SEp1jTd2qxSjcnJWxyNKuaXiI EOnA== 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=l4f9Hq3sojv8st8cmTEcczjw8VpC3hg3/Md1QzBuNvk=; fh=iL9DSYpC5RGeithzN5d/JVKj3o11LZT+9z7PU5q/3vc=; b=BYXPsAqJiud3tmg/yPbqPlWhFy7AVMIHY1LTXZuJeadAPexLEocJ2xwgL+WN7ZIe53 MbimkrktN/Rhn+ZslHqI0rVBAgHgKFYUs0N+USe1LHE4umyodp89KqZJZk6Xax8E3Qza G7WLKE1oNeKJb5cH9BTX00zCPG8NAQfIz4h4CTHM6YeQ6BrtuVRYgvcQxn/Yl7EM9lMR 70GHQ6uPLMU5nDfzeY9rpCN8zRLaE8vo3MiLz4LDmTeurcDXm9ZIuQT1PBuMb+XxOtQl QrO0c73saGqPt5oCcNRgERiy1E9Tjm3Mww6I1WdAOnR4mwDdpZ7ilhMGl+wJ5n4TJnqL qtUA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=YwGowIaW; spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::22c as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com. [2a00:1450:4864:20::22c]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-611c930d011si316294a12.0.2025.07.14.06.50.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Jul 2025 06:50:31 -0700 (PDT) Received-SPF: pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::22c as permitted sender) client-ip=2a00:1450:4864:20::22c; Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-32e14cf205cso36995841fa.1 for ; Mon, 14 Jul 2025 06:50:31 -0700 (PDT) X-Gm-Gg: ASbGncsObDulgzha4vKGiHYn4ipEm4eS5K9MzrOOgZabfes7mchxt6x5iW53jfvGW7w 1XWevXIdyrHrqqMJoLfLhRDw+iJRtLr/msxPrtzf/wqZIrLZD23mjoD0BuXFWnDGpDrOuYc+WfZ t8brKNe3AaNMMPS5KZQ238iGZ5Jc+lmc3wuvy0g9YqEm1WB1l+xTV60A9OqcT3eW+gnFK4abwkE 2a6V6AaQmuWbIXYJA== X-Received: by 2002:a2e:be03:0:b0:32b:3dd6:299e with SMTP id 38308e7fff4ca-33053402374mr38309001fa.21.1752501029980; Mon, 14 Jul 2025 06:50:29 -0700 (PDT) MIME-Version: 1.0 References: <37ed2e5d-34cd-4391-84b8-5bcc6d42c617n@googlegroups.com> In-Reply-To: <37ed2e5d-34cd-4391-84b8-5bcc6d42c617n@googlegroups.com> From: Jameson Lopp Date: Mon, 14 Jul 2025 09:50:17 -0400 X-Gm-Features: Ac12FXzImSy3H9g-urWskKSMTfHRJVE_Nao7GY9Lg-Cw3Khnf9KWEq-q_CqcLTY Message-ID: Subject: Re: [bitcoindev] Re: A Post Quantum Migration Proposal To: Tadge Dryja Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000005c4f810639e3f1d4" X-Original-Sender: jameson.lopp@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=YwGowIaW; spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::22c as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --0000000000005c4f810639e3f1d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jul 13, 2025 at 7:53=E2=80=AFPM Tadge Dryja wrote= : > 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. > > Right. I don't see much point enabling PQ cryptography that has significant performance trade-offs to ECC if it's not actually necessary. And if it is actually necessary, then ECC usage becomes an existential risk. Note that this BIP makes no plans about enabling PQC; it's written under the assumption that PQC has been deemed necessary. 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. > I don't expect PQC to be activated until there is widespread consensus that CRQCs are more than mythological FUD. We can only hope that if and when that happens it still provides enough time for the ecosystem to react and protect itself. > Also, how do you define "quantum-vulnerable UTXO"? Would any P2PKH, or > P2WPKH output count? Or only P2PKH / P2WPKH outputs where the public key > 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. > > A quantum vulnerable UTXO is any that is susceptible to both long and short range attacks. Or in other words, any UTXO that isn't using whatever PWC scheme is settled upon. > With no evidence of a QRQC, I can see how there would be people who'd say > "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, sin= ce > that's destroying coins", and that could be a persistent disagreement. B= ut > 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. > > Quite true; and this BIP is not for today, but for a potential future day in which the threat landscape has evolved. > -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 schemes, but rather is >> meant to specifically address the issues of incentivizing adoption and >> migration of funds *after* consensus is established that it is prudent >> to do so. >> >> As such, this proposal requires P2QRH as described in BIP-360 or >> potential future proposals. >> Abstract >> >> This proposal follows the implementation of post-quantum (PQ) output typ= e >> (P2QRH) and introduces a pre-announced sunset of legacy ECDSA/Schnorr >> signatures. It turns quantum security into a private incentive: fail to >> upgrade and you will certainly lose access to your funds, creating a >> certainty where none previously existed. >> >> - >> >> Phase A: Disallows sending of any funds to quantum-vulnerable >> addresses, hastening the adoption of P2QRH address types. >> - >> >> Phase B: Renders ECDSA/Schnorr spends invalid, preventing all >> spending of funds in quantum-vulnerable UTXOs. This is triggered by a >> well-publicized flag-day roughly five years after activation. >> - >> >> Phase C (optional): Pending further research and demand, a separate >> BIP proposing a fork to allow recovery of legacy UTXOs through ZK pro= of of >> possession of BIP-39 seed phrase. >> >> Motivation >> >> We seek to secure the value of the UTXO set and minimize incentives for >> quantum attacks. This proposal is radically different from any in Bitcoi= n=E2=80=99s >> history just as the threat posed by quantum computing is radically >> different from any other threat in Bitcoin=E2=80=99s history. Never bef= ore has >> Bitcoin faced an existential threat to its cryptographic primitives. A >> successful quantum attack on Bitcoin would result in significant economi= c >> disruption and damage across the entire ecosystem. Beyond its impact on >> price, the ability of miners to provide network security may be >> significantly impacted. >> >> - >> >> Accelerating quantum progress. >> - >> >> NIST ratified three production-grade PQ signature schemes in 2024; >> academic road-maps now estimate a cryptographically-relevant quant= um >> computer as early as 2027-2030. [McKinsey >> >> ] >> - >> >> Quantum algorithms are rapidly improving >> - >> >> The safety envelope is shrinking by dramatic increases in >> algorithms even if the pace of hardware improvements is slower. Al= gorithms >> are improving up to 20X >> , >> lowering the theoretical hardware requirements for breaking classi= cal >> encryption. >> - >> >> Bitcoin=E2=80=99s exposed public keys. >> - >> >> Roughly 25% of all bitcoin have revealed a public key on-chain; >> those UTXOs could be stolen with sufficient quantum power. >> - >> >> We may not know the attack is underway. >> - >> >> Quantum attackers could compute the private key for known public >> keys then transfer all funds weeks or months later, in a covert bl= eed to >> not alert chain watchers. Q-Day may be only known much later if th= e attack >> withholds broadcasting transactions in order to postpone revealing= their >> capabilities. >> - >> >> Private keys become public. >> - >> >> Assuming that quantum computers are able to maintain their current >> trajectories and overcome existing engineering obstacles, there is= a near >> certain chance that all P2PK (and other outputs with exposed pubke= ys) >> private keys will be found and used to steal the funds. >> - >> >> Impossible to know motivations. >> - >> >> Prior to a quantum attack, it is impossible to know the >> motivations of the attacker. An economically motivated attacker w= ill try >> to remain undetected for as long as possible, while a malicious at= tacker >> will attempt to destroy as much value as possible. >> - >> >> Upgrade inertia. >> - >> >> Coordinating wallets, exchanges, miners and custodians >> historically takes years. >> - >> >> The longer we postpone migration, the harder it becomes to >> coordinate wallets, exchanges, miners, and custodians. A clear, ti= me-boxed >> pathway is the only credible defense. >> - >> >> Coordinating distributed groups is more prone to delay, even if >> everyone has similar motivations. Historically, Bitcoin has been s= low to >> adopt code changes, often taking multiple years to be approved. >> >> Benefits at a Glance >> >> - >> >> Resilience: Bitcoin protocol remains secure for the foreseeable >> future without waiting for a last-minute emergency. >> - >> >> Certainty: Bitcoin users and stakeholders gain certainty that a plan >> is both in place and being implemented to effectively deal with the t= hreat >> of quantum theft of bitcoin. >> - >> >> Clarity: A single, publicized timeline aligns the entire ecosystem >> (wallets, exchanges, hardware vendors). >> - >> >> Supply Discipline: Abandoned keys that never migrate become >> unspendable, reducing supply, as Satoshi described >> . >> >> Specification >> >> Phase >> >> What Happens >> >> Who Must Act >> >> Time Horizon >> >> Phase A - Disallow spends to legacy script types >> >> Permitted sends are from legacy scripts to P2QRH scripts >> >> Everyone holding or accepting BTC. >> >> 3 years after BIP-360 implementation >> >> Phase B =E2=80=93 Disallow spends from quantum vulnerable outputs >> >> At a preset block-height, nodes reject transactions that rely on >> ECDSA/Schnorr keys. >> >> Everyone holding or accepting BTC. >> >> 2 years after Phase A activation. >> >> Phase C =E2=80=93 Re-enable spends from quantum vulnerable outputs via Z= K Proof >> >> Users with frozen quantum vulnerable funds and a HD wallet seed phrase >> can construct a quantum safe ZK proof to recover funds. >> >> Users who failed to migrate funds before Phase B. >> >> TBD pending research, demand, and consensus. >> Rationale >> >> - >> >> Even if Bitcoin is not a primary initial target of a >> cryptographically relevant quantum computer, widespread knowledge tha= t such >> a computer exists and is capable of breaking Bitcoin=E2=80=99s crypto= graphy will >> damage faith in the network . >> - >> >> An attack on Bitcoin may not be economically motivated - an attacker >> may be politically or maliciously motivated and may attempt to destro= y >> value and trust in Bitcoin rather than extract value. There is no wa= y to >> know in advance how, when, or why an attack may occur. A defensive >> position must be taken well in advance of any attack. >> - >> >> Bitcoin=E2=80=99s current signatures (ECDSA/Schnorr) will be a tantal= izing >> target: any UTXO that has ever exposed its public key on-chain (rough= ly 25 >> % of all bitcoin) could be stolen by a cryptographically relevant qua= ntum >> computer. >> - >> >> Existing Proposals are Insufficient. >> 1. >> >> Any proposal that allows for the quantum theft of =E2=80=9Clost=E2= =80=9D bitcoin >> is creating a redistribution dilemma. There are 3 types of proposa= ls: >> 1. >> >> Allow anyone to steal vulnerable coins, benefitting those who >> reach quantum capability earliest. >> 2. >> >> Allow throttled theft of coins, which leads to RBF battles and >> ultimately miners subsidizing their revenue from lost coins. >> 3. >> >> Allow no one to steal vulnerable coins. >> - >> >> Minimizes attack surface >> 1. >> >> By disallowing new spends to quantum vulnerable script types, we >> minimize the attack surface with each new UTXO. >> 2. >> >> Upgrades to Bitcoin have historically taken many years; this will >> hasten and speed up the adoption of new quantum resistant script t= ypes. >> 3. >> >> With a clear deadline, industry stakeholders will more readily >> upgrade existing infrastructure to ensure continuity of services. >> - >> >> Minimizes loss of access to funds >> 1. >> >> If there is sufficient demand and research proves possible, >> submitting a ZK proof of knowledge of a BIP-39 seed phrase corresp= onding to >> a public key hash or script hash would provide a trustless means f= or legacy >> outputs to be spent in a quantum resistant manner, even after the = sunset. >> >> >> Stakeholder >> >> Incentive to Upgrade >> >> Miners >> >> =E2=80=A2 Larger size PQ signatures along with incentive for users to mi= grate >> will create more demand for block space and thus higher fees collected b= y >> miners. >> >> =E2=80=A2 Post-Phase B, non-upgraded miners produce invalid blocks. >> >> =E2=80=A2 A quantum attack on Bitcoin will significantly devalue both th= eir >> hardware and Bitcoin as a whole. >> >> Institutional Holders >> >> =E2=80=A2 Fiduciary duty: failing to act to prevent a quantum attack on = Bitcoin >> would violate the fiduciary duty to shareholders. >> >> =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to effectively mitigat= e emerging >> threats will prove Bitcoin to be an investment grade asset. >> >> Exchanges & Custodians >> >> =E2=80=A2 Concentrated risk: a quantum hack could bankrupt them overnigh= t. >> >> =E2=80=A2 Early migration is cheap relative to potential losses, potenti= al >> lawsuits over improper custody and reputational damage. >> >> Everyday Users >> >> =E2=80=A2 Self-sovereign peace of mind. >> >> =E2=80=A2 Sunset date creates a clear deadline and incentive to improve = their >> security rather than an open-ended =E2=80=9Csome day=E2=80=9D that invit= es procrastination. >> >> Attackers >> >> =E2=80=A2 Economic incentive diminishes as sunset nears, stolen coins ca= nnot be >> spent after Q-day. >> >> Key Insight: As mentioned earlier, the proposal turns quantum security >> into a private incentive to upgrade. >> >> This is not an offensive attack, rather, it is defensive: our thesis is >> that the Bitcoin ecosystem wishes to defend itself and its interests >> against those who would prefer to do nothing and allow a malicious actor= to >> destroy both value and trust. >> >> >> "Lost coins only make everyone else's coins worth slightly more. Think o= f >>> it as a donation to everyone." - Satoshi Nakamoto >> >> >> If true, the corollary is: >> >> >> "Quantum recovered coins only make everyone else's coins worth less. >>> Think of it as a theft from everyone." >> >> >> The timelines that we are proposing are meant to find the best balance >> between giving ample ability for account owners to migrate while >> maintaining the integrity of the overall ecosystem to avoid catastrophic >> attacks. >> >> Backward Compatibility >> >> As a series of soft forks, older nodes will continue to operate without >> modification. Non-upgraded nodes, however, will consider all post-quantu= m >> witness programs as anyone-can-spend scripts. They are strongly encourag= ed >> to upgrade in order to fully validate the new programs. >> >> Non-upgraded wallets can receive and send bitcoin from non-upgraded and >> upgraded wallets until Phase A. After Phase A, they can no longer receiv= e >> from any other wallets and can only send to upgraded wallets. After Pha= se >> B, both senders and receivers will require upgraded wallets. Phase C wou= ld >> likely require a loosening of consensus rules (a hard fork) to allow >> vulnerable funds recovery via ZK proofs. >> > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/37ed2e5d-34cd-4391-84b8-5bcc= 6d42c617n%40googlegroups.com > > . > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CADL_X_dcdCOX3eHHU7q3EE7vDFRF_696f-k6aNEi-L3e05pB5Q%40mail.gmail.com. --0000000000005c4f810639e3f1d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 13,= 2025 at 7:53=E2=80=AFPM Tadge Dryja <rx@awsomnet.org> wrote:
Hi =C2=A0

While I generally agree that "freeze= " beats "steal", and that a lot of lead time is good, I don&= #39;t think this plan is viable.
To me the biggest problem is that it ti= es 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 great stuf= f in libsecp256k1 should try to prevent BIP360 from being activated.

Right. I don't see much point enablin= g PQ cryptography that has significant performance trade-offs to ECC if it&= #39;s not actually necessary. And if it is actually necessary, then ECC usa= ge becomes an existential risk. Note that this BIP makes no plans about ena= bling PQC; it's written under the assumption that PQC has been deemed n= ecessary.

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

I don't expect PQC to be activated unt= il there is widespread consensus that CRQCs are more than mythological FUD.= We can only hope that if and when that happens it still provides enough ti= me for the ecosystem to react and protect itself.


Also, how do you define &q= uot;quantum-vulnerable UTXO"?=C2=A0 Would any P2PKH, or P2WPKH output = count?=C2=A0 Or only P2PKH / P2WPKH outputs 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 has never been revealed, commit/reve= al schemes (like the one I posted about & am working on a follow-up pos= t for) should safely let people spend from those outputs indefinitely.
<= br>

A quantum vulnerable UTXO is any that i= s susceptible to both long and short range attacks. Or in other words, any = UTXO that isn't using whatever PWC scheme is settled upon.
= =C2=A0
With no evide= nce of a QRQC, I can see how there would be people who'd say "We m= ight never really know if a CRQC exists, so we need to disable EC spends ou= t of caution" and others who'd say "Don't disable EC spen= ds, since that's destroying 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, there would be significant agreement on freezing know= n-pubkey EC outputs.

Quite true; and th= is BIP is not for today, but for a potential future day in which the threat= landscape has evolved.
=C2=A0
-Tadge
On Saturday, July 12, 2025 at 8:46:= 09=E2=80=AFPM UTC-4 Jameson Lopp wrote:

Building upon my earlier e= ssay against allowing quantum recovery of bit= coin I wish to formalize a proposal after s= everal months of discussions.

This proposal does not delve into = the multitude of issues regarding post quantum cryptography and trade-offs = of different schemes, but rather is meant to specifically address the issue= s of incentivizing adoption and migration of funds after consensus is established that it is prudent to d= o so.

As suc= h, 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 quantum security into a priv= ate incentive: fail to upgrade and you will certainly lo= se access to your funds, creating a certainty where none previously existed= .=C2=A0

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

  • Phase B: R= enders ECDSA/Schnorr spends invalid, preventing all spending of funds in qu= antum-vulnerable UTXOs. This is triggered by a well-publicized flag-day rou= ghly five years after activation.

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

Mo= tivation

We seek to secure the = value of the UTXO set and minimize incentives for quantum attacks. This proposal is radically di= fferent from any in Bitcoin=E2=80=99s history just as the threat posed by q= uantum 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 cryptographic primitives. A successful quantum attack on Bitcoin wo= uld result in significant economic disruption and damage across the entire = ecosystem. Beyond its impact on price, the ability of miners to provide net= work security may be significantly impacted.=C2=A0=C2=A0

  • Accelerating quantum progress.=C2=A0

    • NIST ratified three production-grade PQ si= gnature schemes in 2024; academic road-maps now estimate a cryptographicall= y-relevant quantum computer as early as 2027-2030. [McKinsey]

  • Quantum algorithms are rapidly improving

    • =

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

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

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

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

    • Quantum attacker= s could compute the private key for known public keys then transfer all fun= ds weeks or months later, in a covert bleed to not alert chain watchers. Q-= Day may be only known much later if the attack withholds broadcasting trans= actions in order to postpone revealing their capabilities.

      • <= /ul>

    • Private keys become = public.=C2=A0

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

    • Impossible to know motivations.=C2=A0

      • Prior to a quantum atta= ck, it is impossible to know the motivations of the attacker.=C2=A0 An econ= omically motivated attacker will try to remain undetected for as long as po= ssible, while 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 custodian= s historically takes years.

      • = The longer we postpone migration, the harder it bec= omes to coordinate wallets, exchanges, miners, and custodians. A clear, tim= e-boxed pathway is the only credible defense.

      • Coordinating distributed groups = is more prone to delay, even if everyone has similar motivations. Historica= lly, Bitcoin has been slow to adopt code changes, often taking multiple yea= rs to be approved.

  • Resilience: Bitcoin protocol remains sec= ure for the foreseeable future without waiting for a last-minute emergency.=

  • Certainty: Bitcoin users and stak= eholders gain certainty that a plan is both in place and being implemented = to effectively deal with the threat of quantum theft of bitcoin.=C2=A0=C2= =A0

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

  • Supply Discipline: Abandoned ke= ys that never migrate become unspendable, reducing supply, as Satoshi described.=C2=A0=C2=A0

    • Specification

    What Happens

    Who Must Act

    Time Horizon<= /p>

    Phase A - Disallow = spends to legacy script types

    Permitted sends are from legacy scripts to P= 2QRH scripts

    		Everyone holding or acce= pting 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 transac= tions that rely on ECDSA/Schnorr keys.=C2=A0

    Everyone holding or accepting BTC.

    2 years after Phase A activatio= n.

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

    Use= rs with frozen quantum vulnerable funds and a HD wallet seed phrase can con= struct a quantum safe ZK proof to recover funds.

    Users who failed to mig= rate funds before Phase B.

    TBD pending research, demand, and consensus.

    R= ationale

    • Even if Bitcoin is not a pr= imary initial target of a cryptographically relevant quantum computer, wide= spread knowledge that such a computer exists and is capable of breaking Bit= coin=E2=80=99s cryptography will damage faith in the network .=C2=A0=

    • An attack on= Bitcoin may not be economically motivated - an attacker may be politically= or maliciously motivated and may attempt to destroy value and trust in Bit= coin rather than extract value.=C2=A0 There is no way to know in advance ho= w, when, or why an attack may occur.=C2=A0 A defensive position must be tak= en well in advance of any attack.=C2=A0=C2=A0

    • Bitcoin=E2=80=99s current signatu= res (ECDSA/Schnorr) will be a tantalizing target: any UTXO that has ever ex= posed its public key on-chain (roughly 25 % of all bitcoin) could be stolen= by a cryptographically relevant quantum computer.

    • Existing Proposals are Insufficient.=C2=A0=C2=A0<= /p>

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

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

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

        3. Allow no one to steal vulnerable coins.

      2. Minimizes attack surface

        1. = By disallowing new spends to quantum vulnerable script types, we minimize t= he attack surface with each new UTXO.=C2=A0=C2=A0

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

        3. With a clear deadline, indust= ry stakeholders will more readily upgrade existing infrastructure to ensure= continuity of services.=C2=A0=C2=A0

      3. Minimizes loss of acces= s to funds=C2=A0

        1. =

          If there = is sufficient demand and research proves possible, submitting a ZK proof of= knowledge of a BIP-39 seed phrase corresponding to a public key hash or s= cript hash would provide a trustless means for legacy outputs to be spent i= n a quantum resistant manner, even after the sunset.=C2=A0=C2=A0

          =

    <= /tbody>

    =

    = Incentive to Upgrade

    <= 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-weight:700;font-variant-= numeric:normal;font-variant-east-asian:normal;font-variant-alternates:norma= l;vertical-align:baseline">Miners

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

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

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

    Institutional Holders

    =E2=80=A2 Fiduciary duty: failing to= act to prevent a quantum attack on Bitcoin would violate the fiduciary dut= y to shareholders.=C2=A0=C2=A0

    =E2=80=A2 Demonstratin= g Bitcoin=E2=80=99s ability to effectively mitigate emerging threats will p= rove Bitcoin to be an investment grade asset.

    Exchanges & Custodians

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

    =E2=80= =A2 Early migration is cheap relative to potential losses, potential lawsui= ts 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 i= ncentive 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 su= nset nears, stolen coins cannot be spent after Q-day.

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

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


    "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 propos= ing are meant to find the best balance between giving ample ability for acc= ount owners to migrate while maintaining the integrity of the overall ecosy= stem to avoid catastrophic attacks.=C2=A0=C2=A0


    Backward Compatibility

    As a series of soft forks, o= lder nodes will continue to operate without modification. Non-upgraded node= s, however, will consider all post-quantum witness programs as anyone-can-s= pend scripts. They are strongly encouraged to upgrade in order to fully val= idate 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 receive from any other wallets and ca= n only send to upgraded wallets.=C2=A0 After Phase B, both senders and rece= ivers will require upgraded wallets.=C2=A0Phase C would likely require a lo= osening 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/37ed2e5d-34cd-4391-84b8-5bcc6d42c617n%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/ms= gid/bitcoindev/CADL_X_dcdCOX3eHHU7q3EE7vDFRF_696f-k6aNEi-L3e05pB5Q%40mail.g= mail.com.
--0000000000005c4f810639e3f1d4--