path: root/e9/9f96ae884f2c2b349e0d2688fa3f5e6a862101

Delivery-date: Wed, 16 Jul 2025 09:48:38 -0700
Received: from mail-yw1-f183.google.com ([209.85.128.183])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCL7RHHJZYJBBVVP37BQMGQEPIVWF4Y@googlegroups.com>)
	id 1uc5J7-0001fP-9l
	for bitcoindev@gnusha.org; Wed, 16 Jul 2025 09:48:38 -0700
Received: by mail-yw1-f183.google.com with SMTP id 00721157ae682-710e75f9229sf101217677b3.2
        for <bitcoindev@gnusha.org>; Wed, 16 Jul 2025 09:48:37 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1752684507; cv=pass;
        d=google.com; s=arc-20240605;
        b=FaLOiomjLQPdj/BvU2RaL/0jC7KZhsRVf11DMnI4X/AczF0ImY9yZzQUbi0Be4nIeX
         k+8vqmiHnMz7JUgogeaJ1r2As4ml/Z5duLqQZhX4ruEdgI/ooO6k+FNX6Nkh7uzEQI1d
         jZLV0wrdYh79oEPrWf2Ch7LuhZRlqpIYHc72i4IAj6iVDMyLl13nzV2hT9zVFfy+RnEC
         7YikFkazJHXuhlVU/hxm8LeN/J0QrnHUl0OGgKEwTkT1WaOdI8wxQAJFMUg4aEZuTJxF
         gO49bOwuvL/FqaaCbyFCuLwxPxAIUjaGj15KyueN2hn2++NWaWl+XvTXNSjK04gTZ9L/
         WbQg==
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=J25mA9Y6PTPgCSwEVmVqbFkfHWPZOmMJ+slOhqEvsPQ=;
        fh=CUs0flmAMn1r1aGQJVhl+zsZ0j8G9VyLIfDaCANLOaU=;
        b=iWBDyWHcGgNhKBB+BoXpeOVL7xYzBfI/OZhf5E29VpZMX6D8C6lUx5HXigQ5oUFrMF
         oX0r2bMh2voaG79cu4RGUV7kvo3DB73qa6i19xqAz6ImXd4awX5G7aZjgQD5aRku9s1t
         clpzqIOpy+x67r6OOCxS+WZBEFWy22qgKTQuWZfEWDXDP/EomRKqjT4aPZYtN8SUwICx
         VlV9IjmFtaCu3wUWfkuRng0JvccbXtCyp7TobNO6g6KrNZ3+LYVSvPFwryRRjqdrTjfs
         kpXy75LXY3botv//PaMPsTpMkcCQWYEdm5Uw3PS7D8rOO75HV9KDfQjme2JBYZbRgGxF
         vlSQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@proton.me header.s=protonmail header.b="kf/13yTh";
       spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.18 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=1752684507; x=1753289307; 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=J25mA9Y6PTPgCSwEVmVqbFkfHWPZOmMJ+slOhqEvsPQ=;
        b=b2E48587X4ibEOtmEminpRDi1HiqTAv4HM3QDZgB27q7pL/LYApcg8qYBN9jC9Vm+G
         oDk7lWnOqjZCOdSQB/a5FN3CVOezmQaHn7AWU7nGQ+DskLTw9pSkIrWyRzDX9Kv752RS
         qm7wQCCzahtNmav+d+gQ/n5Y0oKBMQDYp9+LFBZ810TBZnWWeFGb3FAZPEUUwNyOkBdm
         FE5hDo/Wm73aIRQNUG7iA3dpwzwtvFNFOzEXsZkkfiupIQL7uvWesq/glC5UMkjdjmkV
         v2ERsPaD65J6lc5a1uPOHlQlwHqNlo3s/YETbvV76VFbT5v1jMttlTSZNDyYuheOii1d
         +NCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1752684507; x=1753289307;
        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=J25mA9Y6PTPgCSwEVmVqbFkfHWPZOmMJ+slOhqEvsPQ=;
        b=tyCVEpfX1XytvnNd1d/OW6XrKI3zH9nWLNbug9m+Gk6DD8SS1HY1XdClvNvZpzVX8Y
         7a6mKQ9sfehjidbsNn7YtONf802dgq51ZNNGLIhfjASeIK4pKyZwMX7OqErS7n0xENDv
         OLk5CH7xRWP89+st3PmY3c86phFagl+JeoY/mpzd/jBRIbnqBtzMgk8vJe7YQfyKHG7G
         kP3Y26I9dstMLVAq4G5sGRQ14DGuTkrHKvR2Zv5qcWg7NKgYrj4tjQYVPoW0WqqGU4SM
         rGnIf4ZRkohc+IK7y6wHkEfLAbNj+rtnhbb1hFfozIPGKd6jPizS+C7T0TPdJFTdc9Gk
         sGsQ==
