path: root/69/1883f88268dbe4e9986aeba2beb314020413a3

Delivery-date: Fri, 28 Jun 2024 11:49:47 -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+bncBC5P5KEHZQLBBQUL7SZQMGQEDD4NFUA@googlegroups.com>)
	id 1sNGfK-0006Xg-Gk
	for bitcoindev@gnusha.org; Fri, 28 Jun 2024 11:49:47 -0700
Received: by mail-yw1-f189.google.com with SMTP id 00721157ae682-6452f8f2942sf17296727b3.1
        for <bitcoindev@gnusha.org>; Fri, 28 Jun 2024 11:49:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1719600580; x=1720205380; 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=CCiDRfxhGTHmOkpko15ZOpnCAVP6G+aYD2PdN7iio/c=;
        b=AvDLLlP376m29PEM4Hf6IoEq9tXUT3qER2556T7fa8DOdxXDQIvyGIYGeSV6dF2Q92
         YhZk1DrxgO95wqn+OdG2EWRoanDgYQLrqhWddjnkPrcLQYQ46o857L7e4H9qzrVqG6sg
         Num0TsQ9LvAPTtA8uWUMOnl2XlXdeJZ2hWq8FG06XlEW0NwKpIK1cXJ2YtTvUmxrzZT3
         6nvBhYBZ9Px79lAdHPgXc76MUEgAziDcwuBfdHVHZYRzehqzziU6hTKuWdPxwpbb4t75
         dXKpIdjJjpV6cJoe+DWuA+aH9+bcWaRJkOJcrRrrn2wfNLM4+moY8ZprSJC3t4q2NovU
         wUrg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1719600580; x=1720205380; 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=CCiDRfxhGTHmOkpko15ZOpnCAVP6G+aYD2PdN7iio/c=;
        b=edbep6Wc69PEidLa6Hm90pcDIIm3Ct2Rb3PtHv9ZVqn17KNSCiGotzwlEjUhLhpoRJ
         KuFQVrM57Sj8UoSF96dfOHWPrSF0+A32Tck/yA+bKgbTCFK5w20q0DYq/A4j5TUdtdbW
         bLg+Y9SYDO+2EE2ABcBK/kFpnOHEYctAgnWY+i0QkQJWWYnwD9zFOvp+zetyumOTQ62i
         9xC+tB52p4uIez66sRerGCN55Y+yjv9ZeiFo9pDabopc45jw4eEoclI0h0a/PjTx/WKJ
         3ZtZAnRIu+8gk7j9klGm55aFtCHoJVXhiOD728ZEC4eK+5exr+cDHU/662lJJWceN2Tf
         H64Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1719600580; x=1720205380;
        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=CCiDRfxhGTHmOkpko15ZOpnCAVP6G+aYD2PdN7iio/c=;
        b=KD5aBd2bweh2LEMvhnkvmKBZYWxZTSowMUA3MAjUo2DTLVjG8QO2UwN/IuDxayyhTY
         I+Qgzvd6CSB2UN8VMDOr2GRigIttt0M3Hg81LhoLSpmq0JWzK3/UcrIjn+JCOxgQgOjz
         wxDLK3aE9OpP+jKcb8cwVlzwFmTj0esRc0trn8ZHaX2DpBtOLMiroWz0ydPwOdPedadk
         5m2kFHAoyFz6+x+hX61Nuk5gTiBrn30vJ6i4wYE3YtMifrZ/amaTeVxSeZDR54GgUeqi
         nw2YOxC+C9JfUr1XtbhccNfIx2vLUbs05vSGK6C3MS8TOtICv9n9ff4ZlbMsa09pK1mN
         FnPA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVh+8D5G1ih+sNB4Oc/mXxOKLknCvxu31b6fPHa0pUPM2ll28l34ZbrECwb6PFddw2szzjKSOoMYWTqMeTSTmG8MDwwvu4=
X-Gm-Message-State: AOJu0YzQojYwgbnwhI8AYbZu8nUw3oOoqO6l4G2NkDtF9zhNf447MOcI
	6Fn6Qs40kk0Fu0SgfQ/TfwGnE/S2/GpxGiRlLhJDAX4BQUHilAKx
