path: root/85/2aac3ae308e13cb3a39fee85076f63752d3b0e

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 03CAE927
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 11 Nov 2017 19:51:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f45.google.com (mail-pg0-f45.google.com [74.125.83.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CCD69196
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 11 Nov 2017 19:51:07 +0000 (UTC)
Received: by mail-pg0-f45.google.com with SMTP id s75so9856916pgs.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 11 Nov 2017 11:51:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=IlA4Fdhppu4wP8xMgeVxSpAI4R5JiUQJIWIbpPskGpc=;
	b=jrjr2wQnwuPqosOzTLiL0qbfDSL3dQd50jLOuBsTmW27B62xfErHhEJtRJWL51Shy2
	ufjGUN/ypUSJwiIFwbXHxsU8xhbkSojymFPnLUjUY76Hem6910Gh08oPq+EJiXo2o04l
	AnL32msFfn1dVJpR1gtaeCXkkjpISNzzYulwKIOv5kjd/Ii8/wbiDqaQ8fbbQv04U8vE
	901Sutzku3WW+mmABcSSBmLk07bjcsxdbJDuwvqOGeEJ5qMjnP3Nt1ARjOQYFOoeNirG
	3OsglfKLDAHvy0YR/yk3ev8UTyovPWkxZxgMDIX1fqYUSfHJo75O+ksLjsAJd/V37p3N
	QJeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=IlA4Fdhppu4wP8xMgeVxSpAI4R5JiUQJIWIbpPskGpc=;
	b=e4yos6w1SVdT+dogn91OWrrCfeK5SBAaFrZfUQ4aDQ3n+OFi//OjEysVzY6wVcA7v+
	3YG5lX7Z6QTeqcZQscvLTwaeD1QmMLvO+pr6Ufl3fZA3CYfjmk4694/x4biY3h/B4cbl
	FnhoBjuq7OjqxsK23UziAGwKR6uTiKFFPao5SiQpu5o8rp3g58cOb1w0pqMvzt7YsgyC
	3ry7iUcOexjPp5N+yN/E7ancOXdrQHm86EYkAyAOMRNuKAPALrquE2SuAQBV8wXMErto
	dVNZi+vJMEv/xwAhtE/ar17py6JszhHw1DgZKwC/uYJLZZzP3TxS5fxOMV7GVYDKOA0b
	Hjlg==
X-Gm-Message-State: AJaThX7irmAOdOlmTS6ngTFvTxJZlg6QeTFQa4eSLnpg3f1bmZrcNFoq
	worzt8d96UF8NNQO9LS66r4bxw==
X-Google-Smtp-Source: AGs4zMaYEoeUPmUhv2GZlnfr7TWpPo1tHFmG+X/V+zjHCy8h0ZrrdcIQFWHZMHQEI/Pje8jrrVHpZw==
X-Received: by 10.98.29.211 with SMTP id d202mr4632059pfd.49.1510429867296;
	Sat, 11 Nov 2017 11:51:07 -0800 (PST)
Received: from ?IPv6:2600:380:7764:47f:49a3:91a1:6239:38d3?
	([2600:380:7764:47f:49a3:91a1:6239:38d3])
	by smtp.gmail.com with ESMTPSA id
	g7sm25551255pfj.13.2017.11.11.11.51.05
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 11 Nov 2017 11:51:06 -0800 (PST)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-2FF6A11F-75CD-431C-A0FB-CDA13D688580
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <CAB0O3SX-m1Uw8Ga-ddzyU6oYdM2QRXn2OetgPmPBT+-5wGmjKQ@mail.gmail.com>
Date: Sat, 11 Nov 2017 11:51:04 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <795D69CA-1591-4B69-96EE-BAF14CAAD71B@voskuil.org>
References: <CAB0O3SVjhG19R61B78hFCPwfwWemTXj=tOsvgAgoNbjFYXXAtg@mail.gmail.com>
	<20171106195000.GA7245@fedora-23-dvm>
	<CA+XQW1j2vNNswEQ-HVWF9MpyGBzmq3ij+v=2NGH2VicQ63=v6A@mail.gmail.com>
	<61253DDB-A045-4346-A39C-F5C4E07396C7@voskuil.org>
	<CAB0O3SX-m1Uw8Ga-ddzyU6oYdM2QRXn2OetgPmPBT+-5wGmjKQ@mail.gmail.com>
To: Devrandom <c1.bitcoin@niftybox.net>
X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE autolearn=disabled
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 11 Nov 2017 19:53:02 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Introducing a POW through a soft-fork
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: Sat, 11 Nov 2017 19:51:09 -0000


--Apple-Mail-2FF6A11F-75CD-431C-A0FB-CDA13D688580
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable


> On Nov 6, 2017, at 20:38, Devrandom <c1.bitcoin@niftybox.net> wrote:
>=20
> A hard-fork is a situation where non-upgraded nodes reject a block mined a=
nd relayed by upgraded nodes.

As Peter pointed out, that is the case here.

> This creates a fork that cannot heal regardless of what follows.

That is not a condition of the hard fork concept.

https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki
Softfork
A consensus fork wherein everything that was previously invalid remains inva=
lid while blocks that would have previously considered valid become invalid.=
 A hashrate majority of miners can impose the new rules. They have some depl=
oyment advantages like backward compatibility.
Hardfork
A consensus fork that makes previously invalid blocks valid. Hardforks requi=
re all users to upgrade.

The essential element of a hard fork is that the new rule may cause rejectio=
n of blocks that are not rejected by old rules (thereby requiring that all u=
sers adopt the new rule in order to avoid a split). The reason a hard fork i=
s interesting is that it can create a chain split even if it is enforced by m=
ajority hash power.

That is not the case with a soft fork and it is not the case here. A split c=
an occur. The fact that it is possible for the split to also eventually orph=
an the old nodes does not make it a soft fork. A soft fork requires that a h=
ash power majority can impose the rule. However, under the proposed new rule=
 the hash power majority (according to the new rule) cannot impose the rule o=
n existing nodes.

> This proposal is not a hard-fork, because the non-upgraded node *will heal=
* if the attack has less than 1/2 of the original-POW power in the long term=
.

Nothing about this proposal implies an attack. =46rom the Motivation section=
:

Mitigate centralization pressures by introducing a POW that does not have ec=
onomies of scale
Introduce an intermediary confirmation point, reducing the impact of mining p=
ower fluctuations

> The cost of such an attack is the cost of a normal "51%" attack, multiplie=
d by the fractional weight of the original POW (e.g. 0.75 or 0.5).
>=20
> So rather than saying this is a hard-fork, I would say that this is a soft=
-fork with reduced security for non-upgraded nodes.

Presumably this preference exists because it implies the new rule would not c=
ause a chain split, making it more acceptable to a risk-averse economy. This=
 is precisely why it should be described correctly.

> I would also say that the reduction in security is proportional to the red=
uction in weight of the original POW at the time of attack.
>=20
> As mentioned before, the original-POW weight starts at 1.0 and is reduced o=
ver a long period of time.  I would set up the transition curve so that all n=
odes upgrade by the time the weight is, say, 0.75.  In reality, nodes protec=
ting high economic value would upgrade early.

In reality you have no way to know if/when people would adopt this rule. Wha=
t matters in the proposal is that people who do adopt it are well aware of i=
ts ability to split them from the existing economy.

e

>> On Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org> wrote:
>> If a block that would be discarded under previous rules becomes accepted a=
fter a rule addition, there is no reason to not simply call the new rule a h=
ard fork. IOW it's perfectly rational to consider a weaker block as "invalid=
" relative to the strong chain. As such I don't see any reason to qualify th=
e term, it's a hard fork. But Peter's observation (the specific behavior) is=
 ultimately what matters.
>>=20
>> e
>>=20
>>> On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>>>=20
>>> +1 to all of Peter Todd's comments
>>>=20
>>>> On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
>>>> On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wro=
te:
>>>>=20
>>>> Some quick thoughts...
>>>>=20
>>>> > Hi all,
>>>> >
>>>> > Feedback is welcome on the draft below.  In particular, I want to see=
 if
>>>> > there is interest in further development of the idea and also interes=
ted in
>>>> > any attack vectors or undesirable dynamics.
>>>> >
>>>> > (Formatted version available here:
>>>> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>>>> >
>>>> > # Soft-fork Introduction of a New POW
>>>>=20
>>>> First of all, I don't think you can really call this a soft-fork; I'd c=
all it a
>>>> "pseudo-soft-fork"
>>>>=20
>>>> My reasoning being that after implementation, a chain with less total w=
ork than
>>>> the main chain - but more total SHA256^2 work than the main chain - mig=
ht be
>>>> followed by non-supporting clients. It's got some properties of a soft-=
fork,
>>>> but it's security model is definitely different.
>>>>=20
>>>> > ### Aux POW intermediate block
>>>> >
>>>> > Auxiliary POW blocks are introduced between normal blocks - i.e. the c=
hain
>>>> > alternates between the two POWs.
>>>> > Each aux-POW block points to the previous normal block and contains
>>>> > transactions just like a normal block.
>>>> > Each normal block points to the previous aux-POW block and must conta=
in all
>>>> > transactions from the aux-POW block.
>>>>=20
>>>> Note how you're basically proposing for the block interval to be decrea=
sed,
>>>> which has security implications due to increased orphan rates.
>>>>=20
>>>> > ### Heaviest chain rule change
>>>> >
>>>> > This is a semi-hard change, because non-upgraded nodes can get on the=
 wrong
>>>> > chain in case of attack.  However,
>>>>=20
>>>> Exactly! Not really a soft-fork.
>>>>=20
>>>> --
>>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>>>=20
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-2FF6A11F-75CD-431C-A0FB-CDA13D688580
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><span></span></div><div><meta http-equ=
iv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><div></div><div><=
br></div><div>On Nov 6, 2017, at 20:38, Devrandom &lt;<a href=3D"mailto:c1.b=
itcoin@niftybox.net">c1.bitcoin@niftybox.net</a>&gt; wrote:<br><br></div><bl=
ockquote type=3D"cite"><div><div dir=3D"ltr">A hard-fork is a situation wher=
e non-upgraded nodes reject a block mined and relayed by upgraded nodes. </d=
iv></div></blockquote><div><br></div><div>As Peter pointed out, that is the c=
ase here.</div><br><blockquote type=3D"cite"><div><div dir=3D"ltr">This crea=
tes a fork that cannot heal regardless of what follows.</div></div></blockqu=
ote><div><br></div><div>That is not a condition of the hard fork concept.</d=
iv><div><br></div><div><a href=3D"https://github.com/bitcoin/bips/blob/maste=
r/bip-0099.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-0099.m=
ediawiki</a></div><div><dl style=3D"box-sizing: border-box; margin-top: 0px;=
 margin-bottom: 16px; padding: 0px;"><dt style=3D"box-sizing: border-box; pa=
dding: 0px; margin-top: 16px; font-style: italic; font-weight: 600;"><span s=
tyle=3D"background-color: rgba(255, 255, 255, 0);">Softfork</span></dt></dl>=
<dl style=3D"box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; p=
adding: 0px;"><dd style=3D"box-sizing: border-box; padding: 0px 16px; margin=
-bottom: 16px;"><span style=3D"background-color: rgba(255, 255, 255, 0);">A c=
onsensus fork wherein everything that was previously invalid remains invalid=
 while blocks that would have previously considered valid become invalid. A h=
ashrate majority of miners can impose the new rules. They have some deployme=
nt advantages like backward compatibility.</span></dd></dl><dl style=3D"box-=
sizing: border-box; margin-top: 0px; margin-bottom: 16px; padding: 0px;"><dt=
 style=3D"box-sizing: border-box; padding: 0px; margin-top: 16px; font-style=
: italic; font-weight: 600;"><span style=3D"background-color: rgba(255, 255,=
 255, 0);">Hardfork</span></dt></dl><dl style=3D"box-sizing: border-box; mar=
gin-top: 0px; margin-bottom: 16px; padding: 0px;"><dd style=3D"box-sizing: b=
order-box; padding: 0px 16px; margin-bottom: 16px;"><span style=3D"backgroun=
d-color: rgba(255, 255, 255, 0);">A consensus fork that makes previously inv=
alid blocks valid. Hardforks require all users to upgrade.</span></dd></dl><=
/div><div><br></div><div>The essential element of a hard fork is that the ne=
w rule may cause rejection of blocks that are not rejected by old rules (the=
reby requiring that all users adopt the new rule in order to avoid a split).=
 The reason a hard fork is interesting is that it can create a chain split e=
ven if it is enforced by majority hash power.</div><div><br></div><div>That i=
s not the case with a soft fork and it is not the case here. A split can occ=
ur. The fact that it is possible for the split to also eventually orphan the=
 old nodes does not make it a soft fork. A soft fork requires that a hash po=
wer majority can impose the rule. However, under the proposed new rule the h=
ash power majority (according to the new rule) cannot impose the rule on exi=
sting nodes.</div><br><blockquote type=3D"cite"><div><div dir=3D"ltr"><div>T=
his proposal is not a hard-fork, because the non-upgraded node *will heal* i=
f the attack has less than 1/2 of the original-POW power in the long term.</=
div></div></div></blockquote><div><br></div><div>Nothing about this proposal=
 implies an attack. =46rom the Motivation section:</div><div><br></div><div>=
<ul style=3D"box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; p=
adding-left: 2em;"><li style=3D"box-sizing: border-box;"><span style=3D"back=
ground-color: rgba(255, 255, 255, 0);">Mitigate centralization pressures by i=
ntroducing a POW that does not have economies of scale</span></li><li style=3D=
"box-sizing: border-box; margin-top: 0.25em;"><span style=3D"background-colo=
r: rgba(255, 255, 255, 0);">Introduce an intermediary confirmation point, re=
ducing the impact of mining power fluctuations</span></li></ul></div><div><b=
r></div><blockquote type=3D"cite"><div><div dir=3D"ltr"><div>The cost of suc=
h an attack is the cost of a normal "51%" attack, multiplied by the fraction=
al weight of the original POW (e.g. 0.75 or 0.5).<br></div><div><br></div><d=
iv>So rather than saying this is a hard-fork, I would say that this is a sof=
t-fork with reduced security for non-upgraded nodes.</div></div></div></bloc=
kquote><div><br></div><div>Presumably this preference exists because it impl=
ies the new rule would not cause a chain split, making it more acceptable to=
 a risk-averse economy. This is precisely why it should be described correct=
ly.</div><br><blockquote type=3D"cite"><div><div dir=3D"ltr"><div> I would a=
lso say that the reduction in security is proportional to the reduction in w=
eight of the original POW at the time of attack.<br></div><div><br></div><di=
v>As mentioned before, the original-POW weight starts at 1.0 and is reduced o=
ver a long period of time.&nbsp; I would set up the transition curve so that=
 all nodes upgrade by the time the weight is, say, 0.75.&nbsp; In reality, n=
odes protecting high economic value would upgrade early.</div></div></div></=
blockquote><div><br></div><div>In reality you have no way to know if/when pe=
ople would adopt this rule. What matters in the proposal is that people who d=
o adopt it are well aware of its ability to split them from the existing eco=
nomy.</div><div><br></div><div>e</div><div><br></div><blockquote type=3D"cit=
e"><div><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On=
 Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"=
><div></div><div>If a block that would be discarded under previous rules bec=
omes accepted after a rule addition, there is no reason to not simply call t=
he new rule a hard fork. IOW it's perfectly rational to consider a weaker bl=
ock as "invalid" relative to the strong chain. As such I don't see any reaso=
n to qualify the term, it's a hard fork. But Peter's observation (the specif=
ic behavior) is ultimately what matters.</div></div><div dir=3D"auto"><div><=
br></div><div>e</div></div><div dir=3D"auto"><div><br>On Nov 6, 2017, at 12:=
30, Paul Sztorc via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>=
&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"auto">+1=
 to all of Peter Todd's comments</div><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">On Wed, Nov 01, 2017 at 05:48:27AM +0000, De=
vrandom via bitcoin-dev wrote:<br>
<br>
Some quick thoughts...<br>
<br>
&gt; Hi all,<br>
&gt;<br>
&gt; Feedback is welcome on the draft below.&nbsp; In particular, I want to s=
ee if<br>
&gt; there is interest in further development of the idea and also intereste=
d in<br>
&gt; any attack vectors or undesirable dynamics.<br>
&gt;<br>
&gt; (Formatted version available here:<br>
&gt; <a href=3D"https://github.com/devrandom/btc-papers/blob/master/aux-pow.=
md" rel=3D"noreferrer" target=3D"_blank">https://github.com/devrandom/btc-pa=
pers/blob/master/aux-pow.md</a> )<br>
&gt;<br>
&gt; # Soft-fork Introduction of a New POW<br>
<br>
First of all, I don't think you can really call this a soft-fork; I'd call i=
t a<br>
"pseudo-soft-fork"<br>
<br>
My reasoning being that after implementation, a chain with less total work t=
han<br>
the main chain - but more total SHA256^2 work than the main chain - might be=
<br>
followed by non-supporting clients. It's got some properties of a soft-fork,=
<br>
but it's security model is definitely different.<br>
<br>
&gt; ### Aux POW intermediate block<br>
&gt;<br>
&gt; Auxiliary POW blocks are introduced between normal blocks - i.e. the ch=
ain<br>
&gt; alternates between the two POWs.<br>
&gt; Each aux-POW block points to the previous normal block and contains<br>=

&gt; transactions just like a normal block.<br>
&gt; Each normal block points to the previous aux-POW block and must contain=
 all<br>
&gt; transactions from the aux-POW block.<br>
<br>
Note how you're basically proposing for the block interval to be decreased,<=
br>
which has security implications due to increased orphan rates.<br>
<br>
&gt; ### Heaviest chain rule change<br>
&gt;<br>
&gt; This is a semi-hard change, because non-upgraded nodes can get on the w=
rong<br>
&gt; chain in case of attack.&nbsp; However,<br>
<br>
Exactly! Not really a soft-fork.<br>
<br>
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">https=
://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"no=
referrer" target=3D"_blank">petertodd.org</a><br>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mailma=
n/listinfo/bitcoin-dev</a><br>
<br></blockquote></div></div>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.linuxfoundation.org</a></span><br><span><a href=3D=
"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_=
blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></s=
pan><br></div></blockquote></div>___________________________________________=
____<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mailma=
n/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>
</div></blockquote></div></body></html>=

--Apple-Mail-2FF6A11F-75CD-431C-A0FB-CDA13D688580--