path: root/a6/8f546c888d5fc51f256e7b1b19c6200530ca10

Delivery-date: Sun, 20 Jul 2025 09:06:51 -0700
Received: from mail-oa1-f56.google.com ([209.85.160.56])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCL7RHHJZYJBBENI6TBQMGQEAMFBPUA@googlegroups.com>)
	id 1udWYs-0007i8-GF
	for bitcoindev@gnusha.org; Sun, 20 Jul 2025 09:06:51 -0700
Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-2ffa5b5f321sf2522514fac.0
        for <bitcoindev@gnusha.org>; Sun, 20 Jul 2025 09:06:50 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1753027604; cv=pass;
        d=google.com; s=arc-20240605;
        b=Wgmo5cntgG+KegEMMIQYq6Pb4B0bdRSqUAfdJ2vd0ZFx/nbHtDpkzIj9Y6R9ENiJJP
         Awd0ZNe7pl6+EiAE/zveguWOzvLWAqHayNhtTzSekuVIMjqxZU6g0I8LLTx24068Me6p
         CmNTKxJH3nqMheFc3gQfQc73e/kFDDNOsvvMwSw8AKliiU50/LiT53QmGRz0kCtQFbP9
         OJMNlcGKTlUpCWixY5d6WD5j6ZXS5Pb9A/685IaqjrlJi/f5/5uR9aCv5wK9S/Ub4cxq
         znWn4UXGIguavm7j5zJSDnP7O1Wb4wAl5AEDqerDr5jp4f5K1MxJVPI3boLKOKOnQv3z
         0NEA==
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:reply-to:mime-version:feedback-id
         :references:in-reply-to:message-id:subject:cc:from:to:date
         :dkim-signature;
        bh=FBwcEOoZzlZESe88D8QQKv2yIMXFRCvRB+/sN3FbGKk=;
        fh=NJ8izJBy1uzTzi0xOZt0lcLIO5XV6IrPqC6X76zuxpw=;
        b=ZacRslyjlKiz1IiFRNCXScCXFVuuYeO2Sas7+9Cfni/YcLL+JWG8wqFBLPuuhIyXW0
         B0o+I/lDvrCilF3F7bQrFco8pMWO9lfhDvCSiDI2OYZ/3ZQl2sDvaRrb1p+BoJyN/LFJ
         61Tw0SK04/Cr9/3LRnCFZBetIp2FyDA6y8JEYmKtXsTxjCL1cFpNEiRwLJDUVvwJ0lvF
         PjFVsoGxSkMk2yL0a3zRxY0uoS/d8g/kAklNS65ecWRjWKWKqD6s7Rtmp74sm1KszQvM
         xVdorwJdQZLDMSKN383is5v8X/Bv+mIQbkx10mUpm75tvxtjT1U5mvyqfEngN1PkwlMc
         Abzg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@proton.me header.s=protonmail header.b=IClwIPer;
       spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.28 as permitted sender) smtp.mailfrom=conduition@proton.me;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1753027604; x=1753632404; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=FBwcEOoZzlZESe88D8QQKv2yIMXFRCvRB+/sN3FbGKk=;
        b=qKPTyRbNjDzN116HnACASdnU+K/3kcXwB9vUu9bIGAKKQ63gtdusxY9SCvu7s/AVp6
         Eg894beB++vZortClRN/oX/43CM4phMv8kQG3m4VHRlC8op5A/GX1TYvLdEyx70mp5jQ
         zqaFsZljmvjO3WvvKTKJFmD6zlO2slzwpDYl5t9ilgPnYVZwL0gOpJY47x+sOXdhPiRl
         X7WSR/Nf5Hk3OggKh7PmdRO9ux1SCb1fF7rQHHW/q3Tpsw6OV10hTzqjjw6TNN4csna6
         DgkMsQ3eLmhtodonev+3g7Ey1oct3FcrEpI+TDUsiQ+jLgDoVQWjzxRCm4TBdsn0kRk+
         BkHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1753027604; x=1753632404;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=FBwcEOoZzlZESe88D8QQKv2yIMXFRCvRB+/sN3FbGKk=;
        b=VmyQJzrFSWq/9hjPdTtBUwurlLgV6crUQnYJ7oC3yNA2Zaowi0PN9F2G25mL9uYkJ+
         6lEEVbTV98FhpxSTpXHn2aa+9ojubMnKsiQHA5J0/OHWmnc3iQdSCDVOXaiFoWghsUgX
         7nr0jsykqeS1y1Bj7zfdY70lENJszsUtrmds9rPilMbKCQhxF55UtvijfeNgAJsNBt/2
         SCe5kczAKeckb3xIRE8zK5fwUsd5GeV7MPcee4EfOkWSPDbuXc4zF0S2j93ZZL6bgjOf
         7G7O1i41P5wLRWy70SDmfR00lt+SeAcxnQnaZ68HKt332F24cMlES5oCm/hwta6xrIwI
         Z7pw==