X-Forwarded-Encrypted: i=2; AJvYcCXPVMusoSynHoouI4VcUpCET3tKe8ukdpC1WmUbCcgoY1VdZmrWshSFk/kkTzDLUdA1XwCJLopQX543@gnusha.org
X-Gm-Message-State: AOJu0YyyqEq+W2oc+1eJ6i79YxjSMdh+R2WnmLGILA4H8uU+NFwkasqS
	quw60McHBHy7GDo73XaifSeg4oAzwjcYQuiXQfJuar4ISQtz4ggrloc7
X-Google-Smtp-Source: AGHT+IEfPYslqddEyCQ44x5EhZ5g9N8b3xwAksHFAgpT1kBoFL32gxtcZxTjX0YNp6z4R8G1dR2sZw==
X-Received: by 2002:a05:6902:258a:b0:e8b:d2d0:8b12 with SMTP id 3f1490d57ef6-e8bd2d091admr1696495276.17.1752684506993;
        Wed, 16 Jul 2025 09:48:26 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcTdVwbrAY8dRgDA225LugiWS6Lnrw4br7CRYgMeAfepQ==
Received: by 2002:a25:4cc2:0:b0:e87:adad:c527 with SMTP id 3f1490d57ef6-e8bd4608490ls145269276.1.-pod-prod-04-us;
 Wed, 16 Jul 2025 09:48:22 -0700 (PDT)
X-Received: by 2002:a05:690c:7006:b0:70e:82d6:9af2 with SMTP id 00721157ae682-7183519693bmr54582107b3.34.1752684502613;
        Wed, 16 Jul 2025 09:48:22 -0700 (PDT)
Received: by 2002:a05:6808:2186:b0:40d:498:c1f6 with SMTP id 5614622812f47-41cd998409bmsb6e;
        Wed, 16 Jul 2025 09:43:30 -0700 (PDT)
