From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 15 Jul 2025 11:03:47 -0700 Received: from mail-yb1-f188.google.com ([209.85.219.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ubk0G-0003tP-4D for bitcoindev@gnusha.org; Tue, 15 Jul 2025 11:03:47 -0700 Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e8bb30fdd8bsf1767049276.1 for ; Tue, 15 Jul 2025 11:03:43 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1752602615; cv=pass; d=google.com; s=arc-20240605; b=MT5iZwk01Jvy4IGKaWE08bgHRHpNyplZILsz32AZ5wNFJj0LQwQozq1QPyq8X2l3fR IuhI1ti3Uq6bJcY1ir99qOKKRZW498xEBVNxEMrso3eIQUdr6vPjXMDPhzh60yu5EyTl RcnsZMv2W3Jal/FoXnPBaajqqoIrhiFsyTdYoTmkP7RzmSfTUAV3DfJlOXozeo45RF2f Dt03rQsqeC5V65pM0pzE/10rYsfuFqzeLKwmA2I5sCxN1F2vgXk4NnV5DhcwxLki1zvE 5OoJyArobqcNCXBkARUkAYSypyDG/vWZR1YL0ZE0lVn+u5RNpri5TcrtYzFv13hhTtU6 po/g== 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=j7+lq4J/Q790dOi+nS84Bc/FTSPWxTB7E56AqMic1tY=; fh=7hx4EH4ozdv4dB7SQfkC4lxJaJv99+gc9qZG5ASXnEo=; b=QDUdvl2PhuavnEZX7Jq+S/ut5FmXIBQFFZiG912DgxnJzrzB1tQQPtwzSWbcqNlnSW cNp5xr0VQ5pK2AaDDkqmWfGsRQvXu2izIz1Ua47MBYpvf7CJPKPO48wSCgE1feTB4yTq CKblikluuIuMp4BVRrtT7I0+QzjvoCxWYVuDA0Bp0mwKWdcBHg2qlwBD4pQqrX5k6uvg 7xjU26aThDWHOllV+eKo28dgAuAmmgOKdebzDLqakJvNHJ5uecz5MUEiYKnJCnpfSDPQ BNXdEynfoL0MWWKRO9BDRuSJJbYZzyDs6kGp9ct2wDPBcTVWOliFYeZjLcMdZ8Zhreno MWug==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=bowyxysV; spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::529 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=1752602615; x=1753207415; 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=j7+lq4J/Q790dOi+nS84Bc/FTSPWxTB7E56AqMic1tY=; b=p7XdYyvsCHShf1GSe+LzX/h+J3saYvQff8xEUSJjMQ8Z9BEijKxaVJM0k6DPhK5mZL G2gOelCB5uyeXaNl47brPpl06YcJKa/2hLnz++x1C6D/BjRhgApAP5coVDi5jZ+tjzjj iXhgQr5eq7GX2TWx19js09R9tV9CfUv+JPqmeiZjG5VeF/TjGbrEQ8Lg3eOtwxLyXnZ3 MeYUUlnc2mnUIJ/X7tZZWYD3hmBFf2eJHTOXaxKPlSIH21tYQjp5YpQh/YZbb2m2FVRA 7XeRCna240aKZXfh4KGRRYjbFCtZVhFNT6P8IKWnykl6aq2QzI1+BXKr/XkOvkJtq86o u+rw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752602615; x=1753207415; 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=j7+lq4J/Q790dOi+nS84Bc/FTSPWxTB7E56AqMic1tY=; b=IuigQcOd2nQtyK5z3eXbeDYuwgUZBIyj2df3bhN6+GkROBM4pwwYoZYxGJCf3RVSgR KAieyTTyzlslBP7iBZIiYOuaHeZOG6rIZ88LGdjbsbNrv7I2ulYPmZIbRwkLcxDGMCBa PdBPxeDg2t7Vh2cCLThSwuWr/JR7WtbutjO6D5tGQlqYmqxHKbbMf9L+R2RKPbsywKPR ckQLN4qfFY7jT2POowS53KZmavOuX0uHknIMbzBGH0nGMlAeL+XkZdX+2cQf//80AAec qa2vt0AafHZmwMNA2upThW2yrf/v8e+9Y9v8zaXpaBuq2Hl7imE8vt3BtM/Bt7/ysBJg qEHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752602615; x=1753207415; 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=j7+lq4J/Q790dOi+nS84Bc/FTSPWxTB7E56AqMic1tY=; b=C3PBOUhKoKNPQidbyXyJ2ikARAcpsJppmRDXY7R40Q8fRicw7OHJifFy5LrMhP1YFT 70p/wf4uUsyOoX64sW1+oeyNeujqPM7riEn+YPlbB0SLDU8I5yAP7e3CwHeiJ62CRARQ MzjEp8BH/bly1u7RCjWlyr/nA+z1WRcmusWXEyzOvU0p1LNOaJuWLzGQXaObTN18g+Wj zCVAGd9CWonFWWOaI0qfyQnIB5pktVEmgwaRmhSiV/9P17TdMH8pH2F/aSeJLRURyayX P9qvvUabBMN1bEutxFyblw3+TquP86j6pP6fR/HtSJDkEt1I0uZ+NS+o6ZKtFNkPfif1 eq2Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWHI6HuoqBRFBCI/VEdvPJusN2g2oYi1LHdQDITp1igXSsPehE7TdD2HRofFqxUdhmB+/jCgbGqwjnA@gnusha.org X-Gm-Message-State: AOJu0YzBGXn2O5UtloZXZo5n7pdiMnDjDJmTWk38WnuSRQFdKtUa84IB lVXOKd8L2PRwj2FIwtFlrYj/w0VBkqyxr1oet6HGLRTUvQ0RYrJ4j3S5 X-Google-Smtp-Source: AGHT+IFXcRddVrna70O5lXOd8DK6RVqWYUT2Xidjt0lQJiZFrL89l48J1HSQzb/tIroZHv6xGkuUUw== X-Received: by 2002:a05:6902:4585:b0:e8b:79cd:ef1e with SMTP id 3f1490d57ef6-e8bc1d9423dmr3973276.47.1752602614524; Tue, 15 Jul 2025 11:03:34 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeO4joGFauQJ9SzOjhnIcn5XRecsdMiqgvayEgovUMpuQ== Received: by 2002:a25:dd06:0:b0:e7d:cd62:3589 with SMTP id 3f1490d57ef6-e8b7799efc7ls6398282276.2.-pod-prod-04-us; Tue, 15 Jul 2025 11:03:30 -0700 (PDT) X-Received: by 2002:a05:690c:6f8d:b0:70e:7a67:b4b5 with SMTP id 00721157ae682-71835159529mr2031047b3.22.1752602610252; Tue, 15 Jul 2025 11:03:30 -0700 (PDT) Received: by 2002:a05:6504:980d:b0:2b1:97ca:fe9d with SMTP id a1c4a302cd1d6-2ba15bc185amsc7a; Tue, 15 Jul 2025 10:58:03 -0700 (PDT) X-Received: by 2002:a05:6512:ac8:b0:553:34b7:5731 with SMTP id 2adb3069b0e04-55a23300ab3mr150419e87.3.1752602280550; Tue, 15 Jul 2025 10:58:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1752602280; cv=none; d=google.com; s=arc-20240605; b=VzOLeliO5I6LvOrU+3IoWr5IAwEWJCuR84gI/nEmGWejLdYvRR8uxRa/5XboCoYMqc Xykh9lVCbBZ5Zn703JxnE3Ft8/Jiirz//XuJTsiggetwA+ntZJcFzuqngx31fUR7COWk YRJVljssDYKmj+xdl9Tk07WqTSDpZISUSbbE3hfkOWM/fzLY9AaoTFzZJq7YmTeZ1Col Cx9fnMapJG2BaQT2LMctNB8y5ADjbpxagg3sD+oztVQNoawK2ixPGYUyarzwzP3AEQR/ /3c1R4aVD9IrmHf7UMKJg2t6AtyLRBgiajszLmRc1u2lsDjNmUHrJXk26wIq2iZs+Y4I KWDg== 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=QMqFVuq8IykdwFD5DcjiS5ZZ5AhuqT4qzPzyF5IWGIs=; fh=dEDbYMbbYyDNRr1LOwMlw2+lJDEDNk0XskwzeS3uI5o=; b=EIqwCBcPhxeck1nzCH3FKZQSQdu3kUK9zO7e5nWGQk0/6cV2Mnglcu5zrlJE/PW4kb kAfI1vEDfPLvIR/5kGUfCoSzF1/mvIoCV7eA1kL4vrEUlKI4kPEd9pR99bql9c0WMSFp gj+JI5d7VDJ7hADMcZFWR9HEsbm2f0j2lIOPZIK4N4lxJILAymSZ/Y+fWsAzG0kW+mnC QGaBEq/UONhBnNS429IZZfwTFj8snC7jqHtGGdSHiNMkaVcsbVFQiiHek8Ei0HiLzitA QI23ZgMHWXmg+NAxnWVsjQ4Kftq8NdOEXhOaWHhbN+i6PPej9m2TSEPSAHQW42vTgQE7 0XYw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=bowyxysV; spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::529 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-x529.google.com (mail-ed1-x529.google.com. [2a00:1450:4864:20::529]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5593c9a7ea4si276336e87.8.2025.07.15.10.58.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jul 2025 10:58:00 -0700 (PDT) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) client-ip=2a00:1450:4864:20::529; Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-6077dea37easo10265352a12.3 for ; Tue, 15 Jul 2025 10:58:00 -0700 (PDT) X-Gm-Gg: ASbGncupI0aJZJjC9I0oLBSfP5toBl1BrxVcbo0+4x97jnNpImOUWtBuAJ/vC758jQn VJqqWZ7TJiggS98yAIxHzgNOsApTO6Aeqjdz2iP/kI4uGL10uOsGqh/MKROxlTSbGgNWMnhX3+H rDPU66x2R2ahrQqzQMwy57Ow1g+yHuTeUb9X2V+aPWpItNeY71+ooroUWWORBEhCpRQrSZdRDhj pAznhuPeqvOJmphntArFZlWQhJNUXPbvtcN4MGa X-Received: by 2002:a05:6402:5244:b0:601:d77f:47d9 with SMTP id 4fb4d7f45d1cf-61281eaaaf7mr204678a12.5.1752602279239; Tue, 15 Jul 2025 10:57:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ethan Heilman Date: Tue, 15 Jul 2025 13:57:21 -0400 X-Gm-Features: Ac12FXwsadG8AlVBm19FI54M06_-eYjRvan5jrj6c6grmpVgaKZqOnhLpZwSTuE Message-ID: Subject: Re: [bitcoindev] A Post Quantum Migration Proposal To: Jameson Lopp Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000004966cc0639fb844e" 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=bowyxysV; spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::529 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 (/) --0000000000004966cc0639fb844e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 Bitcoin rather than extract value. There is no way to know in advance how, when, or why an attack may occur. A defensive position must be taken well in advance of any attack. Reading through this, an idea occurred to me. Failure to freeze the coins might incentivize attackers to claim they are performing a quantum attack or incentivize victims of hacks to blame a quantum attack. We may see fake quantum attacks before we see real ones and we may not be able to tell the difference. Consider an attacker who manages to acquire the spending keys to quantum vulnerable outputs considered to be lost because they haven't been spent in a long period of time. They could announce they will be performing a quantum attack and then spend those outputs as evidence. They could then short Bitcoin to profit. If this caused a panic, it is likely that other outputs, assumed to be lost, would be spent as holders attempt to secure their funds. This would look a lot like a quantum attack. Imagine if a massive exchange hack happened a few years in the future as CRQC is looking more and more real. The hacked exchange could deflect responsibility by saying it was a quantum attack since everything was stored in a cold wallet and a quantum attack is the only possible way it could have happened. An executive at such an exchange may even convince themselves that this is the best way to make their customers whole again. They cause a panic then use the lower price to buy Bitcoin cheaper and then announce they "discovered" the real cause of the hack and it wasn't a quantum computer. Well reasoned technical arguments about why something isn't a quantum attack will lose to headlines unless it is beyond a reasonable doubt that a quantum attack could not have taken place due to the vulnerable coins being frozen. On Sat, Jul 12, 2025 at 8:46=E2=80=AFPM 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 potentia= l > 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 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 proo= f 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 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. Never befo= re has > Bitcoin faced an existential threat to its cryptographic primitives. A > successful quantum attack on Bitcoin would result in significant economic > 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 quantu= m > 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. Alg= orithms > are improving up to 20X > , > lowering the theoretical hardware requirements for breaking classic= al > 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 ble= ed to > not alert chain watchers. Q-Day may be only known much later if the= 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 pubkey= s) > 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 re= main > undetected for as long as possible, while a malicious attacker 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, tim= e-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 sl= ow 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 th= reat > 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 ca= n > 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 that such a computer e= xists > and is capable of breaking Bitcoin=E2=80=99s cryptography 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 destroy > value and trust in Bitcoin rather than extract value. There is no way= 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 tantali= zing > target: any UTXO that has ever exposed its public key on-chain (roughl= y 25 > % of all bitcoin) could be stolen by a cryptographically relevant quan= tum > 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 proposals: > 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 ty= pes. > 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 correspo= nding to > a public key hash or script hash would provide a trustless means fo= r legacy > outputs to be spent in a quantum resistant manner, even after the s= unset. > > > Stakeholder > > Incentive to Upgrade > > Miners > > =E2=80=A2 Larger size PQ signatures along with incentive for users to mig= rate will > create more demand for block space and thus higher fees collected by mine= rs. > > =E2=80=A2 Post-Phase B, non-upgraded miners produce invalid blocks. > > =E2=80=A2 A quantum attack on Bitcoin will significantly devalue both the= ir > hardware and Bitcoin as a whole. > > Institutional Holders > > =E2=80=A2 Fiduciary duty: failing to act to prevent a quantum attack on B= itcoin > would violate the fiduciary duty to shareholders. > > =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to effectively mitigate= emerging threats > will prove Bitcoin to be an investment grade asset. > > Exchanges & Custodians > > =E2=80=A2 Concentrated risk: a quantum hack could bankrupt them overnight= . > > =E2=80=A2 Early migration is cheap relative to potential losses, potentia= l > 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 t= heir > security rather than an open-ended =E2=80=9Csome day=E2=80=9D that invite= s procrastination. > > Attackers > > =E2=80=A2 Economic incentive diminishes as sunset nears, stolen coins can= not 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 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. Thin= k >> 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-quantum > witness programs as anyone-can-spend scripts. They are strongly encourage= d > 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 receive > from any other wallets and can only send to upgraded wallets. After Phas= e > B, both senders and receivers will require upgraded wallets. Phase C woul= d > 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/CADL_X_fpv-aXBxX%2BeJ_EVTirk= AJGyPRUNqOCYdz5um8zu6ma5Q%40mail.gmail.com > > . > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CAEM%3Dy%2BWr4g%2BkcZpjSUEVay_NCdZcwGSEHcC6W9PcjpibYwd-sA%40mail.gmail.com. --0000000000004966cc0639fb844e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 An attack on Bitcoin may not be = economically motivated - an attacker may be politically or maliciously moti= vated and may attempt to destroy value and trust in Bitcoin rather than ext= ract value.=C2=A0 There is no way to know in advance how, when, or why an a= ttack may occur.=C2=A0 A defensive position must be taken well in advance o= f any attack. Reading through this, an idea occurred to me. Failure to freeze the = coins might incentivize attackers to claim they are performing a quantum at= tack or incentivize victims of hacks to blame a quantum attack. We may see = fake quantum attacks before we see real ones and we may not be able to tell= the difference.

Consider an attacker who manages to acquire the spe= nding keys to quantum vulnerable outputs considered to be lost because they= haven't been spent in a long period of time. They could announce they = will be performing a quantum attack and then spend those outputs as evidenc= e. They could then short Bitcoin to profit. If this caused a panic, it is l= ikely that other outputs,=C2=A0assumed to be lost, would be spent as holder= s attempt to secure their funds. This would look a lot like a quantum attac= k.

Imagine if a massive exchange hack happened a few years in the fu= ture as CRQC is looking more and more real. The hacked exchange could defle= ct responsibility by saying it was a quantum attack since everything was st= ored in a cold wallet and a quantum attack is the only possible way it coul= d have happened. An executive at such an exchange may even convince themsel= ves that this is the best way to make their customers whole again. They cau= se a panic then use the lower price to buy Bitcoin cheaper and then announc= e they "discovered" the real cause of the hack and it wasn't = a quantum computer.

Well reasoned technical arguments about why some= thing isn't a quantum attack will lose to headlines unless it is beyond= a reasonable doubt that a quantum attack could not have taken place due to= the vulnerable coins being frozen.

On Sat, Jul 12, 2025 at 8:46=E2=80=AFPM= Jameson Lopp <jameson.lopp@gm= ail.com> wrote:

Building upon my earlier es= say against allowing quantum recovery of bitcoin I wish to formalize a proposal after several months of d= iscussions.

This proposal does not delve into the multitude of i= ssues regarding post quantum cryptography and trade-offs of different schem= es, 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/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 algo= rithms are rapidly improving

    • The= safety envelope is shrinking by dramatic increases in algorithms even if t= he 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 publ= ic keys.=C2=A0

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

    =

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

    • Quantum attackers could compute the private key for known public k= eys then transfer all funds weeks or months later, in a covert bleed to not= alert chain watchers. Q-Day may be only known much later if the attack wit= hholds broadcasting transactions in order to postpone revealing their capab= ilities.

  • Private keys become public.=C2=A0

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

  • Impossible to kno= w motivations.=C2=A0

    • Prior to a quantum attack, it is impossible to know the motivations of th= e attacker.=C2=A0 An economically motivated attacker will try to remain und= etected for as long as possible, while a malicious attacker will attempt to= destroy as much value as possible.=C2=A0=C2=A0

  • Upgrade inertia.=C2=A0

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

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

    • Coordin= ating distributed groups is more prone to delay, even if everyone has simil= ar motivations. Historically, Bitcoin has been slow to adopt code changes, = often taking multiple years to be approved.

Benefits at a Glance

  • Resilience:<= span style=3D"font-size:11pt;font-family:"Courier New",monospace;= background-color:transparent;font-variant-numeric:normal;font-variant-east-= asian:normal;font-variant-alternates:normal;vertical-align:baseline"> Bitco= in 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.=C2=A0=C2=A0

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

  • Supply Disci= pline: Abandoned keys that never migrate become unspendable, reducing sup= ply, as Satoshi described.=C2=A0=C2=A0

Specification

Phas= e C =E2=80=93 Re-enable spends from quantum vulnerable o= utputs via ZK Proof

Phase

What Happen= s

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-heig= ht, nodes reject transactions that rely on ECDSA/Schnorr keys.=C2=A0=

Everyone holding or accepting BTC.

2 years= after Phase A activation.

Users with frozen quantum vulnerable funds and a HD wa= llet seed phrase can construct a quantum safe ZK proof to recover funds.

Users who failed to migrate funds before Phase B.

TBD pending research, d= emand, and consensus.

Rationale

  • Even i= f Bitcoin is not a primary initial target of a cryptographically relevant q= uantum computer, widespread knowledge that such a computer exists and is ca= pable of breaking Bitcoin=E2=80=99s cryptography will damage faith in the n= etwork .=C2=A0

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

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

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

      • =

    1. Any proposal t= hat allows for the quantum theft of =E2=80=9Clost=E2=80=9D bitcoin is creat= ing a redistribution dilemma. There are 3 types of proposals:

      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 subsidizin= g their revenue from lost coins.

      2. Allow no one to steal vulnerable coins.

  • Minimizes attack surface

    1. By disallowing new spends to quantum vulnerable script typ= es, we minimize the attack surface with each new UTXO.=C2=A0=C2=A0

    2. Upgrade= s 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, industry stakeholders will more readily upgrade existing infrast= ructure to ensure continuity of services.=C2=A0=C2=A0

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

    Minimi= zes loss of access to funds=C2=A0

    1. If there is sufficient demand and research proves possible, submitt= ing a ZK proof of knowledge of a BIP-39 seed phrase corresponding to a pub= lic key hash or script hash would provide a trustless means for legacy outp= uts to be spent in a quantum resistant manner, even after the sunset.=C2=A0= =C2=A0


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

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

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

= <= /tr>

Stakeholder

Incentive to Upgrade=

Miners

=E2=80=A2 Larger size P= Q signatures along with incentive for users to migrate will create more dem= and 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 signific= antly devalue both their hardware and Bitcoin as a whole.=C2=A0

<= /td>

Institutional Holders

Exchanges & Custodians

=

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

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

Everyday Users

=E2=80=A2 Self-sovereig= n peace of mind.

=E2=80=A2 Sunset date creates a clea= r deadline and incentive to improve their security rather than an open-ende= d =E2=80=9Csome day=E2=80=9D that invites procrastination.

Attackers

=E2=80=A2 Economic incentive d= iminishes as sunset nears, stolen coins cannot be spent after Q-day.=

Key Insight: As mentioned earlier, the proposa= l turns quantum security into a privat= e incentive to upgrade.=C2=A0=C2=A0


"Lost coins only make everyone else's coins wort= h slightly more. Think of it as a donation to everyone." - Satoshi Nak= amoto

If true, the corollary is:<= /p>


"Quantum recovered c= oins 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 a= bility for account owners to migrate while maintaining the integrity of the= overall ecosystem to avoid catastrophic attacks.=C2=A0=C2=A0

Backward Compatibility

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


Non-upgrade= d wallets can receive and send bitcoin from non-upgraded and upgraded walle= ts until Phase A. After Phase A, they can no longer receive from any other = wallets and can only send to upgraded wallets.=C2=A0 After Phase B, both se= nders and receivers will require upgraded wallets.=C2=A0Phase C would likel= y require a loosening of consensus rules (a hard fork) to allow vulnerable = funds recovery via ZK proofs.

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

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