X-Google-Smtp-Source: AGHT+IGushFeZy08e+f2shaNUZW0+VsjyQ1V96L+9DnIxVFBHMQ3AbLmUktBkS/ByoFCSRRvA2qbOA==
X-Received: by 2002:a25:ad98:0:b0:e03:5bf4:d508 with SMTP id 3f1490d57ef6-e035bf4d6c3mr2669928276.27.1719600579748;
        Fri, 28 Jun 2024 11:49:39 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:150d:b0:dff:aa9:b9ad with SMTP id
 3f1490d57ef6-e035a580299ls1374913276.2.-pod-prod-08-us; Fri, 28 Jun 2024
 11:49:38 -0700 (PDT)
X-Received: by 2002:a05:6902:2b84:b0:e02:c739:367 with SMTP id 3f1490d57ef6-e0303fe4816mr965886276.13.1719600578361;
        Fri, 28 Jun 2024 11:49:38 -0700 (PDT)
Received: by 2002:a0d:e6cd:0:b0:64a:6fb4:b878 with SMTP id 00721157ae682-64a84019cd1ms7b3;
        Fri, 28 Jun 2024 10:14:05 -0700 (PDT)
X-Received: by 2002:a05:6902:18c6:b0:e03:510d:3b6e with SMTP id 3f1490d57ef6-e03510d3f6amr312250276.3.1719594844324;
        Fri, 28 Jun 2024 10:14:04 -0700 (PDT)
Date: Fri, 28 Jun 2024 10:14:04 -0700 (PDT)
From: Eric Voskuil <eric@voskuil.org>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <9a4c4151-36ed-425a-a535-aa2837919a04n@googlegroups.com>
In-Reply-To: <jJLDrYTXvTgoslhl1n7Fk9-pL1mMC-0k6gtoniQINmioJpzgtqrJ_WqyFZkLltsCUusnQ4jZ6HbvRC-mGuaUlDi3kcqcFHALd10-JQl-FMY=@protonmail.com>
References: <gnM89sIQ7MhDgI62JciQEGy63DassEv7YZAMhj0IEuIo0EdnafykF6RH4OqjTTHIHsIoZvC2MnTUzJI7EfET4o-UQoD-XAQRDcct994VarE=@protonmail.com>
 <72e83c31-408f-4c13-bff5-bf0789302e23n@googlegroups.com>
 <heKH68GFJr4Zuf6lBozPJrb-StyBJPMNvmZL0xvKFBnBGVA3fVSgTLdWc-_8igYWX8z3zCGvzflH-CsRv0QCJQcfwizNyYXlBJa_Kteb2zg=@protonmail.com>
 <5b0331a5-4e94-465d-a51d-02166e2c1937n@googlegroups.com>
 <yt1O1F7NiVj-WkmnYeta1fSqCYNFx8h6OiJaTBmwhmJ2MWAZkmmjPlUST6FM7t6_-2NwWKdglWh77vcnEKA8swiAnQCZJY2SSCAh4DOKt2I=@protonmail.com>
 <be78e733-6e9f-4f4e-8dc2-67b79ddbf677n@googlegroups.com>
 <jJLDrYTXvTgoslhl1n7Fk9-pL1mMC-0k6gtoniQINmioJpzgtqrJ_WqyFZkLltsCUusnQ4jZ6HbvRC-mGuaUlDi3kcqcFHALd10-JQl-FMY=@protonmail.com>
Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_317950_1433319534.1719594844096"
X-Original-Sender: eric@voskuil.org
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.7 (/)

------=_Part_317950_1433319534.1719594844096
Content-Type: multipart/alternative; 
	boundary="----=_Part_317951_1488383171.1719594844096"

------=_Part_317951_1488383171.1719594844096
Content-Type: text/plain; charset="UTF-8"

>> It is not clear to me how determining the coinbase size can be done at 
an earlier stage of validation than detection of the non-null coinbase.
> My point wasn't about checking the coinbase size, it was about being able 
to cache the hash of a (non-malleated) invalid block as permanently invalid 
to avoid re-downloading and re-validating it.

This I understood, but I think you misunderstood me. Your point was 
specifically that, "it would let node implementations cache block failures 
at an earlier stage of validation." Since you have not addressed that 
aspect I assume you agree with my assertion above that the proposed rule 
does not actually achieve this.

Regarding the question of checking coinbase size, the issue is of detecting 
(or preventing) hashes mallied via the 64 byte tx technique. A rule against 
64 byte txs would allow this determination by checking the coinbase alone. 
If the coinbase is 64 bytes the block is invalid, if it is not the block 
hash cannot have been mallied (all txs must have been 64 bytes, see 
previous reference).