X-Received: by 2002:a05:6808:11cb:b0:409:f8e:72a7 with SMTP id 5614622812f47-41cefffbdf5mr2385419b6e.33.1752684209448;
        Wed, 16 Jul 2025 09:43:29 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1752684209; cv=none;
        d=google.com; s=arc-20240605;
        b=e3u/eIxjhHc6gvhe5sa41dq7lKEOUgP0EJqEXCKJO82LmPuy12WETyLmcN1yNt3egn
         sIXTedo2qnQbQ601q5eMY2gL23XT05Qm7rQXHsUaOENY6Yam8pzPdJyWqtjTpojQAMQo
         Y68M+hjgCIuTgU/f4bTWsRCZtVhSIIwwDTRct2uzOnwjpL3Pv2jO3phrb+hEQ1aiPvnd
         QQ3zkYjYdIPyAN23wLa0kze3a6jEPkAgBEv5BhFss5wkcOgiOKJDJSe3nTZttjbQxKca
         lHjixU5uFJZPp149aX2Bk7TUtlJrq6QVfhlYBSHqU1qpDw/tn/7V6EBVJhPq/bP1aIx9
         7Jaw==
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=sTpaqEy06+xJrN4LCDPf+qkTqBOJqiihkxMrASKd7D8=;
        fh=6b1pLcW6tcZ6I7AhOCDpUTdU/HBZRb+DjIxd1ga4+Sc=;
        b=ghWJtM8QKCrpQimWVkVFNfQOGMSz1k64/pSfk6Ld4wZQVzxemFjmVFT4i0w13K/QgR
         oC1zuf4z8ry5wVKidqaKR1i9iJYB9/GojFu2HriajkXONbW0pqRPVa+CD3ffonh0ugdD
         10+N1rf4mhhrSbOySQD5FmaB/RnLr8dO6RN2Bkbz/g2TN/2m0es/Aiig0pin0l/H41w2
         HrG+QZkidyuExyFFbyS82ibVQjkmLH3k5HHSbHzkkm+lpr8/3QnvVp6qROr2qLoCyeDu
         8Q20mIKDWCWIVY7qukyXMDjgl5OQiILHCwBZmmN/katCKoUQ7sS1NsuXP6eXEE5aN7JH
         iCbw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@proton.me header.s=protonmail header.b="kf/13yTh";
       spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.18 as permitted sender) smtp.mailfrom=conduition@proton.me;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch. [109.224.244.18])
        by gmr-mx.google.com with ESMTPS id 006d021491bc7-6159092ea4asi279672eaf.2.2025.07.16.09.43.29
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 16 Jul 2025 09:43:29 -0700 (PDT)
Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.18 as permitted sender) client-ip=109.224.244.18;
Date: Wed, 16 Jul 2025 16:43:23 +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: <gSvbx255CIbMSivfsn-1cGECh7UpJufvfVP4lwnp5r7gIamZo9t5LdBZBEYyiw4Eb9zNSvLXoi2SW8Sq3i7shSwBkWwxLRjoPkncexfCPRM=@proton.me>
In-Reply-To: <88a7b020-e84f-4052-9716-fb40b23f07ddn@googlegroups.com>
References: <CADL_X_fpv-aXBxX+eJ_EVTirkAJGyPRUNqOCYdz5um8zu6ma5Q@mail.gmail.com> <W2O6Al4bdVzx1EkszgN5dhtSUD0GwRgwYcRSWlQzfsvZE0UN5f6HBGXB2zorkGOpdsbDAS_X6xcsrH6zBIeYbPY8MM_sPfeN9Wblts5Gcog=@proton.me> <88a7b020-e84f-4052-9716-fb40b23f07ddn@googlegroups.com>
Feedback-ID: 72003692:user:proton
X-Pm-Message-ID: 9b7047850c1dff8579057cdb7f87032998e2d624
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------442003c1b53fea4273b5e8261d1b5e1fed421d5b9f717560147700cce0069004"; 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="kf/13yTh";       spf=pass
 (google.com: domain of conduition@proton.me designates 109.224.244.18 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: -0.4 (/)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------442003c1b53fea4273b5e8261d1b5e1fed421d5b9f717560147700cce0069004
Content-Type: multipart/mixed;boundary=---------------------62bf685ff5328b00dc0f0d1bae6f9d3f

-----------------------62bf685ff5328b00dc0f0d1bae6f9d3f
Content-Type: multipart/alternative;boundary=---------------------53a85936325f78fd11dddc5852d49201

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

Hey Boris and list,


> 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 poin=
t these coins become EC-spendable again?



Great idea. It gives us more time to get the zk-STARK proof system for phas=
e C tightened up, but we still have the option of deploying phase B indepen=
dently to protect procrastinators against a fast-arriving quantum adversary=
, even if the STARK system isn't ready yet. If quantum progress is slower (=
or phase C development is faster) than anticipated, we also have the option=
 to merge the phases B and C together into a single deployment.

If we do that, should we apply the same logic to phase A though, and eventu=
ally permit sending to pre-quantum addresses at height X? Because as descri=
bed, once phase A is locked in, we can never again permit sending to pre-qu=
antum addresses (without a hard fork).

Maybe we should also talk about BIP360 P2QRH addresses and how they'd be tr=
eated by these phases. As Ethan pointed out, P2QRH addresses can contain EC=
 signature spending conditions (OP_CHECKSIG). Would phase B's stricter rule=
s also block EC spends from P2QRH UTXOs?

If yes, and phase B restricts EC spending from P2QRH, users may accidentall=
y send money to P2QRH addresses whose leafs all require at least one EC sig=
nature opcode. This locks the money up until phase C, even though the purpo=
se of phase A was to avoid exactly this from happening. Restricting P2QRH E=
C spending also makes hybrid spending conditions, which require both EC sig=
natures and=C2=A0PQ signatures for extra safety, harder to implement explic=
itly in P2QRH script - We'd need dedicated EC/PQ hybrid checksig opcodes (w=
hich is an option if we want it).

If no, and phase B doesn't=C2=A0restrict 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.

