diff options
| author | Dustin Ray <dustinvonsandwich@gmail.com> | 2025-02-19 14:05:47 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2025-02-20 17:44:43 -0800 |
| commit | d10c4fdf1b119cdbff75d3417a17c07d49bac5be (patch) | |
| tree | c2cc306d6c3064a9aa5d401b3a1f767dbff5e040 | |
| parent | 73b4a996823984aaf2ddf65c6fc2f7982f6b37f9 (diff) | |
| download | pi-bitcoindev-d10c4fdf1b119cdbff75d3417a17c07d49bac5be.tar.gz pi-bitcoindev-d10c4fdf1b119cdbff75d3417a17c07d49bac5be.zip | |
Re: [bitcoindev] Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP
| -rw-r--r-- | e9/e88edf580708426d345a13cee2914d7bd02b51 | 1051 |
1 files changed, 1051 insertions, 0 deletions
diff --git a/e9/e88edf580708426d345a13cee2914d7bd02b51 b/e9/e88edf580708426d345a13cee2914d7bd02b51 new file mode 100644 index 000000000..17e7b5331 --- /dev/null +++ b/e9/e88edf580708426d345a13cee2914d7bd02b51 @@ -0,0 +1,1051 @@ +Delivery-date: Thu, 20 Feb 2025 17:44:43 -0800 +Received: from mail-oo1-f62.google.com ([209.85.161.62]) + by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + (Exim 4.94.2) + (envelope-from <bitcoindev+bncBCXOL6U6XMBRBAFV366QMGQEDRPUX4A@googlegroups.com>) + id 1tlI5p-0006Va-5m + for bitcoindev@gnusha.org; Thu, 20 Feb 2025 17:44:43 -0800 +Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-5fcec4e9f78sf1550746eaf.0 + for <bitcoindev@gnusha.org>; Thu, 20 Feb 2025 17:44:41 -0800 (PST) +ARC-Seal: i=2; a=rsa-sha256; t=1740102275; cv=pass; + d=google.com; s=arc-20240605; + b=dF3fTB1OdPHVy6CkrohyYygKw8DrJQ7Wi/MIkOKPEKpdEo144r/DqIzd97ybteGWXt + W6Mgv7o+s31YHOtYhgGDe8n7SEYcGaa4o9UifayL3pXTs63xbEzgyk6zk1BxwiteLMOi + UZebyJbO4Xrjc83Xx3KPbaysvJnaUQcApBJTAOj3C6qOOGmo34zdlpZN3HG+a/01HOQK + QfQrbPROq0Z/1NLVSatLLI24gEhd2U5D7Nvz7Q/uZ7UkjvSTIv2+lG9iIP8HWU11mF7G + DzTNXUM3d/9ulZxpeKoOo1y5AKRWs2KVmHJPQ7zwt7e2Y/KCK8EKi5bBRP3dIj2lqfGy + Kmpw== +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=OioOR5e6xe1poTI09IAn8JsValyYZNe4+LrF8elqUK8=; + fh=gAtMJRrqKa0+Ac8vA1UafwuL2bn1+9xS5UPPPYKUihw=; + b=XqKLcwK4lsL8EaOv8GGDNVx+FGffPEStTPPl43t4WHZafyCs8OYU724M028l79P/HP + NKQH0utFEwd+B8H6BSjNS2eBAbp/vNYqvBtGsdFZqz8Y+ludBRZPrYRFYrg/aXZtc5sD + EOYYctwiAqrVXUOVVUHsqkLp4QI1EpFf6Vxo+fhTp41Dr9BmLYHoGqthI/Fvx2od3EyR + 2TeAgQM4fgXob33HVFB0d1oC2xiV13ja+hpQ8LOkfim4XopHc7AbEJtTyZjprk48bVra + HHIneRACHQr7HX1anRGedKJy3WShQy/HJSn6mKSnTl5rX0hJD2saPzesJVx9NMvlzK1x + PJUg==; + darn=gnusha.org +ARC-Authentication-Results: i=2; gmr-mx.google.com; + dkim=pass header.i=@gmail.com header.s=20230601 header.b=PUpDIxjn; + spf=pass (google.com: domain of dustinvonsandwich@gmail.com designates 2001:4860:4864:20::31 as permitted sender) smtp.mailfrom=dustinvonsandwich@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=1740102275; x=1740707075; 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=OioOR5e6xe1poTI09IAn8JsValyYZNe4+LrF8elqUK8=; + b=BtzgJtw3rA6D46TDlTW+7yUx2E1eTORV61TvIUqqIQoJFfYElC/FAGO2mW/BhrEwE9 + QVs+GZYcnAXRHjCzimPjbsmFb9kayTlcnU1WKNwY+KZ9CRJE01LOdBfY2Gsl8rR30c33 + YzVGYZGvJoKbA6cnCGA+sleo6J/UtJJoLEpA/xvTWHef2cKh5K8jxoJwz/wB45IQY7yH + xmy6XB1uZwBCL2V7YeobAiilxZ8qaTzyDw84sJgqsncABbX85kv0GCyeASsRlq2Br/Lz + RH1sFEjyzfzkxKjLw+8dUkNN6iTYfkLEjrb70wBY4GYAmWh/CT787wwL5Q5PQasMH0RK + bwPw== +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20230601; t=1740102275; x=1740707075; 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=OioOR5e6xe1poTI09IAn8JsValyYZNe4+LrF8elqUK8=; + b=N9UKmfatvovoPZ9giv/QNCB7NkY5dUzfRSi1zrOVGM45QZEPpHEW9eGZ9ueLa74ScI + eBC1QywsTmzZU8y4mnTsW517r8CUxX2Xdaav3Uto/pCs03ZTU2lbbyf9vudbR3s75AcF + oUXLoGPXVbJ6QdXl+WxZNK0GQ+unTWE15VJPmnJ1M3oyekTP8IYT2ZRjeFdJGxoqszs3 + HPolrPvXQT6AuKJ6sl0JvN7+Gf02YhYT8zT3enQi0PoFD8431vh/jkRcN61pJ+xd15TD + zNSNmyR5umB92Y/MegpnGTV0mWuXVjNS3XXOVohiaCZUXn9g9cQsZdF0MCqFZbywHrtN + polg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1740102275; x=1740707075; + 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=OioOR5e6xe1poTI09IAn8JsValyYZNe4+LrF8elqUK8=; + b=Aw9TgszsqF0/BVxha4Fih4CaVjH8D+s4zUQ4mgU/sTKi3QVktcM66LWYHy1Gllzx3S + WeqMJ0V+77oNpIXFlfh26DZK6i/xpaVJZvAMEkkKlJWWF7JWObV7kqVKS+FsRGvSOXFe + M08P84HAc5jFM8/ptnOIKk6YfTyKTqatHPz5kI2BjxyzTvk/bwrpe0SwEL4jNqkQCh5I + o1bNdthY5UJ6JdjV1a/rIMCXrQBIv6u66AJvqetEdZXJwI5slJYhD/0QdIUXTUKcCWYA + rz4+6WRZ3ZbOdVwHFnxvrsuxbZzMz3XAdnpbv/chz4RCifEyjt0gaqGtGB/KXDe7S2uK + 9gWA== +Sender: bitcoindev@googlegroups.com +X-Forwarded-Encrypted: i=2; AJvYcCWGqkCXC2dJbrhnHrxRgjjger2o2ie43xhdtF2HgVgVjeP/05KrMKln/kmZD0Wpb9ToO/bJYvqhlffQ@gnusha.org +X-Gm-Message-State: AOJu0YxsCL7N55qDh/ZoU5T5S/bpEWPW6H4B5EhZq6axYj9qsuB0HBs6 + RJwS3uQw6HikfX/WkqL4O1vJ8MotLX0ti04REB15UPp88M3h/XI3 +X-Google-Smtp-Source: AGHT+IGYxCdf+Kt+KkM1YrIP4ZJkF4ubRSFefDw+Okey7RX7VzHjz/rJBPTZgGvDRWmwTsHF/cB81g== +X-Received: by 2002:a05:6820:999:b0:5fc:a89b:a340 with SMTP id 006d021491bc7-5fd195d0c6fmr1268215eaf.4.1740102275195; + Thu, 20 Feb 2025 17:44:35 -0800 (PST) +X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVH8QCAU7FwxtKA9DgaEfFfM6XbkCequ7/1cCYTrPLrSvA== +Received: by 2002:a4a:e7ce:0:b0:5fd:13fe:3bec with SMTP id 006d021491bc7-5fd13fe4063ls524284eaf.0.-pod-prod-08-us; + Thu, 20 Feb 2025 17:44:32 -0800 (PST) +X-Forwarded-Encrypted: i=2; AJvYcCWaksE3VCouNOLhTVbiw7CPKz2KxQTXK+FxEqq9g9Aj1OEGsMjAQIXkWYULp2AilgwDuI+GekIA3fDo@googlegroups.com +X-Received: by 2002:a05:6808:2e4f:b0:3f3:e3ad:f5bc with SMTP id 5614622812f47-3f4246c2ed1mr1679323b6e.9.1740102272432; + Thu, 20 Feb 2025 17:44:32 -0800 (PST) +Received: by 2002:aca:100e:0:b0:3f4:4b9:4605 with SMTP id 5614622812f47-3f404b947b7msb6e; + Wed, 19 Feb 2025 14:06:00 -0800 (PST) +X-Forwarded-Encrypted: i=2; AJvYcCVA+6bb1byYcNLAWSl/U4jISGHLgef0qlAKoN1mwvkgh3IIAqFdQmUYE5tENp1cIbeeI8WQ1uPZOn+F@googlegroups.com +X-Received: by 2002:a05:6a20:1582:b0:1ee:8520:f979 with SMTP id adf61e73a8af0-1eed4fd395bmr11859183637.36.1740002759075; + Wed, 19 Feb 2025 14:05:59 -0800 (PST) +ARC-Seal: i=1; a=rsa-sha256; t=1740002759; cv=none; + d=google.com; s=arc-20240605; + b=f/5RkV9lUpqlQZ4AydxQrdRur2tTX4t7nCUjL4y2y7D8t8QekbzgyTuA5poU6T4T9D + iZHfiZeLQCD4++uN5meiCg1ecttGB4TX0ZYn/ueUNlN5jdbcDdUmmjd4vSiJUqUev0A8 + EVeyn2QdnWq82Lp66YyuIMVXo1hsAKgie7F3GfP3xsh5U7yTLJyz3v9kKUW08kf2dxaA + emb4UKOUBAIKg4JXZo9b+aEtABJ9ECG1Qu4Kr1zhDXQTKdHHxYAIlybwtyc4KzPA9Z5C + o9npZ1f5A77PI7NqcB9YITpCnjr4ormkuzOxrbT/oizJqjVAW3kIZq8heSBjSyqJIFl3 + inAA== +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=/DqzEZS1VavDOoOuVLVoDELQqHK1gcsUxZp4mjGNKNk=; + fh=CZ33CWAh0FKVpq5ZRT+3YYWpgzmPdo5onYCiUZNHaYA=; + b=c8oK0R8al4o6vCHup8WQ+S+C9mhz9By99MFVxaEdOWCERcBmL1CMwzgmx5IbsjpMd7 + ZToSb4RL1mX8HH4MTYdHFtWpMzHsLGtIrTKe0x793mCUqwcDlIQ24xCzD/EgvahjCnwf + wRT+mmCOhBFDWettud7+x7mB7ZK6RB4gOcCUVaXxiP70byfdx3AxHIQXty7vbVa+a33g + oTeICGYKy/z2gWfr9hOSkmHXjC0RlZDMcMzsuMpYMnt7QMtMzOblXibNMY90LMEJmF1d + Azc5hdEsaMvGv1m9qKg7z8Tz96/Iw9hh55bvn7KQFObJG+H1iDVAma9zz3ku+nVunlXg + /wZw==; + dara=google.com +ARC-Authentication-Results: i=1; gmr-mx.google.com; + dkim=pass header.i=@gmail.com header.s=20230601 header.b=PUpDIxjn; + spf=pass (google.com: domain of dustinvonsandwich@gmail.com designates 2001:4860:4864:20::31 as permitted sender) smtp.mailfrom=dustinvonsandwich@gmail.com; + dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; + dara=pass header.i=@googlegroups.com +Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com. [2001:4860:4864:20::31]) + by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-adb57c5e0aesi631156a12.2.2025.02.19.14.05.59 + for <bitcoindev@googlegroups.com> + (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); + Wed, 19 Feb 2025 14:05:59 -0800 (PST) +Received-SPF: pass (google.com: domain of dustinvonsandwich@gmail.com designates 2001:4860:4864:20::31 as permitted sender) client-ip=2001:4860:4864:20::31; +Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-2bc659753d0so129030fac.3 + for <bitcoindev@googlegroups.com>; Wed, 19 Feb 2025 14:05:59 -0800 (PST) +X-Forwarded-Encrypted: i=1; AJvYcCXPncovS3N1Ck80kxqqNGU8HmZfXETgewmpxp9EZjof0QU40so40eiAH7rO+1oRscc5lugSLydo1jiL@googlegroups.com +X-Gm-Gg: ASbGnct7kSc/7G87U95iuOsEVzbc+V1YnemTX4yTROQPQT8erqJnjeiXe2PSLtV2l8t + pgmnGWQId+BpSwS7vzanbVaCzq/A1Q0dbigtj5sWCYvPf8++gHwBW+rpw6Qr6SluxKvhu7YjqMZ + mJw4FgPNTIgn3JX2F5jPpvIMyNnv0y +X-Received: by 2002:a05:6870:899b:b0:2b8:e4b9:47a3 with SMTP id + 586e51a60fabf-2bd102f08cbmr4193522fac.22.1740002758156; Wed, 19 Feb 2025 + 14:05:58 -0800 (PST) +MIME-Version: 1.0 +References: <08a544fa-a29b-45c2-8303-8c5bde8598e7n@googlegroups.com> + <CAC3UE4+kme2N6D_Xx8+VaH1BJnkVEfntPmnLQzaqTQfK4D5QhQ@mail.gmail.com> + <CAJDmzYxJzFs=myecyMS6iJwSni1sDwUVq3kMnNGg=dK5kULRJg@mail.gmail.com> + <CAC3UE4K=T8BmOeLW9s=x+TBauK+M5Z3MaSicD42+rOj_jZ2Ugw@mail.gmail.com> + <CAJDmzYzUAzoCj3da-3M_ast0_+Qxf3_J1OXWf88B2D-R70pPrg@mail.gmail.com> + <f9e233e0-9d87-4e71-9a9f-3310ea242194n@googlegroups.com> <CAJDmzYz=52MGGLE0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg@mail.gmail.com> + <CAC3UE4K4L58Oz147m5Tnd2cqt7uCN2niyGK6ffRTuu5x5YvRDQ@mail.gmail.com> + <CAJDmzYzvYkm8At6yMrn+mAXnXbk=-R36SL5WneaDT9-Y-d=11w@mail.gmail.com> + <CAC3UE4KZ7GajyaPT1DYfjyxAACnntqfAnoxZwc0kNV2yivDnyQ@mail.gmail.com> <CAJDmzYzPGz9Xd=kdaGkkL+r1zh5y1cBHNh7SQXJEzg7YUX--PA@mail.gmail.com> +In-Reply-To: <CAJDmzYzPGz9Xd=kdaGkkL+r1zh5y1cBHNh7SQXJEzg7YUX--PA@mail.gmail.com> +From: Dustin Ray <dustinvonsandwich@gmail.com> +Date: Wed, 19 Feb 2025 14:05:47 -0800 +X-Gm-Features: AWEUYZneCD7jdBcEAokiEB65SDX-L6K4Om9rUROFA7DeCBdevcBPKJSuDxs-Szw +Message-ID: <CAC3UE4KaVVjLGsAvACmh75KkCNZeHJNnk2+FuZOu23YFAyYg5w@mail.gmail.com> +Subject: Re: [bitcoindev] Proposal for Quantum-Resistant Address Migration + Protocol (QRAMP) BIP +To: Agustin Cruz <agustin.cruz@gmail.com> +Cc: Hunter Beast <hunter@surmount.systems>, + Bitcoin Development Mailing List <bitcoindev@googlegroups.com> +Content-Type: multipart/alternative; boundary="0000000000004ee7c4062e85f653" +X-Original-Sender: Dustinvonsandwich@gmail.com +X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass + header.i=@gmail.com header.s=20230601 header.b=PUpDIxjn; spf=pass + (google.com: domain of dustinvonsandwich@gmail.com designates + 2001:4860:4864:20::31 as permitted sender) smtp.mailfrom=dustinvonsandwich@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: <bitcoindev.googlegroups.com> +X-Google-Group-Id: 786775582512 +List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com> +List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com> +List-Archive: <https://groups.google.com/group/bitcoindev +List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com> +List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>, + <https://groups.google.com/group/bitcoindev/subscribe> +X-Spam-Score: -0.5 (/) + +--0000000000004ee7c4062e85f653 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +I don't disagree personally with most of what you're saying except where +the real catastrophe lies. Id argue it's catastrophic for the value +proposition of a blockchain to effectively seize funds, which is what your +proposal does in case anyone fails to migrate before the deadline. + +On the other hand, it's equally catastrophic for digital signatures to be +broken and funds lost in any scenario. So it seems we are staring down two +extremely untenable outcomes, both of which see the fundamental properties +of a blockchain shattered in one way or another. + +I hope it doesn't come down to having to choose one or the other. There is +very serious financial harm that will occur in either scenario. I dearly +hope there is a practical technological solution that allows for safe and +fair migration, and in my mind and experience, I don't think we have to +resign ourselves to a zero sum game just yet. But I appreciate your +proposal and the proactive nature of this discussion, it's important to +have these conversations now rather than later. + +On Wed, Feb 19, 2025 at 1:50=E2=80=AFPM Agustin Cruz <agustin.cruz@gmail.co= +m> wrote: + +> Hi Dustin, +> +> My proposal is not about locking down or confiscating funds. It is about +> ensuring that vulnerable pre-P2PKH funds are migrated to quantum-safe +> addresses before any quantum adversary can exploit them. Even though P2PK= +H +> addresses are secured by hashes that are currently considered safe, relyi= +ng +> solely on that safety may leave us exposed in the future, especially as +> quantum capabilities continue to evolve. Without a forced migration, we +> risk leaving a significant portion of the coin supply vulnerable. Conside= +r +> the possibility that if we don=E2=80=99t act, any Bitcoin in lost wallets= + could +> eventually be hacked and put back into circulation. Such a scenario would +> be catastrophic for the network. +> +> I believe that by enforcing a deadline for migration, we provide rightful +> owners with a clear, non-negotiable opportunity to secure their funds. Th= +is +> approach is not merely hypothetical. It is a proactive measure that +> addresses the imminent risk of quantum attacks. While turnstile mechanism= +s +> have been considered and might have merit under certain conditions, I +> remain committed to the idea that a forced migration, with sufficient +> notice and robust safeguards, is both realistic and necessary to protect +> the long-term security of Bitcoin. +> +> On Wed, Feb 19, 2025 at 6:35=E2=80=AFPM Dustin Ray <dustinvonsandwich@gma= +il.com> +> wrote: +> +>> To be clear, the turnstile approach is definitely a forced migration. It +>> just means that instead of permanently confiscating funds and removing t= +hem +>> from circulation, you force the rightful owners of those funds to move t= +hem +>> into quantum safe addresses, assuming the existence of a hypothetical +>> turnstile mechanism. There's too many hypotheticals with this idea right +>> now to give it any more than a cursory glance, but turnstiles have been +>> built before and could potentially be built again in this scenario. +>> +>> For further clarification, I'm suggesting that we enforce migration of +>> unspent funds in p2pkh addresses because they are already secured by has= +hes +>> which are currently conjectured to remain safe against a quantum adversa= +ry. +>> Pre-p2pkh addresses are probably the most vulnerable but few of these ha= +d +>> seen use comparatively and may require confiscation. +>> +>> If your idea is to simply lock down and confiscate any pre-pq safe funds= +, +>> I resolutely disagree with that decision and I am fairly confident that +>> consensus will fail to materialize around that. What I'm suggesting howe= +ver +>> is that your idea is realistic and sound if we assume the existence of s= +ome +>> mechanism that allows rightful owners of pre-pq funds the opportunity to= + do +>> nothing except migrate to safe addresses which then resolves the issue. +>> +>> On Wed, Feb 19, 2025 at 1:07=E2=80=AFPM Agustin Cruz <agustin.cruz@gmail= +.com> +>> wrote: +>> +>>> Hi Dustin, +>>> +>>> I remain convinced that a forced migration mechanism=E2=80=94with a cle= +ar block +>>> height deadline after which quantum-unsafe funds become unspendable=E2= +=80=94is the +>>> more robust and secure approach. Here=E2=80=99s why: +>>> +>>> A forced migration approach is unambiguous. By establishing a definitiv= +e +>>> deadline, we eliminate the need for an additional transitional transact= +ion +>>> type, thereby reducing complexity and potential attack vectors. Additio= +nal +>>> complexity could inadvertently open up new vulnerabilities that a more +>>> straightforward deadline avoids. +>>> +>>> If we don=E2=80=99t enforce a hard migration, any Bitcoin in lost +>>> wallets=E2=80=94including coins in addresses that no longer have active= + private key +>>> management, such as potentially Satoshi=E2=80=99s=E2=80=94could eventua= +lly be compromised +>>> by quantum adversaries. If these coins were hacked and put back into +>>> circulation, the resulting market shock would be catastrophic. The forc= +ed +>>> migration mechanism is designed to preempt such a scenario by ensuring = +that +>>> only quantum-safe funds can be spent once the deadline is reached. +>>> +>>> El mi=C3=A9, 19 de feb de 2025, 5:10=E2=80=AFp. m., Dustin Ray < +>>> dustinvonsandwich@gmail.com> escribi=C3=B3: +>>> +>>>> It's worth considering a hypothetical but as of yet unknown middle +>>>> ground solution, again nothing like this exists currently but conceptu= +ally +>>>> it would be interesting to explore: +>>>> +>>>> 1. At some block height deemed appropriate, modify consensus so that +>>>> any pre-quantum unspent funds are restricted from being spent as norma= +l. +>>>> +>>>> 2. Develop a new transaction type whose sole purpose is to migrate +>>>> funds from a quantum unsafe address to a safe one. +>>>> +>>>> 3. This new transaction type is a quantum safe digital signature, but +>>>> here's the hypothetical: It is satisfied by developing a mechanism by = +which +>>>> a private key from a quantum-unsafe scheme can be repurposed as a priv= +ate +>>>> key for a pq-safe scheme. It may also be possible that since we know t= +he +>>>> hash of the public key, perhaps we can invent some mechanism whereby a +>>>> quantum safe signature is created from an ecdsa private key that direc= +tly +>>>> implies knowledge of a secret key that derived the known public key. +>>>> +>>>> In this way, we create a kind of turnstile that can safely transition +>>>> funds from unsafe addresses into safe ones. Such turnstiles have been = +used +>>>> in blockchains before, a notable example is in the zcash network as pa= +rt of +>>>> an audit of shielded funds. +>>>> +>>>> There are likely hidden complexities in this idea that may cause it to +>>>> be completely unworkable, but a theoretical transition mechanism both +>>>> prevents a heavy handed confiscation of funds and also prevents funds = +from +>>>> being stolen and injected back into the supply under illegitimate pret= +enses. +>>>> +>>>> This only works for p2pkh, anything prior to this is immediately +>>>> vulnerable to key inversion, but Satoshi owns most of those coins as f= +ar as +>>>> we know, so confiscating them might not be as controversial. +>>>> +>>>> I'm typing this on my phone so sorry for the lack of detailed +>>>> references. I think the core idea is clear though. +>>>> +>>>> On Wed, Feb 19, 2025 at 10:47=E2=80=AFAM Agustin Cruz <agustin.cruz@gm= +ail.com> +>>>> wrote: +>>>> +>>>>> Hi Hunter, +>>>>> +>>>>> I appreciate the work you=E2=80=99re doing on BIP-360 for Anduro. You= +r point +>>>>> about not =E2=80=9Cconfiscating=E2=80=9D old coins and allowing those= + with quantum +>>>>> capabilities to free them up is certainly a valid one, and I understa= +nd the +>>>>> argument that any inflationary impact could be transitory. +>>>>> +>>>>> From my viewpoint, allowing quantum-capable adversaries to reintroduc= +e +>>>>> dormant coins (e.g., Satoshi=E2=80=99s if those keys are lost) could = +have +>>>>> unintended consequences that go beyond transient inflation. It could +>>>>> fundamentally alter trust in Bitcoin=E2=80=99s fixed supply and disru= +pt economic +>>>>> assumptions built around the current distribution of coins. While som= +e +>>>>> might view these dormant coins as =E2=80=9Cfair game,=E2=80=9D their = +sudden reappearance +>>>>> could cause lasting market shocks and undermine confidence. The goal = +of a +>>>>> proactive migration is to close the door on such a scenario before it +>>>>> becomes imminent. +>>>>> +>>>>> I agree that Q-day won=E2=80=99t necessarily be a single, catastrophi= +c moment. +>>>>> It will likely be gradual and subtle, giving the network some time to +>>>>> adapt. That said, one challenge is ensuring we don=E2=80=99t find our= +selves in an +>>>>> emergency scramble the moment a capable quantum machine appears. A fo= +rced +>>>>> or proactive migration is an admittedly strong measure, but it attemp= +ts to +>>>>> address the scenario where a slow, creeping capability becomes a sudd= +en +>>>>> attack vector once it matures. In that sense, =E2=80=9Crushing=E2=80= +=9D isn=E2=80=99t ideal, but +>>>>> neither is waiting until the threat is undeniably present. +>>>>> +>>>>> El mi=C3=A9, 19 de feb de 2025, 1:31=E2=80=AFp. m., Hunter Beast +>>>>> <hunter@surmount.systems> escribi=C3=B3: +>>>>> +>>>>>> I don't see why old coins should be confiscated. The better option i= +s +>>>>>> to let those with quantum computers free up old coins. While this mi= +ght +>>>>>> have an inflationary impact on bitcoin's price, to use a turn of phr= +ase, +>>>>>> the inflation is transitory. Those with low time preference should s= +upport +>>>>>> returning lost coins to circulation. +>>>>>> +>>>>>> Also, I don't see the urgency, considering the majority of coins are +>>>>>> in either P2PKH, P2WPKH, P2SH, and P2WSH addresses. If PQC signature= +s +>>>>>> aren't added, such as with BIP-360, there will be some concern aroun= +d long +>>>>>> exposure attacks on P2TR coins. For large amounts, it would be smart= + to +>>>>>> modify wallets to support broadcasting transactions to private mempo= +ol +>>>>>> services such as Slipstream, to mitigate short exposure attacks. Tho= +se will +>>>>>> also be rarer early on since a CRQC capable of a long exposure attac= +k is +>>>>>> much simpler than one capable of pulling off a short exposure attack +>>>>>> against a transaction in the mempool. +>>>>>> +>>>>>> Bitcoin's Q-day likely won't be sudden and obvious. It will also tak= +e +>>>>>> time to coordinate a soft fork activation. This shouldn't be rushed. +>>>>>> +>>>>>> In the interest of transparency, it's worth mentioning that I'm +>>>>>> working on a BIP-360 implementation for Anduro. Both Anduro and Slip= +stream +>>>>>> are MARA services. +>>>>>> +>>>>>> On Tuesday, February 11, 2025 at 9:01:51=E2=80=AFPM UTC-7 Agustin Cr= +uz wrote: +>>>>>> +>>>>>>> Hi Dustin: +>>>>>>> +>>>>>>> I understand that the proposal is an extraordinary ask=E2=80=94it w= +ould +>>>>>>> indeed void a non-trivial part of the coin supply if users do not m= +igrate +>>>>>>> in time, and under normal circumstances, many would argue that unus= +ed P2PKH +>>>>>>> funds are safe from a quantum adversary. However, the intent here i= +s to be +>>>>>>> proactive rather than reactive. +>>>>>>> +>>>>>>> The concern isn=E2=80=99t solely about funds in active wallets. Con= +sider +>>>>>>> that if we don=E2=80=99t implement a proactive migration, any Bitco= +in in lost +>>>>>>> wallets=E2=80=94including, hypothetically, Satoshi=E2=80=99s if he = +is not alive=E2=80=94will remain +>>>>>>> vulnerable. In the event of a quantum breakthrough, those coins cou= +ld be +>>>>>>> hacked and put back into circulation. Such an outcome would not onl= +y +>>>>>>> disrupt the balance of supply but could also undermine the trust an= +d +>>>>>>> security that Bitcoin has built over decades. In short, the consequ= +ences of +>>>>>>> a reactive measure in a quantum emergency could be far more catastr= +ophic. +>>>>>>> +>>>>>>> While I agree that a forced migration during an active quantum +>>>>>>> attack scenario might be more acceptable (since funds would likely = +be +>>>>>>> considered lost anyway), waiting until such an emergency arises lea= +ves us +>>>>>>> with little margin for error. By enforcing a migration now, we crea= +te a +>>>>>>> window for the entire community to transition safely=E2=80=94assumi= +ng we set the +>>>>>>> deadline generously and provide ample notifications, auto-migration= + tools, +>>>>>>> and, if necessary, emergency extensions. +>>>>>>> +>>>>>>> El mar, 11 de feb de 2025, 9:48=E2=80=AFp. m., Dustin Ray < +>>>>>>> dustinvo...@gmail.com> escribi=C3=B3: +>>>>>>> +>>>>>>>> I think youre going to have a tough time getting consensus on this +>>>>>>>> proposal. It is an extraordinary ask of the community to instill a +>>>>>>>> change that will essentially void out a non-trivial part of the co= +in +>>>>>>>> supply, especially when funds behind unused P2PKH addresses are at +>>>>>>>> this point considered safe from a quantum adversary. +>>>>>>>> +>>>>>>>> In my opinion, where parts of this proposal make sense is in a +>>>>>>>> quantum +>>>>>>>> emergency in which an adversary is actively extracting private key= +s +>>>>>>>> from known public keys and a transition must be made quickly and +>>>>>>>> decisively. In that case, we might as well consider funds to be lo= +st +>>>>>>>> anyways. In any other scenario prior to this hypothetical emergenc= +y +>>>>>>>> however, I have serious doubts that the community is going to +>>>>>>>> consent +>>>>>>>> to this proposal as it stands. +>>>>>>>> +>>>>>>>> On Tue, Feb 11, 2025 at 4:37=E2=80=AFPM Agustin Cruz <agusti...@gm= +ail.com> +>>>>>>>> wrote: +>>>>>>>> > +>>>>>>>> > Hi Dustin +>>>>>>>> > +>>>>>>>> > To clarify, the intent behind making legacy funds unspendable +>>>>>>>> after a certain block height is indeed a hard security measure=E2= +=80=94designed to +>>>>>>>> mitigate the potentially catastrophic risk posed by quantum attack= +s on +>>>>>>>> ECDSA. The idea is to force a proactive migration of funds to +>>>>>>>> quantum-resistant addresses before quantum computers become capabl= +e of +>>>>>>>> compromising the current cryptography. +>>>>>>>> > +>>>>>>>> > The migration window is intended to be sufficiently long +>>>>>>>> (determined by both block height and community input) to provide a= +mple time +>>>>>>>> for users and service providers to transition. +>>>>>>>> > +>>>>>>>> > +>>>>>>>> > El mar, 11 de feb de 2025, 9:15=E2=80=AFp. m., Dustin Ray < +>>>>>>>> dustinvo...@gmail.com> escribi=C3=B3: +>>>>>>>> >> +>>>>>>>> >> Right off the bat I notice you are proposing that legacy funds +>>>>>>>> become unspendable after a certain block height which immediately = +raises +>>>>>>>> serious problems. A migration to quantum hard addresses in this ma= +nner +>>>>>>>> would cause serious financial damage to anyone holding legacy fund= +s, if I +>>>>>>>> understand your proposal correctly. +>>>>>>>> >> +>>>>>>>> >> On Tue, Feb 11, 2025 at 4:10=E2=80=AFPM Agustin Cruz < +>>>>>>>> agusti...@gmail.com> wrote: +>>>>>>>> >>> +>>>>>>>> >>> Dear Bitcoin Developers, +>>>>>>>> >>> +>>>>>>>> >>> I am writing to share my proposal for a new Bitcoin Improvemen= +t +>>>>>>>> Proposal (BIP) titled Quantum-Resistant Address Migration Protocol= + (QRAMP). +>>>>>>>> The goal of this proposal is to safeguard Bitcoin against potentia= +l future +>>>>>>>> quantum attacks by enforcing a mandatory migration period for fund= +s held in +>>>>>>>> legacy Bitcoin addresses (secured by ECDSA) to quantum-resistant a= +ddresses. +>>>>>>>> >>> +>>>>>>>> >>> The proposal outlines: +>>>>>>>> >>> +>>>>>>>> >>> Reducing Vulnerabilities: Transitioning funds to +>>>>>>>> quantum-resistant schemes preemptively to eliminate the risk posed= + by +>>>>>>>> quantum attacks on exposed public keys. +>>>>>>>> >>> Enforcing Timelines: A hard migration deadline that forces +>>>>>>>> timely action, rather than relying on a gradual, voluntary migrati= +on that +>>>>>>>> might leave many users at risk. +>>>>>>>> >>> Balancing Risks: Weighing the non-trivial risk of funds being +>>>>>>>> permanently locked against the potential catastrophic impact of a = +quantum +>>>>>>>> attack on Bitcoin=E2=80=99s security. +>>>>>>>> >>> +>>>>>>>> >>> Additionally, the proposal addresses common criticisms such as +>>>>>>>> the risk of permanent fund loss, uncertain quantum timelines, and = +the +>>>>>>>> potential for chain splits. It also details backwards compatibilit= +y +>>>>>>>> measures, comprehensive security considerations, an extensive suit= +e of test +>>>>>>>> cases, and a reference implementation plan that includes script in= +terpreter +>>>>>>>> changes, wallet software updates, and network monitoring tools. +>>>>>>>> >>> +>>>>>>>> >>> For your convenience, I have published the full proposal on my +>>>>>>>> GitHub repository. You can review it at the following link: +>>>>>>>> >>> +>>>>>>>> >>> Quantum-Resistant Address Migration Protocol (QRAMP) Proposal +>>>>>>>> on GitHub +>>>>>>>> >>> +>>>>>>>> >>> I welcome your feedback and suggestions and look forward to +>>>>>>>> engaging in a constructive discussion on how best to enhance the s= +ecurity +>>>>>>>> and resilience of the Bitcoin network in the quantum computing era= +. +>>>>>>>> >>> +>>>>>>>> >>> Thank you for your time and consideration. +>>>>>>>> >>> +>>>>>>>> >>> Best regards, +>>>>>>>> >>> +>>>>>>>> >>> Agustin Cruz +>>>>>>>> >>> +>>>>>>>> >>> -- +>>>>>>>> >>> 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+...@googlegroups.com. +>>>>>>>> >>> To view this discussion visit +>>>>>>>> https://groups.google.com/d/msgid/bitcoindev/08a544fa-a29b-45c2-83= +03-8c5bde8598e7n%40googlegroups.com +>>>>>>>> . +>>>>>>> +>>>>>>> +>>>>>>>> -- +>>>>>> You received this message because you are subscribed to the Google +>>>>>> Groups "Bitcoin Development Mailing List" group. +>>>>>> To unsubscribe from this group and stop receiving emails from it, +>>>>>> send an email to bitcoindev+unsubscribe@googlegroups.com. +>>>>>> To view this discussion visit +>>>>>> https://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71-9a9f= +-3310ea242194n%40googlegroups.com +>>>>>> <https://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71-9a9= +f-3310ea242194n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter> +>>>>>> . +>>>>>> +>>>>> -- +>>>>> 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, sen= +d +>>>>> an email to bitcoindev+unsubscribe@googlegroups.com. +>>>>> To view this discussion visit +>>>>> https://groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGLE0ZWm5t= +mfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com +>>>>> <https://groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGLE0ZWm5= +tmfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com?utm_medium=3Demail&utm_sour= +ce=3Dfooter> +>>>>> . +>>>>> +>>>> + +--=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/= +CAC3UE4KaVVjLGsAvACmh75KkCNZeHJNnk2%2BFuZOu23YFAyYg5w%40mail.gmail.com. + +--0000000000004ee7c4062e85f653 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"auto">I don't disagree personally with most of what you'= +;re saying except where the real catastrophe lies. Id argue it's catast= +rophic for the value proposition of a blockchain to effectively seize funds= +, which is what your proposal does in case anyone fails to migrate before t= +he deadline.</div><div dir=3D"auto"><br></div><div dir=3D"auto">On the othe= +r hand, it's equally catastrophic for digital signatures to be broken a= +nd funds lost in any scenario. So it seems we are staring down two extremel= +y untenable outcomes, both of which see the fundamental properties of a blo= +ckchain shattered in one way or another.</div><div dir=3D"auto"><br></div><= +div dir=3D"auto">I hope it doesn't come down to having to choose one or= + the other. There is very serious financial harm that will occur in either = +scenario. I dearly hope there is a practical technological solution that al= +lows for safe and fair migration, and in my mind and experience, I don'= +t think we have to resign ourselves to a zero sum game just yet. But I appr= +eciate your proposal and the proactive nature of this discussion, it's = +important to have these conversations now rather than later.</div><div><br>= +<div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"= +gmail_attr">On Wed, Feb 19, 2025 at 1:50=E2=80=AFPM Agustin Cruz <<a hre= +f=3D"mailto:agustin.cruz@gmail.com">agustin.cruz@gmail.com</a>> wrote:<b= +r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex= +;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left= +-color:rgb(204,204,204)"><div dir=3D"ltr"><div>Hi Dustin,</div><br>My propo= +sal is not about locking down or confiscating funds. It is about ensuring t= +hat vulnerable pre-P2PKH funds are migrated to quantum-safe addresses befor= +e any quantum adversary can exploit them. Even though P2PKH addresses are s= +ecured by hashes that are currently considered safe, relying solely on that= + safety may leave us exposed in the future, especially as quantum capabilit= +ies continue to evolve. Without a forced migration, we risk leaving a signi= +ficant portion of the coin supply vulnerable. Consider the possibility that= + if we don=E2=80=99t act, any Bitcoin in lost wallets could eventually be h= +acked and put back into circulation. Such a scenario would be catastrophic = +for the network.<br><br>I believe that by enforcing a deadline for migratio= +n, we provide rightful owners with a clear, non-negotiable opportunity to s= +ecure their funds. This approach is not merely hypothetical. It is a proact= +ive measure that addresses the imminent risk of quantum attacks. While turn= +stile mechanisms have been considered and might have merit under certain co= +nditions, I remain committed to the idea that a forced migration, with suff= +icient notice and robust safeguards, is both realistic and necessary to pro= +tect the long-term security of Bitcoin.<br></div><br><div class=3D"gmail_qu= +ote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 19, 2025 at 6:35=E2= +=80=AFPM Dustin Ray <<a href=3D"mailto:dustinvonsandwich@gmail.com" targ= +et=3D"_blank">dustinvonsandwich@gmail.com</a>> wrote:<br></div><blockquo= +te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt= +h:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,20= +4,204)"><div></div><div><div dir=3D"auto" style=3D"font-family:-apple-syste= +m,"helvetica neue";font-size:1rem;font-style:normal;font-weight:4= +00;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:no= +rmal;word-spacing:1px;text-decoration:none;background-color:rgba(0,0,0,0);b= +order-color:rgb(49,49,49);color:rgb(49,49,49)">To be clear, the turnstile a= +pproach is definitely a forced migration. It just means that instead of per= +manently confiscating funds and removing them from circulation, you force t= +he rightful owners of those funds to move them into quantum safe addresses,= + assuming the existence of a hypothetical turnstile mechanism. There's = +too many hypotheticals with this idea right now to give it any more than a = +cursory glance, but turnstiles have been built before and could potentially= + be built again in this scenario.</div><div dir=3D"auto" style=3D"font-fami= +ly:-apple-system,"helvetica neue";font-size:16px;font-style:norma= +l;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none= +;white-space:normal;word-spacing:1px;text-decoration:none;background-color:= +rgba(0,0,0,0);border-color:rgb(49,49,49);color:rgb(49,49,49)"><br></div><di= +v dir=3D"auto" style=3D"font-family:-apple-system,"helvetica neue"= +;;font-size:1rem;font-style:normal;font-weight:400;letter-spacing:normal;te= +xt-indent:0px;text-transform:none;white-space:normal;word-spacing:1px;text-= +decoration:none;background-color:rgba(0,0,0,0);border-color:rgb(49,49,49);c= +olor:rgb(49,49,49)">For further clarification, I'm suggesting that we e= +nforce migration of unspent funds in p2pkh addresses because they are alrea= +dy secured by hashes which are currently conjectured to remain safe against= + a quantum adversary. Pre-p2pkh addresses are probably the most vulnerable = +but few of these had seen use comparatively and may require confiscation.</= +div><div dir=3D"auto" style=3D"font-family:-apple-system,"helvetica ne= +ue";font-size:16px;font-style:normal;font-weight:400;letter-spacing:no= +rmal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:1p= +x;text-decoration:none;background-color:rgba(0,0,0,0);border-color:rgb(49,4= +9,49);color:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-family= +:-apple-system,"helvetica neue";font-size:1rem;font-style:normal;= +font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;w= +hite-space:normal;word-spacing:1px;text-decoration:none;background-color:rg= +ba(0,0,0,0);border-color:rgb(49,49,49);color:rgb(49,49,49)">If your idea is= + to simply lock down and confiscate any pre-pq safe funds, I resolutely dis= +agree with that decision and I am fairly confident that consensus will fail= + to materialize around that. What I'm suggesting however is that your i= +dea is realistic and sound if we assume the existence of some mechanism tha= +t allows rightful owners of pre-pq funds the opportunity to do nothing exce= +pt migrate to safe addresses which then resolves the issue.</div><div dir= +=3D"auto" style=3D"font-family:-apple-system,"helvetica neue";fon= +t-size:1rem;font-style:normal;font-weight:400;letter-spacing:normal;text-in= +dent:0px;text-transform:none;white-space:normal;word-spacing:1px;text-decor= +ation:none;background-color:rgba(0,0,0,0);border-color:rgb(49,49,49);color:= +rgb(49,49,49)"><br></div></div><div><div class=3D"gmail_quote"><div dir=3D"= +ltr" class=3D"gmail_attr">On Wed, Feb 19, 2025 at 1:07=E2=80=AFPM Agustin C= +ruz <<a href=3D"mailto:agustin.cruz@gmail.com" target=3D"_blank">agustin= +.cruz@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s= +tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:so= +lid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir=3D"auto">= +<p dir=3D"ltr">Hi Dustin,</p><p dir=3D"ltr">I remain convinced that a force= +d migration mechanism=E2=80=94with a clear block height deadline after whic= +h quantum-unsafe funds become unspendable=E2=80=94is the more robust and se= +cure approach. Here=E2=80=99s why:</p><p dir=3D"ltr"> +A forced migration approach is unambiguous. By establishing a definitive de= +adline, we eliminate the need for an additional transitional transaction ty= +pe, thereby reducing complexity and potential attack vectors. Additional co= +mplexity could inadvertently open up new vulnerabilities that a more straig= +htforward deadline avoids.</p><p dir=3D"ltr"> +If we don=E2=80=99t enforce a hard migration, any Bitcoin in lost wallets= +=E2=80=94including coins in addresses that no longer have active private ke= +y management, such as potentially Satoshi=E2=80=99s=E2=80=94could eventuall= +y be compromised by quantum adversaries. If these coins were hacked and put= + back into circulation, the resulting market shock would be catastrophic. T= +he forced migration mechanism is designed to preempt such a scenario by ens= +uring that only quantum-safe funds can be spent once the deadline is reache= +d.</p></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_= +attr">El mi=C3=A9, 19 de feb de 2025, 5:10=E2=80=AFp.=C2=A0m., Dustin Ray &= +lt;<a href=3D"mailto:dustinvonsandwich@gmail.com" target=3D"_blank">dustinv= +onsandwich@gmail.com</a>> escribi=C3=B3:<br></div><blockquote class=3D"g= +mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-= +left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div = +dir=3D"auto">It's worth considering a hypothetical but as of yet unknow= +n middle ground solution, again nothing like this exists currently but conc= +eptually it would be interesting to explore:</div><div dir=3D"auto"><br></d= +iv><div dir=3D"auto">1. At some block height deemed appropriate, modify con= +sensus so that any pre-quantum unspent funds are restricted from being spen= +t as normal.</div><div dir=3D"auto"><br></div><div dir=3D"auto">2. Develop = +a new transaction type whose sole purpose is to migrate funds from a quantu= +m unsafe address to a safe one.</div><div dir=3D"auto"><br></div><div dir= +=3D"auto">3. This new transaction type is a quantum safe digital signature,= + but here's the hypothetical: It is satisfied by developing a mechanism= + by which a private key from a quantum-unsafe scheme can be repurposed as a= + private key for a pq-safe scheme. It may also be possible that since we kn= +ow the hash of the public key, perhaps we can invent some mechanism whereby= + a quantum safe signature is created from an ecdsa private key that directl= +y implies knowledge of a secret key that derived the known public key.</div= +><div dir=3D"auto"><br></div><div dir=3D"auto">In this way, we create a kin= +d of turnstile that can safely transition funds from unsafe addresses into = +safe ones. Such turnstiles have been used in blockchains before, a notable = +example is in the zcash network as part of an audit of shielded funds.=C2= +=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">There are likely hid= +den complexities in this idea that may cause it to be completely unworkable= +, but a theoretical transition mechanism both prevents a heavy handed confi= +scation of funds and also prevents funds from being stolen and injected bac= +k into the supply under illegitimate pretenses.</div><div dir=3D"auto"><br>= +</div><div dir=3D"auto">This only works for p2pkh, anything prior to this i= +s immediately vulnerable to key inversion, but Satoshi owns most of those c= +oins as far as we know, so confiscating them might not be as controversial.= +</div><div dir=3D"auto"><br></div><div dir=3D"auto">I'm typing this on = +my phone so sorry for the lack of detailed references. I think the core ide= +a is clear though.</div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr= +" class=3D"gmail_attr">On Wed, Feb 19, 2025 at 10:47=E2=80=AFAM Agustin Cru= +z <<a href=3D"mailto:agustin.cruz@gmail.com" rel=3D"noreferrer" target= +=3D"_blank">agustin.cruz@gmail.com</a>> wrote:<br></div><blockquote clas= +s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b= +order-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"= +><div dir=3D"auto"><p dir=3D"ltr">Hi Hunter,</p><p dir=3D"ltr">I appreciate= + the work you=E2=80=99re doing on BIP-360 for Anduro. Your point about not = +=E2=80=9Cconfiscating=E2=80=9D old coins and allowing those with quantum ca= +pabilities to free them up is certainly a valid one, and I understand the a= +rgument that any inflationary impact could be transitory.</p> +<p dir=3D"ltr">From my viewpoint, allowing quantum-capable adversaries to r= +eintroduce dormant coins (e.g., Satoshi=E2=80=99s if those keys are lost) c= +ould have unintended consequences that go beyond transient inflation. It co= +uld fundamentally alter trust in Bitcoin=E2=80=99s fixed supply and disrupt= + economic assumptions built around the current distribution of coins. While= + some might view these dormant coins as =E2=80=9Cfair game,=E2=80=9D their = +sudden reappearance could cause lasting market shocks and undermine confide= +nce. The goal of a proactive migration is to close the door on such a scena= +rio before it becomes imminent.</p><p dir=3D"ltr">I agree that Q-day won=E2= +=80=99t necessarily be a single, catastrophic moment. It will likely be gra= +dual and subtle, giving the network some time to adapt. That said, one chal= +lenge is ensuring we don=E2=80=99t find ourselves in an emergency scramble = +the moment a capable quantum machine appears. A forced or proactive migrati= +on is an admittedly strong measure, but it attempts to address the scenario= + where a slow, creeping capability becomes a sudden attack vector once it m= +atures. In that sense, =E2=80=9Crushing=E2=80=9D isn=E2=80=99t ideal, but n= +either is waiting until the threat is undeniably present.</p></div><br><div= + class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">El mi=C3=A9, 1= +9 de feb de 2025, 1:31=E2=80=AFp.=C2=A0m., Hunter Beast <hunter@surmount= +.systems> escribi=C3=B3:<br></div><blockquote class=3D"gmail_quote" styl= +e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid= +;padding-left:1ex;border-left-color:rgb(204,204,204)">I don't see why o= +ld coins should be confiscated. The better option is to let those with quan= +tum computers free up old coins. While this might have an inflationary impa= +ct on bitcoin's price, to use a turn of phrase, the inflation is transi= +tory. Those with low time preference should support returning lost coins to= + circulation.<div><br></div><div>Also, I don't see the urgency, conside= +ring the majority of coins are in either P2PKH, P2WPKH, P2SH, and P2WSH add= +resses. If PQC signatures aren't added, such as with BIP-360, there wil= +l be some concern around long exposure attacks on P2TR coins. For large amo= +unts, it would be smart to modify wallets to support broadcasting transacti= +ons to private mempool services such as Slipstream, to mitigate short expos= +ure attacks. Those will also be rarer early on since a CRQC capable of a lo= +ng exposure attack is much simpler than one capable of pulling off a short = +exposure attack against a transaction in the mempool.</div><div><br></div><= +div>Bitcoin's Q-day likely won't be sudden and obvious. It will als= +o take time to coordinate a soft fork activation. This shouldn't be rus= +hed.</div><div><br></div><div>In the interest of transparency, it's wor= +th mentioning that I'm working on a BIP-360 implementation for Anduro. = +Both Anduro and Slipstream are MARA services.</div><div><br></div><div clas= +s=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Tuesday, Februa= +ry 11, 2025 at 9:01:51=E2=80=AFPM UTC-7 Agustin Cruz wrote:<br></div><block= +quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w= +idth:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204= +,204,204)"><div dir=3D"auto"><p dir=3D"ltr">Hi Dustin:</p> +<p dir=3D"ltr">I understand that the proposal is an extraordinary ask=E2=80= +=94it would indeed void a non-trivial part of the coin supply if users do n= +ot migrate in time, and under normal circumstances, many would argue that u= +nused P2PKH funds are safe from a quantum adversary. However, the intent he= +re is to be proactive rather than reactive.</p> +<p dir=3D"ltr">The concern isn=E2=80=99t solely about funds in active walle= +ts. Consider that if we don=E2=80=99t implement a proactive migration, any = +Bitcoin in lost wallets=E2=80=94including, hypothetically, Satoshi=E2=80=99= +s if he is not alive=E2=80=94will remain vulnerable. In the event of a quan= +tum breakthrough, those coins could be hacked and put back into circulation= +. Such an outcome would not only disrupt the balance of supply but could al= +so undermine the trust and security that Bitcoin has built over decades. In= + short, the consequences of a reactive measure in a quantum emergency could= + be far more catastrophic.</p> +<p dir=3D"ltr">While I agree that a forced migration during an active quant= +um attack scenario might be more acceptable (since funds would likely be co= +nsidered lost anyway), waiting until such an emergency arises leaves us wit= +h little margin for error. By enforcing a migration now, we create a window= + for the entire community to transition safely=E2=80=94assuming we set the = +deadline generously and provide ample notifications, auto-migration tools, = +and, if necessary, emergency extensions.</p></div><br><div class=3D"gmail_q= +uote"><div dir=3D"ltr" class=3D"gmail_attr">El mar, 11 de feb de 2025, 9:48= +=E2=80=AFp.=C2=A0m., Dustin Ray <<a rel=3D"nofollow noreferrer noreferre= +r">dustinvo...@gmail.com</a>> escribi=C3=B3:<br></div><blockquote class= +=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo= +rder-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">= +I think youre going to have a tough time getting consensus on this<br> +proposal. It is an extraordinary ask of the community to instill a<br> +change that will essentially void out a non-trivial part of the coin<br> +supply, especially when funds behind unused P2PKH addresses are at<br> +this point considered safe from a quantum adversary.<br> +<br> +In my opinion, where parts of this proposal make sense is in a quantum<br> +emergency in which an adversary is actively extracting private keys<br> +from known public keys and a transition must be made quickly and<br> +decisively. In that case, we might as well consider funds to be lost<br> +anyways. In any other scenario prior to this hypothetical emergency<br> +however, I have serious doubts that the community is going to consent<br> +to this proposal as it stands.<br> +<br> +On Tue, Feb 11, 2025 at 4:37=E2=80=AFPM Agustin Cruz <<a rel=3D"noreferr= +er nofollow noreferrer noreferrer">agusti...@gmail.com</a>> wrote:<br> +><br> +> Hi Dustin<br> +><br> +> To clarify, the intent behind making legacy funds unspendable after a = +certain block height is indeed a hard security measure=E2=80=94designed to = +mitigate the potentially catastrophic risk posed by quantum attacks on ECDS= +A. The idea is to force a proactive migration of funds to quantum-resistant= + addresses before quantum computers become capable of compromising the curr= +ent cryptography.<br> +><br> +> The migration window is intended to be sufficiently long (determined b= +y both block height and community input) to provide ample time for users an= +d service providers to transition.<br> +><br> +><br> +> El mar, 11 de feb de 2025, 9:15=E2=80=AFp. m., Dustin Ray <<a rel= +=3D"noreferrer nofollow noreferrer noreferrer">dustinvo...@gmail.com</a>>= +; escribi=C3=B3:<br> +>><br> +>> Right off the bat I notice you are proposing that legacy funds bec= +ome unspendable after a certain block height which immediately raises serio= +us problems. A migration to quantum hard addresses in this manner would cau= +se serious financial damage to anyone holding legacy funds, if I understand= + your proposal correctly.<br> +>><br> +>> On Tue, Feb 11, 2025 at 4:10=E2=80=AFPM Agustin Cruz <<a rel=3D= +"noreferrer nofollow noreferrer noreferrer">agusti...@gmail.com</a>> wro= +te:<br> +>>><br> +>>> Dear Bitcoin Developers,<br> +>>><br> +>>> I am writing to share my proposal for a new Bitcoin Improvemen= +t Proposal (BIP) titled Quantum-Resistant Address Migration Protocol (QRAMP= +). The goal of this proposal is to safeguard Bitcoin against potential futu= +re quantum attacks by enforcing a mandatory migration period for funds held= + in legacy Bitcoin addresses (secured by ECDSA) to quantum-resistant addres= +ses.<br> +>>><br> +>>> The proposal outlines:<br> +>>><br> +>>> Reducing Vulnerabilities: Transitioning funds to quantum-resis= +tant schemes preemptively to eliminate the risk posed by quantum attacks on= + exposed public keys.<br> +>>> Enforcing Timelines: A hard migration deadline that forces tim= +ely action, rather than relying on a gradual, voluntary migration that migh= +t leave many users at risk.<br> +>>> Balancing Risks: Weighing the non-trivial risk of funds being = +permanently locked against the potential catastrophic impact of a quantum a= +ttack on Bitcoin=E2=80=99s security.<br> +>>><br> +>>> Additionally, the proposal addresses common criticisms such as= + the risk of permanent fund loss, uncertain quantum timelines, and the pote= +ntial for chain splits. It also details backwards compatibility measures, c= +omprehensive security considerations, an extensive suite of test cases, and= + a reference implementation plan that includes script interpreter changes, = +wallet software updates, and network monitoring tools.<br> +>>><br> +>>> For your convenience, I have published the full proposal on my= + GitHub repository. You can review it at the following link:<br> +>>><br> +>>> Quantum-Resistant Address Migration Protocol (QRAMP) Proposal = +on GitHub<br> +>>><br> +>>> I welcome your feedback and suggestions and look forward to en= +gaging in a constructive discussion on how best to enhance the security and= + resilience of the Bitcoin network in the quantum computing era.<br> +>>><br> +>>> Thank you for your time and consideration.<br> +>>><br> +>>> Best regards,<br> +>>><br> +>>> Agustin Cruz<br> +>>><br> +>>> --<br> +>>> You received this message because you are subscribed to the Go= +ogle Groups "Bitcoin Development Mailing List" group.<br> +>>> To unsubscribe from this group and stop receiving emails from = +it, send an email to <a rel=3D"noreferrer nofollow noreferrer noreferrer">b= +itcoindev+...@googlegroups.com</a>.<br> +>>> To view this discussion visit <a href=3D"https://groups.google= +.com/d/msgid/bitcoindev/08a544fa-a29b-45c2-8303-8c5bde8598e7n%40googlegroup= +s.com" rel=3D"noreferrer noreferrer nofollow noreferrer noreferrer" target= +=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/08a544fa-a29b-45c2= +-8303-8c5bde8598e7n%40googlegroups.com</a>.</blockquote></div></blockquote>= +</div></blockquote></div><div class=3D"gmail_quote"><blockquote class=3D"gm= +ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l= +eft-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div c= +lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px = +0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1e= +x;border-left-color:rgb(204,204,204)"><div class=3D"gmail_quote"><blockquot= +e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width= +:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204= +,204)"><br></blockquote></div></blockquote></div></blockquote></div></block= +quote></div></div></blockquote></div></blockquote></div></div></blockquote>= +</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D= +"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;pad= +ding-left:1ex;border-left-color:rgb(204,204,204)"><div><div class=3D"gmail_= +quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;= +border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-= +color:rgb(204,204,204)"><div class=3D"gmail_quote"><blockquote class=3D"gma= +il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le= +ft-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div><d= +iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:= +0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-lef= +t:1ex;border-left-color:rgb(204,204,204)"><div class=3D"gmail_quote"><block= +quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w= +idth:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204= +,204,204)"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty= +le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli= +d;padding-left:1ex;border-left-color:rgb(204,204,204)"><div class=3D"gmail_= +quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;= +border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-= +color:rgb(204,204,204)"> +</blockquote></div> +</blockquote></div> + +<p></p> + +-- <br> +You received this message because you are subscribed to the Google Groups &= +quot;Bitcoin Development Mailing List" group.<br> +To unsubscribe from this group and stop receiving emails from it, send an e= +mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n= +oreferrer noreferrer" target=3D"_blank">bitcoindev+unsubscribe@googlegroups= +.com</a>.<br> +To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/= +bitcoindev/f9e233e0-9d87-4e71-9a9f-3310ea242194n%40googlegroups.com?utm_med= +ium=3Demail&utm_source=3Dfooter" rel=3D"noreferrer noreferrer" target= +=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71= +-9a9f-3310ea242194n%40googlegroups.com</a>.<br> +</blockquote></div> + +<p></p> + +-- <br> +You received this message because you are subscribed to the Google Groups &= +quot;Bitcoin Development Mailing List" group.<br> +To unsubscribe from this group and stop receiving emails from it, send an e= +mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n= +oreferrer" target=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<b= +r> +To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/= +bitcoindev/CAJDmzYz%3D52MGGLE0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gma= +il.com?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"noreferrer" targe= +t=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGL= +E0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com</a>.<br> +</blockquote></div></div> +</blockquote></div> +</blockquote></div></div> +</blockquote></div> +</blockquote></div></div> + +<p></p> + +-- <br /> +You received this message because you are subscribed to the Google Groups &= +quot;Bitcoin Development Mailing List" group.<br /> +To unsubscribe from this group and stop receiving emails from it, send an e= +mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind= +ev+unsubscribe@googlegroups.com</a>.<br /> +To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/= +bitcoindev/CAC3UE4KaVVjLGsAvACmh75KkCNZeHJNnk2%2BFuZOu23YFAyYg5w%40mail.gma= +il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/= +msgid/bitcoindev/CAC3UE4KaVVjLGsAvACmh75KkCNZeHJNnk2%2BFuZOu23YFAyYg5w%40ma= +il.gmail.com</a>.<br /> + +--0000000000004ee7c4062e85f653-- + |