path: root/e6/64d2c344e077f5106fc48f2b60ab36adb01a8b

Delivery-date: Wed, 16 Jul 2025 14:06:02 -0700
Received: from mail-yw1-f189.google.com ([209.85.128.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCYMD7OS6ECBBL5I4DBQMGQEBOZDS3A@googlegroups.com>)
	id 1uc9KE-0005R4-1B
	for bitcoindev@gnusha.org; Wed, 16 Jul 2025 14:06:02 -0700
Received: by mail-yw1-f189.google.com with SMTP id 00721157ae682-70e72e81fafsf3278697b3.2
        for <bitcoindev@gnusha.org>; Wed, 16 Jul 2025 14:06:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1752699956; x=1753304756; 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=x4YYX55SaSKQFSvBRaFx+r2JiK9PJQIXJWJL7lX1g5U=;
        b=fajDwTGLs3cnA8tW7wCOLyflvVNT3vBDG9kQOhZW54wZlT7bbrYCMlO40glItzb0E+
         80pTHGnwhYhr7Lz7uZYCiHtpkiLDY3IrONkpnewcNRqgbFK01JAjH6aLDTgSLI80NkiR
         NH2nNnkwOdvReXWWRLWIXKyCQpeVZthN+in7t4kSzkL3U3sO7+SSILeqTTCBkRFAIDig
         3MPm0VQYTA9JU6bRFwm8vPutjQf4bbUGgR1PFsuz1U71TCxemfI7UtDQVRlZrG9Kf+g8
         usqf6rNmmeze1B3eX245gmC0aMNLxaUOFGVd3udjqN18UWd1iajk01kAeLYpCGx5p6wk
         X4fA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1752699956; x=1753304756; 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=x4YYX55SaSKQFSvBRaFx+r2JiK9PJQIXJWJL7lX1g5U=;
        b=iSI85LEzdvpihRSaByo9GcRUNNvh+B8jS+5eKnMCBh5XCbQE4vjGBfp0ols7ROhIJi
         9ubW0ly/jAnFGjvzChUtGy7+SiwlQsaEtZVLa+cmBLAu4a4Y2QgRwt+OZ36G6UuL7Pep
         XOSACbcOHULUi485rIOju3lXBu0UboqedPR6u2ogyGBorrI5vuOe8TzFn5hJgKyCRNWy
         V292ncGt9GLIfj8eZBBxxeKsspTK2E5q3K1WIeGnel5GNyzIsemAtKPRHcpBzFZm1GYk
         Gsi1YGUxNdztziApoAOKYC1kkQPgVvcxu4wSwo1Q+vrVvklmH7MCd+wm6vyojsrCl88c
         BO8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1752699956; x=1753304756;
        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=x4YYX55SaSKQFSvBRaFx+r2JiK9PJQIXJWJL7lX1g5U=;
        b=bciBdkj9jQDAhwCCYj6xVNvfGIJRyQmVCHv5oZ57NiVnhf3e8Y2P1o4XzuIGoUEz3T
         knMOZ8i9VbDhDhEdFOkjyzCw431+7/T+XWl4Zu2Idx61YUfhmv7PVvMs/cRr36OKl6iJ
         C+fm+5txSG+LVdHM23KkyMJgsjNNEYvqGFMNt4VqToJfUA2mKhXwvKyuTcL4xDEoLu+V
         urMRaZBAVV71WgR0jHDRe9jtjbxEAeZYtNFCDx1jQ/HN2T6fRazZZegzcB+2jljo1Mam
         bAN3wXdb7XSJ0QsYAGYBiAMZoDLV3CoWnLUXNI26Nc2w7ltxwGU1ArXNeGipvNUoQeUU
         JRjw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWxpoi3x5+oZiduboa4G3C6edxZpot3gNvUIhhg7Y7wkbgzCruA5krz/8Zb7qhuGjmAdQqcqQLx4GVl@gnusha.org
X-Gm-Message-State: AOJu0Yy3tt8IXA2TjXKHJS5Y3D06reiJi58TpBXCjvKp8h9xVdXSSCOt
	HNClovN2stNcCv6AwcStNwQG7fIgjgYL+frtLJtJPHzloMz3cmRHtffj
X-Google-Smtp-Source: AGHT+IGDovPrLBDT8LkPb/FZJqqUoK1aC7xA12NhAjihamO7gqF81a+NOKBjpYSnD7FmLZwK9Dnf5g==
X-Received: by 2002:a05:6902:983:b0:e8b:53ba:2a2 with SMTP id 3f1490d57ef6-e8bc250f36amr5115860276.39.1752699955514;
        Wed, 16 Jul 2025 14:05:55 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeP6oeoF11TXNUFDnFIAhuy5/r2WIcuhbqvfON+MlHCpw==
Received: by 2002:a25:d6c4:0:b0:e7d:801a:4dd6 with SMTP id 3f1490d57ef6-e8bd43ed90als360456276.0.-pod-prod-05-us;
 Wed, 16 Jul 2025 14:05:51 -0700 (PDT)
X-Received: by 2002:a05:690c:708b:b0:712:c55c:4e65 with SMTP id 00721157ae682-71836c63d32mr59892357b3.16.1752699951095;
        Wed, 16 Jul 2025 14:05:51 -0700 (PDT)
Received: by 2002:a05:690c:4684:b0:710:fccf:6901 with SMTP id 00721157ae682-71834b57adams7b3;
        Wed, 16 Jul 2025 10:34:49 -0700 (PDT)
X-Received: by 2002:a05:690c:628a:b0:70f:83af:7dab with SMTP id 00721157ae682-71836c259b7mr43654897b3.4.1752687288876;
        Wed, 16 Jul 2025 10:34:48 -0700 (PDT)
Date: Wed, 16 Jul 2025 10:34:48 -0700 (PDT)
From: Boris Nagaev <bnagaev@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <02f2130c-c024-40ce-8623-c09ceb090619n@googlegroups.com>
In-Reply-To: <gSvbx255CIbMSivfsn-1cGECh7UpJufvfVP4lwnp5r7gIamZo9t5LdBZBEYyiw4Eb9zNSvLXoi2SW8Sq3i7shSwBkWwxLRjoPkncexfCPRM=@proton.me>
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>
Subject: Re: [bitcoindev] A Post Quantum Migration Proposal
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_88998_707175299.1752687288515"
X-Original-Sender: bnagaev@gmail.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: 0.1 (/)

------=_Part_88998_707175299.1752687288515
Content-Type: multipart/alternative; 
	boundary="----=_Part_88999_534962838.1752687288515"

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

Hey Conduition and all!

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

Hey Boris and list,

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


Great idea. It gives us more time to get the zk-STARK proof system for=20
phase C tightened up, but we still have the option of deploying phase B=20
independently to protect procrastinators against a fast-arriving quantum=20
adversary, even if the STARK system isn't ready yet. If quantum progress is=
=20
slower (or phase C development is faster) than anticipated, we also have=20
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=20
eventually permit sending to pre-quantum addresses at height X? Because as=
=20
described, once phase A is locked in, we can never again permit sending to=
=20
pre-quantum addresses (without a hard fork).


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

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

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

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

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

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

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


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

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

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

To nodes who have upgraded to phase A (or earlier), funds sent to this=20
address could be unlocked with the OP_CHECKSIG=E2=80=8B branch using a rela=
tively=20
small witness stack. On the other hand, nodes upgraded to phase B would=20
reject the OP_CHECKSIG=E2=80=8B-only branch, because there is no PQ-checksi=
g opcode=20
in the same script. Phase B nodes require the OP_MLDSACHECKSIG + OP_CHECKSI=
G=E2=80=8B branch=20
to validate the spend. This branch needs a much larger witness stack, but=
=20
would still permit a hybrid spend, covered by the combined security of=20
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/=
02f2130c-c024-40ce-8623-c09ceb090619n%40googlegroups.com.

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

<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><b=
lockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(20=
4, 204, 204); padding-left: 1ex;"><div style=3D"font-family: Arial, sans-se=
rif; font-size: 14px;">Hey Boris and list,</div><div style=3D"font-family: =
Arial, sans-serif; font-size: 14px;"><br /></div><blockquote style=3D"borde=
r-left: 3px solid rgb(200, 200, 200); border-color: rgb(200, 200, 200); pad=
ding-left: 10px; color: rgb(102, 102, 102);"><div style=3D"font-family: Ari=
al, sans-serif; font-size: 14px;"><span>What if all vulnerable coins are te=
mporarily 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-spendable aga=
in?</span><br /></div></blockquote><div style=3D"font-family: Arial, sans-s=
erif; font-size: 14px;"><span><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 t=
he option of deploying phase B independently to protect procrastinators aga=
inst a fast-arriving quantum adversary, even if the STARK system isn't read=
y yet. If quantum progress is slower (or phase C development is faster) tha=
n anticipated, we also have the option to merge the phases B and C together=
 into a single deployment.</div><div style=3D"font-family: Arial, sans-seri=
f; 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=
 is better to replace permanent blocking with temporary restrictions in cas=
e of both sending to and spending from vulnerable addresses. That way, we l=
eave the door open for future recovery schemes without needing a hard fork.=
<br /><br />Note that permanently blocking sends to vulnerable addresses ca=
n also be confiscatory. For example, someone might have a presigned transac=
tion, like a Lightning force-close, where the destination address is a vuln=
erable address. If that path is blocked, the funds could be lost. If sendin=
g is temporary, the funds can be recovered later.</div><div><br /></div><di=
v>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.</div><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 heir with a timelocked inheritance. It's genuinely difficult to say =
what's better: risking loss to a quantum adversary, or facing a temporary b=
lock with the prospect of future recovery. It really comes down to individu=
al risk appetite and time preference. And the challenge is, we can't ask th=
em now -- that's the nature of the problem.</div></div><div>=C2=A0</div><bl=
ockquote 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-ser=
if; font-size: 14px;"></div><div style=3D"font-family: Arial, sans-serif; f=
ont-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 address=
es can contain EC signature spending conditions (OP_CHECKSIG). <b>Would pha=
se 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 pha=
se B restricts EC spending from P2QRH, users may accidentally 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 purpose of phase A w=
as to avoid exactly this from happening. Restricting P2QRH EC spending also=
 makes hybrid spending conditions, which require both EC signatures <i>and<=
/i>=C2=A0PQ 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).<br /><br /></div></blockquote><div></div><div></d=
iv><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid r=
gb(204, 204, 204); padding-left: 1ex;"><div style=3D"font-family: Arial, sa=
ns-serif; font-size: 14px;"></div><div style=3D"font-family: Arial, sans-se=
rif; font-size: 14px;">If no, and phase B <i>doesn't</i>=C2=A0restrict EC s=
pending from P2QRH, then P2QRH UTXOs with exposed EC spending leafs will be=
 even more vulnerable to a quantum attacker than those who have exposed pub=
