path: root/24/37cd886c157daa17c2aeb076cca56379d5fcb7

Delivery-date: Mon, 07 Apr 2025 03:31:59 -0700
Received: from mail-yb1-f191.google.com ([209.85.219.191])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCSPDK6B2UIBBFGTZ27QMGQEEFQFBCA@googlegroups.com>)
	id 1u1jlm-00076E-6j
	for bitcoindev@gnusha.org; Mon, 07 Apr 2025 03:31:59 -0700
Received: by mail-yb1-f191.google.com with SMTP id 3f1490d57ef6-e02fff66a83sf5024797276.0
        for <bitcoindev@gnusha.org>; Mon, 07 Apr 2025 03:31:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1744021912; x=1744626712; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:x-original-sender
         :mime-version:subject:references:in-reply-to:message-id:to:from:date
         :from:to:cc:subject:date:message-id:reply-to;
        bh=hX5fDU2VannuaKx9OBIGzJ/K0y32Q51EIcvsoP/9CZ8=;
        b=UJOsyo2X9osFRSxlIXuFUbVxNJAajKqEQpK/fY2JVw4jcU90uo9f7/cZ/xO2in3KvW
         Ki4nOYXxVwBa38xqVMjafTq3AEvgFNsSk6FbyQrkCFXIG4mBSBAE6aSt+IPdES70uLps
         bovZj5yoAISdvMdhIWcU3mMQBTzEtdtf89gOeX4ibsFiQCLtc3wL8xhS9fiutbM2TEvU
         DAG8M+mKCRCOU0A7PCyislboldEW6BbB/NWIQ+1wHRvjfL6JAsRZ+U+GFmrYap46Z9jB
         SPw9ba9xF3vM3tuE/qKD5R1h8IQP1IfAYc7KsIDLbveOow5+vpznXAmaeXCaYpddsCA6
         k3DQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1744021912; x=1744626712;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:x-original-sender
         :mime-version:subject:references:in-reply-to:message-id:to:from:date
         :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=hX5fDU2VannuaKx9OBIGzJ/K0y32Q51EIcvsoP/9CZ8=;
        b=NnRkDkD1p7KG/ZwUicKJ4QwCnrOH8mP21sIE1MnOs5v6lnVbvANMBO8ihy1luU2UEI
         mI3yhjFK1OiUfLtGsPC+Gk4omymRT1C7ZCrTTerWeXR3qK7M731zWsYyJy9Gp/pNhnKE
         mL+q5L0PBJRYMXOB2AHhgMCly/Uc77EVKZCKfxVZatqyd/+J1JlP4LvSrQy92NR7aIDv
         2RqI/yPQlPIrBwubJeVUs0keF1cfrJmM/0WsNonZdgsvVZtgqhCfcKF8OgOn7U/vt40z
         /rK3Uwt7LkokrYOBoP9FRSPvdLdSAfk874bNJF07Mnxs6Nd/7Ud9RsyoSJr+FvCwJczc
         Rydw==
X-Forwarded-Encrypted: i=1; AJvYcCXCqBhqSVvTky9tDHx3tDJ0/C87Q9dOoJ39WzRGnv48Veeh9pMpzSCSUWwcipuZ2+o3FOi9I7XE5epN@gnusha.org
X-Gm-Message-State: AOJu0Yw9eEjveVij3vIg+JnJVzwcwrF/GRIXWEAldNtcaq6foJrofc3s
	CgOdewZ7r/xpOieOSPDsHZ9U59013zp+hdpUGV4W6HXQAFKajVCi
X-Google-Smtp-Source: AGHT+IH8cXAscdheZ5u/bHYbqyVE8OEjRxDHTKgoiE2SnUcKG9uh8Q3aSyePCN3y+xYUR9f5B+3xUg==
X-Received: by 2002:a05:6902:278a:b0:e60:87a0:61fd with SMTP id 3f1490d57ef6-e6e316eb453mr12929048276.6.1744021911819;
        Mon, 07 Apr 2025 03:31:51 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAJS1bK2WRLGFX0THs0nA0mn/X6KoW/ZBH1+m8/l4x47jQ==
