Delivery-date: Mon, 07 Apr 2025 03:31:59 -0700
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"
Reply-To: Ben Sigman <ben@bigbitcoinbook.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_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--