diff options
| author | Ken Friece <kfriece@gmail.com> | 2015-08-15 18:28:15 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-15 22:28:19 +0000 |
| commit | 0dcf815e2721f117ed941daca39c92833117f949 (patch) | |
| tree | 636dc14ceff539733eb4bfab039e030c09fb2371 | |
| parent | 3a50453fd3a2a4f2f0d9c44bd2eb33978cfb2f62 (diff) | |
| download | pi-bitcoindev-0dcf815e2721f117ed941daca39c92833117f949.tar.gz pi-bitcoindev-0dcf815e2721f117ed941daca39c92833117f949.zip | |
Re: [bitcoin-dev] Bitcoin XT 0.11A
| -rw-r--r-- | 63/b628f112b9cd9c86183eabf20aeed19955755f | 440 |
1 files changed, 440 insertions, 0 deletions
diff --git a/63/b628f112b9cd9c86183eabf20aeed19955755f b/63/b628f112b9cd9c86183eabf20aeed19955755f new file mode 100644 index 000000000..2f7a30779 --- /dev/null +++ b/63/b628f112b9cd9c86183eabf20aeed19955755f @@ -0,0 +1,440 @@ +Return-Path: <kfriece@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id EEFF24D3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 15 Aug 2015 22:28:19 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-la0-f47.google.com (mail-la0-f47.google.com + [209.85.215.47]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CF46B11F + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 15 Aug 2015 22:28:17 +0000 (UTC) +Received: by lagz9 with SMTP id z9so60546806lag.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 15 Aug 2015 15:28:16 -0700 (PDT) +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 + :content-type; bh=ymEYLZysnc+UmdkebZYEitanuiVeVP82DJ5cHg1vMs8=; + b=tqopsBlb+YDTBRHXrPcNvuBe5Qd9Qu9RfgbSGJKphXh0Jji24EBfkBIRm1XqAB1XQ0 + k2TMuhu/LoP/xsCx7Gjx11wGMjeiYSG5loiJ6RAEIQO7RbPN9IGqhCY254hmmbg0P0L/ + MB0pDKgdRzh0XnIFjfwFGaLQH7vIn1zXNS62hTh122RMHhrd7M8hvFBLIkwhP232tvto + z6LG3LBdCOvK8CJYf5Z8VI2Ue8FEJZE5yRAC4rvGZlx7qdYyR9IvpasxnaXGwwBYYmd6 + lTODn9KdUtOafYmOLdC5IAtrkLifaRhPUWOk5uvOV7I1/ccethv6mWVzX1bP4aEgyt53 + XaMw== +MIME-Version: 1.0 +X-Received: by 10.152.20.196 with SMTP id p4mr49338080lae.121.1439677695851; + Sat, 15 Aug 2015 15:28:15 -0700 (PDT) +Received: by 10.25.62.147 with HTTP; Sat, 15 Aug 2015 15:28:15 -0700 (PDT) +In-Reply-To: <CC1B6D0E-F9D5-422B-980D-C589CDC00612@gmail.com> +References: <CA+w+GKT7t5OahS-+P=QAmOyFzPnOs4J6KSo+mhSrC0YggmMupg@mail.gmail.com> + <E7866FD5-9CEC-400F-8270-407499E0B012@gmail.com> + <CAKujSOFNHNngt0HV=B3YHxOwXksk+JZDaHt+mUVniwMPTM6SaA@mail.gmail.com> + <CC1B6D0E-F9D5-422B-980D-C589CDC00612@gmail.com> +Date: Sat, 15 Aug 2015 18:28:15 -0400 +Message-ID: <CAKujSOGdXoo4DORHtD7KV1fgjHzvcSQnUr=yNL4ruKhn1Lwjig@mail.gmail.com> +From: Ken Friece <kfriece@gmail.com> +To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary=089e013d203ca700f0051d6115f4 +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 +Subject: Re: [bitcoin-dev] Bitcoin XT 0.11A +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: Sat, 15 Aug 2015 22:28:20 -0000 + +--089e013d203ca700f0051d6115f4 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +I know full well who works for Blockstream and I know you're not one of +those folks. The Blockstream core devs are very vocal against a reasonable +blocksize increase (17% growth per year in Pieter's BIP is not what I +consider reasonable because it doesn't come close to keeping with +technological increases). I think we can both agree that more on-chain +space means less demand for lightning, and vice versa, which is a blatant +conflict of interest. + +I'm also trying to figure out how things like lightning are not competing +directly with miners for fees. More off-chain transactions means less +blockchain demand, which would lower on-chain fees. I'm not sure what is +controversial about that statement. + +The lightning network concept is actually a brilliant way to take fees away +from miners without having to make any investment at all in SSH-256 ASIC +mining hardware. + +On Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo <elombrozo@gmail.com> wrote: + +> +> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +> What are you so afraid of, Eric? If Mike's fork is successful, consensus +> is reached around larger blocks. If it is rejected, the status quo will +> remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is the +> only thing that matters, and those that go against network consensus will +> be severely punished with complete loss of income. +> +> +> I fully agree that core developers are not the only people who should hav= +e +> a say in this. But again, we=E2=80=99re not talking about merely forking = +some open +> source project - we=E2=80=99re talking about forking a ledger representin= +g real +> assets that real people are holding=E2=80=A6and I think it=E2=80=99s fair= + to say that the +> risk of permanent ledger forks far outweighs whatever benefits any change +> in the protocol might bring. And this would be true even if there were +> unanimous agreement that the change is good (which there clearly IS NOT i= +n +> this case) but the deployment mechanism could still break things. +> +> If anything we should attempt a hard fork with a less contentious change +> first, just to test deployability. +> +> I'm not sure who appointed the core devs some sort of Bitcoin Gods that +> can hold up any change that they happen to disagree with. It seems like t= +he +> core devs are scared to death that the bitcoin network may change without +> their blessing, so they go on and on about how terrible hard forks are. +> Hard forks are the only way to keep core devs in check. +> +> +> Again, let=E2=80=99s figure out a hard fork mechanism and test it with a = +far less +> contentious change first +> +> Despite significant past technical bitcoin achievements, two of the most +> vocal opponents to a reasonable blocksize increase work for a company +> (Blockstream) that stands to profit directly from artificially limiting t= +he +> blocksize. The whole situation reeks. Because of such a blatant conflict = +of +> interest, the ethical thing to do would be for them to either resign from +> Blockstream or immediately withdraw themselves from the blocksize debate. +> This is the type of stuff that I hoped would end with Bitcoin, but alas, = +I +> guess human nature never changes. +> +> +> For the record, I do not work for Blockstream. Neither do a bunch of othe= +r +> people who have published a number of concerns. Very few of the concerns +> I=E2=80=99ve seen from the technical community seem to be motivated prima= +rily by +> profit motives. +> +> It should also be pointed out that *not* making drastic changes is the +> default consensus policy=E2=80=A6and the burden of justifying a change fa= +lls on +> those who want to make the change. Again, the risk of permanent ledger +> forks far outweighs whatever benefits protocol changes might bring. +> +> Personally, I think miners should give Bitcoin XT a serious look. Miners +> need to realize that they are in direct competition with the lightning +> network and sidechains for fees. Miners, ask yourselves if you think you'= +ll +> earn more fees with 1 MB blocks and more off-chain transactions or with 8 +> MB blocks and more on-chain transactions=E2=80=A6 +> +> +> Miners are NOT in direct competition with the lightning network and +> sidechains - these claims are patently false. I recommend you take a look +> at these ideas and understand them a little better before trying to make +> any such claims. Again, I do not work for Blockstream=E2=80=A6and my agen= +da in this +> post is not to promote either of these ideas=E2=80=A6but with all due res= +pect, I do +> not think you properly understand them at all. +> +> The longer this debate drags on, the more I agree with BIP 100 and Jeff +> Garzik because the core devs are already being influenced by outside forc= +es +> and should not have complete control of the blocksize. It's also +> interesting to note that most of the mining hashpower is already voting f= +or +> 8MB blocks BIP100 style. +> +> +> I don=E2=80=99t think the concern here is so much that some people want t= +o +> increase block size. It=E2=80=99s the *way* in which this change is being= + pushed +> that is deeply problematic. +> +> On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +>> You deeply disappoint me, Mike. +>> +>> Not only do you misrepresent many cogent, well thought out positions fro= +m +>> a great number of people who have published and posted a number of artic= +les +>> detailing an explaining in-depth technical concerns=E2=80=A6you also see= +m to fancy +>> yourself more capable of reading into the intentions of someone who +>> disappeared from the scene years ago, before we even were fully aware of +>> many things we now know that bring the original =E2=80=9Cplan=E2=80=9D i= +nto question. +>> +>> I ask of you, as a civilized human being, to stop doing this divisive +>> crap. Despite your protestations to the contrary, YOU are the one who is +>> proposing a radical departure from the direction of the project. Also, a= +s +>> several of us have clearly stated before, equating the fork of an open +>> source project with a fork of a cryptoledger is completely bogus - there= +=E2=80=99s +>> a lot of other people=E2=80=99s money at stake. This isn=E2=80=99t a dem= +ocracy - consensus +>> is all or nothing. The fact that a good number of the people most +>> intimately familiar with the inner workings of Satoshi=E2=80=99s inventi= +on do not +>> believe doing this is a good idea should give you pause. +>> +>> Please stop using Bitcoin as your own political football=E2=80=A6for the= + sake of +>> Bitcoin=E2=80=A6and for your own sake. Despite your obvious technical ab= +ilities +>> (and I sincerely do believe you have them) you are discrediting yourself +>> and hurting your own reputation. +>> +>> +>> - Eric +>> +>> On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev < +>> bitcoin-dev@lists.linuxfoundation.org> wrote: +>> +>> Hello, +>> +>> As promised, we have released Bitcoin XT 0.11A which includes the bigger +>> blocks patch set. You can get it from +>> +>> https://bitcoinxt.software/ +>> +>> I feel sad that it's come to this, but there is no other way. The Bitcoi= +n +>> Core project has drifted so far from the principles myself and many othe= +rs +>> feel are important, that a fork is the only way to fix things. +>> +>> Forking is a natural thing in the open source community, Bitcoin is not +>> the first and won't be the last project to go through this. Often in for= +ks, +>> people say there was insufficient communication. So to ensure everything= + is +>> crystal clear I've written a blog post and a kind of "manifesto" to +>> describe why this is happening and how XT plans to be different from Cor= +e +>> (assuming adoption, of course). +>> +>> The article is here: +>> +>> https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1 +>> +>> It makes no attempt to be neutral: this explains things from our point o= +f +>> view. +>> +>> The manifesto is on the website. +>> +>> I say to all developers on this list: if you also feel that Core is no +>> longer serving the interests of Bitcoin users, come join us. We don't bi= +te. +>> +>> _______________________________________________ +>> 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 +> +> +> + +--089e013d203ca700f0051d6115f4 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div><div>I know full well who works for Blockstream and I= + know you're not one of those folks. The Blockstream core devs are very= + vocal against a reasonable blocksize increase (17% growth per year in Piet= +er's BIP is not what I consider reasonable because it doesn't come = +close to keeping with technological increases). I think we can both agree t= +hat more on-chain space means less demand for lightning, and vice versa, wh= +ich is a blatant conflict of interest.<br><br></div>I'm also trying to = +figure out how things like lightning are not competing directly with miners= + for fees. More off-chain transactions means less blockchain demand, which = +would lower on-chain fees. I'm not sure what is controversial about tha= +t statement.<br><br></div><div>The lightning network concept is actually a = +brilliant way to take fees away from miners without having to make any inve= +stment at all in SSH-256 ASIC mining hardware.<br></div><div><div><div><div= + class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Aug 15, 2015 = +at 6:16 PM, Eric Lombrozo <span dir=3D"ltr"><<a href=3D"mailto:elombrozo= +@gmail.com" target=3D"_blank">elombrozo@gmail.com</a>></span> wrote:<br>= +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div= +><blockquote type=3D"cite"><div>On Aug 15, 2015, at 3:01 PM, Ken Friece via= + bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t= +arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div>= +<br><div><div dir=3D"ltr"><div><div>What are you so afraid of, Eric? If Mik= +e's fork is successful, consensus is reached around larger blocks. If i= +t is rejected, the status quo will remain for now. Network consensus, NOT C= +ORE DEVELOPER CONSENSUS, is the only thing that matters, and those that go = +against network consensus will be severely punished with complete loss of i= +ncome.<br></div></div></div></div></blockquote><div><br></div>I fully agree= + that core developers are not the only people who should have a say in this= +. But again, we=E2=80=99re not talking about merely forking some open sourc= +e project - we=E2=80=99re talking about forking a ledger representing real = +assets that real people are holding=E2=80=A6and I think it=E2=80=99s fair t= +o say that the risk of permanent ledger forks far outweighs whatever benefi= +ts any change in the protocol might bring. And this would be true even if t= +here were unanimous agreement that the change is good (which there clearly = +IS NOT in this case) but the deployment mechanism could still break things.= +</div><div><br></div><div>If anything we should attempt a hard fork with a = +less contentious change first, just to test deployability.</div><div><div><= +br></div><blockquote type=3D"cite"><div><div dir=3D"ltr"><div><div>I'm = +not sure who appointed the core devs some sort of Bitcoin Gods that can hol= +d up any change that they happen to disagree with. It seems like the core d= +evs are scared to death that the bitcoin network may change without their b= +lessing, so they go on and on about how terrible hard forks are. Hard forks= + are the only way to keep core devs in check.</div></div></div></div></bloc= +kquote><div><br></div><div>Again, let=E2=80=99s figure out a hard fork mech= +anism and test it with a far less contentious change first</div><br><blockq= +uote type=3D"cite"><div><div dir=3D"ltr"><div>Despite significant past tech= +nical bitcoin achievements, two of the most vocal opponents to a reasonable= + blocksize increase work for a company (Blockstream) that stands to profit = +directly from artificially limiting the blocksize. The whole situation reek= +s. Because of such a blatant conflict of interest, the ethical thing to do = +would be for them to either resign from Blockstream or immediately withdraw= + themselves from the blocksize debate. This is the type of stuff that I hop= +ed would end with Bitcoin, but alas, I guess human nature never changes.<br= +></div></div></div></blockquote><div><br></div><div>For the record, I do no= +t work for Blockstream. Neither do a bunch of other people who have publish= +ed a number of concerns. Very few of the concerns I=E2=80=99ve seen from th= +e technical community seem to be motivated primarily by profit motives.</di= +v><div><br></div><div>It should also be pointed out that *not* making drast= +ic changes is the default consensus policy=E2=80=A6and the burden of justif= +ying a change falls on those who want to make the change. Again, the risk o= +f permanent ledger forks far outweighs whatever benefits protocol changes m= +ight bring.</div><br><blockquote type=3D"cite"><div><div dir=3D"ltr"><div>P= +ersonally, I think miners should give Bitcoin XT a serious look. Miners nee= +d to realize that they are in direct competition with the lightning network= + and sidechains for fees. Miners, ask yourselves if you think you'll ea= +rn more fees with 1 MB blocks and more off-chain transactions or with 8 MB = +blocks and more on-chain transactions=E2=80=A6<br></div></div></div></block= +quote><div><br></div>Miners are NOT in direct competition with the lightnin= +g network and sidechains - these claims are patently false. I recommend you= + take a look at these ideas and understand them a little better before tryi= +ng to make any such claims. Again, I do not work for Blockstream=E2=80=A6an= +d my agenda in this post is not to promote either of these ideas=E2=80=A6bu= +t with all due respect, I do not think you properly understand them at all.= +<br><br><blockquote type=3D"cite"><div><div dir=3D"ltr"><div>The longer thi= +s debate drags on, the more I agree with BIP 100 and Jeff Garzik because th= +e core devs are already being influenced by outside forces and should not h= +ave complete control of the blocksize. It's also interesting to note th= +at most of the mining hashpower is already voting for 8MB blocks BIP100 sty= +le. =C2=A0</div></div></div></blockquote><div><br></div>I don=E2=80=99t thi= +nk the concern here is so much that some people want to increase block size= +. It=E2=80=99s the *way* in which this change is being pushed that is deepl= +y problematic.</div><div><br><blockquote type=3D"cite"><div><div dir=3D"ltr= +"><div><div><div><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S= +at, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <span dir=3D"ltr= +"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b= +lank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><block= +quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= + solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>You deepl= +y disappoint me, Mike.</div><div><br></div><div>Not only do you misrepresen= +t many cogent, well thought out positions from a great number of people who= + have published and posted a number of articles detailing an explaining in-= +depth technical concerns=E2=80=A6you also seem to fancy yourself more capab= +le of reading into the intentions of someone who disappeared from the scene= + years ago, before we even were fully aware of many things we now know that= + bring the original =E2=80=9Cplan=E2=80=9D into question.</div><div><br></d= +iv><div>I ask of you, as a civilized human being, to stop doing this divisi= +ve crap. Despite your protestations to the contrary, YOU are the one who is= + proposing a radical departure from the direction of the project. Also, as = +several of us have clearly stated before, equating the fork of an open sour= +ce project with a fork of a cryptoledger is completely bogus - there=E2=80= +=99s a lot of other people=E2=80=99s money at stake. This isn=E2=80=99t a d= +emocracy - consensus is all or nothing. The fact that a good number of the = +people most intimately familiar with the inner workings of Satoshi=E2=80=99= +s invention do not believe doing this is a good idea should give you pause.= +</div><div><br></div><div>Please stop using Bitcoin as your own political f= +ootball=E2=80=A6for the sake of Bitcoin=E2=80=A6and for your own sake. Desp= +ite your obvious technical abilities (and I sincerely do believe you have t= +hem) you are discrediting yourself and hurting your own reputation.</div><d= +iv><br></div><div><br></div><div>- Eric</div><div><br></div><div><div><bloc= +kquote type=3D"cite"><div>On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitc= +oin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target= +=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><br><= +div><div dir=3D"ltr">Hello,<div><br></div><div>As promised, we have release= +d Bitcoin XT 0.11A which includes the bigger blocks patch set. You can get = +it from</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0<a href=3D"https://bit= +coinxt.software/" target=3D"_blank">https://bitcoinxt.software/</a><br></di= +v><div><br></div><div>I feel sad that it's come to this, but there is n= +o other way. The Bitcoin Core project has drifted so far from the principle= +s myself and many others feel are important, that a fork is the only way to= + fix things.</div><div><br></div><div>Forking is a natural thing in the ope= +n source community, Bitcoin is not the first and won't be the last proj= +ect to go through this. Often in forks, people say there was insufficient c= +ommunication. So to ensure everything is crystal clear I've written a b= +log post and a kind of "manifesto" to describe why this is happen= +ing and how XT plans to be different from Core (assuming adoption, of cours= +e).</div><div><br></div><div>The article is here:</div><div><br></div><div>= +=C2=A0 =C2=A0 <a href=3D"https://medium.com/@octskyward/why-is-bitcoin-fork= +ing-d647312d22c1" target=3D"_blank">https://medium.com/@octskyward/why-is-b= +itcoin-forking-d647312d22c1</a><br></div><div><br></div><div>It makes no at= +tempt to be neutral: this explains things from our point of view.</div><div= +><br></div><div>The manifesto is on the website.</div><div><br></div><div>I= + say to all developers on this list: if you also feel that Core is no longe= +r serving the interests of Bitcoin users, come join us. We don't bite.<= +/div><div><br></div></div> +_______________________________________________<br>bitcoin-dev mailing list= +<br><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla= +nk">bitcoin-dev@lists.linuxfoundation.org</a><br><a href=3D"https://lists.l= +inuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://= +lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></div></block= +quote></div><br></div></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></div></div> +_______________________________________________<br>bitcoin-dev mailing list= +<br><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla= +nk">bitcoin-dev@lists.linuxfoundation.org</a><br><a href=3D"https://lists.l= +inuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://= +lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></div></block= +quote></div><br></div></blockquote></div><br></div></div></div></div></div> + +--089e013d203ca700f0051d6115f4-- + |