path: root/c0/1b6cbd85c8c2979c3c651977df1afdcac77444

Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 615B52C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 26 Mar 2017 02:38:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com
	[209.85.218.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 12429170
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 26 Mar 2017 02:38:17 +0000 (UTC)
Received: by mail-oi0-f45.google.com with SMTP id r203so10189396oib.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 Mar 2017 19:38:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=5Qt8EG3UyC731zVSv2/sdTdTJ+mUEyWuklckWEPtVog=;
	b=Ew00map5LbczQVNYtM09LrszZ4tB3N8nVsK5XlESJMhozH9ocdpbzNeZWVAIRdyneR
	SkSjjwIbrz+pSTyC1+bc+0VrS2QconhS04oD1ZixzVYxwzfsiJO5PmY1Idqi/GeVBGEj
	8e8JMIdJKAf95Lo6byzHXfOQy4HFhZB7dpTkk6dBWdAvtsg8fjYl+/hf7yqdBXlnCdBF
	tS6EYt3Sc9Zzk78mDx/x4jFPr97HQri7h1Nj7CWKtITOSv61nUqxKSPiKfjPq2AGVbrW
	hKRJK5Vhm45zqyq+QhQAafWA0LTuh6Rt9ja0TU6HjkYzn36iu1kXvBWIfxGrL9tnO7Xz
	iZ9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=5Qt8EG3UyC731zVSv2/sdTdTJ+mUEyWuklckWEPtVog=;
	b=Mtzj1ssFfUA0zOQwVx5h6FyC/dv47K6iEk/NpiTYCpQrEBPdhnV11I8AvYNcusmzvb
	5oHj4dfZaS4D6yfu6NL3YGYxJVok5ImiK+1GzIv8uLmGaGSiHRljFXlBiUt2JcLwy5Nw
	EEIuxwXnl3hJn7qFsdKinUpOKp7gcdepRc0NUCI6r3gYxOIKZroLUAwh9G43gxC27TWP
	D10sFnCEUbcFiWup86TKnN5MmoLu/Vm5xDzMOqJoWNxT9eDGlgRLrKfKFhaYnmdFdImz
	bGk7FkcGZ9FbJuO1VE+QCpoUIQlGjTeo657gJkzh9MbDFk83rrCQFfbcoQF8Q0cvsD74
	1pkQ==
X-Gm-Message-State: AFeK/H1Oqu11dt2smbmNAos4e5OTzTZ1vOcqg+k7Jd/wuEOw7JcpMjPV1HFGfqncY43IWL2wVWwgINcp16fDxg==
X-Received: by 10.202.69.130 with SMTP id s124mr8256431oia.17.1490495897145;
	Sat, 25 Mar 2017 19:38:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.246.102 with HTTP; Sat, 25 Mar 2017 19:38:16 -0700 (PDT)
In-Reply-To: <9C2A6867-470D-4336-8439-17F4E0CA4B17@gmx.com>
References: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info>
	<35ba77db-f95a-4517-c960-8ad42a633ba0@gmail.com>
	<f4849cef-3c40-31a4-e323-6a731bb52bc2@cannon-ciota.info>
	<9C2A6867-470D-4336-8439-17F4E0CA4B17@gmx.com>
From: Alex Morcos <morcos@gmail.com>
Date: Sat, 25 Mar 2017 21:38:16 -0500
Message-ID: <CAPWm=eV2aLJKMM_5T-jaXCm1umRFxy+vfirBqCGAvUKHtOphQg@mail.gmail.com>
To: Peter R <peter_r@gmx.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113ddd2e7d1e99054b991e86
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,LOTS_OF_MONEY,
	RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,T_MONEY_PERCENT autolearn=no
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from
 malicious miner takeover?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Mar 2017 02:38:19 -0000

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

Surely you are aware that what you are proposing is vastly different from
the way soft forks have historically worked.

First of all, the bar for miners being on the new chain is extremely high,
95%.

Second of all, soft forks make rule restrictions on classes of transactions
that are already non-standard so that any non-upgraded miners are unlikely
to be including txs in their blocks which would violate the new rules and
should not have their blocks orphaned even after the fork.

Finally, soft forks are designed to only be used when there is a very wide
community consensus and the intention is not to overrule anyone's choice to
remain on the old rules but to ensure the security of nodes that may have
neglected to upgrade.  Obviously it is impossible to draw a bright line
between users who intentionally are not upgrading due to opposition and
users that are just being lazy.  But in the case of a proposed BU hard fork
it is abundantly clear that there is a very significant fraction, in fact
likely a majority of users who intentionally want to remain on the old
rules.

As a Bitcoin user I find it abhorrent the way you are proposing to
intentionally cripple the chain and rules I want to use instead of just
peacefully splitting.


On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> One of the purported benefits of a soft-forking change (a tightening of
> the consensus rule set) is the reduced risk of a blockchain split compare=
d
> to a loosening of the consensus rule set.  The way this works is that
> miners who fail to upgrade to the new tighter ruleset will have their
> non-compliant blocks orphaned by the hash power majority.  This is a stro=
ng
> incentive to upgrade and has historically worked well.  If a minority
> subset of the network didn=E2=80=99t want to abide by the new restricted =
rule set,
> a reasonable solution would be for them to change the proof-of-work and
> start a spin-off from the existing Bitcoin ledger (
> https://bitcointalk.org/index.php?topic=3D563972.0).
>
> In the case of the coming network upgrade to larger blocks, a primary
> concern of both business such as Coinbase and Bitpay, and most miners, is
> the possibility of a blockchain split and the associated confusion, repla=
y
> risk, etc.  By applying techniques that are known to be successful for
> soft-forking changes, we can likewise benefit in a way that makes a split
> less likely as we move towards larger blocks.  Two proposed techniques to
> reduce the chances of a split are:
>
> 1. That miners begin to orphan the blocks of non-upgraded miners once a
> super-majority of the network hash power has upgraded. This would serve a=
s
> an expensive-to-ignore reminder to upgrade.
>
> 2. That, in the case where a minority branch emerges (unlikely IMO),
> majority miners would continually re-org that minority branch with empty
> blocks to prevent transactions from confirming, thereby eliminating repla=
y
> risk.
>
> Just like after a soft forking change, a minority that does not want to
> abide by the current ruleset enforced by the majority could change the
> proof-of-work and start a spin-off from the existing Bitcoin ledger, as
> suggested by Emin.
>
> Best regards,
> Peter R
>
>
> > On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <bitcoin-dev@lists.
> linuxfoundation.org> wrote:
> >
> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
> >> I don't know what "Time is running short I fear" stands for and when 5=
0%
> >> is supposed to be reached
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
> > "Time is running short I fear" stands for and when 50% > is supposed
> > to be reached
> >
> > According to current hashrate distribution tracking site coin.dance,
> > very likely within less than four weeks according to current hashrate
> > takeover rate.
> >
> > While a fork is very likely, that I dont really fear because worst
> > case scenario is that bitcoin still survives and the invalid chain
> > becomes an alt.  My fear is the centralized mining power being used
> > to attack the valid chain with intentions on killing it. [1]
> >
> > Shouldn't this 50% attack they are threatening be a concern? If it
> > is a concern, what options are on the table. If it is not a concern
> > please enlightent me as to why.
> >
> >
> > [1] Source:
> > https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_
> rizun_tells_miners_to_force_a_hard_fork_by/
> >
> > Text:
> >
> > The attack quoted from his article:
> > https://medium.com/@peter_r/on-the-emerging-consensus-
> regarding-bitcoins-block-size-limit-insights-from-my-visit-
> with-2348878a16d8
> >
> >    [Level 2] Anti-split protection Miners will orphan the
> >    blocks of non-compliant miners prior to the first larger block
> >    to serve as a reminder to upgrade. Simply due to the possibility
> >    of having blocks orphaned, all miners would be motivated to
> >    begin signalling for larger blocks once support definitively
> >    passes 51%. If some miners hold out (e.g., they may not be
> >    paying attention regarding the upgrade), then they will begin
> >    to pay attention after losing approximately $15,000 of revenue
> >    due to an orphaned block.
> >
> >    [Level 3] Anti-split protection In the scenario where Levels
> >    1 and 2 protection fails to entice all non-compliant miners to
> >    upgrade, a small-block minority chain may emerge. To address the
> >    risk of coins being spent on this chain (replay risk), majority
> >    miners will deploy hash power as needed to ensure the minority
> >    chain includes only empty blocks after the forking point. This
> >    can easily be accomplished if the majority miners maintain a
> >    secret chain of empty blocks built off their last empty
> >    block publishing only as much of this chain as necessary
> >    to orphan any non-empty blocks produced on the minority chain.
> >
> >
> >
> >
> > - --
> > Cannon
> > PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> > Email: cannon@cannon-ciota.info
> >
> > NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
> > BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
> > If this matters to you, use PGP.
> > -----BEGIN PGP SIGNATURE-----
> >
> > iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM
> > eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH
> > h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu
> > gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK
> > VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B
> > TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj
> > j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw
> > NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u
> > YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN
> > ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa
> > 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S
> > /T93MuZgmvSCry5MlccA
> > =3DR71g
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Surely you are aware that what you are proposing is vastly=
 different from the way soft forks have historically worked.=C2=A0<div><br>=
</div><div>First of all, the bar for miners being on the new chain is extre=
mely high, 95%.</div><div><br></div><div>Second of all, soft forks make rul=
e restrictions on classes of transactions that are already non-standard so =
that any non-upgraded miners are unlikely to be including txs in their bloc=
ks which would violate the new rules and should not have their blocks orpha=
ned even after the fork.</div><div><br></div><div>Finally, soft forks are d=
esigned to only be used when there is a very wide community consensus and t=
he intention is not to overrule anyone&#39;s choice to remain on the old ru=
les but to ensure the security of nodes that may have neglected to upgrade.=
=C2=A0 Obviously it is impossible to draw a bright line between users who i=
ntentionally are not upgrading due to opposition and users that are just be=
ing lazy.=C2=A0 But in the case of a proposed BU hard fork it is abundantly=
 clear that there is a very significant fraction, in fact likely a majority=
 of users who intentionally want to remain on the old rules.</div><div><br>=
</div><div>As a Bitcoin user I find it abhorrent the way you are proposing =
to intentionally cripple the chain and rules I want to use instead of just =
peacefully splitting.</div><div><br></div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Sat, Mar 25, 2017 at 3:28 PM, Peter R via=
 bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One of the purported =
benefits of a soft-forking change (a tightening of the consensus rule set) =
is the reduced risk of a blockchain split compared to a loosening of the co=
nsensus rule set.=C2=A0 The way this works is that miners who fail to upgra=
de to the new tighter ruleset will have their non-compliant blocks orphaned=
 by the hash power majority.=C2=A0 This is a strong incentive to upgrade an=
d has historically worked well.=C2=A0 If a minority subset of the network d=
idn=E2=80=99t want to abide by the new restricted rule set, a reasonable so=
lution would be for them to change the proof-of-work and start a spin-off f=
rom the existing Bitcoin ledger (<a href=3D"https://bitcointalk.org/index.p=
hp?topic=3D563972.0" rel=3D"noreferrer" target=3D"_blank">https://bitcointa=
lk.org/<wbr>index.php?topic=3D563972.0</a>).<br>
<br>
In the case of the coming network upgrade to larger blocks, a primary conce=
rn of both business such as Coinbase and Bitpay, and most miners, is the po=
ssibility of a blockchain split and the associated confusion, replay risk, =
etc.=C2=A0 By applying techniques that are known to be successful for soft-=
forking changes, we can likewise benefit in a way that makes a split less l=
ikely as we move towards larger blocks.=C2=A0 Two proposed techniques to re=
duce the chances of a split are:<br>
<br>
1. That miners begin to orphan the blocks of non-upgraded miners once a sup=
er-majority of the network hash power has upgraded. This would serve as an =
expensive-to-ignore reminder to upgrade.<br>
<br>
2. That, in the case where a minority branch emerges (unlikely IMO), majori=
ty miners would continually re-org that minority branch with empty blocks t=
o prevent transactions from confirming, thereby eliminating replay risk.<br=
>
<br>
Just like after a soft forking change, a minority that does not want to abi=
de by the current ruleset enforced by the majority could change the proof-o=
f-work and start a spin-off from the existing Bitcoin ledger, as suggested =
by Emin.<br>
<br>
Best regards,<br>
Peter R<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
&gt; On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoun=
dation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On 03/24/2017 07:00 PM, Aymeric Vitte wrote:<br>
&gt;&gt; I don&#39;t know what &quot;Time is running short I fear&quot; sta=
nds for and when 50%<br>
&gt;&gt; is supposed to be reached<br>
&gt;<br>
&gt; -----BEGIN PGP SIGNED MESSAGE-----<br>
&gt; Hash: SHA512<br>
&gt;<br>
&gt; On 03/24/2017 07:00 PM, Aymeric Vitte wrote: &gt; I don&#39;t know wha=
t<br>
&gt; &quot;Time is running short I fear&quot; stands for and when 50% &gt; =
is supposed<br>
&gt; to be reached<br>
&gt;<br>
&gt; According to current hashrate distribution tracking site coin.dance,<b=
r>
&gt; very likely within less than four weeks according to current hashrate<=
br>
&gt; takeover rate.<br>
&gt;<br>
&gt; While a fork is very likely, that I dont really fear because worst<br>
&gt; case scenario is that bitcoin still survives and the invalid chain<br>
&gt; becomes an alt.=C2=A0 My fear is the centralized mining power being us=
ed<br>
&gt; to attack the valid chain with intentions on killing it. [1]<br>
&gt;<br>
&gt; Shouldn&#39;t this 50% attack they are threatening be a concern? If it=
<br>
&gt; is a concern, what options are on the table. If it is not a concern<br=
>
&gt; please enlightent me as to why.<br>
&gt;<br>
&gt;<br>
&gt; [1] Source:<br>
&gt; <a href=3D"https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizu=
n_tells_miners_to_force_a_hard_fork_by/" rel=3D"noreferrer" target=3D"_blan=
k">https://www.reddit.com/r/<wbr>Bitcoin/comments/6172s3/peter_<wbr>rizun_t=
ells_miners_to_force_a_<wbr>hard_fork_by/</a><br>
&gt;<br>
&gt; Text:<br>
&gt;<br>
&gt; The attack quoted from his article:<br>
&gt; <a href=3D"https://medium.com/@peter_r/on-the-emerging-consensus-regar=
ding-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8" re=
l=3D"noreferrer" target=3D"_blank">https://medium.com/@peter_r/<wbr>on-the-=
emerging-consensus-<wbr>regarding-bitcoins-block-size-<wbr>limit-insights-f=
rom-my-visit-<wbr>with-2348878a16d8</a><br>
&gt;<br>
&gt;=C2=A0 =C2=A0 [Level 2] Anti-split protection=E2=80=8A=E2=80=8AMiners w=
ill orphan the<br>
&gt;=C2=A0 =C2=A0 blocks of non-compliant miners prior to the first larger =
block<br>
&gt;=C2=A0 =C2=A0 to serve as a reminder to upgrade. Simply due to the poss=
ibility<br>
&gt;=C2=A0 =C2=A0 of having blocks orphaned, all miners would be motivated =
to<br>
&gt;=C2=A0 =C2=A0 begin signalling for larger blocks once support definitiv=
ely<br>
&gt;=C2=A0 =C2=A0 passes 51%. If some miners hold out (e.g., they may not b=
e<br>
&gt;=C2=A0 =C2=A0 paying attention regarding the upgrade), then they will b=
egin<br>
&gt;=C2=A0 =C2=A0 to pay attention after losing approximately $15,000 of re=
venue<br>
&gt;=C2=A0 =C2=A0 due to an orphaned block.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 [Level 3] Anti-split protection=E2=80=8A=E2=80=8AIn the s=
cenario where Levels<br>
&gt;=C2=A0 =C2=A0 1 and 2 protection fails to entice all non-compliant mine=
rs to<br>
&gt;=C2=A0 =C2=A0 upgrade, a small-block minority chain may emerge. To addr=
ess the<br>
&gt;=C2=A0 =C2=A0 risk of coins being spent on this chain (replay risk), ma=
jority<br>
&gt;=C2=A0 =C2=A0 miners will deploy hash power as needed to ensure the min=
ority<br>
&gt;=C2=A0 =C2=A0 chain includes only empty blocks after the forking point.=
 This<br>
&gt;=C2=A0 =C2=A0 can easily be accomplished if the majority miners maintai=
n a<br>
&gt;=C2=A0 =C2=A0 secret chain of empty blocks=E2=80=8A=E2=80=8Abuilt off t=
heir last empty<br>
&gt;=C2=A0 =C2=A0 block=E2=80=8A=E2=80=8Apublishing only as much of this ch=
ain as necessary<br>
&gt;=C2=A0 =C2=A0 to orphan any non-empty blocks produced on the minority c=
hain.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; - --<br>
&gt; Cannon<br>
&gt; PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832<br>
&gt; Email: <a href=3D"mailto:cannon@cannon-ciota.info">cannon@cannon-ciota=
.info</a><br>
&gt;<br>
&gt; NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD<=
br>
&gt; BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.<br>
&gt; If this matters to you, use PGP.<br>
&gt; -----BEGIN PGP SIGNATURE-----<br>
&gt;<br>
&gt; iQIcBAEBCgAGBQJY1pbaAAoJEAYDai<wbr>9lH2mwOO0QANOWqGzPNlifWguc+<wbr>Y5U=
QxQM<br>
&gt; eAiztAayQBoAyLcFE7/<wbr>qdtSNlUxbIAHG17fM+<wbr>aNkehjYH2oN5ODJ+j7E2Yt6=
EoUH<br>
&gt; h5t8MLhNRG/<wbr>YGF1hJK8Io940EmdcjuNmohiZvrjIq<wbr>EOYggmLU3hR6J4gsuGs=
QQhu<br>
&gt; gY3sMS/TtT+<wbr>gZNH8w53ePGrsVhuQR7yEMMr91/<wbr>vM4+Q5abpwqLeYLnslaZDc=
d3XK<br>
&gt; VB9vyyK08r34J1GQt/<wbr>H4UvTvGs28MFKBkvueA/Sfyvnrih7+<wbr>WSQLuSvhiFr+=
cW1B<br>
&gt; TmSVYrB2DzyHN27jDCI2ty3ryNE4PM<wbr>YcaeLfI2TTbsD/MuVU5lK0kM/<wbr>1JajP=
4eRj<br>
&gt; j+P03OipuQiy/<wbr>dNU63w0Uka2PbdKhDC13hVtK/<wbr>ttBbNppbjnGeB9PYSJCzOp=
InGw<br>
&gt; NwAyz0rVS/<wbr>llGsdctcII7Z6AUMGuJXzsosY8vjUr<wbr>oU+KFRDqIbDfC53sH7Da=
Ph7u<br>
&gt; YawwId5S5RnZsAGCUJ+<wbr>qNcg0s728J1eDjofN291IS5sOKMzpI<wbr>7KhaOhFxjnk=
1MpN<br>
&gt; ZAlQeTlvG+sAdn61QMQK1NbFt0km+<wbr>jcqyVh0+<wbr>L01yB0K4VDi1YFJaSBOaYUE=
LBXa<br>
&gt; 8a6WhZf5nrl5UIpH7rRcPzzqchcdYc<wbr>zy5VRZp2UsU+<wbr>HYeqLXlcN0a03yPpVQ=
ik9S<br>
&gt; /T93MuZgmvSCry5MlccA<br>
&gt; =3DR71g<br>
&gt; -----END PGP SIGNATURE-----<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--001a113ddd2e7d1e99054b991e86--