Personally i think phase B should restrict ALL EC spending across all scrip=
t types, because at least then users can eventually reclaim their BTC when =
phase C rolls out. We can ameliorate the situation by properly standardizin=
g P2QRH address derivation, providing libraries to generate addresses with =
ML-DSA and SLH-DSA leafs. We should recommend strongly against=C2=A0creatin=
g P2QRH addresses without at least one post-quantum spending path.

To better support hybrid spending conditions in P2QRH, we should modify pha=
se B as follows: Fail any EC checksig opcode unless at least one PQ checksi=
g opcode was executed earlier in the script. This implicitly blocks spendin=
g of pre-quantum UTXOs (until the predefined height X as Boris suggested). =
P2QRH addresses can explicitly define flexible hybrid signature schemes in =
the P2QRH tree using a two-leaf construction: one leaf with just=C2=A0`OP_C=
HECKSIG`, and one leaf with both=C2=A0`OP_CHECKSIG` and a PQ checksig opcod=
e (such as `OP_MLDSACHECKSIG`).

To nodes who have upgraded to phase A (or earlier), funds sent to this addr=
ess could be unlocked with the `OP_CHECKSIG` branch using a relatively smal=
l witness stack. On the other hand, nodes upgraded to phase B would reject =
the `OP_CHECKSIG`-only branch, because there is no PQ-checksig opcode in th=
e same script. Phase B nodes require the=C2=A0`OP_MLDSACHECKSIG + OP_CHECKS=
IG`=C2=A0branch to validate the spend. This branch needs a much larger witn=
ess stack, but would still permit a hybrid spend, covered by the combined s=
ecurity of Schnorr + Dilithium.


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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
gSvbx255CIbMSivfsn-1cGECh7UpJufvfVP4lwnp5r7gIamZo9t5LdBZBEYyiw4Eb9zNSvLXoi2=
SW8Sq3i7shSwBkWwxLRjoPkncexfCPRM%3D%40proton.me.

-----------------------53a85936325f78fd11dddc5852d49201
Content-Type: multipart/related;boundary=---------------------23e536eee94a34b1ab8b657456532477

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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Hey Boris a=
nd 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-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200, 2=
00); border-bottom-color: rgb(200, 200, 200); padding-left: 10px; color: rg=
b(102, 102, 102);"><div style=3D"font-family: Arial, sans-serif; font-size:=
 14px;"><span>What if all vulnerable coins are temporarily locked during ph=
ase B, with a clearly defined future block height X (e.g., in 5-10 years) a=
t which point these coins become EC-spendable again?</span><br></div></bloc=
kquote><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><spa=
n><br></span></div><div style=3D"font-family: Arial, sans-serif; font-size:=
 14px;">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=
 independently to protect procrastinators against a fast-arriving quantum a=
dversary, even if the STARK system isn't ready yet. If quantum progress is =
slower (or phase C development is faster) than anticipated, we also have th=
e option to merge the phases B and C together into a single deployment.</di=
v><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div=
><div style=3D"font-family: Arial, sans-serif; font-size: 14px;">If we do t=
hat, should we apply the same logic to phase A though, and eventually permi=
t sending to pre-quantum addresses at height X? Because as described, once =
phase A is locked in, we can never again permit sending to pre-quantum addr=
esses (without a hard fork).</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;">Maybe we should also talk about BIP360 P2QRH addresse=
s and how they'd be treated by these phases. As Ethan pointed out, P2QRH ad=
dresses can contain EC signature spending conditions (OP_CHECKSIG). <b>Woul=
d phase B's stricter 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-family: Arial, sans-serif; font-size: 14px;">If yes, and =
phase B restricts EC spending from P2QRH, users may accidentally send money=
 to P2QRH addresses whose leafs all require at least one EC signature opcod=
e. This locks the money up until phase C, even though the purpose of phase =
A was to avoid exactly this from happening. Restricting P2QRH EC spending a=
lso makes hybrid spending conditions, which require both EC signatures <i>a=
nd</i>&nbsp;PQ signatures for extra safety, harder to implement explicitly =
in P2QRH script - We'd need dedicated EC/PQ hybrid checksig opcodes (which =
is an option if we want it).</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 no, and phase B <i>doesn't</i>&nbsp;restrict EC sp=
ending from P2QRH, then P2QRH UTXOs with exposed EC spending leafs will be =
even more vulnerable to a quantum attacker than those who have exposed pubk=
eys in pre-quantum UTXOs: Pre-quantum UTXOs would have better protection, s=
ince they are temporarily locked by phase B but P2QRH UTXOs aren't.</div><d=
iv style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div><di=
v style=3D"font-family: Arial, sans-serif; font-size: 14px;">Personally i t=
hink phase B should  restrict ALL EC spending across all script types, beca=
use at least then users can eventually reclaim their BTC when phase C rolls=
 out. We can ameliorate the situation by properly standardizing P2QRH addre=
