From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 631898DD for ; Sat, 15 Aug 2015 23:57:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0A0D71EA for ; Sat, 15 Aug 2015 23:57:34 +0000 (UTC) Received: by lbcbn3 with SMTP id bn3so62900341lbc.2 for ; Sat, 15 Aug 2015 16:57:32 -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=GmFI3iNDaGsxTgYb6POtR08ZzaBSsvEBEsO1TyKRuv8=; b=xmqwdivd5N/aga49owUm4AfeQm/mSaDN8AUhf4RFPCcmts4EY6dnnttsvmRmDG2xLf UtUNr7JH0iN9IzNq+nAHU38tDfp8uKbhKCHCMG4dmBjSrH/4DdQx7+OpD50bQDm7ddXU 1V3BJ2H8belERxhvlLyWwLH7/KeIhppyOkrgt9eowGykloTrQapzL9vZkd26deHy653a SDTThTAjezeSdKVcfw3oFfnENLN3j1MRzgWZPYmUfPdrkwJB4+JpqaIz/FsXXB8hrAOo MILs7EV9+6L29MScB77iP7OUm4E96pm7qBi6meYMTz6ikZHUoOh++l71k6qSw4tHmRwR ijMA== MIME-Version: 1.0 X-Received: by 10.112.157.136 with SMTP id wm8mr25654551lbb.26.1439683051666; Sat, 15 Aug 2015 16:57:31 -0700 (PDT) Received: by 10.25.62.147 with HTTP; Sat, 15 Aug 2015 16:57:31 -0700 (PDT) In-Reply-To: References: <90267BA3-06D8-412B-8FF6-BA21BCCA8AB8@gmail.com> Date: Sat, 15 Aug 2015 19:57:31 -0400 Message-ID: From: Ken Friece To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11c282c0e244d2051d625412 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 23:57:36 -0000 --001a11c282c0e244d2051d625412 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Let's start with the definition of a conflict of interest before we go any further: A *conflict of interest* (COI) is a situation in which a person or organization is involved in multiple interests (financial, emotional, or otherwise), one of which could possibly corrupt the motivation of the individual or organization. Just because a conflict of interest exists does not necessarily mean the individual with a conflict of interest has engaged in any wrongdoing. They could be a saint. However, to not even be able to acknowledge that such a conflict of interest exists when debating such a serious issue as the bitcoin blocksize is incredibly naive. On Sat, Aug 15, 2015 at 7:40 PM, Mark Friedenbach wrote: > Baseless accusations also have no place on this mailing list. They are > unprofessional, and poisonous to the consensus-building process we all se= ek > to engage in. > > The Lightning Network effort at Blockstream is purposefully structured to > avoid any conflict of interest. ALL code related to lightning is availabl= e > on Github. There is absolutely nothing that we are holding back, and the > protocol itself is entirely p2p. There is no privileged entity, Blockstre= am > or otherwise. > > On Sat, Aug 15, 2015 at 4:07 PM, Eric Lombrozo via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Please take the lightning 101 discussion to another thread. >> >> The main point I was trying to make was that Mike is clearly >> misrepresenting the views of a great number of people who have deep, >> intimate knowledge of how things work and are almost certainly not >> primarily motivated by their own potential for profits. >> >> On Aug 15, 2015, at 4:04 PM, Ken Friece via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> Being an early hub provider would be an obvious place to start >> capitalizing on lightning. Early lightning adopters would be in the best >> position to do this. >> >> Long term, Bitcoin needs to scale the blockchain in a reasonable manner >> and implement things like lightning. >> >> Limiting the blocksize is a blatant conflict of interest because it >> creates artificial demand for lightning that would not otherwise exist i= f >> the blockchain scaled in a reasonable manner. >> >> On Sat, Aug 15, 2015 at 6:55 PM, Mark Friedenbach >> wrote: >> >>> I would like very much to know how it is that we're supposed to be >>> making money off of lightning, and therefore how it represents a confli= ct >>> of interest. Apparently there is tons of money to be made in releasing >>> open-source protocols! I would hate to miss out on that. >>> >>> We are working on lightning because Mike of all people said, >>> essentially, " if you're so fond of micro payment channels, why aren't = you >>> working on them?" And he was right! So we looked around and found the b= est >>> proposal and funded it. >>> On Aug 15, 2015 3:28 PM, "Ken Friece via bitcoin-dev" < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> I know full well who works for Blockstream and I know you're not one o= f >>>> those folks. The Blockstream core devs are very vocal against a reason= able >>>> 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 blat= ant >>>> 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 m= eans >>>> 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-2= 56 >>>> ASIC mining hardware. >>>> >>>> On Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo >>>> 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 sta= tus >>>>> quo will remain for now. Network consensus, NOT CORE DEVELOPER CONSEN= SUS, >>>>> is the only thing that matters, and those that go against network con= sensus >>>>> will be severely punished with complete loss of income. >>>>> >>>>> >>>>> 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 source project - we=E2=80=99re talking about forking a ledger re= presenting >>>>> 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 an= y >>>>> change in the protocol might bring. And this would be true even if th= ere >>>>> were unanimous agreement that the change is good (which there clearly= IS >>>>> NOT in this case) but the deployment mechanism could still break thin= gs. >>>>> >>>>> 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 see= ms >>>>> like the core devs are scared to death that the bitcoin network may c= hange >>>>> 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 wit= h 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 co= mpany >>>>> (Blockstream) that stands to profit directly from artificially limiti= ng the >>>>> blocksize. The whole situation reeks. Because of such a blatant confl= ict of >>>>> interest, the ethical thing to do would be for them to either resign = from >>>>> Blockstream or immediately withdraw themselves from the blocksize deb= ate. >>>>> This is the type of stuff that I hoped would end with Bitcoin, but al= as, I >>>>> guess human nature never changes. >>>>> >>>>> >>>>> For the record, I do not work for Blockstream. Neither do a bunch of >>>>> other 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 mo= tivated >>>>> primarily by profit motives. >>>>> >>>>> It should also be pointed out that *not* making drastic changes is th= e >>>>> default consensus policy=E2=80=A6and the burden of justifying a chang= e falls on >>>>> those who want to make the change. Again, the risk of permanent ledge= r >>>>> 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 m= ake >>>>> any such claims. Again, I do not work for Blockstream=E2=80=A6and my = agenda in this >>>>> post is not to promote either of these ideas=E2=80=A6but with all due= respect, 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 out= side >>>>> forces and should not have complete control of the blocksize. It's al= so >>>>> interesting to note that most of the mining hashpower is already voti= ng for >>>>> 8MB blocks BIP100 style. >>>>> >>>>> >>>>> I don=E2=80=99t think the concern here is so much that some people wa= nt to >>>>> increase block size. It=E2=80=99s the *way* in which this change is b= eing 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 >>>>>> 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 capable of reading into the intentions of som= eone >>>>>> 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. >>>>>> >>>>>> I ask of you, as a civilized human being, to stop doing this divisiv= e >>>>>> crap. Despite your protestations to the contrary, YOU are the one wh= o is >>>>>> proposing a radical departure from the direction of the project. Als= o, as >>>>>> several of us have clearly stated before, equating the fork of an op= en >>>>>> source project with a fork of a cryptoledger is completely bogus - t= here=E2=80=99s >>>>>> a lot of other people=E2=80=99s money at stake. This isn=E2=80=99t a= democracy - 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 inv= ention 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 techn= ical abilities >>>>>> (and I sincerely do believe you have them) you are discrediting your= self >>>>>> 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 >>>>>> Bitcoin Core project has drifted so far from the principles myself a= nd many >>>>>> others 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. Ofte= n in >>>>>> forks, 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 Core (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 of 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 d= on't >>>>>> bite. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> > --001a11c282c0e244d2051d625412 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let's start with the definition of a conflict of inter= est before we go any further:
A conflict of inte= rest (COI) is a situation in which a person or organization is involved in multiple interests=20 (financial, emotional, or otherwise), one of which could possibly=20 corrupt the motivation of the individual or organization.
Just because a conflict of interest exists does not necessarily mean the = individual with a conflict of interest has enga= ged in any wrongdoing. They could be a saint. However, to not even be able = to acknowledge that such a conflict of interest exists when debating such a= serious issue as the bitcoin blocksize is incredibly naive.

On Sat, Aug 15, 2015 a= t 7:40 PM, Mark Friedenbach <mark@friedenbach.org> wrote:=
Baseless accusatio= ns also have no place on this mailing list. They are unprofessional, and po= isonous to the consensus-building process we all seek to engage in.

=
The Lightning Network effort at Blockstream is purposefully structure= d to avoid any conflict of interest. ALL code related to lightning is avail= able on Github. There is absolutely nothing that we are holding back, and t= he protocol itself is entirely p2p. There is no privileged entity, Blockstr= eam or otherwise.

On Sat, Aug 15, 2015 at 4:07 PM, Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wr= ote:
= Please take the lightning 101 discussion to another thread.

<= div>The main point I was trying to make was that Mike is clearly misreprese= nting the views of a great number of people who have deep, intimate knowled= ge of how things work and are almost certainly not primarily motivated by t= heir own potential for profits.

On Aug 15, 2015, at 4:04 PM, Ken Friece via bitcoin-dev &l= t;bitcoin-dev@lists.linuxfoundation.org> wrote:

Being an early hub provider would be an obvious place to start c= apitalizing on lightning. Early lightning adopters would be in the best pos= ition to do this.

Long term, Bitcoin needs to scale the blockchain in a reas= onable manner and implement things like lightning.

Limiting the blocksize is a blatant conflict of interest b= ecause it creates artificial demand for lightning that would not otherwise = exist if the blockchain scaled in a reasonable manner.

On Sat, Aug 15, 2015 at 6:5= 5 PM, Mark Friedenbach <mark@friedenbach.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

I would like very much to know= how it is that we're supposed to be making money off of lightning, and= therefore how it represents a conflict of interest. Apparently there is to= ns of money to be made in releasing open-source protocols! I would hate to = miss out on that.

We are working on lightning because Mik= e of all people said, essentially, " if you're so fond of micro pa= yment channels, why aren't you working on them?" And he was right!= So we looked around and found the best proposal and funded it.

On Aug 15, 2015 3:28 PM, "Ken Friece via bi= tcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
=
I know full well who works for Blockstream and I know you're not o= ne of those folks. The Blockstream core devs are very vocal against a reaso= nable blocksize increase (17% growth per year in Pieter's BIP is not wh= at I consider reasonable because it doesn't come close to keeping with = technological increases). I think we can both agree that more on-chain spac= e means less demand for lightning, and vice versa, which is a blatant confl= ict of interest.

I'm also trying to figure out how things = like lightning are not competing directly with miners for fees. More off-ch= ain transactions means less blockchain demand, which would lower on-chain f= ees. 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-2= 56 ASIC mining hardware.

On Sat, Aug 15, 2015 at 6:16 PM, Eric Lombr= ozo <elombrozo@gmail.com> wrote:

On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <bitco= in-dev@lists.linuxfoundation.org> wrote:

What are you so afraid of, Eric? If Mike's fork is succes= sful, consensus is reached around larger blocks. If it is rejected, the sta= tus quo will remain for now. Network consensus, NOT CORE DEVELOPER CONSENSU= S, is the only thing that matters, and those that go against network consen= sus will be severely punished with complete loss of income.
=

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 source project - we=E2=80= =99re talking about forking a ledger representing real assets that real peo= ple 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 in this case)= but the deployment mechanism could still break things.