X-Forwarded-Encrypted: i=2; AJvYcCU9vjAE3MK7LoaBsmCYlR6Ke3/7cz7KQvlWVZhDtez9saaAHHjcqplG5kWlRG9cxbIsCl5QIJKLwwpk@gnusha.org
X-Gm-Message-State: AOJu0YyXVy63twe27C7FOJW2rZbc0R3xDIuiy2EU61d4ZD9wla0fS42y
	1S9ajsKfFQ25y2kb0z0bbfyak4Uc+tL3lIPNaoTF3Oc4DL+PmIA3sctQ
X-Google-Smtp-Source: AGHT+IEudZPatZsq2m+Yu6JdNkX9vZvaAOAS25LzlAWsqy/MNfHqtNEEMPqwwg/Enpr7DtSrJGMl8Q==
X-Received: by 2002:a05:6871:5a11:b0:2b8:78c0:2592 with SMTP id 586e51a60fabf-2ffb244a887mr11106308fac.23.1753027604247;
        Sun, 20 Jul 2025 09:06:44 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfCoOaqA59ZhWQDAwfxU4R2lYNbiSesDBqqVohgtzWwQA==
Received: by 2002:a05:6870:6c02:b0:2ff:8cb6:b720 with SMTP id
 586e51a60fabf-2ffca3d2a0als2607183fac.0.-pod-prod-05-us; Sun, 20 Jul 2025
 09:06:41 -0700 (PDT)
X-Received: by 2002:a05:6808:4494:b0:40b:441e:3a5f with SMTP id 5614622812f47-41d04d8a574mr10759582b6e.25.1753027600943;
        Sun, 20 Jul 2025 09:06:40 -0700 (PDT)
Received: by 2002:a05:600c:a297:b0:456:53b:5b5e with SMTP id 5b1f17b1804b1-4563a8f4e6bms5e9;
        Sun, 20 Jul 2025 08:37:15 -0700 (PDT)