ss derivation, providing libraries to generate addresses with ML-DSA and SL=
H-DSA leafs. We should recommend strongly <i>against</i>&nbsp;creating P2QR=
H addresses without at least one post-quantum spending path.</div><div styl=
e=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style=
=3D"font-size: 14px;"><span style=3D"font-family: Arial, sans-serif;">To be=
tter support hybrid spending conditions in P2QRH, we should modify phase B =
as follows: Fail any EC checksig opcode unless at least one PQ checksig opc=
ode was executed earlier in the script. This implicitly blocks spending of =
pre-quantum UTXOs (until the predefined height X as Boris suggested). P2QRH=
 addresses can explicitly define flexible hybrid signature schemes in the P=
2QRH tree using a two-leaf construction: one leaf with just&nbsp;<code styl=
e=3D"scrollbar-color: rgba(0, 0, 0, 0.35) rgba(0, 0, 0, 0);">OP_CHECKSIG</c=
ode>=E2=80=8B, and one leaf with both&nbsp;<code style=3D"scrollbar-color: =
rgba(0, 0, 0, 0.35) rgba(0, 0, 0, 0);">OP_CHECKSIG</code>=E2=80=8B <i>and <=
/i>a PQ checksig opcode (such as <code>OP_MLDSACHECKSIG</code>=E2=80=8B)</s=
pan><font face=3D"Arial, sans-serif">.</font></div><div style=3D"font-famil=
y: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-family=
: Arial, sans-serif; font-size: 14px;">To nodes who have upgraded to phase =
A (or earlier), funds sent to this address could be unlocked with the <code=
>OP_CHECKSIG</code>=E2=80=8B branch using a relatively small witness stack.=
 On the other hand, nodes upgraded to phase B would reject the <code>OP_CHE=
CKSIG</code>=E2=80=8B-only branch, because there is no PQ-checksig opcode i=
n the same script. Phase B nodes require the&nbsp;<code>OP_MLDSACHECKSIG + =
OP_CHECKSIG</code>=E2=80=8B&nbsp;branch to validate the spend. This branch =
needs a much larger witness stack, but would still permit a hybrid spend, c=
overed 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: 14px;"><br></div><div =
style=3D"font-family: Arial, sans-serif; font-size: 14px;">regards,</div><d=
iv style=3D"font-family: Arial, sans-serif; font-size: 14px;">conduition</d=
iv>

<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/gSvbx255CIbMSivfsn-1cGECh7UpJufvfVP4lwnp5r7gIamZo9t5LdBZBEYyiw4E=
b9zNSvLXoi2SW8Sq3i7shSwBkWwxLRjoPkncexfCPRM%3D%40proton.me?utm_medium=3Dema=
il&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/gSvbx2=
55CIbMSivfsn-1cGECh7UpJufvfVP4lwnp5r7gIamZo9t5LdBZBEYyiw4Eb9zNSvLXoi2SW8Sq3=
i7shSwBkWwxLRjoPkncexfCPRM%3D%40proton.me</a>.<br />

-----------------------23e536eee94a34b1ab8b657456532477--
-----------------------53a85936325f78fd11dddc5852d49201--
-----------------------62bf685ff5328b00dc0f0d1bae6f9d3f
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==
-----------------------62bf685ff5328b00dc0f0d1bae6f9d3f--

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

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

wrsEARYKAG0Fgmh31psJkHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmctw708EFxBLldnUatDgrcJfYmwNLE1/0MQsEE9
c8pIdRYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAAwRQD+P5dYguAthYzDPC2W
bHKWIQBGnO5XHpGcvIK1iMq/RCAA/Rt0xN4anIqGo4wyzIjBb3zw1+zAN5vK
Uph0EQOybwsG
=zzDi
-----END PGP SIGNATURE-----


--------442003c1b53fea4273b5e8261d1b5e1fed421d5b9f717560147700cce0069004--