In that case if the block is invalid the invalidity can be cached. But 
block invalidity cannot actually be cached until the block is fully 
validated. A rule to prohibit *all* 64 byte txs is counterproductive as it 
only adds additional checks on typically thousands of txs per block, 
serving no purpose.

>> It seems to me that introducing an arbitrary tx size validity may create 
more potential implementation bugs than it resolves.
> The potential for implementation bugs is a fair point to raise, but in 
this case i don't think it's a big concern. Verifying no transaction in a 
block is 64 bytes is as simple a check as you can get.

You appear to be making the assumption that the check is performed after 
the block is fully parsed (contrary to your "earlier" criterion above). The 
only way to determine the tx sizes is to parse each tx for witness marker, 
input count, output count, input script sizes, output script sizes, witness 
sizes, and skipping over the header, several constants, and associated 
buffers. Doing this "early" to detect malleation is an extraordinarily 
complex and costly process. On the other hand, as I pointed out, a rational 
implementation would only do this early check for the coinbase.

Yet even determining the size of the coinbase is significantly more complex 
and costly than checking its first input point against null. That check 
(which is already necessary for validation) resolves the malleation 
question, can be performed on the raw unparsed block buffer by simply 
skipping header, version, reading input count and witness marker as 
necessary, offsetting to the 36 byte point buffer, and performing a byte 
comparison against 
[0000000000000000000000000000000000000000000000000000000000000000ffffffff].

This is:

(1) earlier
(2) faster
(3) simpler
(4) already consensus

>> And certainly anyone implementing such a verifier must know many 
intricacies of the protocol.
> They need to know some, but i don't think it's reasonable to expect them 
to realize the merkle tree construction is such that an inner node may be 
confused with a 64 bytes transaction.

A protocol developer needs to understand that the hash of an invalid block 
cannot be cached unless at least the coinbase has been restricted in size 
(under the proposal) -or- that the coinbase is a null point (presently or 
under the proposal). In the latter case the check is already performed in 
validation, so there is no way a block would presently be cached as invalid 
without checking it. The proposal adds a redundant check, even if limited 
to just the coinbase. [He must also understand the second type of 
malleability, discussed below.]

If this proposed rule was to activate we would implement it in a late stage 
tx.check, after txs/blocks had been fully deserialized. We would not check 
it an all in the case where the block is under checkpoint or milestone 
("assume valid"). In this case we would retain the early null point 
malleation check (along with the hash duplication malleation check) that we 
presently have, would validate tx commitments, and commit the block. In 
other words, the proposal adds unnecessary late stage checks only. 
Implementing it otherwise would just add complexity and hurt performance.

>> I do not see this. I see a very ugly perpetual seam which will likely 
result in unexpected complexities over time.
> What makes you think making 64 bytes transactions invalid could result in 
unexpected complexities? And why do you think it's likely?

As described above, it's later, slower, more complex, unnecessarily broad, 
and a consensus change. Beyond that it creates an arbitrary size limit - 
not a lower or upper bound, but a slice out of the domain. Discontinuities 
are inherent complexities in computing. The "unexpected" part speaks for 
itself.

>> This does not produce unmalleable block hashes. Duplicate tx hash 
malleation remains in either case, to the same effect. Without a resolution 
to both issues this is an empty promise.
> Duplicate txids have been invalid since 2012 (CVE-2012-2459).

I think again here you may have misunderstood me. I was not making a point 
pertaining to BIP30. I was referring to the other form of block hash 
malleability, which results from duplicating sets of trailing txs in a 
single block (see previous reference). This malleation vector remains, even 
with invalid 64 byte txs. As I pointed out, this has the "same effect" as 
the 64 byte tx issue. Merkle hashing the set of txs is insufficient to 
determine identity. In one case the coinbase must be checked (null point or 
size) and in the other case the set of tx hashes must be checked for 
trailing duplicated sets. [Core performs this second check within the 
Merkle hashing algorithm (with far more comparisons than necessary), though 
this can be performed earlier and independently to avoid any hashing in the 
malleation case.]

I would also point out in the interest of correctness that Core reverted 
its BIP30 soft fork implementation as a consequence of the BIP90 hard fork, 
following and requiring the BIP34 soft fork that presumably precluded it 
but didn't, so it is no longer the case that duplicate tx hashes are 
invalid in implementation. As you have proposed in this rollup, this 
requires fixing again.

> If 64 bytes transactions are also made invalid, this would make it 
impossible for two valid blocks to have the same hash.