Received: by 2002:a25:aaa4:0:b0:e60:8883:5aa4 with SMTP id 3f1490d57ef6-e6e07a8e627ls823420276.2.-pod-prod-03-us;
 Mon, 07 Apr 2025 03:31:48 -0700 (PDT)
X-Received: by 2002:a05:690c:350d:b0:703:b47a:72db with SMTP id 00721157ae682-703f417e379mr164495277b3.15.1744021908194;
        Mon, 07 Apr 2025 03:31:48 -0700 (PDT)
Received: by 2002:a05:690c:b83:b0:6ef:590d:3213 with SMTP id 00721157ae682-703b7fe7b78ms7b3;
        Thu, 3 Apr 2025 21:49:29 -0700 (PDT)
X-Received: by 2002:a05:690c:60c7:b0:6d4:4a0c:fcf0 with SMTP id 00721157ae682-703e1589ef8mr32753497b3.20.1743742168710;
        Thu, 03 Apr 2025 21:49:28 -0700 (PDT)
Date: Thu, 3 Apr 2025 21:49:28 -0700 (PDT)
From: "'Ben Sigman' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <50193bed-7134-4b4a-9c15-12c5dd559ad7n@googlegroups.com>
In-Reply-To: <fe4acdff-67ba-4fc6-8844-92d3bd7ca402n@googlegroups.com>
References: <CADL_X_cF=UKVa7CitXReMq8nA_4RadCF==kU4YG+0GYN97P6hQ@mail.gmail.com>
 <43afd5bb-244e-4698-ba3d-139efa2c2058@mattcorallo.com>
 <ED96C777-5BBD-4ACE-8821-A53FDE8FA128@sprovoost.nl>
 <912fd35e-02f5-49b5-b373-ca02806d952f@mattcorallo.com>
 <27A7048A-88D3-432A-AD7C-07C5EC60942D@sprovoost.nl>
 <1c7817fa-6451-4256-b8ce-ddca45abbf52@mattcorallo.com>
 <fe4acdff-67ba-4fc6-8844-92d3bd7ca402n@googlegroups.com>
Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_260874_1871148358.1743742168402"
X-Original-Sender: ben@bigbitcoinbook.com
X-Original-From: Ben Sigman <ben@bigbitcoinbook.com>
Reply-To: Ben Sigman <ben@bigbitcoinbook.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: -1.0 (-)

------=_Part_260874_1871148358.1743742168402
Content-Type: multipart/alternative; 
	boundary="----=_Part_260875_777449492.1743742168402"

------=_Part_260875_777449492.1743742168402
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Considering the information presented by Jameson, it's difficult to see a=
=20
solution to the quantum attack question other than some form of freeze.=20

Murch=E2=80=99s idea of a rolling timeout sounds elegant from one perspecti=
ve, but=20
also more difficult to calculate or understand for an average user. The=20
quantum doomsday clock is simpler - albeit, there would be a bidding war=E2=
=80=A6

That being said, the first step seems to be that Bitcoin needs a path to=20
having post-quantum signatures / addresses as an option.=20

I=E2=80=99d advocate that the developer community focus resources on implem=
enting a=20
path forward with at least some version of this - either BIP 360 or some=20
form of Taproot PQC.

On Monday, March 31, 2025 at 1:41:20=E2=80=AFPM UTC-7 Javier Mateos wrote:

> Hi everyone!
>
> Seeing the discussions about transitioning to quantum-resistant=20
> signatures, I notice three main concerns:
>
>    -=20
>   =20
>    What should be done with vulnerable funds? Freeze them or leave them=
=20
>    exposed?
>    -=20
>   =20
>    How can the transition be made without affecting Bitcoin=E2=80=99s sta=
bility=20
>    or dividing the community?
>    -=20
>   =20
>    How can we avoid market chaos if the transition is disorderly?
>   =20
> Personally, I believe the key is a gradual, well-planned transition based=
=20
> on incentives rather than abrupt changes that create uncertainty.
>
> I can think of a three-phase approach:
>
> =F0=9F=94=B9 First, allow users to add optional PQC keys to their Taproot=
 addresses=20