X-Received: by 2002:a05:600c:4ecd:b0:456:fdd:6030 with SMTP id 5b1f17b1804b1-4562e373d83mr169117575e9.19.1753025833353;
        Sun, 20 Jul 2025 08:37:13 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1753025833; cv=none;
        d=google.com; s=arc-20240605;
        b=axvRZuavpz9JUbHJurlHHfz6WviriyyuTic+bgvsesVOB6hAmh69fIuFoXpBPTi9KM
         3zeqsbiN2jPC+tIb92RpT7/jV7VT8fguzmGTF8uMTNVhOY2/xZAda27KTyCXkqGfTwIw
         p4MG0SM95Iur0PGlpa0+6xa3Lo5orVVC9Ch/klpUai0MjrS8bRju1+Qgv68lw4JfpSmb
         tikK+rNDpZtqZ9tMUin8Tab+rqEwgUDwW0nGgLZb+HDWmpoajwy7s0+eChzmJ09pNmMV
         493nAOJYAel777TJSOddx9iRC6EfP95cIngtu9iOisW+SG+cvffnCuVuFLPnANVALhgK
         9sew==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=XLqfEydL5ZVSvd/+viPzp1ID829BUL+VDX/EMOZJdiQ=;
        fh=6b1pLcW6tcZ6I7AhOCDpUTdU/HBZRb+DjIxd1ga4+Sc=;
        b=TwONmaFD46hQDB0KYGsWgmFgUFdfKiO/rkAWOzKKmy4XTV7H5Glyi2pYtP86j2y2qn
         e0s3YA8fjnkec/eAR7xFVtMdAbIr/B+BXkRbdRq0nZ/RHot1LO/gQRWpVH30puic6EeD
         jhB6hdD+Q8ZNxKIbzv03HUDfPzm9+IBvF4xFntRQRryL0RMOmPZ1LeYXSqC/2tZDHumo
         +3DevGyWZqd14LpkPEzcGF9+ZiMUDz9+/dem10Uk7UbyXTD4nZuHIWH8h4yuZDVkEVPa
         fz85j1vgBJs4c8fd5nKSUloL/HI5Ee+zbF6im0katZpZnLQM7MeBcYUHoFlSBMVk/fTW
         u63g==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@proton.me header.s=protonmail header.b=IClwIPer;
       spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.28 as permitted sender) smtp.mailfrom=conduition@proton.me;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch. [79.135.106.28])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-45627899918si4009795e9.1.2025.07.20.08.37.13
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sun, 20 Jul 2025 08:37:13 -0700 (PDT)
Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.28 as permitted sender) client-ip=79.135.106.28;
Date: Sun, 20 Jul 2025 15:37:05 +0000
To: Boris Nagaev <bnagaev@gmail.com>
From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A Post Quantum Migration Proposal
Message-ID: <a9xGMAv-oogmIdFuXMuXcgn_dkcCrIX9UNjXA-UuTqKrp6Tn8n6Q6usj33q66tr9SVP_jRpzeeq7Bw9wgcwCXsv2H5QTA1WL_JKvPH0eFdU=@proton.me>
In-Reply-To: <02f2130c-c024-40ce-8623-c09ceb090619n@googlegroups.com>
References: <CADL_X_fpv-aXBxX+eJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q@mail.gmail.com> <W2O6Al4bdVzx1EkszgN5dhtSUD0GwRgwYcRSWlQzfsvZE0UN5f6HBGXB2zorkGOpdsbDAS_X6xcsrH6zBIeYbPY8MM_sPfeN9Wblts5Gcog=@proton.me> <88a7b020-e84f-4052-9716-fb40b23f07ddn@googlegroups.com> <gSvbx255CIbMSivfsn-1cGECh7UpJufvfVP4lwnp5r7gIamZo9t5LdBZBEYyiw4Eb9zNSvLXoi2SW8Sq3i7shSwBkWwxLRjoPkncexfCPRM=@proton.me> <02f2130c-c024-40ce-8623-c09ceb090619n@googlegroups.com>
Feedback-ID: 72003692:user:proton
X-Pm-Message-ID: 9287953f8bb0294bb187ab3492ce485972df5024
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------9ac74a0ec5295f78b5947e7333939603053aecebf35b3bb386e7f3c7129cdb08"; charset=utf-8
X-Original-Sender: conduition@proton.me
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@proton.me header.s=protonmail header.b=IClwIPer;       spf=pass
 (google.com: domain of conduition@proton.me designates 79.135.106.28 as
 permitted sender) smtp.mailfrom=conduition@proton.me;       dmarc=pass
 (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
X-Original-From: conduition <conduition@proton.me>
Reply-To: conduition <conduition@proton.me>
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 (-)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------9ac74a0ec5295f78b5947e7333939603053aecebf35b3bb386e7f3c7129cdb08
Content-Type: multipart/mixed;boundary=---------------------483d638301960e48d863ca115c276842

-----------------------483d638301960e48d863ca115c276842
Content-Type: multipart/alternative;boundary=---------------------e8a7cf808aa2130caf35992785a36afe

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

> Will phase C also unblock such EC-dependent P2QRH addresses? If so, they =
are equally protected as classic P2PKH -- both must wait until phase C to a=
void exposing a public key by spending too early.
@Boris Yes, this should definitely be the case. Restrictions should be base=
d on cryptographic operations needed to spend, not by output script type br=
oadly. Though in the case of P2QRH, the best case should be that everyone u=
sing P2QRH includes a leaf script that supports post-quantum opcodes, even =
if they're not fully defined yet. Then spending with PQ crypto is as easy a=
s a software update.

regards,
conduition
On Wednesday, July 16th, 2025 at 5:05 PM, Boris Nagaev <bnagaev@gmail.com> =
wrote:

> Hey Conduition and all!
>=20

> On Wednesday, July 16, 2025 at 1:48:27=E2=80=AFPM UTC-3 conduition wrote:
>=20

> > Hey Boris and list,
> >=20

> >=20

> > > What if all vulnerable coins are temporarily locked during phase B, w=
ith a clearly defined future block height X (e.g., in 5-10 years) at which =
point these coins become EC-spendable again?
> >=20

> >=20

> >=20

> > Great idea. It gives us more time to get the zk-STARK proof system for =
phase C tightened up, but we still have the option of deploying phase B ind=
ependently to protect procrastinators against a fast-arriving quantum adver=
sary, even if the STARK system isn't ready yet. If quantum progress is slow=
er (or phase C development is faster) than anticipated, we also have the op=
tion to merge the phases B and C together into a single deployment.
> >=20

> > If we do that, should we apply the same logic to phase A though, and ev=
entually permit sending to pre-quantum addresses at height X? Because as de=
scribed, once phase A is locked in, we can never again permit sending to pr=
e-quantum addresses (without a hard fork).
>=20

>=20

>=20

> If the proposal gets traction, it is better to replace permanent blocking=
 with temporary restrictions in case of both sending to and spending from v=
ulnerable addresses. That way, we leave the door open for future recovery s=
chemes without needing a hard fork.
>=20

> Note that permanently blocking sends to vulnerable addresses can also be =
confiscatory. For example, someone might have a presigned transaction, like=
 a Lightning force-close, where the destination address is a vulnerable add=
ress. If that path is blocked, the funds could be lost. If sending is tempo=
rary, the funds can be recovered later.
>=20

> If nothing is permanently blocked, and temporary blocking is intended to =
allow legitimate owners to recover their funds, this could be seen as a win=
-win. It is no longer one group trying to capture the purchasing power of a=
nother. However, I still have doubts about whether this is an ethical solut=
ion.
>=20

> I'm trying to place myself in the position of someone who can't move thei=
r funds before the deadline -- for example, a young heir with a timelocked =
inheritance. It's genuinely difficult to say what's better: risking loss to=
 a quantum adversary, or facing a temporary block with the prospect of futu=
re recovery. It really comes down to individual risk appetite and time pref=
erence. And the challenge is, we can't ask them now -- that's the nature of=
 the problem.
>=20

> > Maybe we should also talk about BIP360 P2QRH addresses and how they'd b=
e treated by these phases. As Ethan pointed out, P2QRH addresses can contai=
n EC signature spending conditions (OP_CHECKSIG). Would phase B's stricter =
rules also block EC spends from P2QRH UTXOs?
> >=20

> > If yes, and phase B restricts EC spending from P2QRH, users may acciden=
tally send money to P2QRH addresses whose leafs all require at least one EC=
 signature opcode. This locks the money up until phase C, even though the p=
urpose of phase A was to avoid exactly this from happening. Restricting P2Q=
RH EC spending also makes hybrid spending conditions, which require both EC=
 signatures and PQ signatures for extra safety, harder to implement explici=
tly in P2QRH script - We'd need dedicated EC/PQ hybrid checksig opcodes (wh=
ich is an option if we want it).
>=20

