path: root/20/edf38b4b98ac3aa1664896aadcbc41d58255d8

Return-Path: <jacob.eliosoff@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CA1DCA7F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 23:01:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com
	[209.85.215.44])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C8C123D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 23:01:17 +0000 (UTC)
Received: by mail-lf0-f44.google.com with SMTP id m77so83680344lfe.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Jun 2017 16:01: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
	:cc; bh=p9s6QcEotuZPkICkk5/kgCUGF7TbvXsJituTxPgvtSk=;
	b=OPeYbiIQ1qh9870T6LRnQMGdgG9w3KTQeBymes/BoKNWaay2onVwdTqHx+sXyCZGSl
	FI6EA8TN0VxYS1tsJ0zr2DdGUIiaIJA2ZSOweogPT16ZwTVfLF2+I9WYZhDCdxeYCZQC
	dNgzOOoKVHjcY5Of6PtWxH03TGZ/gqvigS4HbC1ECwiz8qD0l+MbQfWKh34I5b61F9Qu
	BmUCktAUf3Kn2M7GmmXLJz1TzF0WQ7BZtS5QsBoRUzIxCCvz21whcJkFo/fJJseQVNW3
	WusyMPfnUWhhNWrJHH97ENK4dCrKf2XbhCXTNGl//Amlkm5YTWyDtPmZao7BBz6Nss1M
	iQ7g==
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:cc;
	bh=p9s6QcEotuZPkICkk5/kgCUGF7TbvXsJituTxPgvtSk=;
	b=hCNW2XENy+Ax0wmymjwI7rYyjiEKGyTnT6QVBCUERd1GfJIJ4+OT/brnhPSPNN2ote
	wHosM31vT1kjUHsbX0JJMDujwsmWzT+aU8PFhh6qhwve+4TXRrseR8/PZJYGuowUyOpN
	mFIhiwRZuNMpMqvYRGiwlh4hE+oHqyreaukZ2JusA3mXy2+KkswEO7D8UkSpD/RhciWa
	caEQ1QmD/+RkBN4X0Lk3xVU8KFujL3IbMOMobTOsfnB5lTLKfS09hJc0eXs4994BH28V
	Z4eyOj64v1BYiH1CxF+uN/16NTSuR5EN+192K0ZA9kNyfovw5DfQug55jxzwQYPEQQT+
	GBpg==
X-Gm-Message-State: AKS2vOylIfcMgyPHRvZCpsK8ze1N8oixwe3MbUQsJcOKJHro+1OWAP0v
	S1oFEb5wbqq0kpjWy+u2q/ms6M9KXA==
X-Received: by 10.46.88.78 with SMTP id x14mr8529208ljd.108.1497999675467;
	Tue, 20 Jun 2017 16:01:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.86.26 with HTTP; Tue, 20 Jun 2017 16:01:14 -0700 (PDT)
In-Reply-To: <CAAUaCyh+4m+t9d4yOoEOf6VUDyJ=sUpDT3hD3cDmd9dcBQZ+nw@mail.gmail.com>
References: <CAJowKgLtu-HUDuakk4DDU53nyChbQk_zY=f5OO2j1Za95PdL7w@mail.gmail.com>
	<CAAS2fgSZ_X3G7j3-S6tAGPe2TOTT2umBB8a0RHpD-wAHN9aPgw@mail.gmail.com>
	<CAFMkqK_73RrpaS2oJQ-0o6oC29m6a1h411_P7HmVcAyX712Sgw@mail.gmail.com>
	<CAAUaCyg2Nmsa2UaO2msBqSFeHLetUUN+cTETvSSmB7c=nH9ZhQ@mail.gmail.com>
	<BC758648-BD4F-4DEF-8B79-7E8E0A887033@friedenbach.org>
	<CAAUaCyh+4m+t9d4yOoEOf6VUDyJ=sUpDT3hD3cDmd9dcBQZ+nw@mail.gmail.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Tue, 20 Jun 2017 19:01:14 -0400
Message-ID: <CAAUaCyiDhHtn0rHt6D+gLqe_-UArUwBzomOdYXp4MnkqVFgfgw@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary="f403043878ec87b1ab05526c3aa5"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 21 Jun 2017 01:18:51 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Miners forced to run non-core code in order to
 get segwit activated
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: Tue, 20 Jun 2017 23:01:18 -0000

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