> starting now.
> =F0=9F=94=B9 Then, before the quantum threat becomes real, introduce a so=
ft fork=20
> that disables vulnerable signatures, but with a long migration period (at=
=20
> least four years).
> =F0=9F=94=B9 Finally, when the threat is imminent, gradually phase out ol=
d=20
> signatures instead of forcing a sudden change.
>
> For this to work, adoption should be incentivized=E2=80=94for example, wi=
th lower=20
> fees for secure transactions and wallet tools that facilitate a smooth=20
> transition. Additionally, real-time monitoring of vulnerable addresses=20
> would help mitigate risks.
>
> Another key point is to avoid panic. Instead of a sudden "D-Day" where=20
> everything changes at once, the deactivation of old UTXOs should be=20
> gradual, with clear communication so no one feels forced or disadvantaged=
.
>
> In summary, this is not about imposing rules or confiscating anything, bu=
t=20
> about providing options for an orderly transition that doesn=E2=80=99t co=
mpromise=20
> Bitcoin=E2=80=99s philosophy.
>
> -Javier Mateos
>
> El viernes, 28 de marzo de 2025 a las 21:02:43 UTC-3, Matt Corallo=20
> escribi=C3=B3:
>
>>
>>
>> On 3/25/25 4:16 AM, Sjors Provoost wrote:=20
>> > Matt Corallo wrote:=20
>> >=20
>> >>> In that scenario you'd need to use a NUMS point for the key path. Or=
=20
>> maybe that's unsafe, in which case we'd need a new Taproot version witho=
ut=20
>> key path support (or BIP360). That's also not a difficult soft fork, but=
=20
>> now again you have something that only a small set of users will want to=
=20
>> use.=20
>> >>>>=20
>> >>>>=20
>> >> A NUMS point does not suffice unless we explicitly soft-fork out=20
>> spending from that NUMS point (which is, of course, doable).=20
>> >=20
>> > This could be a solution to the sequencing conundrum that I tried to=
=20
>> explain.=20
>> >=20
>> > Along with the first PCQ scheme for tapscript (script path), we could=
=20
>> have a soft that disables one or more NUMS points. The latter has zero=
=20
>> effect under the current cryptographic assumptions, so it's not=20
>> confiscatory.=20
>> >=20
>> > That way people can start using the scheme without having to worry=20
>> about whether the community decides to freeze key path spending in time.=
=20
>> They'll still worry about the market value of their coins, but not about=
=20
>> whether they're going to be the first victim (or the umpteenth victim wh=
ile=20
>> everyone is in denial and blames them for poor key management).=20
>>
>>
>> Mmm, yea, fair enough, that seems perfectly reasonable to include.=20
>>
>> Matt=20
>>
>

--=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/=
50193bed-7134-4b4a-9c15-12c5dd559ad7n%40googlegroups.com.

------=_Part_260875_777449492.1743742168402
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto" style=3D"font-family: -apple-system, &quot;helvetica neue=
&quot;; font-size: 16px; word-spacing: 1px; background-color: rgba(0, 0, 0,=
 0); border-color: rgb(49, 49, 49); color: rgb(49, 49, 49);">Considering th=
e information presented by Jameson, it's difficult to see a solution to the=
 quantum attack question other than some form of freeze. <br /><br />Murch=
=E2=80=99s idea of a rolling timeout sounds elegant from one perspective, b=
ut also more difficult to calculate or understand for an average user. The =
quantum doomsday clock is simpler - albeit, there would be a bidding war=E2=
=80=A6<br /><br />That being said, the first step seems to be that Bitcoin =
needs a path to having post-quantum signatures / addresses as an option. <b=
r /><br />I=E2=80=99d advocate that the developer community focus resources=
 on implementing a path forward with at least some version of this - either=
 BIP 360 or some form of Taproot PQC.<br /></div><br /><div class=3D"gmail_=