> > If no, and phase B doesn't restrict EC spending from P2QRH, then P2QRH =
UTXOs with exposed EC spending leafs will be even more vulnerable to a quan=
tum attacker than those who have exposed pubkeys in pre-quantum UTXOs: Pre-=
quantum UTXOs would have better protection, since they are temporarily lock=
ed by phase B but P2QRH UTXOs aren't.
>=20

>=20

> Will phase C also unblock such EC-dependent P2QRH addresses? If so, they =
are equally protected as classic P2PKH -- both must wait until phase C to a=
void exposing a public key by spending too early.
>=20

> > Personally i think phase B should restrict ALL EC spending across all s=
cript types, because at least then users can eventually reclaim their BTC w=
hen phase C rolls out. We can ameliorate the situation by properly standard=
izing P2QRH address derivation, providing libraries to generate addresses w=
ith ML-DSA and SLH-DSA leafs. We should recommend strongly against creating=
 P2QRH addresses without at least one post-quantum spending path.
> >=20

> > To better support hybrid spending conditions in P2QRH, we should modify=
 phase B as follows: Fail any EC checksig opcode unless at least one PQ che=
cksig opcode was executed earlier in the script. This implicitly blocks spe=
nding of pre-quantum UTXOs (until the predefined height X as Boris suggeste=
d). P2QRH addresses can explicitly define flexible hybrid signature schemes=
 in the P2QRH tree using a two-leaf construction: one leaf with just OP_CHE=
