From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 12 Jul 2025 17:46:17 -0700 Received: from mail-yw1-f183.google.com ([209.85.128.183]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uakrA-0004yU-9u for bitcoindev@gnusha.org; Sat, 12 Jul 2025 17:46:17 -0700 Received: by mail-yw1-f183.google.com with SMTP id 00721157ae682-70e5ae5c517sf45598667b3.1 for ; Sat, 12 Jul 2025 17:46:15 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1752367570; cv=pass; d=google.com; s=arc-20240605; b=AmqAguq+6c0o1CLQf126ddQKtI75eFs4u0W0FznsHbw1Wo++mnYCLjMSIWE420W7BN EuJhQuopuGX4vbmfkzHsnIbXfKs1B8ATSCtWcctDxfjoUtvwJa2GEYOBZBB/JSgd9OQp iBE7Q41jke6r9MmvZax6bPduzjecflbTd8pD6C9VwzC4d6IqRv/QDTcaZdLMOG3mJyCz wsUWbhYpJbHynVM22p3D7OK+p/Rq6A2IQ4+PlBJmxaaMNjHtmo16RsN0W6SLX4Au2tmd 1pcHBlQ0juAsmPZ6tCpjVg9tQEQPKBLdBl4BVzgK87SKbgPLLW+CUyLAjSrCXw9u4vl4 NyGA== 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:to:subject:message-id:date:from :mime-version:sender:dkim-signature:dkim-signature; bh=UFc+IQplhBMSS9xd8yu/okXaTp//SbStDZDXn+0EagQ=; fh=nFlLCiSqz0eksuCH215gM5q4r0SvlrlQWMLNlgyiLLI=; b=JoBwUhf5sO9KrrUgicV+sh/fPxhefdv/j94Y2ddmyFsNU3Pg7FWeTVXC4cGOOpmwmd 0CjGY5EJXHQ09d4v+aGqaMAIWi/Eo16QkSxLGmk3jCUTAmSmK5MKNX4sH3mT5KA+Kuxu jcTLgD/NiIJOFBL4rBnNesYX80SY88N/kYYldl6pjoIwoMfMOwYFmChRYdHHY9RnyFuu xC8nj+Njml1aZ61irzAI0PbEXuEnlv06JcqBMHcm0l9GzdWHYiN6C9kc0JmCARkD4uPm ABjEAleyNTB4BGL5NlLR+o3ed+dYS+a/htJxJhx7ir9EgfK1/2QoRe4+GsCUsgOYhM/d pmhg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=TZUPqbHe; 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=1752367570; x=1752972370; 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:to:subject:message-id:date:from:mime-version :sender:from:to:cc:subject:date:message-id:reply-to; bh=UFc+IQplhBMSS9xd8yu/okXaTp//SbStDZDXn+0EagQ=; b=WA2HbPmJJxSJz54TDjVWWt1Bj2KBwOgVDl0b9Yl9j2+24rFAKpU3pRjmAHNj+eK5Wt AMTnxl5KyWY3nbSCBJQSNnlBnCIXZcrJGTwm1PYnPhVBd5JyC6NZ1ZKPy8B2K+BNhPFD bGHxJUXI+IpT52XXNPKyTMqzi34dwfPOPqZuPCPUBi6fbgJxGXwtRNauY8gce+t0OoVA T7LpA9esXhKX6PsjHaLzAHzLDZpxfRnNZ+ahMM18g6Vqgke3kfMfLxWCOnT3r8G6SoSI dQ3gh8pNGO6asRa3NRtS2eLEDnjgZisSfy2gUNnIG4p9HR4cG3PI+Hidgya42lEZ7VFV keDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752367570; x=1752972370; 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:to:subject:message-id:date:from:mime-version:from :to:cc:subject:date:message-id:reply-to; bh=UFc+IQplhBMSS9xd8yu/okXaTp//SbStDZDXn+0EagQ=; b=OWs68vdo2V8QYwhNTfEIhfVPXEzvuTm4LJn5DvWL5m/FG2EZlTY/jq0B+rhDA4yRGc GchPruejldThsFwABU38tNfEhulr/fVSlSUDsvgwSocRVXLTOygmmmZwUgSYoE1m/qNM PkTuHp40eIX3WzQ7hQDhgU3++OFmK3MxaTGTRsCkwx/K0lH0QpZUHLmPvjNVfZal6w7C ZShzfHbO7ZIB5n4twiH+DfJi6tnJIub2WphFmTwMOpmrO6UyAGlUQvmdYtPzhyKFKx6S 1pV92A8cPGm65IVWPtsCQH28j5WamZwuQqXOzFRpNyi0MhBAGUpCXukgyX+158Dnzf0/ ed3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752367570; x=1752972370; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:subject:message-id:date:from:mime-version :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=UFc+IQplhBMSS9xd8yu/okXaTp//SbStDZDXn+0EagQ=; b=eJfFNmqCPZbPsxyS9PSyeMtRdRYHwBTEyt47Wg0xA8CTe+hYxXm8tr7WMRlpTdzH21 HwkvLZvXpztH+I/PSgmcpKoTCqiDunmhoaigyvFsHqyao90LJ3c1+dRa4U1T+JBSBZK0 dnBZoQYr4E0u9RDTkk7Q05Gm9sfiw25O5vXx3Iev9ggoLnyKa7vYkoCTWclFMciIWtq0 aQLbMWwSUbFa8acwZgTTrbJomIYq24i6+iMwm7L4iQ9h27ZxKxihyAozv0YxvNKbzHrb WA4h3xKXWXNAsq8L2YmOqbPnyQsdohbYEHjnAn1SbRwHtQwU8hD6kF8bhaRslw2anjsr ijpw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXI6E38qTfIdHVohRhTj0LtXPuAIeztIMoT/twBP9Ij70Ls6pWXiLYiJFZe2VhPyEo8sJMvDoYiWz0h@gnusha.org X-Gm-Message-State: AOJu0YyodRBcTBvdprXicF2m2prNDijdZdQx2Iv5x1+6VHzR7Qt87AaP YhKO+HT7drm1HWPtKvaWmbh9MgzxAn9n99jjRz24J28tms6bIEnas1Qo X-Google-Smtp-Source: AGHT+IFKQK0vPAINv3a46CKV8vKszAvdPGytHsKKgUWGFFTeGI57Ln84osXgHbcBLWcpU0SVoQi2+g== X-Received: by 2002:a05:690c:6e05:b0:710:edf9:d93b with SMTP id 00721157ae682-717d78c06c4mr138764407b3.11.1752367569537; Sat, 12 Jul 2025 17:46:09 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZc80G+voQJnwxz0n7UWQcXtskxJc0BchVaaY7qhW51m+Q== Received: by 2002:a25:49c7:0:b0:e7d:cee1:1ba9 with SMTP id 3f1490d57ef6-e8b77943577ls3467740276.2.-pod-prod-08-us; Sat, 12 Jul 2025 17:46:05 -0700 (PDT) X-Received: by 2002:a05:690c:968e:b0:711:41a5:482a with SMTP id 00721157ae682-717d7a19bf4mr141350377b3.27.1752367565284; Sat, 12 Jul 2025 17:46:05 -0700 (PDT) Received: by 2002:a05:600c:1c1f:b0:456:53b:5b5e with SMTP id 5b1f17b1804b1-4561334fd09ms5e9; Sat, 12 Jul 2025 14:36:48 -0700 (PDT) X-Received: by 2002:adf:b613:0:b0:3a4:eb92:b5eb with SMTP id ffacd0b85a97d-3b5f18f8be2mr6233258f8f.50.1752356205989; Sat, 12 Jul 2025 14:36:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1752356205; cv=none; d=google.com; s=arc-20240605; b=HUR6A03592GONxqSH98/+MVtm9kh9cWG8O5IDmlYuBn0rKWWhy5BhEcTZ7j7a3Y6oO L4w79tODnN5nSJD9/f2DCT8Hwjuaz4M4rlguvB/V4fN7U8Zb9iso78dI7MBHVxXE165S dTubvrR/m5bUy7uB5ZAmVdqhdp5moHScJeZCMCO2yRisfvQg6DSlqz3PZqJDgvUVEnCQ HaR/a7+k7poKVf7IDdY8gd/vEVTF51IRql+XX/2OIPoHQa7IkV9tsVs7ABmgNvEnFz2D JH+UL7wVvkzyVLmGeTuAsPsX9YuwsiMd1geasY7T33Nv8pFUt3x+xHbdyN7b5wPVeTq2 V+ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=eSdsWfQXGrssxAK9pfQH27X9Leb9gIenMLXpR+eXnQA=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=g3TiOHYot3zOmU7Bmn9zPLD+3xcvsAqHSx1hetz7Dq6ZQ2y3MDHBgGMEm4JWm6Xwrq /1+CG1WOjqIVkuzbOnZbfDZBz7BdHJLJOkEXgx84GaAbqkgHYYk9geUxLwGjiqb0ixPl 0/ElG/0coSIlbwh/HmcLPp5vst5FnzOZnu9isgTRtNP5R4QTYCzpGucxwhq3bJrN/qs6 2aDgiN/En0uwTKOCRpJTmjztAaGcZ86PNcNn/sBEyz8z+6UhHXOTeM6bBTSxk0kn9V2m Cc/gbbu7ZTEEOJKQhGX+j1jFKu5iSlNwDKFcqO6wRmw3gLjKeI41jCBzedBgrVNN10Dy 7n+Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=TZUPqbHe; 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 ffacd0b85a97d-3b5e8dfa170si179682f8f.3.2025.07.12.14.36.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 12 Jul 2025 14:36:45 -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-32b3a3a8201so28719371fa.0 for ; Sat, 12 Jul 2025 14:36:45 -0700 (PDT) X-Gm-Gg: ASbGncvV43xD9v1Fl+ujQf77mB3MOAwu6RQoUqVudtmHh73h50HEG9nHlnfGKywyAcA i7wZGNCKkq/eV7OkPOzX/9BEfl+FimqVANkeCuZoOKoM4LWBKkKE9wquX+B0xu0N6CKU8ch8VoQ Pel5vxCyiLf0lf+nAAe7Xxaam97tOiyE93s3Ui9mj/2dbCA0S71al7qUiHUtD80IWzLoFa2ObVr hc2EYCt X-Received: by 2002:a2e:aa86:0:b0:32b:7ddd:275f with SMTP id 38308e7fff4ca-3305343839emr18032711fa.30.1752356204197; Sat, 12 Jul 2025 14:36:44 -0700 (PDT) MIME-Version: 1.0 From: Jameson Lopp Date: Sat, 12 Jul 2025 17:36:31 -0400 X-Gm-Features: Ac12FXyc1cw6eTJyBWxaO3hn5Wl6z9LIk34KAiZ_Ku2EghjeTne1_DHbp3XMxFo Message-ID: Subject: [bitcoindev] A Post Quantum Migration Proposal To: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000123e1d0639c239f9" 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=TZUPqbHe; 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 (/) --000000000000123e1d0639c239f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 proof 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 before= 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 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. Algorithms are improving up to 20X , lowering the theoretical hardware requirements for breaking classical 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 bleed to n= ot alert chain watchers. Q-Day may be only known much later if the attac= k withholds broadcasting transactions in order to postpone revealing th= eir 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 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 rema= in 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, time-boxed pathway is the only credible defense. - Coordinating distributed groups is more prone to delay, even if everyone has similar motivations. Historically, Bitcoin has been slow= to adopt code changes, often taking multiple years to be 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 P= roof 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 that such a computer exi= sts and is capable of breaking Bitcoin=E2=80=99s cryptography will damage fa= ith 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 mus= t be taken well in advance of any attack. - Bitcoin=E2=80=99s current signatures (ECDSA/Schnorr) will be a tantalizi= ng target: any UTXO that has ever exposed its public key on-chain (roughly = 25 % of all bitcoin) could be stolen by a cryptographically relevant quantu= m 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 type= s. 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 corresponding 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 migra= te 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 their hardware and Bitcoin as a whole. Institutional Holders =E2=80=A2 Fiduciary duty: failing to act to prevent a quantum attack on Bit= coin would violate the fiduciary duty to shareholders. =E2=80=A2 Demonstrating Bitcoin=E2=80=99s ability to effectively mitigate e= merging 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, potential = 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 the= ir 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, stolen coins canno= t 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. 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-quantum witness programs as anyone-can-spend scripts. They are strongly encouraged 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 Phase B, both senders and receivers will require upgraded wallets. Phase C would likely require a loosening of consensus rules (a hard fork) to allow vulnerable funds recovery via ZK proofs. --=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_fpv-aXBxX%2BeJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q%40mail.gmail.com. --000000000000123e1d0639c239f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Building upon my earlier essay against allowing quantum recov= ery of bitcoin I wish to formalize a propos= al after several months of discussions.

This proposal does not d= elve into the multitude of issues regarding post quantum cryptography and t= rade-offs of different schemes, but rather is meant to specifically address= the issues of incentivizing adoption and migration of funds a= fter consensus is established that it is pr= udent to do so.

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

Abstract

This proposal follows the implementation of post-quantum (PQ) output t= ype (P2QRH) and introduces a pre-announced sunset of legacy ECDSA/Schnorr s= ignatures. It turns quantum security into a private incentive: fail to upgrade and you will ce= rtainly lose access to your funds, creating a certainty where none previous= ly existed.=C2=A0

    =

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

  • Phase B: Re= nders ECDSA/Schnorr spends invalid, preventing all spending of funds in qua= ntum-vulnerable UTXOs. This is triggered by a well-publicized flag-day roug= hly five years after activation.

  • Phase C (optional): Pendi= ng further research and demand, a separate BIP proposing a fork to allow re= covery of legacy UTXOs through ZK proof of possession of BIP-39 seed phrase= .=C2=A0=C2=A0

Motivati= on

We seek to secure the value = of the UTXO set and m= inimize incentives for quantum attacks. This proposal is radically differen= t 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=99= s history.=C2=A0 Never before has Bitcoin faced an existential threat to it= s cryptographic primitives. A successful quantum attack on Bitcoin would re= sult in significant economic disruption and damage across the entire ecosys= tem. Beyond its impact on price, the ability of miners to provide network s= ecurity may be significantly impacted.=C2=A0=C2=A0

  • Accelerating quantum progress.=C2=A0

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

  • Quantum algorithms are rapidly improv= ing

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

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

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

    • Quantum attackers could compute the private key for know= n 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 the = attack withholds broadcasting transactions in order to postpone revealing t= heir capabilities.

  • 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 know mot= ivations.=C2=A0

    • Prior to= a quantum attack, it is impossible to know the motivations of the attacker= .=C2=A0 An economically motivated attacker will try to remain undetected fo= r as long as possible, while a malicious attacker will attempt to destroy a= s much value as possible.=C2=A0=C2=A0

  • Upgrade inertia.=C2=A0

    • Coordinating wallets, exchanges, miners and cust= odians 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 mo= re 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.

Ben= efits at a Glance

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

    <= /li>

  • Certainty: Bitcoin users and stakeholders gain cer= tainty that a plan is both in place and being implemented to effectively de= al with the threat of quantum theft of bitcoin.=C2=A0=C2=A0

    • =

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

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

Specification

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

Who Must Act

Users who failed= to migrate funds before Phase B.

Phase

=

What Happens

Time Horizon<= /span>

Phase A - Di= sallow spends to legacy script types

Permitted sends are from legacy scrip= ts to P2QRH scripts

Everyone holding = or accepting BTC.

3 years after BIP-360 implementation

Phase B =E2=80=93 Disallow spen= ds from quantum vulnerable outputs

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

Ever= yone holding or accepting BTC.

2 years after Phase A a= ctivation.

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

Users with frozen quantum vulnerable funds and a HD wallet seed phras= e can construct a quantum safe ZK proof to recover funds.

TBD pending research, demand, and consen= sus.

Rationale

    Even if Bitcoin is not a pri= mary initial target of a cryptographically relevant quantum computer, wides= pread knowledge that such a computer exists and is capable of breaking Bitc= oin=E2=80=99s cryptography will damage faith in the network .=C2=A0<= /p>

  • An attack on Bit= coin 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.=C2=A0 There is no way to know in advance how, w= hen, or why an attack may occur.=C2=A0 A defensive position must be taken w= ell in advance of any attack.=C2=A0=C2=A0

  • Bitcoin=E2=80=99s current signatures (ECDSA/= Schnorr) will be a tantalizing target: any UTXO that has ever exposed its p= ublic key on-chain (roughly 25 % of all bitcoin) could be stolen by a crypt= ographically relevant quantum computer.

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

    1. Any proposal that allows for the quantum theft of =E2=80= =9Clost=E2=80=9D bitcoin is creating a 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 ultima= tely miners subsidizing their revenue from lost coins.

      3. Allow no one to steal vu= lnerable coins.

  • Minimizes attack surface

    1. = By disallowing new spends to quantum vulnerable scr= ipt types, we minimize the attack surface with each new UTXO.=C2=A0=C2=A0

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

      <= /li>

    3. With a clear de= adline, industry stakeholders will more readily upgrade existing infrastruc= ture to ensure continuity of services.=C2=A0=C2=A0

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

    1. If th= ere is sufficient demand and research proves possible, submitting a ZK proo= f 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 spe= nt in a quantum resistant manner, even after the sunset.=C2=A0=C2=A0=


=

Stakeholder

Incentive to Upgrade

Miners

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

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

=

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

Institutional Holders

=E2=80=A2 Fiduciary duty: fail= ing to act to prevent a quantum attack on Bitcoin would violate the fiducia= ry duty to shareholders.=C2=A0=C2=A0

=E2=80=A2 Demons= trating 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 ri= sk: a quantum hack could bankrupt them overnight.

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

Everyday Users

=E2=80=A2 Self-sovereign peace of mi= nd.

=E2=80=A2 Sunset date creates a clear deadline an= d incentive to improve their security rather than an open-ended =E2=80=9Cso= me day=E2=80=9D that invites procrastination.

Attackers

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

Key= Insight: As mentioned earlier, the proposal turns quant= um security into a private incentive t= o upgrade.=C2=A0=C2=A0

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


"Lost coins only make everyone else's coins worth slightly mo= re. Think of it as a donation to everyone." - Satoshi Nakamoto<= /blockquote>

If true, the corollary is:


"Quantum recovered coins only mak= e everyone else's coins worth less. Think of it as a theft from everyon= e."

The timelines that we are propo= sing are meant to find the best balance between giving ample ability for ac= count owners to migrate while maintaining the integrity of the overall ecos= ystem to avoid catastrophic attacks.=C2=A0=C2=A0


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


Non-upgraded wallets can= receive and send bitcoin from non-upgraded and upgraded wallets until Phas= e A. After Phase A, they can no longer receive from any other wallets and c= an only send to upgraded wallets.=C2=A0 After Phase B, both senders and rec= eivers will require upgraded wallets.=C2=A0Phase C would likely require a l= oosening of consensus rules (a hard fork) to allow vulnerable funds recover= y 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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CADL_X_fpv-aXBxX%2BeJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q%40ma= il.gmail.com.
--000000000000123e1d0639c239f9--