diff options
| author | Dustin Ray <dustinvonsandwich@gmail.com> | 2025-02-19 13:35:00 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2025-02-19 13:54:44 -0800 |
| commit | 68a7222bd132bdea0710ba5519c6616869b3f972 (patch) | |
| tree | 7c33b89305dd892530737eabd1a104008de4e593 | |
| parent | 83a26c62706599b615ac6624673d74f15fd11a5a (diff) | |
| download | pi-bitcoindev-68a7222bd132bdea0710ba5519c6616869b3f972.tar.gz pi-bitcoindev-68a7222bd132bdea0710ba5519c6616869b3f972.zip | |
Re: [bitcoindev] Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP
| -rw-r--r-- | ab/d29841cfbc522ce1e96d82ac4b5d765fb980d9 | 920 |
1 files changed, 920 insertions, 0 deletions
diff --git a/ab/d29841cfbc522ce1e96d82ac4b5d765fb980d9 b/ab/d29841cfbc522ce1e96d82ac4b5d765fb980d9 new file mode 100644 index 000000000..26dc15d75 --- /dev/null +++ b/ab/d29841cfbc522ce1e96d82ac4b5d765fb980d9 @@ -0,0 +1,920 @@ +Delivery-date: Wed, 19 Feb 2025 13:54:44 -0800 +Received: from mail-qt1-f192.google.com ([209.85.160.192]) + by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + (Exim 4.94.2) + (envelope-from <bitcoindev+bncBCXOL6U6XMBRBGNG3G6QMGQE4GUC5VQ@googlegroups.com>) + id 1tks1i-0001Zv-3u + for bitcoindev@gnusha.org; Wed, 19 Feb 2025 13:54:44 -0800 +Received: by mail-qt1-f192.google.com with SMTP id d75a77b69052e-471fa1c3dacsf6715561cf.2 + for <bitcoindev@gnusha.org>; Wed, 19 Feb 2025 13:54:42 -0800 (PST) +ARC-Seal: i=2; a=rsa-sha256; t=1740002076; cv=pass; + d=google.com; s=arc-20240605; + b=AY15Vuo848dFZgbB0gBMcmR1pwmaQKQWYK+mTsdDyN7Ndu+FcfzofW1RYFZr1w2vzS + +6k/T3BSMXeKMy89fn1F1QegJDNmeevlv4kCz40hgPHyO+ckxn+pkL7EiANrdDv68z8/ + rbrx60UGI5iVxMFX3wf7VVywxNbbOkgSgYvL8otz1QowSHcoDe35ghneEmZsJx5msmf7 + k0UCE+Tny+7zooqJvlbWAPBKRuUSWWTHpojlKpUNh3z9sq80Te+bYVOw3mrjCRoEt6mZ + UWGTQjn2yj+yn9xln+Xxc0XZp4REEVyMKLTCZ9xqfE7x07mC3wBsT2b5dLR6Adbn3qcn + ufJg== +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=lVKe5Z492Lhk6FxyhV7N05YMqbM2A7B9uwxoV2xVvO4=; + fh=e7mZxPLIoNYthiCjEk2Wd/n6F2bd5gp+cAPgw+fYjfg=; + b=JFzgaXfrGqupKnUhesVicX5EIrQL4yVyA7hffg8UfU4J0sgc/ydUjCJEaCCAlb8Fg4 + 3iVtzyd1ulKO8zLXoMLf8aRxuYcYeNFW6t5OjKJaYGj/zZenRYBfOa9UkShnmzcsUtfD + OaQIouC5c3CjedF9O0U264XO4gv5rzk0ff1zu5gOCvvL03U9Cv8XzhItdfN0VEYNS4mm + vXRAkCtPenSNI/+gjFpVFe4dcaXxTPT2FHiqXRaIBatTh5FgghBcv3Ph9t+vqTc4++kQ + UaMOSa1C9r+U2ryl5uX8gQvaAz3AdCGHxRqEt8uAfiPau4OwVSMS9rSfulPwhF18XVrt + BS8A==; + darn=gnusha.org +ARC-Authentication-Results: i=2; gmr-mx.google.com; + dkim=pass header.i=@gmail.com header.s=20230601 header.b=ItZraEOw; + spf=pass (google.com: domain of dustinvonsandwich@gmail.com designates 2607:f8b0:4864:20::c35 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=1740002076; x=1740606876; 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=lVKe5Z492Lhk6FxyhV7N05YMqbM2A7B9uwxoV2xVvO4=; + b=it8XPXzC4yambQLS7l0qxGkSJiSnPErc23OVoaKAMPGOmFROTygV8vjOU/jMmGWEjd + yY+dLLKkn8I9diYt89lZc/FX+DF7YQqFMaVwjIu5w5XrMh9Lw1Z2Zo3QaV+tvuDREwbL + 0yi85fPxczTPpjnvrrw25uLQdDlDXEraKdloHyWFeXKL5qnZqNLAzP4RFCc6FfmdQMOs + TAmt/3u3/VnylC5nxWvsfDQHhJLBahIlDnvV15TVchoLClYyqg9Nkur6UK3+a4BQWm95 + K6HV6mP7+fzT2cvqg2ByMyD72GUf9JRxt3wqGEmZ75PJRH0T+fsE2JN8QprXU8FBvUw3 + fc+Q== +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20230601; t=1740002076; x=1740606876; 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=lVKe5Z492Lhk6FxyhV7N05YMqbM2A7B9uwxoV2xVvO4=; + b=OYJPuLaMg5JpWzKeND6WhwoDdZJhfoyUWmydjvlqj6TL+1QNO/rwiXFnS/QzPyvi0D + W04ZfihG63dCT4jPmh/MQBiTJoKlJA3ydjOXeNmkxHxAJGjJ6VflbSpAMlELYfkhlexi + kt+Qj9Shlm3rKon4eNgqsfW4hIDxqjaH7pJ060d+hfA95IqDQUg+Hgl4+t9SpUWDHfLy + ojj9miEs6bKRvxYf0u2Aeaq8HRn99r2o46K0+xLlf5NQOROn72JnXnzfaagE3x+ooQBW + J3lKqKHuG6S2vCRwTryzWi+OOwrf6I5n5c/g9IuH58igN7YTxEdJTCBmX5UQ7D+9IqTx + zKOQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1740002076; x=1740606876; + 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=lVKe5Z492Lhk6FxyhV7N05YMqbM2A7B9uwxoV2xVvO4=; + b=kGm+S0P2XvUR++w3Flzpy84DccnK5NHwk56eWT7sAIZ4SfWeb+NaTR/M+DXePcJ5dP + qVjo+44LSSywLU/ZE5QYZAB+8++lpWo+du0ISavqqVW4WqfsZGFPQ7bIs9x5DzVzD5/K + TJlCot1toWwRFduoa6rEsCdF9A9cIbVEaKAu93Lp73CRPmwnY9RtR47nJI3niy4lIXJI + UH2hOa6ThMN12FvxVDZ6stOoQjr/1Mm5Ym4SfRvDTblYnkfDnkHW4pIJFh91RSorpUvt + OVV1MkRxDFdksVDAcOCxWjVV0BLcI+984mKS6/TPwoV2Sa24Z7gxZMsjqZwddrqzBUd4 + sg3A== +Sender: bitcoindev@googlegroups.com +X-Forwarded-Encrypted: i=2; AJvYcCXWzeLuXyo8jocJVfmqKTWQHgtcvVdIa2o5Vcse/at+HaDNrDhhOlXEKYEAZujm3P8+Twhfu8bQ6a+v@gnusha.org +X-Gm-Message-State: AOJu0YzEhfLY/2nFlhTDJmGiCg99MVZVIzVVWZG4neqE+TOwWW+488hT + TlXYOQCncljehJfEZ7p69/ryv1qSDwopOoPbv0XW0aVJfmn8hEod +X-Google-Smtp-Source: AGHT+IEpH9SiaYihjRzanF8WszYeuJV5yxORWXtjm4sZ9YxBMC1wEymdBNR9yVdHt5Yzt3MLDj7RCw== +X-Received: by 2002:a05:622a:24d:b0:471:8b48:70d with SMTP id d75a77b69052e-4721734d091mr645701cf.21.1740002076149; + Wed, 19 Feb 2025 13:54:36 -0800 (PST) +X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVGU7qqJOv8gQ6WvdKaH5NxppYK4H8XzmVtfdIxLF1S4NQ== +Received: by 2002:a05:622a:134c:b0:471:f5a4:7d3a with SMTP id + d75a77b69052e-4721708d465ls654891cf.1.-pod-prod-01-us; Wed, 19 Feb 2025 + 13:54:32 -0800 (PST) +X-Forwarded-Encrypted: i=2; AJvYcCUpRJ+0TK8TxWR6zcOU0vGRPIG8kVtJinyzURp+l34LTkpl/96qvrj0i6di03wOqU845ScEoyVWEVqS@googlegroups.com +X-Received: by 2002:a05:620a:44d6:b0:7c0:c332:1cdb with SMTP id af79cd13be357-7c0c3321d91mr44615685a.38.1740002072832; + Wed, 19 Feb 2025 13:54:32 -0800 (PST) +Received: by 2002:a05:620a:4015:b0:7c0:9619:31e1 with SMTP id af79cd13be357-7c0c3017a36ms85a; + Wed, 19 Feb 2025 13:35:13 -0800 (PST) +X-Forwarded-Encrypted: i=2; AJvYcCXq3gBcjUcMUYbA5GhVxC+OaIjDBOqSJA+bx696gLzi4HzanNWkz0X55t8hX8do11rjlzzxUtxTSenx@googlegroups.com +X-Received: by 2002:a05:6122:2015:b0:518:965c:34a with SMTP id 71dfb90a1353d-521df759896mr34447e0c.2.1740000912946; + Wed, 19 Feb 2025 13:35:12 -0800 (PST) +ARC-Seal: i=1; a=rsa-sha256; t=1740000912; cv=none; + d=google.com; s=arc-20240605; + b=ifpI42SpUnB4TKtJUmA1B+LE6215glzfwe+lxgOXI9AZfCtZWXqGMBl8sPg1r5/YR8 + dGMdK6yvH3wxJOkNdCg49wetsLyUne7KXtUhYzwDMXyHHxi8Ac8G20n+spEW4bQizc89 + +7DkOs+RhaTmuEO2BtN4268HH3uxJgb7zIMqRPBT3gTlR3SzHQviCcFHX1oc+Ty8nZwe + qeHXRyDKVx/1RnSmlLPlhmHv9TzoLi2+5BxpIKIn7kZLGWCcDZqmHzNWqV/1cHdiCytV + 5ZuoTR0NwifRsBsx7y3LwCx4xm+5ZzD7CAq2VV3eRrXkUSA3HB63Avlevd9XP8kaGXOA + G51w== +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=Zj2g5AyBLYbBTbAzBvb4B2VKqBPMMS/7Pz5jQrQ4y3M=; + fh=ir3h3lShDhQBRRlPpPM/ahyqmomg1te7XpwI2Kdwc5k=; + b=dpopIEPwTp8555zA0xrZEvhjtVgUOS16ztr2QI2ZBqsCgNaZhygGkvTWQ1eWSmsHPm + glMg/lZZiNMfwOFskcOQIq3OmHFqozaoznk3q5UtXKSS5SxuqK1Q9Au8P12ePf8dRl/T + 8/AQYMGSWDD10+EF6uvMArzVvTzu+bxnc5AqNx5wFXIqgoFLHCEIIP+3U+ydIJG7SI4s + vqlztxTcNCqjfmfQmfJhNJHZCBhWbsKzuyKXeF4cmJv6bDD83vAmOhn24JehHOr5IGnd + BzSmgd4dcl/ytSxfOCWT1UXyGZbVM3BUAEoDLOCZ6FmC5X3q+RKm5MkVCP8k4NNhTJAe + p5yQ==; + dara=google.com +ARC-Authentication-Results: i=1; gmr-mx.google.com; + dkim=pass header.i=@gmail.com header.s=20230601 header.b=ItZraEOw; + spf=pass (google.com: domain of dustinvonsandwich@gmail.com designates 2607:f8b0:4864:20::c35 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-oo1-xc35.google.com (mail-oo1-xc35.google.com. [2607:f8b0:4864:20::c35]) + by gmr-mx.google.com with ESMTPS id 71dfb90a1353d-520b350831dsi365186e0c.0.2025.02.19.13.35.12 + for <bitcoindev@googlegroups.com> + (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); + Wed, 19 Feb 2025 13:35:12 -0800 (PST) +Received-SPF: pass (google.com: domain of dustinvonsandwich@gmail.com designates 2607:f8b0:4864:20::c35 as permitted sender) client-ip=2607:f8b0:4864:20::c35; +Received: by mail-oo1-xc35.google.com with SMTP id 006d021491bc7-5fa9778fa2cso160230eaf.0 + for <bitcoindev@googlegroups.com>; Wed, 19 Feb 2025 13:35:12 -0800 (PST) +X-Forwarded-Encrypted: i=1; AJvYcCUS4F5j99M3dMAigfVMe572M/Z1idvd/v9vzpWX6+8HsLNf7whAOre0U9SejqeMYWe9UYVC7qDCWNZ7@googlegroups.com +X-Gm-Gg: ASbGnctuYxiNj7FJJq1hBcniqCovtjqQ0obKjEQrc4zKyPDdCkSJTjAAaRu4LSb4Ie6 + 9CDE9ou9UuOOkqxchqISwaGVYX89riBJo2KGjAa5I+F1wjFvKCGa0+RQKU5OPy2pvSsekzA8Dd2 + RPQWON15CwZbM1tu3ItLh49jSCBV/X +X-Received: by 2002:a05:6871:3a2c:b0:2b7:f8d9:d5f7 with SMTP id + 586e51a60fabf-2bc99b4f095mr13013003fac.19.1740000912247; Wed, 19 Feb 2025 + 13:35:12 -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> +In-Reply-To: <CAJDmzYzvYkm8At6yMrn+mAXnXbk=-R36SL5WneaDT9-Y-d=11w@mail.gmail.com> +From: Dustin Ray <dustinvonsandwich@gmail.com> +Date: Wed, 19 Feb 2025 13:35:00 -0800 +X-Gm-Features: AWEUYZlN5PMvWpFXbGrao4_QnKn4tIdgEp7L_EnwAdNGSkXENiDjIqK1o_0RQt8 +Message-ID: <CAC3UE4KZ7GajyaPT1DYfjyxAACnntqfAnoxZwc0kNV2yivDnyQ@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="000000000000489472062e8588d5" +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=ItZraEOw; spf=pass + (google.com: domain of dustinvonsandwich@gmail.com designates + 2607:f8b0:4864:20::c35 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 (/) + +--000000000000489472062e8588d5 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +To be clear, the turnstile approach is definitely a forced migration. It +just means that instead of permanently confiscating funds and removing them +from circulation, you force the 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. + +For further clarification, I'm suggesting that we enforce migration of +unspent funds in p2pkh addresses because they are already 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. + +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 however +is that your idea is realistic and sound if we assume the existence of some +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.co= +m> wrote: + +> Hi Dustin, +> +> I remain convinced that a forced migration mechanism=E2=80=94with a clear= + 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 definitive +> deadline, we eliminate the need for an additional transitional transactio= +n +> type, thereby reducing complexity and potential attack vectors. Additiona= +l +> 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 p= +rivate key +> 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. The forced +> migration mechanism is designed to preempt such a scenario by ensuring th= +at +> 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 groun= +d +>> solution, again nothing like this exists currently but conceptually 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 normal. +>> +>> 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 wh= +ich +>> a private key from a quantum-unsafe scheme can be repurposed as a privat= +e +>> key for a pq-safe scheme. It may also be possible that since we know 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. +>> +>> In this way, we create a kind of turnstile that can safely transition +>> funds from unsafe addresses into safe ones. Such turnstiles have been us= +ed +>> in blockchains before, a notable example is in the zcash network as part= + of +>> an audit of shielded funds. +>> +>> There are likely hidden complexities in this idea that may cause it to b= +e +>> completely unworkable, but a theoretical transition mechanism both preve= +nts +>> a heavy handed confiscation of funds and also prevents funds from being +>> stolen and injected back into the supply under illegitimate pretenses. +>> +>> This only works for p2pkh, anything prior to this is immediately +>> vulnerable to key inversion, but Satoshi owns most of those coins as far= + 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@gmai= +l.com> +>> wrote: +>> +>>> Hi Hunter, +>>> +>>> 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 w= +ith quantum +>>> capabilities to free them up is certainly a valid one, and I understand= + the +>>> argument that any inflationary impact could be transitory. +>>> +>>> From my viewpoint, allowing quantum-capable adversaries to reintroduce +>>> dormant coins (e.g., Satoshi=E2=80=99s if those keys are lost) could ha= +ve +>>> unintended consequences that go beyond transient inflation. It could +>>> 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 su= +dden 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, catastrophic = +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 ourse= +lves in an +>>> emergency scramble the moment a capable quantum machine appears. A forc= +ed +>>> or proactive migration is an admittedly strong measure, but it attempts= + to +>>> address the scenario where a slow, creeping capability becomes a sudden +>>> 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 is +>>>> to let those with quantum computers free up old coins. While this migh= +t +>>>> have an inflationary impact on bitcoin's price, to use a turn of phras= +e, +>>>> the inflation is transitory. Those with low time preference should sup= +port +>>>> returning lost coins to circulation. +>>>> +>>>> Also, I don't see the urgency, considering the majority of coins are i= +n +>>>> either P2PKH, P2WPKH, P2SH, and P2WSH addresses. If PQC signatures are= +n't +>>>> added, such as with BIP-360, there will be some concern around long +>>>> exposure attacks on P2TR coins. For large amounts, it would be smart t= +o +>>>> modify wallets to support broadcasting transactions to private mempool +>>>> services such as Slipstream, to mitigate short exposure attacks. Those= + will +>>>> also be rarer early on since a CRQC capable of a long exposure attack = +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 take +>>>> time to coordinate a soft fork activation. This shouldn't be rushed. +>>>> +>>>> In the interest of transparency, it's worth mentioning that I'm workin= +g +>>>> on a BIP-360 implementation for Anduro. Both Anduro and Slipstream are= + MARA +>>>> services. +>>>> +>>>> On Tuesday, February 11, 2025 at 9:01:51=E2=80=AFPM UTC-7 Agustin Cruz= + wrote: +>>>> +>>>>> Hi Dustin: +>>>>> +>>>>> I understand that the proposal is an extraordinary ask=E2=80=94it wou= +ld indeed +>>>>> void a non-trivial part of the coin supply if users do not migrate in= + time, +>>>>> and under normal circumstances, many would argue that unused P2PKH fu= +nds +>>>>> are safe from a quantum adversary. However, the intent here is to be +>>>>> proactive rather than reactive. +>>>>> +>>>>> The concern isn=E2=80=99t solely about funds in active wallets. Consi= +der that +>>>>> if we don=E2=80=99t implement a proactive migration, any Bitcoin in l= +ost +>>>>> 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 could= + be +>>>>> hacked and put back into circulation. Such an outcome would not only +>>>>> disrupt the balance of supply but could also undermine the trust and +>>>>> security that Bitcoin has built over decades. In short, the consequen= +ces of +>>>>> a reactive measure in a quantum emergency could be far more catastrop= +hic. +>>>>> +>>>>> While I agree that a forced migration during an active quantum attack +>>>>> scenario might be more acceptable (since funds would likely be consid= +ered +>>>>> lost anyway), waiting until such an emergency arises leaves us with l= +ittle +>>>>> margin for error. By enforcing a migration now, we create a window fo= +r the +>>>>> entire community to transition safely=E2=80=94assuming we set the dea= +dline +>>>>> 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 coin +>>>>>> 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 quant= +um +>>>>>> emergency in which an adversary is actively extracting private keys +>>>>>> from known public keys and a transition must be made quickly and +>>>>>> decisively. In that case, we might as well consider funds to be lost +>>>>>> anyways. In any other scenario prior to this hypothetical emergency +>>>>>> however, I have serious doubts that the community is going to consen= +t +>>>>>> to this proposal as it stands. +>>>>>> +>>>>>> On Tue, Feb 11, 2025 at 4:37=E2=80=AFPM Agustin Cruz <agusti...@gmai= +l.com> +>>>>>> wrote: +>>>>>> > +>>>>>> > Hi Dustin +>>>>>> > +>>>>>> > To clarify, the intent behind making legacy funds unspendable afte= +r +>>>>>> a certain block height is indeed a hard security measure=E2=80=94des= +igned to +>>>>>> mitigate the potentially catastrophic risk posed by quantum attacks = +on +>>>>>> ECDSA. The idea is to force a proactive migration of funds to +>>>>>> quantum-resistant addresses before quantum computers become capable = +of +>>>>>> compromising the current cryptography. +>>>>>> > +>>>>>> > The migration window is intended to be sufficiently long +>>>>>> (determined by both block height and community input) to provide amp= +le 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 ra= +ises +>>>>>> serious problems. A migration to quantum hard addresses in this mann= +er +>>>>>> would cause serious financial damage to anyone holding legacy funds,= + if I +>>>>>> understand your proposal correctly. +>>>>>> >> +>>>>>> >> On Tue, Feb 11, 2025 at 4:10=E2=80=AFPM Agustin Cruz <agusti...@g= +mail.com> +>>>>>> wrote: +>>>>>> >>> +>>>>>> >>> Dear Bitcoin Developers, +>>>>>> >>> +>>>>>> >>> I am writing to share my proposal for a new Bitcoin Improvement +>>>>>> Proposal (BIP) titled Quantum-Resistant Address Migration Protocol (= +QRAMP). +>>>>>> The goal of this proposal is to safeguard Bitcoin against potential = +future +>>>>>> quantum attacks by enforcing a mandatory migration period for funds = +held in +>>>>>> legacy Bitcoin addresses (secured by ECDSA) to quantum-resistant add= +resses. +>>>>>> >>> +>>>>>> >>> The proposal outlines: +>>>>>> >>> +>>>>>> >>> Reducing Vulnerabilities: Transitioning funds to +>>>>>> quantum-resistant schemes preemptively to eliminate the risk posed b= +y +>>>>>> quantum attacks on exposed public keys. +>>>>>> >>> Enforcing Timelines: A hard migration deadline that forces timel= +y +>>>>>> action, rather than relying on a gradual, voluntary migration that m= +ight +>>>>>> leave many users at risk. +>>>>>> >>> Balancing Risks: Weighing the non-trivial risk of funds being +>>>>>> permanently locked against the potential catastrophic impact of a qu= +antum +>>>>>> 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 th= +e +>>>>>> potential for chain splits. It also details backwards compatibility +>>>>>> measures, comprehensive security considerations, an extensive suite = +of test +>>>>>> cases, and a reference implementation plan that includes script inte= +rpreter +>>>>>> 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 sec= +urity +>>>>>> 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-8303= +-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-3= +310ea242194n%40googlegroups.com +>>>> <https://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71-9a9f-= +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, send +>>> an email to bitcoindev+unsubscribe@googlegroups.com. +>>> To view this discussion visit +>>> https://groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGLE0ZWm5tmf= +LUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com +>>> <https://groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGLE0ZWm5tm= +fLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com?utm_medium=3Demail&utm_source= +=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/= +CAC3UE4KZ7GajyaPT1DYfjyxAACnntqfAnoxZwc0kNV2yivDnyQ%40mail.gmail.com. + +--000000000000489472062e8588d5 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div></div><div><div dir=3D"auto" style=3D"font-family:-apple-system,"= +helvetica neue";font-size:1rem;font-style:normal;font-weight:400;lette= +r-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;wor= +d-spacing:1px;text-decoration:none;background-color:rgba(0,0,0,0);border-co= +lor:rgb(49,49,49);color:rgb(49,49,49)">To be clear, the turnstile approach = +is definitely a forced migration. It just means that instead of permanently= + confiscating funds and removing them from circulation, you force the right= +ful owners of those funds to move them into quantum safe addresses, assumin= +g 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 buil= +t again in this scenario.</div><div dir=3D"auto" style=3D"font-family:-appl= +e-system,"helvetica neue";font-size:16px;font-style:normal;font-w= +eight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-s= +pace: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><div dir=3D= +"auto" style=3D"font-family:-apple-system,"helvetica neue";font-s= +ize:1rem;font-style:normal;font-weight:400;letter-spacing:normal;text-inden= +t:0px;text-transform:none;white-space:normal;word-spacing:1px;text-decorati= +on:none;background-color:rgba(0,0,0,0);border-color:rgb(49,49,49);color:rgb= +(49,49,49)">For further clarification, I'm suggesting that we enforce m= +igration of unspent funds in p2pkh addresses because they are already secur= +ed by hashes which are currently conjectured to remain safe against a quant= +um 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 neue"= +;font-size:16px;font-style:normal;font-weight:400;letter-spacing:normal;tex= +t-indent:0px;text-transform:none;white-space:normal;word-spacing:1px;text-d= +ecoration:none;background-color:rgba(0,0,0,0);border-color:rgb(49,49,49);co= +lor: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-wei= +ght:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-spa= +ce: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)">If your idea is to simp= +ly lock down and confiscate any pre-pq safe funds, I resolutely disagree wi= +th that decision and I am fairly confident that consensus will fail to mate= +rialize around that. What I'm suggesting however is that your idea is r= +ealistic and sound if we assume the existence of some mechanism that allows= + rightful owners of pre-pq funds the opportunity to do nothing except migra= +te to safe addresses which then resolves the issue.</div><div dir=3D"auto" = +style=3D"font-family:-apple-system,"helvetica neue";font-size:1re= +m;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;t= +ext-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></div><div><div class=3D"gmail_quote gmail_quote_container">= +<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 19, 2025 at 1:07=E2=80=AF= +PM Agustin Cruz <<a href=3D"mailto:agustin.cruz@gmail.com">agustin.cruz@= +gmail.com</a>> wrote:<br></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"auto"><p d= +ir=3D"ltr">Hi Dustin,</p><p dir=3D"ltr">I remain convinced that a forced mi= +gration mechanism=E2=80=94with a clear block height deadline after which qu= +antum-unsafe funds become unspendable=E2=80=94is the more robust and secure= + 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><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><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)"><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 cl= +ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= +px 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> + +<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/CAC3UE4KZ7GajyaPT1DYfjyxAACnntqfAnoxZwc0kNV2yivDnyQ%40mail.gmail= +.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms= +gid/bitcoindev/CAC3UE4KZ7GajyaPT1DYfjyxAACnntqfAnoxZwc0kNV2yivDnyQ%40mail.g= +mail.com</a>.<br /> + +--000000000000489472062e8588d5-- + |