CKSIG, and one leaf with both OP_CHECKSIG and a PQ checksig opcode (such as=
 OP_MLDSACHECKSIG).
> >=20

> > To nodes who have upgraded to phase A (or earlier), funds sent to this =
address could be unlocked with the OP_CHECKSIG branch using a relatively sm=
all witness stack. On the other hand, nodes upgraded to phase B would rejec=
t the OP_CHECKSIG-only branch, because there is no PQ-checksig opcode in th=
e same script. Phase B nodes require the OP_MLDSACHECKSIG + OP_CHECKSIG bra=
nch to validate the spend. This branch needs a much larger witness stack, b=
ut would still permit a hybrid spend, covered by the combined security of S=
chnorr + Dilithium.
> >=20

> >=20

> > regards,
> > conduition
>=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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/02f2130c-c024-40ce-8623-c09ceb090619n%40googlegroups.com.

--=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/=
a9xGMAv-oogmIdFuXMuXcgn_dkcCrIX9UNjXA-UuTqKrp6Tn8n6Q6usj33q66tr9SVP_jRpzeeq=
7Bw9wgcwCXsv2H5QTA1WL_JKvPH0eFdU%3D%40proton.me.

-----------------------e8a7cf808aa2130caf35992785a36afe
Content-Type: multipart/related;boundary=---------------------a702f8253f9222a563439779dafe5b26

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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"></div><span=
>&gt; Will phase C also unblock such EC-dependent P2QRH addresses? If so, t=
hey are equally protected as classic P2PKH -- both must wait until phase C =
to avoid exposing a public key by spending too early.</span><div><br></div>=
<div><span>@Boris Yes, this should definitely be the case. Restrictions sho=
uld be based on cryptographic operations needed to spend, not by output scr=
ipt type broadly. Though in the case of P2QRH, the best case should be that=
 everyone using P2QRH includes a leaf script that supports post-quantum opc=
odes, even if they're not fully defined yet. Then spending with PQ crypto i=
s as easy as a software update.</span></div><div style=3D"font-family: Aria=
l, sans-serif; font-size: 14px;"><br></div><div style=3D"font-family: Arial=
, sans-serif; font-size: 14px;">regards,</div><div style=3D"font-family: Ar=
ial, sans-serif; font-size: 14px;">conduition</div><div class=3D"protonmail=
_quote">
        On Wednesday, July 16th, 2025 at 5:05 PM, Boris Nagaev &lt;bnagaev@=
gmail.com&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            <div>Hey Conduition and all!</div><br><div><div dir=3D"auto">On=
 Wednesday, July 16, 2025 at 1:48:27=E2=80=AFPM UTC-3 conduition wrote:<br>=
</div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px soli=
d rgb(204, 204, 204); padding-left: 1ex;"><div style=3D"font-family: Arial,=
 sans-serif; font-size: 14px;">Hey Boris and list,</div><div style=3D"font-=
family: Arial, sans-serif; font-size: 14px;"><br></div><blockquote style=3D=
"border-left: 3px solid rgb(200, 200, 200); border-color: rgb(200, 200, 200=
); padding-left: 10px; color: rgb(102, 102, 102);"><div style=3D"font-famil=
y: Arial, sans-serif; font-size: 14px;"><span>What if all vulnerable coins =
are temporarily locked during phase B, with a clearly defined future block =
height X (e.g., in 5-10 years) at which point these coins become EC-spendab=
le again?</span><br></div></blockquote><div style=3D"font-family: Arial, sa=
ns-serif; font-size: 14px;"><span><br></span></div><div style=3D"font-famil=
y: Arial, sans-serif; font-size: 14px;">Great idea. It gives us more time t=
o get the zk-STARK proof system for phase C tightened up, but we still have=
 the option of deploying phase B independently to protect procrastinators a=