Aside from the BIP30/34/90 issue addressed above, it is already 
"impossible" (cannot be stronger than computationally infeasible) for two 
*valid* blocks to have the same hash. The proposal does not enable that 
objective, it is already the case. No malleated block is a valid block.

The proposal aims only to make it earlier or easier or faster to check for 
block hash malleation. And as I've pointed out above, it doesn't achieve 
those objectives. Possibly the perception that this would be the case is a 
consequence of implementation details, but as I have shown above, it is not 
in fact the case.

Given either type of malleation, the malleated block can be determined to 
be invalid by a context free check. But this knowledge cannot ever be 
cached against the block hash, since the same hash may be valid. Invalidity 
can only be cached once a non-mallied block is validated and determined to 
be invalid. Block hash malleations are and will remain invalid blocks with 
or without the proposal, and it will continue to be necessary to avoid 
caching invalid against the malleation. As you said:

> it was about being able to cache the hash of a (non-malleated) invalid 
block as permanently invalid to avoid re-downloading and re-validating it.

This is already the case, and requires validating the full non-malleated 
block. Adding a redundant invalidity check doesn't improve this in any way.

Best,
Eric

-- 
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 on the web visit https://groups.google.com/d/msgid/bitcoindev/9a4c4151-36ed-425a-a535-aa2837919a04n%40googlegroups.com.

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

&gt;&gt; It is not clear to me how determining the coinbase size can be don=
e at an earlier stage of validation than detection of the non-null coinbase=
.<br />&gt; My point wasn't about checking the coinbase size, it was about =
being able to cache the hash of a (non-malleated) invalid block as permanen=
tly invalid to avoid re-downloading and re-validating it.<br /><br />This I=
 understood, but I think you misunderstood me. Your point was specifically =
that, "it would let node implementations cache block failures at an earlier=
 stage of validation." Since you have not addressed that aspect I assume yo=
u agree with my assertion above that the proposed rule does not actually ac=
hieve this.<br /><br />Regarding the question of checking coinbase size, th=
e issue is of detecting (or preventing) hashes mallied via the 64 byte tx t=
echnique. A rule against 64 byte txs would allow this determination by chec=
king the coinbase alone. If the coinbase is 64 bytes the block is invalid, =
if it is not the block hash cannot have been mallied (all txs must have bee=
n 64 bytes, see previous reference).<br /><br />In that case if the block i=
s invalid the invalidity can be cached. But block invalidity cannot actuall=
y be cached until the block is fully validated. A rule to prohibit *all* 64=
 byte txs is counterproductive as it only adds additional checks on typical=
ly thousands of txs per block, serving no purpose.<br /><br />&gt;&gt; It s=
eems to me that introducing an arbitrary tx size validity may create more p=
otential implementation bugs than it resolves.<br />&gt; The potential for =
implementation bugs is a fair point to raise, but in this case i don't thin=
k it's a big concern. Verifying no transaction in a block is 64 bytes is as=
 simple a check as you can get.<br /><br />You appear to be making the assu=
mption that the check is performed after the block is fully parsed (contrar=
y to your "earlier" criterion above). The only way to determine the tx size=
s is to parse each tx for witness marker, input count, output count, input =
script sizes, output script sizes, witness sizes, and skipping over the hea=
der, several constants, and associated buffers. Doing this "early" to detec=
t malleation is an extraordinarily complex and costly process. On the other=
 hand, as I pointed out, a rational implementation would only do this early=
 check for the coinbase.<br /><br />Yet even determining the size of the co=
inbase is significantly more complex and costly than checking its first inp=
ut point against null. That check (which is already necessary for validatio=
n) resolves the malleation question, can be performed on the raw unparsed b=
lock buffer by simply skipping header, version, reading input count and wit=
ness marker as necessary, offsetting to the 36 byte point buffer, and perfo=
rming a byte comparison against [000000000000000000000000000000000000000000=
0000000000000000000000ffffffff].<br /><br />This is:<br /><br />(1) earlier=
<br />(2) faster<br />(3) simpler<br />(4) already consensus<br /><br />&gt=
;&gt; And certainly anyone implementing such a verifier must know many intr=
icacies of the protocol.<br />&gt; They need to know some, but i don't thin=
k it's reasonable to expect them to realize the merkle tree construction is=
 such that an inner node may be confused with a 64 bytes transaction.<br />=
<br />A protocol developer needs to understand that the hash of an invalid =
block cannot be cached unless at least the coinbase has been restricted in =
size (under the proposal) -or- that the coinbase is a null point (presently=
 or under the proposal). In the latter case the check is already performed =