quote"><div dir=3D"auto" class=3D"gmail_attr">On Monday, March 31, 2025 at =
1:41:20=E2=80=AFPM UTC-7 Javier Mateos wrote:<br/></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(2=
04, 204, 204); padding-left: 1ex;"><p>Hi everyone!</p><p>Seeing the discuss=
ions about transitioning to quantum-resistant signatures, I notice three ma=
in concerns:</p><ul><li><p>What should be done with vulnerable funds? Freez=
e them or leave them exposed?</p></li><li><p>How can the transition be made=
 without affecting Bitcoin=E2=80=99s stability or dividing the community?</=
p></li><li><p>How can we avoid market chaos if the transition is disorderly=
?</p></li></ul><p>Personally, I believe the key is a gradual, well-planned =
transition based on incentives rather than abrupt changes that create uncer=
tainty.</p><p>I can think of a three-phase approach:</p><p>=F0=9F=94=B9 Fir=
st, allow users to add optional PQC keys to their Taproot addresses startin=
g now.<br>=F0=9F=94=B9 Then, before the quantum threat becomes real, introd=
uce a soft fork that disables vulnerable signatures, but with a long migrat=
ion period (at least four years).<br>=F0=9F=94=B9 Finally, when the threat =
is imminent, gradually phase out old signatures instead of forcing a sudden=
 change.</p><p>For this to work, adoption should be incentivized=E2=80=94fo=
r example, with lower fees for secure transactions and wallet tools that fa=
cilitate a smooth transition. Additionally, real-time monitoring of vulnera=
ble addresses would help mitigate risks.</p><p>Another key point is to avoi=
d panic. Instead of a sudden &quot;D-Day&quot; where everything changes at =
once, the deactivation of old UTXOs should be gradual, with clear communica=
tion so no one feels forced or disadvantaged.</p><p>In summary, this is not=
 about imposing rules or confiscating anything, but about providing options=
 for an orderly transition that doesn=E2=80=99t compromise Bitcoin=E2=80=99=
s philosophy.</p><p>-Javier Mateos</p><br><div class=3D"gmail_quote"><div d=
ir=3D"auto" class=3D"gmail_attr">El viernes, 28 de marzo de 2025 a las 21:0=
2:43 UTC-3, Matt Corallo escribi=C3=B3:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">
<br>
<br>On 3/25/25 4:16 AM, Sjors Provoost wrote:
<br>&gt; Matt Corallo wrote:
<br>&gt;=20
<br>&gt;&gt;&gt; In that scenario you&#39;d need to use a NUMS point for th=
e key path. Or maybe that&#39;s unsafe, in which case we&#39;d need a new T=
aproot version without key path support (or BIP360). That&#39;s also not a =
difficult soft fork, but now again you have something that only a small set=
 of users will want to use.
<br>&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt;
<br>&gt;&gt; A NUMS point does not suffice unless we explicitly soft-fork o=
ut spending from that NUMS point (which is, of course, doable).
<br>&gt;=20
<br>&gt; This could be a solution to the sequencing conundrum that I tried =
to explain.
<br>&gt;=20
<br>&gt; Along with the first PCQ scheme for tapscript (script path), we co=
uld have a soft that disables one or more NUMS points. The latter has zero =
effect under the current cryptographic assumptions, so it&#39;s not confisc=
atory.
<br>&gt;=20
<br>&gt; That way people can start using the scheme without having to worry=
 about whether the community decides to freeze key path spending in time. T=
hey&#39;ll still worry about the market value of their coins, but not about=
 whether they&#39;re going to be the first victim (or the umpteenth victim =
while everyone is in denial and blames them for poor key management).
<br>
<br>
<br>Mmm, yea, fair enough, that seems perfectly reasonable to include.
<br>
<br>Matt
<br></blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; 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/50193bed-7134-4b4a-9c15-12c5dd559ad7n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/50193bed-7134-4b4a-9c15-12c5dd559ad7n%40googlegroups.com</a>.<br />

------=_Part_260875_777449492.1743742168402--

------=_Part_260874_1871148358.1743742168402--