(That is: "...because they're mined by old non-Segwit2x nodes that *aren't
signaling bit 1 support*", ie, that support neither Segwit2x nor old segwit=
)


On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff <jacob.eliosoff@gmail.com>
wrote:

> I could be wrong, but the latest BIP91 implementation (also included in
> Segwit2x) cuts the activation period to 336 blocks (2.33 days).  (This ha=
s
> been updated at https://github.com/bitcoin/bips/blob/master/bip-0091.
> mediawiki.)  So if 80% of hashpower is actually running that code and
> signaling on bit 4 by July 25 or so, then those 80+% will start orphaning
> non-bit-1 blocks before Aug 1, and we avoid a split.
>
> There may still be a few non-bit-1 blocks that get orphaned after Aug 1,
> because they're mined by old BIP141 nodes.  But it seems like very few
> miners won't be signaling either Segwit2x *or* BIP141 by then...
>
> Make sense?
>
>
> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <mark@friedenbach.org>
> wrote:
>
>> Why do you say activation by August 1st is likely? That would require an
>> entire difficulty adjustment period with >=3D95% bit1 signaling. That se=
ems a
>> tall order to organize in the scant few weeks remaining.
>>
>> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> If segwit is activated before Aug 1, as now seems likely, there will be
>> no split that day.  But if activation is via Segwit2x (also likely), and=
 at
>> least some nodes do & some don't follow through with the HF 3mo later
>> (again, likely), agreed w/ Greg that *then* we'll see a split - probably=
 in
