path: root/63/b628f112b9cd9c86183eabf20aeed19955755f

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&#39;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&#39;s BIP is not what I consider reasonable because it doesn&#39;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&#39;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&#39;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">&lt;<a href=3D"mailto:elombrozo=
@gmail.com" target=3D"_blank">elombrozo@gmail.com</a>&gt;</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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div>=
<br><div><div dir=3D"ltr"><div><div>What are you so afraid of, Eric? If Mik=
e&#39;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&#39;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&#39;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&#39;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=
">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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&#39;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&#39;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&#39;ve written a b=
log post and a kind of &quot;manifesto&quot; 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&#39;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--