in validation, so there is no way a block would presently be cached as inva=
lid without checking it. The proposal adds a redundant check, even if limit=
ed to just the coinbase. [He must also understand the second type of mallea=
bility, discussed below.]<br /><br />If this proposed rule was to activate =
we would implement it in a late stage tx.check, after txs/blocks had been f=
ully deserialized. We would not check it an all in the case where the block=
 is under checkpoint or milestone ("assume valid"). In this case we would r=
etain the early null point malleation check (along with the hash duplicatio=
n malleation check) that we presently have, would validate tx commitments, =
and commit the block. In other words, the proposal adds unnecessary late st=
age checks only. Implementing it otherwise would just add complexity and hu=
rt performance.<br /><br />&gt;&gt; I do not see this. I see a very ugly pe=
rpetual seam which will likely result in unexpected complexities over time.=
<br />&gt; What makes you think making 64 bytes transactions invalid could =
result in unexpected complexities? And why do you think it's likely?<br /><=
br />As described above, it's later, slower, more complex, unnecessarily br=
oad, and a consensus change. Beyond that it creates an arbitrary size limit=
 - not a lower or upper bound, but a slice out of the domain. Discontinuiti=
es are inherent complexities in computing. The "unexpected" part speaks for=
 itself.<br /><br />&gt;&gt; This does not produce unmalleable block hashes=
. Duplicate tx hash malleation remains in either case, to the same effect. =
Without a resolution to both issues this is an empty promise.<br />&gt; Dup=
licate txids have been invalid since 2012 (CVE-2012-2459).<br /><br />I thi=
nk again here you may have misunderstood me. I was not making a point perta=
ining to BIP30. I was referring to the other form of block hash malleabilit=
y, which results from duplicating sets of trailing txs in a single block (s=
ee previous reference). This malleation vector remains, even with invalid 6=
4 byte txs. As I pointed out, this has the "same effect" as the 64 byte tx =
issue. Merkle hashing the set of txs is insufficient to determine identity.=
 In one case the coinbase must be checked (null point or size) and in the o=
ther case the set of tx hashes must be checked for trailing duplicated sets=
. [Core performs this second check within the Merkle hashing algorithm (wit=
h far more comparisons than necessary), though this can be performed earlie=
r and independently to avoid any hashing in the malleation case.]<br /><br =
/>I would also point out in the interest of correctness that Core reverted =
its BIP30 soft fork implementation as a consequence of the BIP90 hard fork,=
 following and requiring the BIP34 soft fork that presumably precluded it b=
ut didn't, so it is no longer the case that duplicate tx hashes are invalid=
 in implementation. As you have proposed in this rollup, this requires fixi=
ng again.<br /><br />&gt; If 64 bytes transactions are also made invalid, t=
his would make it impossible for two valid blocks to have the same hash.<br=
 /><br />Aside from the BIP30/34/90 issue addressed above, it is already "i=
mpossible" (cannot be stronger than computationally infeasible) for two *va=
lid* blocks to have the same hash. The proposal does not enable that object=
ive, it is already the case. No malleated block is a valid block.<br /><br =
/>The proposal aims only to make it earlier or easier or faster to check fo=
r block hash malleation. And as I've pointed out above, it doesn't achieve =
those objectives. Possibly the perception that this would be the case is a =
consequence of implementation details, but as I have shown above, it is not=
 in fact the case.<br /><br />Given either type of malleation, the malleate=
d block can be determined to be invalid by a context free check. But this k=
nowledge cannot ever be cached against the block hash, since the same hash =
may be valid. Invalidity can only be cached once a non-mallied block is val=
idated and determined to be invalid. Block hash malleations are and will re=
main invalid blocks with or without the proposal, and it will continue to b=
e necessary to avoid caching invalid against the malleation. As you said:<b=
r /><br />&gt; it was about being able to cache the hash of a (non-malleate=
d) invalid block as permanently invalid to avoid re-downloading and re-vali=
dating it.<br /><br />This is already the case, and requires validating the=
 full non-malleated block. Adding a redundant invalidity check doesn't impr=
ove this in any way.<br /><br />Best,<br />Eric

<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 on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/9a4c4151-36ed-425a-a535-aa2837919a04n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/9a4c4151-36ed-425a-a535-aa2837919a04n%40googlegroups.com</a>.=
<br />

------=_Part_317951_1488383171.1719594844096--

------=_Part_317950_1433319534.1719594844096--