>> Sep/Oct.  How those two chains will match up and how the split will play
>> out is anyone's guess...
>>
>>
>>
>> On Jun 20, 2017 6:16 PM, "Hampus Sj=C3=B6berg via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> > Ironically, it looks like most of the segwit2x signaling miners are
>> > faking it (because they're not signaling segwit which it requires).
>> > It'll be unfortunate if some aren't faking it and start orphaning
>> > their own blocks because they are failing to signal segwit.
>>
>> Well, they're doing some kind of "pre-signaling" in the coinbase at the
>> moment, because the segwit2x project is still in alpha-phase according t=
o
>> the timeline. They're just showing commitment.
>> I'm sure they will begin signaling on version bit 4/BIP91 as well as
>> actually running a segwit2x node when the time comes.
>>
>>
>> > As far as prevent a chain split goes, all those things
>> > (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
>> > don't think that holds.
>>
>> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or
>> BIP148) node, because they wouldn't have the new consensus rule of
>> requiring all blocks to signal for segwit.
>> I don't believe there would be any long lasting chainsplit though
>> (because of the ~80% hashrate support on segwit2x), perhaps 2-3 blocks i=
f
>> we get unlucky.
>>
>> Hampus
>>
>> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org>:
>>
>>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> > Because a large percentage of miners are indifferent, right now miner=
s
>>> have
>>> > to choose between BIP148 and Segwit2x if they want to activate Segwit=
.
>>>
>>> Miners can simply continuing signaling segwit, which will leave them
>>> at least soft-fork compatible with BIP148 and BIP91 (and god knows
>>> what "segwit2x" is since they keep changing the actual definition and
>>> do not have a specification; but last I saw the near-term behavior the
>>> same as BIP91 but with a radically reduced activation window, so the
>>> story would be the same there in the near term).
>>>
>>> Ironically, it looks like most of the segwit2x signaling miners are
>>> faking it (because they're not signaling segwit which it requires).
>>> It'll be unfortunate if some aren't faking it and start orphaning
>>> their own blocks because they are failing to signal segwit.
>>>
>>> I don't think the rejection of segwit2x from Bitcoin's developers
>>> could be any more resolute than what we've already seen:
>>> https://en.bitcoin.it/wiki/Segwit_support
>>>
>>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> > I think it is very na=C3=AFve to assume that any shift would be tempo=
rary.
>>> > We have a hard enough time getting miners to proactively upgrade to
>>> > recent versions of the reference bitcoin daemon. If miners interpret
>>> > the situation as being forced to run non-reference software in order
>>> > to prevent a chain split because a lack of support from Bitcoin Core,
>>> > that could be a one-way street.
>>>
>>> I think this is somewhat naive and sounds a lot like the repeat of the
>>> previously debunked "XT" and "Classic" hysteria.
>>>
>>> There is a reason that segwit2x is pretty much unanimously rejected by
>>> the technical community.  And just like with XT/Classic/Unlimited
>>> you'll continue to see a strong correlation with people who are
>>> unwilling and unable to keep updating the software at an acceptable
>>> level of quality-- esp. because the very founding on their fork is
>>> predicated on discarding those properties.
>>>
>>> If miners want to go off and create an altcoin-- welp, thats something
>>> they can always do,  and nothing about that will force anyone to go
>>> along with it.
>>>
>>> As far as prevent a chain split goes, all those things
>>> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
>>> don't think that holds.
>>> _______________________________________________
>>> 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
>>
>>
>

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

<div dir=3D"ltr">(That is: &quot;...because they&#39;re mined by old non-Se=
gwit2x nodes that *aren&#39;t signaling bit 1 support*&quot;, ie, that supp=
ort neither Segwit2x nor old segwit)<br><div><br></div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jun 20, 2017 at 6:57 PM=
, Jacob Eliosoff <span dir=3D"ltr">&lt;<a href=3D"mailto:jacob.eliosoff@gma=
il.com" target=3D"_blank">jacob.eliosoff@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I could be wrong, but the =
latest BIP91 implementation (also included in Segwit2x) cuts the activation=
 period to 336 blocks (2.33 days). =C2=A0(This has been updated at <a href=
=3D"https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki" target=
=3D"_blank">https://github.com/bitcoin/<wbr>bips/blob/master/bip-0091.<wbr>=
mediawiki</a>.) =C2=A0So if 80% of hashpower is actually running that code =
and signaling on bit 4 by July 25 or so, then those 80+% will start orphani=
ng non-bit-1 blocks before Aug 1, and we avoid a split.<div><br></div><div>=
There may still be a few non-bit-1 blocks that get orphaned after Aug 1, be=
cause they&#39;re mined by old BIP141 nodes.=C2=A0 But it seems like very f=
ew miners won&#39;t be signaling either Segwit2x *or* BIP141 by then...</di=
v><div><br></div><div>Make sense?</div><div><br></div></div><div class=3D"H=
OEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@frieden=
bach.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"><div dir=
=3D"auto"><div>Why do you say activation by August 1st is likely? That woul=
d require an entire difficulty adjustment period with &gt;=3D95% bit1 signa=
ling. That seems a tall order to organize in the scant few weeks remaining.=
=C2=A0<br></div><div><div class=3D"m_-2731151123077402917h5"><div><br>On Ju=
n 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev &lt;<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list=
s.linuxfounda<wbr>tion.org</a>&gt; wrote:<br><br></div><blockquote type=3D"=
cite"><div><div dir=3D"auto"><div>If segwit is activated before Aug 1, as n=
ow seems likely, there will be no split that day.=C2=A0 But if activation i=
s via Segwit2x (also likely), and at least some nodes do &amp; some don&#39=
;t follow through with the HF 3mo later (again, likely), agreed w/ Greg tha=
t *then* we&#39;ll see a split - probably in Sep/Oct.=C2=A0 How those two c=
hains will match up and how the split will play out is anyone&#39;s guess..=
.<div dir=3D"auto"><br></div><br><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Jun 20, 2017 6:16 PM, &quot;Hampus Sj=C3=B6berg via bit=
coin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
 target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote=
:<br type=3D"attribution"><blockquote class=3D"m_-2731151123077402917m_6512=
25331209638612quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><div><div><div class=3D"m_-27311511=
23077402917m_651225331209638612quoted-text"><div>&gt; Ironically, it looks =
like most of the segwit2x signaling miners are<br>&gt; faking it (because t=
hey&#39;re not signaling segwit which it requires).<br>
&gt; It&#39;ll be unfortunate if some aren&#39;t faking it and start orphan=
ing<br>
&gt; their own blocks because they are failing to signal segwit.<br><br></d=
iv></div>Well, they&#39;re doing some kind of &quot;pre-signaling&quot; in =
the coinbase at the moment, because the segwit2x project is still in alpha-=
phase according to the timeline. They&#39;re just showing commitment.<br>I&=
#39;m sure they will begin signaling on version bit 4/BIP91 as well as actu=
ally running a segwit2x node when the time comes.<div class=3D"m_-273115112=
3077402917m_651225331209638612quoted-text"><br><br>&gt; As far as prevent a=
 chain split goes, all those things<br>&gt; (148/91/segwit2x(per today)) ef=
fectively guarantee a chainsplit-- so I<br>&gt; don&#39;t think that holds.=
<br><br></div></div> Segwit2x/BIP91/BIP148 will orphan miners that do not r=
un a Segwit2x (or BIP148) node, because they wouldn&#39;t have the new cons=
ensus rule of requiring all blocks to signal for segwit.<br></div>I don&#39=
;t believe there would be any long lasting chainsplit though (because of th=
e ~80% hashrate support on segwit2x), perhaps 2-3 blocks if we get unlucky.=
<br><br></div>Hampus<br></div><div class=3D"m_-2731151123077402917m_6512253=
31209638612elided-text"><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <span dir=
=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt;</span>:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><span>On Tue, Jun 20, 2017 at 3:44 PM, Erik =
Aronesty via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br>
&gt; Because a large percentage of miners are indifferent, right now miners=
 have<br>
&gt; to choose between BIP148 and Segwit2x if they want to activate Segwit.=
<br>
<br>
</span>Miners can simply continuing signaling segwit, which will leave them=
<br>
at least soft-fork compatible with BIP148 and BIP91 (and god knows<br>
what &quot;segwit2x&quot; is since they keep changing the actual definition=
 and<br>
do not have a specification; but last I saw the near-term behavior the<br>
same as BIP91 but with a radically reduced activation window, so the<br>
story would be the same there in the near term).<br>
<br>
Ironically, it looks like most of the segwit2x signaling miners are<br>
faking it (because they&#39;re not signaling segwit which it requires).<br>
It&#39;ll be unfortunate if some aren&#39;t faking it and start orphaning<b=
r>
their own blocks because they are failing to signal segwit.<br>
<br>
I don&#39;t think the rejection of segwit2x from Bitcoin&#39;s developers<b=
r>
could be any more resolute than what we&#39;ve already seen:<br>
<a href=3D"https://en.bitcoin.it/wiki/Segwit_support" rel=3D"noreferrer" ta=
rget=3D"_blank">https://en.bitcoin.it/wiki/Seg<wbr>wit_support</a><br>
<br>
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev<br>
<span>&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br>
&gt; I think it is very na=C3=AFve to assume that any shift would be tempor=
ary.<br>
&gt; We have a hard enough time getting miners to proactively upgrade to<br=
>
&gt; recent versions of the reference bitcoin daemon. If miners interpret<b=
r>
&gt; the situation as being forced to run non-reference software in order<b=
r>
&gt; to prevent a chain split because a lack of support from Bitcoin Core,<=
br>
&gt; that could be a one-way street.<br>
<br>
</span>I think this is somewhat naive and sounds a lot like the repeat of t=
he<br>
previously debunked &quot;XT&quot; and &quot;Classic&quot; hysteria.<br>
<br>
There is a reason that segwit2x is pretty much unanimously rejected by<br>
the technical community.=C2=A0 And just like with XT/Classic/Unlimited<br>
you&#39;ll continue to see a strong correlation with people who are<br>
unwilling and unable to keep updating the software at an acceptable<br>
level of quality-- esp. because the very founding on their fork is<br>
predicated on discarding those properties.<br>
<br>
If miners want to go off and create an altcoin-- welp, thats something<br>
they can always do,=C2=A0 and nothing about that will force anyone to go<br=
>
along with it.<br>
<br>
As far as prevent a chain split goes, all those things<br>
(148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I<br>
don&#39;t think that holds.<br>
<div class=3D"m_-2731151123077402917m_651225331209638612m_-1870741167812905=
09HOEnZb"><div class=3D"m_-2731151123077402917m_651225331209638612m_-187074=
116781290509h5">______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
</div></div></blockquote></div><br></div>
</div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
<br></blockquote></div><br></div></div></div>
</div></blockquote><blockquote type=3D"cite"><div><span>___________________=
___________<wbr>_________________</span><br><span>bitcoin-dev mailing list<=
/span><br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a></span><br><s=
pan><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/mailman/listin=
fo/bitcoin-d<wbr>ev</a></span><br></div></blockquote></div></div></div></bl=
ockquote></div><br></div>
</div></div></blockquote></div><br></div>

--f403043878ec87b1ab05526c3aa5--