From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 31 Mar 2025 13:41:27 -0700 Received: from mail-yw1-f184.google.com ([209.85.128.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tzLwk-0001pC-It for bitcoindev@gnusha.org; Mon, 31 Mar 2025 13:41:27 -0700 Received: by mail-yw1-f184.google.com with SMTP id 00721157ae682-6f27dd44f86sf61929637b3.0 for ; Mon, 31 Mar 2025 13:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1743453680; x=1744058480; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=LBFclxdciIw5mNPepGDA+oPaAHFe4hiAOvAJespmXzk=; b=rLkChij6bNnU9aw/ZWPjiMS/e+Uz1SJ3dWTP3jRUMzN6hIn9iga93h450xqKm02T3g Pd45OkaY5hD31PsBbqApc31gvj9UlYorfYhaFZTwHFk7xxJcDwPpZsb1lQ3TZzKoIP17 Tkt17MuS0GvcLzfRzNsryHWtQs5IBup25YQ+hSXj0J0jkPv3hSQto6jUJ2LkbZ8zukR9 hPyYyBPwXoGJnUgsknznXmGL6tPIkgpBA5W06leNUxLBtVGYDB+5UE39agPnD/5GipcH kdJrQVf7rnr7XPm0h596jNlH1mS3DrIdyHcSLrixnksTu+hY2ydRcB6ijHTapGezjTqc okKg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743453680; x=1744058480; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence: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=LBFclxdciIw5mNPepGDA+oPaAHFe4hiAOvAJespmXzk=; b=f+MxU71vK9EY0D2IfQLTfQ0/9AqxcQeQAGxcsrEq6aiPYJIC8bffRLO4GZrjuFrL/o i2JKM914PxXfdbtF5XOWqfmpaa/eWxl4JZBgPi4/k2ij9E/Y+oJiuqj5leUV64yYDkJf 7wSoxXVyfsuPNrepP4emmTP0IwzvL0OdEm/RLKVSePo3gQbzeTlUF13krvYyo0wHEAiK sNN9bbUzDH4mc8X6JFS36zUTtYw+czBaMpNu+HSUI5LOMZiA8y9346WRPTmKKqyqxPNN ILYLMW3v+n6vgvLd5GFbZ+b8rFSPbE3I4x0MGHPb2jLa6f7k+iTu5PPP0UOzeyFWBfFC OM/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743453680; x=1744058480; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=LBFclxdciIw5mNPepGDA+oPaAHFe4hiAOvAJespmXzk=; b=wVib0wQBWxr4uR+7MVRpI9DwupMSi21jMYmF9xVX3jV47E/ZoYVIE+A/ZZUbZJM9L4 enJ/tX5ISjIEAC+f/rdB8K2iMrcL72looWKbMrNO5yHCFbLAvOSQ5VOlXxuYR3W+z9pC STX76/4nB775xoz8EJ3nh0wYWsf0t6x7pGieDAKrP9z0zCa88QqaqJK/p1/uXhMwKNp3 9lJv7TI9DnoTRhIUpOsvPHX342HrOsuoPdOZj7HVA1yc62KWHKCfh5KGH0EpHcZyieE5 IAVGm+FekGnpxrVb7D466rlx3kh/vu9FeoQD4vuiFnqjkE5zKE40j36qcvPYtB+bnXPy 90vg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUJNkmoYohHcrSQst/ompmfxSsJPaBClq8x7RghIHPUK4i5L+PRQvzZsort9CuSdH3QFokkBrT78zqp@gnusha.org X-Gm-Message-State: AOJu0YxmviZUSIgxglbAyq9PBfQIVgegIQTRiLneGYKzZ/OSkTWSnaVA OdZ/5RluhEiN7bS5eJktJwz1yV1bGCyIuHjiLpdnCEKEbzWTPDHk X-Google-Smtp-Source: AGHT+IHnpO0H1HkiI4bi+lPKIr3naOZ1WetHTAIpwJIuW4Z0b9EYMlcpP89OVTfOL6wc9RL13fyiLw== X-Received: by 2002:a05:6902:a06:b0:e58:3209:bdb6 with SMTP id 3f1490d57ef6-e6b839118aamr12874412276.16.1743453680306; Mon, 31 Mar 2025 13:41:20 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPALT2n3znXYvoWSExTSq+yxgGDsTJIW2h9W65I5D3c58zw== Received: by 2002:a25:e093:0:b0:e60:8883:5aa4 with SMTP id 3f1490d57ef6-e6942e6122dls887117276.2.-pod-prod-03-us; Mon, 31 Mar 2025 13:41:16 -0700 (PDT) X-Received: by 2002:a05:690c:4d4a:b0:6fb:a696:b23b with SMTP id 00721157ae682-70257303fe6mr144806417b3.33.1743453676363; Mon, 31 Mar 2025 13:41:16 -0700 (PDT) Received: by 2002:a05:690c:9a05:b0:6ef:590d:3213 with SMTP id 00721157ae682-70210946374ms7b3; Sun, 30 Mar 2025 15:23:19 -0700 (PDT) X-Received: by 2002:a05:690c:e05:b0:6ef:4fba:8153 with SMTP id 00721157ae682-702570b7691mr109510957b3.10.1743373397660; Sun, 30 Mar 2025 15:23:17 -0700 (PDT) Date: Sun, 30 Mar 2025 15:23:17 -0700 (PDT) From: Javier Mateos To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <1c7817fa-6451-4256-b8ce-ddca45abbf52@mattcorallo.com> References: <43afd5bb-244e-4698-ba3d-139efa2c2058@mattcorallo.com> <912fd35e-02f5-49b5-b373-ca02806d952f@mattcorallo.com> <27A7048A-88D3-432A-AD7C-07C5EC60942D@sprovoost.nl> <1c7817fa-6451-4256-b8ce-ddca45abbf52@mattcorallo.com> Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_311564_1539963294.1743373397353" X-Original-Sender: javierpmateos@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_311564_1539963294.1743373397353 Content-Type: multipart/alternative; boundary="----=_Part_311565_1664180558.1743373397353" ------=_Part_311565_1664180558.1743373397353 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone! Seeing the discussions about transitioning to quantum-resistant signatures,= =20 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 stabi= lity or=20 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 a= ddresses=20 starting now. =F0=9F=94=B9 Then, before the quantum threat becomes real, introduce a soft= fork that=20 disables vulnerable signatures, but with a long migration period (at least= =20 four years). =F0=9F=94=B9 Finally, when the threat is imminent, gradually phase out old = signatures=20 instead of forcing a sudden change. For this to work, adoption should be incentivized=E2=80=94for example, with= 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, but= =20 about providing options for an orderly transition that doesn=E2=80=99t comp= romise=20 Bitcoin=E2=80=99s philosophy. -Javier Mateos El viernes, 28 de marzo de 2025 a las 21:02:43 UTC-3, Matt Corallo escribi= =C3=B3: > > > On 3/25/25 4:16 AM, Sjors Provoost wrote: > > Matt Corallo wrote: > >=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 withou= t=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. > >>>> > >>>> > >> A NUMS point does not suffice unless we explicitly soft-fork out=20 > spending from that NUMS point (which is, of course, doable). > >=20 > > This could be a solution to the sequencing conundrum that I tried to=20 > explain. > >=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 > > That way people can start using the scheme without having to worry abou= t=20 > whether the community decides to freeze key path spending in time. They'l= l=20 > still worry about the market value of their coins, but not about whether= =20 > they're going to be the first victim (or the umpteenth victim while=20 > everyone is in denial and blames them for poor key management). > > > Mmm, yea, fair enough, that seems perfectly reasonable to include. > > Matt > --=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/= fe4acdff-67ba-4fc6-8844-92d3bd7ca402n%40googlegroups.com. ------=_Part_311565_1664180558.1743373397353 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi everyone!

Seeing the discussions about transitioning to quantum= -resistant signatures, I notice three main concerns:

  • What sho= uld be done with vulnerable funds? Freeze them or leave them exposed?

  • How can the transition be made without affecting Bitcoin=E2=80=99= s stability or dividing the community?

  • How can we avoid mark= et chaos if the transition is disorderly?

Personally, I bel= ieve the key is a gradual, well-planned transition based on incentives rath= er than abrupt changes that create uncertainty.

I can think of a thre= e-phase approach:

=F0=9F=94=B9 First, allow users to add optional PQC= keys to their Taproot addresses starting now.
=F0=9F=94=B9 Then, befo= re the quantum threat becomes real, introduce a soft fork that disables vul= nerable signatures, but with a long migration period (at least four years).=
=F0=9F=94=B9 Finally, when the threat is imminent, gradually phase ou= t old signatures instead of forcing a sudden change.

For this to work= , adoption should be incentivized=E2=80=94for example, with lower fees for = secure transactions and wallet tools that facilitate a smooth transition. A= dditionally, real-time monitoring of vulnerable addresses would help mitiga= te risks.

Another key point is to avoid panic. Instead of a sudden "D= -Day" where everything changes at once, the deactivation of old UTXOs shoul= d be gradual, with clear communication so no one feels forced or disadvanta= ged.

In summary, this is not about imposing rules or confiscating any= thing, but about providing options for an orderly transition that doesn=E2= =80=99t compromise Bitcoin=E2=80=99s philosophy.

-Javier Mateos

El vi= ernes, 28 de marzo de 2025 a las 21:02:43 UTC-3, Matt Corallo escribi=C3=B3= :


On 3/25/25 4:16 AM, Sjors Provoost wrote:
> Matt Corallo wrote:
>=20
>>> In that scenario you'd need to use a NUMS point for th= e key path. Or maybe that's unsafe, in which case we'd need a new T= aproot version without key path support (or BIP360). That's also not a = difficult soft fork, but now again you have something that only a small set= of users will want to use.
>>>>
>>>>
>> A NUMS point does not suffice unless we explicitly soft-fork o= ut spending from that NUMS point (which is, of course, doable).
>=20
> This could be a solution to the sequencing conundrum that I tried = to explain.
>=20
> 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's not confisc= atory.
>=20
> 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'll still worry about the market value of their coins, but not about= whether they're going to be the first victim (or the umpteenth victim = while everyone is in denial and blames them for poor key management).


Mmm, yea, fair enough, that seems perfectly reasonable to include.

Matt

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/fe4acdff-67ba-4fc6-8844-92d3bd7ca402n%40googlegroups.com.
------=_Part_311565_1664180558.1743373397353-- ------=_Part_311564_1539963294.1743373397353--