gainst a fast-arriving quantum adversary, even if the STARK system isn't re=
ady yet. If quantum progress is slower (or phase C development is faster) t=
han anticipated, we also have the option to merge the phases B and C togeth=
er into a single deployment.</div><div style=3D"font-family: Arial, sans-se=
rif; font-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-ser=
if; font-size: 14px;">If we do that, should we apply the same logic to phas=
e A though, and eventually permit sending to pre-quantum addresses at heigh=
t X? Because as described, once phase A is locked in, we can never again pe=
rmit sending to pre-quantum addresses (without a hard fork).</div></blockqu=
ote><div><br></div><div><div></div><div>If the proposal gets traction, it i=
s better to replace permanent blocking with temporary restrictions in case =
of both sending to and spending from vulnerable addresses. That way, we lea=
ve the door open for future recovery schemes without needing a hard fork.<b=
r><br>Note that permanently blocking sends to vulnerable addresses can also=
 be confiscatory. For example, someone might have a presigned transaction, =
like a Lightning force-close, where the destination address is a vulnerable=
 address. If that path is blocked, the funds could be lost. If sending is t=
emporary, the funds can be recovered later.</div><div><br></div><div>If not=
hing is permanently blocked, and temporary blocking is intended to allow le=
gitimate owners to recover their funds, this could be seen as a win-win. It=
 is no longer one group trying to capture the purchasing power of another. =
However, I still have doubts about whether this is an ethical solution.</di=
v><div><br></div><div>I'm trying to place myself in the position of someone=
 who can't move their funds before the deadline -- for example, a young hei=
r with a timelocked inheritance. It's genuinely difficult to say what's bet=
ter: risking loss to a quantum adversary, or facing a temporary block with =
the prospect of future recovery. It really comes down to individual risk ap=
petite and time preference. And the challenge is, we can't ask them now -- =
that's the nature of the problem.</div></div><div> </div><blockquote style=
=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;"><div style=3D"font-family: Arial, sans-serif; font-size:=
 14px;"></div><div style=3D"font-family: Arial, sans-serif; font-size: 14px=
;">Maybe we should also talk about BIP360 P2QRH addresses and how they'd be=
 treated by these phases. As Ethan pointed out, P2QRH addresses can contain=
 EC signature spending conditions (OP_CHECKSIG). <b>Would phase B's stricte=
r rules also block EC spends from P2QRH UTXOs</b>?</div><div style=3D"font-=
family: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-f=
amily: Arial, sans-serif; font-size: 14px;">If yes, and phase B restricts E=
C spending from P2QRH, users may accidentally send money to P2QRH addresses=
 whose leafs all require at least one EC signature opcode. This locks the m=
oney up until phase C, even though the purpose of phase A was to avoid exac=
tly this from happening. Restricting P2QRH EC spending also makes hybrid sp=
ending conditions, which require both EC signatures <i>and</i> PQ signature=
s for extra safety, harder to implement explicitly in P2QRH script - We'd n=
eed dedicated EC/PQ hybrid checksig opcodes (which is an option if we want =
it).<br><br></div></blockquote><div></div><div></div><blockquote style=3D"m=
argin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddin=
g-left: 1ex;"><div style=3D"font-family: Arial, sans-serif; font-size: 14px=
;"></div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;">If=
 no, and phase B <i>doesn't</i> restrict EC spending from P2QRH, then P2QRH=
 UTXOs with exposed EC spending leafs will be even more vulnerable to a qua=
ntum attacker than those who have exposed pubkeys in pre-quantum UTXOs: Pre=
-quantum UTXOs would have better protection, since they are temporarily loc=
ked by phase B but P2QRH UTXOs aren't.</div></blockquote><div><br></div><di=
v>Will phase C also unblock such EC-dependent P2QRH addresses? If so, they =
are equally protected as classic P2PKH -- both must wait until phase C to a=
void exposing a public key by spending too early.</div><div> </div><blockqu=
ote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204=
, 204); padding-left: 1ex;"><div style=3D"font-family: Arial, sans-serif; f=
ont-size: 14px;"></div><div style=3D"font-family: Arial, sans-serif; font-s=
ize: 14px;">Personally i think phase B should  restrict ALL EC spending acr=
oss all script types, because at least then users can eventually reclaim th=
eir BTC when phase C rolls out. We can ameliorate the situation by properly=
 standardizing P2QRH address derivation, providing libraries to generate ad=