keys in pre-quantum UTXOs: Pre-quantum UTXOs would have better protection, =
since they are temporarily locked by phase B but P2QRH UTXOs aren't.</div><=
/blockquote><div><br /></div><div>Will phase C also unblock such EC-depende=
nt P2QRH addresses? If so, they are equally protected as classic P2PKH -- b=
oth must wait until phase C to avoid exposing a public key by spending too =
early.</div><div>=C2=A0</div><blockquote 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; font-size: 14px;"></div><div style=3D"f=
ont-family: Arial, sans-serif; font-size: 14px;">Personally i think phase B=
 should  restrict ALL EC spending across all script types, because at least=
 then users can eventually reclaim their BTC when phase C rolls out. We can=
 ameliorate the situation by properly standardizing P2QRH address derivatio=
n, providing libraries to generate addresses with ML-DSA and SLH-DSA leafs.=
 We should recommend strongly <i>against</i>=C2=A0creating P2QRH addresses =
without at least one post-quantum spending path.</div><div style=3D"font-fa=
mily: Arial, sans-serif; font-size: 14px;"><br /></div><div style=3D"font-s=
ize: 14px;"><span style=3D"font-family: Arial, sans-serif;">To better suppo=
rt hybrid spending conditions in P2QRH, we should modify phase B as follows=
: Fail any EC checksig opcode unless at least one PQ checksig opcode was ex=
ecuted earlier in the script. This implicitly blocks spending of pre-quantu=
m 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<span>OP_CHECKSIG</s=
pan>=E2=80=8B, and one leaf with both=C2=A0<span>OP_CHECKSIG</span>=E2=80=
=8B <i>and </i>a PQ checksig opcode (such as <span>OP_MLDSACHECKSIG</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 styl=
e=3D"font-family: Arial, sans-serif; font-size: 14px;">To nodes who have up=
graded to phase A (or earlier), funds sent to this address could be unlocke=
d with the <span>OP_CHECKSIG</span>=E2=80=8B branch using a relatively smal=
l witness stack. On the other hand, nodes upgraded to phase B would reject =
the <span>OP_CHECKSIG</span>=E2=80=8B-only branch, because there is no PQ-c=
hecksig opcode in the same script. Phase B nodes require the=C2=A0<span>OP_=
MLDSACHECKSIG + OP_CHECKSIG</span>=E2=80=8B=C2=A0branch to validate the spe=
nd. This branch needs a much larger witness stack, but would still permit a=
 hybrid spend, covered by the combined security of Schnorr + Dilithium.</di=
v><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: 14p=
x;">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 &=
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/02f2130c-c024-40ce-8623-c09ceb090619n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/02f2130c-c024-40ce-8623-c09ceb090619n%40googlegroups.com</a>.<br />

------=_Part_88999_534962838.1752687288515--

------=_Part_88998_707175299.1752687288515--