If anything we should attempt a hard fork with a less contentious cha= nge first, just to test deployability.

I'm not sure who appoint= ed the core devs some sort of Bitcoin Gods that can hold up any change that= they happen to disagree with. It seems like the core devs are scared to de= ath 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 wi= th a far less contentious change first

<= div>
Despite significant past technical bitcoin achiev= ements, two of the most vocal opponents to a reasonable blocksize increase = work for a company (Blockstream) that stands to profit directly from artifi= cially limiting the 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 Bi= tcoin, but alas, I guess human nature never changes.
<= /blockquote>

For the record, I do not work for Blockstre= am. Neither do a bunch of other people who have published a number of conce= rns. Very few of the concerns I=E2=80=99ve seen from the technical communit= y seem to be motivated primarily by profit motives.

It should also be pointed out that *not* making drastic changes is the de= fault consensus policy=E2=80=A6and the burden of justifying a change falls = on those who want to make the change. Again, the risk of permanent ledger f= orks far outweighs whatever benefits protocol changes might bring.
Personally, I think m= iners should give Bitcoin XT a serious look. Miners need to realize that th= ey 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-c= hain transactions=E2=80=A6

Miners are NOT in direct competition with the lightning network and sidech= ains - these claims are patently false. I recommend you take a look at thes= e 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 agenda in this = post is not to promote either of these ideas=E2=80=A6but with all due respe= ct, I do not think you properly understand them at all.