dresses with ML-DSA and SLH-DSA leafs. We should recommend strongly <i>agai=
nst</i> creating P2QRH addresses without at least one post-quantum spending=
 path.</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"=
><br></div><div style=3D"font-size: 14px;"><span style=3D"font-family: Aria=
l, sans-serif;">To better support hybrid spending conditions in P2QRH, we s=
hould modify phase B as follows: Fail any EC checksig opcode unless at leas=
t one PQ checksig opcode was executed earlier in the script. This implicitl=
y blocks spending of pre-quantum UTXOs (until the predefined height X as Bo=
ris suggested). P2QRH addresses can explicitly define flexible hybrid signa=
ture schemes in the P2QRH tree using a two-leaf construction: one leaf with=
 just <span>OP_CHECKSIG</span>=E2=80=8B, and one leaf with both <span>OP_CH=
ECKSIG</span>=E2=80=8B <i>and </i>a PQ checksig opcode (such as <span>OP_ML=
DSACHECKSIG</span>=E2=80=8B)</span><font face=3D"Arial, sans-serif">.</font=
></div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br>=
</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;">To no=
des who have upgraded to phase A (or earlier), funds sent to this address c=
ould be unlocked with the <span>OP_CHECKSIG</span>=E2=80=8B branch using a =
relatively small witness stack. On the other hand, nodes upgraded to phase =
B would reject the <span>OP_CHECKSIG</span>=E2=80=8B-only branch, because t=
here is no PQ-checksig opcode in the same script. Phase B nodes require the=
 <span>OP_MLDSACHECKSIG + OP_CHECKSIG</span>=E2=80=8B branch to validate th=
e spend. This branch needs a much larger witness stack, but would still per=
mit a hybrid spend, covered by the combined security of Schnorr + Dilithium=
.</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><div=
><br></div></div><div style=3D"font-family: Arial, sans-serif; font-size: 1=
4px;"><br></div><div style=3D"font-family: Arial, sans-serif; font-size: 14=
px;">regards,</div><div style=3D"font-family: Arial, sans-serif; font-size:=
 14px;">conduition</div></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
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 nofollow noopener">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/02f2130c-c024-40ce-8623-c09ceb090619n%40googlegroups.com" target=
=3D"_blank" rel=3D"noreferrer nofollow noopener">https://groups.google.com/=
d/msgid/bitcoindev/02f2130c-c024-40ce-8623-c09ceb090619n%40googlegroups.com=
</a>.<br>

        </blockquote><br>
    </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/a9xGMAv-oogmIdFuXMuXcgn_dkcCrIX9UNjXA-UuTqKrp6Tn8n6Q6usj33q66tr9=
SVP_jRpzeeq7Bw9wgcwCXsv2H5QTA1WL_JKvPH0eFdU%3D%40proton.me?utm_medium=3Dema=
il&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/a9xGMA=
v-oogmIdFuXMuXcgn_dkcCrIX9UNjXA-UuTqKrp6Tn8n6Q6usj33q66tr9SVP_jRpzeeq7Bw9wg=
cwCXsv2H5QTA1WL_JKvPH0eFdU%3D%40proton.me</a>.<br />

-----------------------a702f8253f9222a563439779dafe5b26--
-----------------------e8a7cf808aa2130caf35992785a36afe--
-----------------------483d638301960e48d863ca115c276842
Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI
YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO
dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3
Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL
YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox
K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo
CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J
MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr
T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR
TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp
S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag
UFVCTElDIEtFWSBCTE9DSy0tLS0tCg==
-----------------------483d638301960e48d863ca115c276842--

--------9ac74a0ec5295f78b5947e7333939603053aecebf35b3bb386e7f3c7129cdb08
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0Fgmh9DRAJkHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmdjL4s4IOchTaRnUm7oH2pT6EWUxnoTpi4pg+17
1iblhRYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAANWgD+OPLg16cbCibGPHKp
PhuLOXGffeJoo/JrTKHIMRtVChQA/R3pJiQ7d+pL4FxvqtKbKmEhFLXspVIw
vNU7plXFLLEG
=Eksv
-----END PGP SIGNATURE-----


--------9ac74a0ec5295f78b5947e7333939603053aecebf35b3bb386e7f3c7129cdb08--