diff options
author | Steven Pine <steven.pine@gmail.com> | 2016-02-07 17:25:40 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2016-02-07 22:25:42 +0000 |
commit | 2dde18bb8418ba00678cccf87dd97e8e34be24ce (patch) | |
tree | d018796e2291f351ef5c4112bdcdd6b5ab36c333 | |
parent | 7d9dd1c8c2c77e83fd4aa3a2b89227506f68d407 (diff) | |
download | pi-bitcoindev-2dde18bb8418ba00678cccf87dd97e8e34be24ce.tar.gz pi-bitcoindev-2dde18bb8418ba00678cccf87dd97e8e34be24ce.zip |
Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
-rw-r--r-- | 25/eae7d4bc7b3ad61e99617197b56a086d2b8bb3 | 410 |
1 files changed, 410 insertions, 0 deletions
diff --git a/25/eae7d4bc7b3ad61e99617197b56a086d2b8bb3 b/25/eae7d4bc7b3ad61e99617197b56a086d2b8bb3 new file mode 100644 index 000000000..6c8c9ec63 --- /dev/null +++ b/25/eae7d4bc7b3ad61e99617197b56a086d2b8bb3 @@ -0,0 +1,410 @@ +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 "very safe" and "significant= +ly faster", 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>"<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."</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">"Broad agre= +ement", 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't broad agreement. Also, resorting to "SHOUTING" doe= +sn'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"><<a href=3D"mailto:corey3@gmail.com" target=3D"= +_blank">corey3@gmail.com</a>></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'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: "upgrade or be kicked off the network&qu= +ot;.=C2=A0 In the previous cases it has been, "here's the latest a= +nd greatest, give it a go!".=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"><<a= + href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi= +tcoin-dev@lists.linuxfoundation.org</a>></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= +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">"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."</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 "<span style=3D"font-size:12.8px">Responding to &= +quot;28 days is not long enough" :</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 "28 days is plenty of time."</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)?"</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't Yifu's comment, evidence, the very best sort o= +f evidence, it isn'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's extremely frus= +trating to read Gavin's comments, it'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"><<a href=3D"mailto:bitcoin-dev@lists.li= +nuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<= +/a>></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> +> On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +> > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-= +dev<br> +wrote:<br> +</span><span>> > > If you have a node that is "old" your= + node will stop getting new<br> +> > > blocks. The node will essentially just say "x-hours beh= +ind" with "x"<br> +> > > getting larger every hour. Funds don't get confirmed. et= +c.<br> +> ><br> +> > Until someone decides to attack you. Then you'll get 6, 10, m= +aybe more<br> +> > blocks confirming a large 10000 BTC payment. If you're just a= + normal end<br> +> > user (or perhaps an automated system), you'll figure that pay= +ment is good<br> +> > and irreversibly hand over the title to the house.<br> +><br> +> There will be approximately zero percentage of hash power left on the<= +br> +> weaker branch of the fork, based on past soft-fork adoption by miners = +(they<br> +> upgrade VERY quickly from 75% to over 95%).<br> +<br> +</span>I'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'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-- + |