path: root/25/eae7d4bc7b3ad61e99617197b56a086d2b8bb3

Return-Path: <steven.pine@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8139AB14
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  7 Feb 2016 22:25:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com
	[209.85.214.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3B3F0100
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  7 Feb 2016 22:25:41 +0000 (UTC)
Received: by mail-ob0-f181.google.com with SMTP id wb13so133715988obb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 07 Feb 2016 14:25:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=rwwVs6gDo+mxWRbB1suBK7xYDZXC4+vdT4Ig2VMUp/k=;
	b=x0d0z9KtB+Lh434dbYmJXYqwGkcdSOvssENC8vuwQ00WrJjLGZqXEV2+QZvCLIKQ6o
	yqGs74GLWcR38V/rXHdxabICkN5teef2IXcxXQVsvmjkjET+qIJiM2m3TC7NE+AYB+J5
	cnvLzBb2To1HkaT1X0HrmH9mD4c6LOhNH6c2YFCqOv3/7pWB6/ODnx24eUsCh9KFYotY
	OtRAbpG613eykwKQPGLnc+3E1Vgb2/hGj+81ZIXE5rKR2s7G/pWCrgFwQYdmR860/oPU
	IbQca8tiB/SUNywYpgm37YpMjs9Kj8Iq9HRrS+aJletnzj04dfAXy/QVlhUfmIotZckv
	Sb0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=rwwVs6gDo+mxWRbB1suBK7xYDZXC4+vdT4Ig2VMUp/k=;
	b=NuB/j0vjiDZe7DHEd+mb2SkxhBCkpIyFOAwCvrPF65yOvJLcSWKrAI3yz9ObhcWogt
	tWyEhq/QpUKI5tmumP8LOIoN/UbX50ehDc58FIfrU4VvQe1LvBNVWLX/RrKOQeTONtOR
	CCvAuxtPzQt+vOMpWvjT0Z3FCvqhc58TQog1JFOISicCcGBi6waQOhN3riFgpmgMAxv4
	8Zaivg442/4r+dDBNxtt6Ajv8RI+aUxNRtMMmxf4ytQChdWjwQpl2jsA/mnDb7FAgfhi
	BozswnmTz2aJ3uwTy2qpxzNfN09J+MX/Fob0GKvc3+r7AVoLhF9maOwpQqCaGgXVBON+
	2r8A==
X-Gm-Message-State: AG10YOS/cI4Dd6CLMdEax3+0ZRNJJ8yW2vbwCC/IqOyhssV1KmIfyNiaK4G4T9Hec9xMBfQGS0SDc11ysFad8A==
MIME-Version: 1.0
X-Received: by 10.182.131.194 with SMTP id oo2mr21137715obb.84.1454883940632; 
	Sun, 07 Feb 2016 14:25:40 -0800 (PST)
Received: by 10.182.246.33 with HTTP; Sun, 7 Feb 2016 14:25:40 -0800 (PST)
In-Reply-To: <CAK_HAC-YDObNzgVYvrYYRPSEpa6CrLadqV+HSYggNZOtjAZGpA@mail.gmail.com>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
	<201602062046.40193.luke@dashjr.org>
	<CABsx9T0N_TBbmy3xr-mqNDdKVF_3_QHYA1W2ttsZBQnt4dWxgw@mail.gmail.com>
	<201602072101.15142.luke@dashjr.org>
	<CAAjy6kDd_1wY=Zrwnp4FZ_b0C0C06ThTLSPZq06Yjh178DuOkA@mail.gmail.com>
	<CAK_HAC-YDObNzgVYvrYYRPSEpa6CrLadqV+HSYggNZOtjAZGpA@mail.gmail.com>
Date: Sun, 7 Feb 2016 17:25:40 -0500
Message-ID: <CAAjy6kD4BDo+k0MMGEMiRd7p7=4_v4C84NXahcQR7kACgp24_w@mail.gmail.com>
From: Steven Pine <steven.pine@gmail.com>
To: Corey Haddad <corey3@gmail.com>
Content-Type: multipart/alternative; boundary=089e01634b8a788f9a052b3590a8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	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: Mon, 08 Feb 2016 00:48:13 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
	megabytes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 07 Feb 2016 22:25:42 -0000

--089e01634b8a788f9a052b3590a8
Content-Type: text/plain; charset=UTF-8

I agree that it seems like a safe assumption that adoption would be faster,
whether it is "very safe" and "significantly faster", whether it will be 6
times faster, all of those assumptions seems significantly less safe and
robust to me.

The nature of the bitcoin protocol, that it is a decentralized census based
protocol involving currency, suggests to me that roll out schedules ought
to be conservative with a minimum of assumptions. In light of the most
recent protocol upgrade, 6 months for this hard fork seems to me to be the
most conservative time frame with the fewest assumptions.

As for why it needs to be so fast, ie what are the dangers of it being as
slow as 6 months?

Gavin writes:

"I strongly disagree with the statement that there is no cost to a longer
grace period. There is broad agreement that a capacity increase is needed
NOW."

~~
"Broad agreement", that really seems to be another assumption, the fact
that the debate has been as long and acrimonious as it has been suggests
that there isn't broad agreement. Also, resorting to "SHOUTING" doesn't win
any favors when it comes to engaging in reasonable discussion om the
technical merits of a proposal.



On Sun, Feb 7, 2016 at 5:04 PM, Corey Haddad <corey3@gmail.com> wrote:

> We don't have any evidence of how fast nodes will upgrade when faced with
> an impending hard fork, but it seems like a very safe assumption that the
> upgrade pace will be significantly faster.  The hard fork case it is:
> "upgrade or be kicked off the network".  In the previous cases it has been,
> "here's the latest and greatest, give it a go!".  Also, there will be
> alerts sent out warning people of the situation, prompting them to take
> action.
>
> It is unclear if this will translate into more or less than 6x the
> adoption speed of previous instances, but the idea that it would be faster
> is solid.  28 days is aggressive, but again, it is only 28 days from when
> the fork triggers.  Compatible software is already available for anyone who
> wants to prepare.
>
> It is also of significance that this proposed fork, and this debate, has
> been going on for many, many months.  If someone proposed a forking concept
> today, wrote the BIP tomorrow, deployed it next week, miners adopted it
> instantly, and 28 days later it was the flag day, those 28 days would be in
> a different context.  There is no surprise here.
>
> On Sun, Feb 7, 2016 at 1:33 PM, Steven Pine via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Is it me or did Gavin ignore Yifu's direct questions? In case you missed
>> it Gavin --
>>
>> ~
>> "We can look at the adoption of the last major Bitcoin core release to
>> guess how long it might take people to upgrade. 0.11.0 was released on 12
>> July, 2015. Twenty eight days later, about 38% of full nodes were
>> running that release. Three months later, about 50% of the network was
>> running that release, and six months later about 66% of the network was
>> running some flavor of 0.11."
>>
>> On what grounds do you think it is reasonable to assume that this update
>> will roll out 6x faster than previous data suggested, as oppose to your own
>> observation of 66% adoption in 6 month. or do you believe 38% node
>> upgrade-coverage (in 28 days ) on the network for a hard fork is good
>> enough?
>>
>> There are no harm in choosing a longer grace period but picking one short
>> as 28 days you risk on alienating the nodes who do not upgrade with the
>> aggressive upgrade timeline you proposed.
>> ~~
>>
>> When Gavin writes "Responding to "28 days is not long enough" :
>>
>> I keep seeing this claim made with no evidence to back it up.  As I said,
>> I surveyed several of the biggest infrastructure providers and the btcd
>> lead developer and they all agree "28 days is plenty of time."
>>
>> For individuals... why would it take somebody longer than 28 days to
>> either download and restart their bitcoind, or to patch and then re-run
>> (the patch can be a one-line change MAX_BLOCK_SIZE from 1000000 to
>> 2000000)?"
>>
>> ~~
>>
>> Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't
>> propositional a priori logic, but empirical evidence that. As for why
>> people take longer, who knows, we simply know from passed experience that
>> it in fact does take longer.
>>
>> It's extremely frustrating to read Gavin's comments, it's hard to believe
>> he is engaging in earnest discussion.
>>
>> On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
>>> > On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
>>> > bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> > > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
>>> wrote:
>>> > > > If you have a node that is "old" your node will stop getting new
>>> > > > blocks. The node will essentially just say "x-hours behind" with
>>> "x"
>>> > > > getting larger every hour. Funds don't get confirmed. etc.
>>> > >
>>> > > Until someone decides to attack you. Then you'll get 6, 10, maybe
>>> more
>>> > > blocks confirming a large 10000 BTC payment. If you're just a normal
>>> end
>>> > > user (or perhaps an automated system), you'll figure that payment is
>>> good
>>> > > and irreversibly hand over the title to the house.
>>> >
>>> > There will be approximately zero percentage of hash power left on the
>>> > weaker branch of the fork, based on past soft-fork adoption by miners
>>> (they
>>> > upgrade VERY quickly from 75% to over 95%).
>>>
>>> I'm assuming there are literally ZERO miners left on the weaker branch.
>>> The attacker in this scenario simply rents hashing for a few days in
>>> advance
>>> to build his fake chain, then broadcasts the blocks to the unsuspecting
>>> merchant at ~10 block intervals so it looks like everything is working
>>> normal
>>> again. There are lots of mining rental services out there, and miners
>>> quite
>>> often do not care to avoid selling hashrate to the highest bidder
>>> regardless
>>> of what they're mining. 10 blocks worth costs a little more than 250 BTC
>>> -
>>> soon, that will be 125 BTC.
>>>
>>> Luke
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>>
>> --
>> Steven Pine
>> (510) 517-7075
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>


-- 
Steven Pine
(510) 517-7075

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

<div dir=3D"ltr">I agree that it seems like a safe assumption that adoption=
 would be faster, whether it is &quot;very safe&quot; and &quot;significant=
ly faster&quot;, whether it will be 6 times faster, all of those assumption=
s seems significantly less safe and robust to me.<div><br></div><div>The na=
ture of the bitcoin protocol, that it is a decentralized census based proto=
col involving currency, suggests to me that roll out schedules ought to be =
conservative with a minimum of assumptions. In light of the most recent pro=
tocol upgrade, 6 months for this hard fork seems to me to be the most conse=
rvative time frame with the fewest assumptions.</div><div><br></div><div>As=
 for why it needs to be so fast, ie what are the dangers of it being as slo=
w as 6 months?</div><div><br></div><div>Gavin writes:</div><div><br></div><=
div>&quot;<span style=3D"font-size:12.8px">I strongly disagree with the sta=
tement that there is no cost to a longer grace period. There is broad agree=
ment that a capacity increase is needed NOW.&quot;</span></div><div><span s=
tyle=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12=
.8px">~~</span></div><div><span style=3D"font-size:12.8px">&quot;Broad agre=
ement&quot;, that really seems to be another assumption, the fact that the =
debate has been as long and=C2=A0acrimonious as it has been suggests that t=
here isn&#39;t broad agreement. Also, resorting to &quot;SHOUTING&quot; doe=
sn&#39;t win any favors when it comes to engaging in reasonable discussion =
om the technical merits of a proposal.</span></div><div><span style=3D"font=
-size:12.8px">=C2=A0</span></div><div><br></div></div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On Sun, Feb 7, 2016 at 5:04 PM, Corey =
Haddad <span dir=3D"ltr">&lt;<a href=3D"mailto:corey3@gmail.com" target=3D"=
_blank">corey3@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div>We don&#39;t have any evidence of how fast node=
s will upgrade when faced with an impending hard fork, but it seems like a =
very safe assumption that the upgrade pace will be significantly faster.=C2=
=A0 The hard fork case it is: &quot;upgrade or be kicked off the network&qu=
ot;.=C2=A0 In the previous cases it has been, &quot;here&#39;s the latest a=
nd greatest, give it a go!&quot;.=C2=A0 Also, there will be alerts sent out=
 warning people of the situation, prompting them to take action.<br><br></d=
iv><div>It is unclear if this will translate into more or less than 6x the =
adoption speed of previous instances, but the idea that it would be faster =
is solid.=C2=A0 28 days is aggressive, but again, it is only 28 days from w=
hen the fork triggers.=C2=A0 Compatible software is already available for a=
nyone who wants to prepare.<br><br></div><div>It is also of significance th=
at this proposed fork, and this debate, has been going on for many, many mo=
nths.=C2=A0 If someone proposed a forking concept today, wrote the BIP tomo=
rrow, deployed it next week, miners adopted it instantly, and 28 days later=
 it was the flag day, those 28 days would be in a different context.=C2=A0 =
There is no surprise here. <br></div></div><div class=3D"HOEnZb"><div class=
=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, F=
eb 7, 2016 at 1:33 PM, Steven Pine via bitcoin-dev <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi=
tcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>Is it me or did Gavin ignore Yifu&#3=
9;s direct questions? In case you missed it Gavin --</div><div><br></div><d=
iv>~</div><span><span style=3D"font-size:12.8px">&quot;We can look at the a=
doption of the last major Bitcoin core release to guess how long it might t=
ake people to upgrade. 0.11.0 was released on 12 July, 2015. Twenty=C2=A0</=
span><span style=3D"font-size:12.8px"><span>eight days later</span></span><=
span style=3D"font-size:12.8px">, about 38% of full nodes were running that=
 release.=C2=A0</span><span style=3D"font-size:12.8px"><span>Three months l=
ater</span></span><span style=3D"font-size:12.8px">, about 50% of the netwo=
rk was running that release, and=C2=A0</span><span style=3D"font-size:12.8p=
x"><span>six months later</span></span><span style=3D"font-size:12.8px">=C2=
=A0about 66% of the network was running some flavor of 0.11.&quot;</span><d=
iv style=3D"font-size:12.8px"><br></div></span><div style=3D"font-size:12.8=
px">On what grounds do you think it is reasonable to assume that this updat=
e will roll out 6x faster than previous data suggested, as oppose to your o=
wn observation of 66% adoption=C2=A0<span><span>in 6 month</span></span>. o=
r do you believe 38% node upgrade-coverage (<span><span>in 28 days</span></=
span>=C2=A0) on the network for a hard fork is good enough?</div><span><div=
 style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">There=
 are no harm in choosing a longer grace period but picking one short as 28 =
days you risk on alienating the nodes who do not upgrade with the aggressiv=
e upgrade timeline you proposed.</div></span><div>~~</div><div><br></div><d=
iv>When Gavin writes &quot;<span style=3D"font-size:12.8px">Responding to &=
quot;28 days is not long enough&quot; :</span></div><span><div style=3D"fon=
t-size:12.8px"><br></div><div style=3D"font-size:12.8px">I keep seeing this=
 claim made with no evidence to back it up.=C2=A0 As I said, I surveyed sev=
eral of the biggest infrastructure providers and the btcd lead developer an=
d they all agree &quot;28 days is plenty of time.&quot;</div><div style=3D"=
font-size:12.8px"><br></div></span><span><div style=3D"font-size:12.8px">Fo=
r individuals... why would it take somebody longer than 28 days to either d=
ownload and restart their bitcoind, or to patch and then re-run (the patch =
can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?&quot;</di=
v><div style=3D"font-size:12.8px"><br></div></span><div style=3D"font-size:=
12.8px">~~</div><div style=3D"font-size:12.8px"><br></div><div style=3D"fon=
t-size:12.8px">Isn&#39;t Yifu&#39;s comment, evidence, the very best sort o=
f evidence, it isn&#39;t propositional a priori logic, but empirical eviden=
ce that. As for why people take longer, who knows, we simply know from pass=
ed experience that it in fact does take longer.</div><div style=3D"font-siz=
e:12.8px"><br></div><div style=3D"font-size:12.8px">It&#39;s extremely frus=
trating to read Gavin&#39;s comments, it&#39;s hard to believe he is engagi=
ng in earnest discussion.</div></div><div class=3D"gmail_extra"><div><div><=
br><div class=3D"gmail_quote">On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr v=
ia bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.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"><span>On Sunday, Fe=
bruary 07, 2016 2:16:02 PM Gavin Andresen wrote:<br>
&gt; On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev &lt;<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; &gt; On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-=
dev<br>
wrote:<br>
</span><span>&gt; &gt; &gt; If you have a node that is &quot;old&quot; your=
 node will stop getting new<br>
&gt; &gt; &gt; blocks. The node will essentially just say &quot;x-hours beh=
ind&quot; with &quot;x&quot;<br>
&gt; &gt; &gt; getting larger every hour. Funds don&#39;t get confirmed. et=
c.<br>
&gt; &gt;<br>
&gt; &gt; Until someone decides to attack you. Then you&#39;ll get 6, 10, m=
aybe more<br>
&gt; &gt; blocks confirming a large 10000 BTC payment. If you&#39;re just a=
 normal end<br>
&gt; &gt; user (or perhaps an automated system), you&#39;ll figure that pay=
ment is good<br>
&gt; &gt; and irreversibly hand over the title to the house.<br>
&gt;<br>
&gt; There will be approximately zero percentage of hash power left on the<=
br>
&gt; weaker branch of the fork, based on past soft-fork adoption by miners =
(they<br>
&gt; upgrade VERY quickly from 75% to over 95%).<br>
<br>
</span>I&#39;m assuming there are literally ZERO miners left on the weaker =
branch.<br>
The attacker in this scenario simply rents hashing for a few days in advanc=
e<br>
to build his fake chain, then broadcasts the blocks to the unsuspecting<br>
merchant at ~10 block intervals so it looks like everything is working norm=
al<br>
again. There are lots of mining rental services out there, and miners quite=
<br>
often do not care to avoid selling hashrate to the highest bidder regardles=
s<br>
of what they&#39;re mining. 10 blocks worth costs a little more than 250 BT=
C -<br>
soon, that will be 125 BTC.<br>
<div><div><br>
Luke<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div></div><=
/div><span><font color=3D"#888888">-- <br><div><div dir=3D"ltr"><div>Steven=
 Pine<div><a href=3D"tel:%28510%29%20517-7075" value=3D"+15105177075" targe=
t=3D"_blank">(510) 517-7075</a></div></div></div></div>
</font></span></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr"><div>Steven Pine<div>(510) =
517-7075</div></div></div></div>
</div>

--089e01634b8a788f9a052b3590a8--