The longer this debate drags on, t= he more I agree with BIP 100 and Jeff Garzik because the core devs are alre= ady being influenced by outside forces and should not have complete control= of the blocksize. It's also interesting to note that most of the minin= g hashpower is already voting for 8MB blocks BIP100 style. =C2=A0

I don=E2=80=99t think 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 deeply problematic.
=

On Sat, Aug 15, 2015 at = 5:32 PM, Eric Lombrozo via bitcoin-dev <bitcoin-dev@li= sts.linuxfoundation.org> wrote:
You deeply disappoint me, Mik= e.

Not only do you misrepresent 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 conc= erns=E2=80=A6you also seem to fancy yourself more capable of reading into t= he intentions of someone who disappeared from the scene years ago, before w= e even were fully aware of many things we now know that bring the original = =E2=80=9Cplan=E2=80=9D into question.

I ask of you= , as a civilized human being, to stop doing this divisive crap. Despite you= r 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 c= learly stated before, equating the fork of an open source project with a fo= rk of a cryptoledger is completely bogus - there=E2=80=99s a lot of other p= eople=E2=80=99s money at stake. This isn=E2=80=99t a democracy - consensus = is all or nothing. The fact that a good number of the people most intimatel= y familiar with the inner workings of Satoshi=E2=80=99s invention do not be= lieve doing this is a good idea should give you pause.

=
Please stop using Bitcoin as your own political football=E2=80=A6for t= he sake of Bitcoin=E2=80=A6and for your own sake. Despite your obvious tech= nical abilities (and I sincerely do believe you have them) you are discredi= ting 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
<= br>
=C2=A0 =C2=A0 =C2=A0https://bitcoinxt.software/

I feel sad that it's come to this, but there is no other way. The Bi= tcoin Core project has drifted so far from the principles myself and many o= thers feel are important, that a fork is the only way to fix things.
<= div>
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 t= his. Often in forks, 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 plan= s to be different from Core (assuming adoption, of course).

<= /div>
The article is here:


It makes no attempt to be neutral= : this explains things from our point of view.

The= manifesto is on the website.

I say to all develop= ers on this list: if you also feel that Core is no longer serving the inter= ests of Bitcoin users, come join us. We don't bite.

_______________________________________________
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/mail= man/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/mail= man/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/mail= man/listinfo/bitcoin-dev



--001a11c282c0e244d2051d625412--