Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BF7EC3EE for ; Sat, 15 Aug 2015 22:27:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 61D8111F for ; Sat, 15 Aug 2015 22:27:21 +0000 (UTC) Received: by iodv127 with SMTP id v127so101062951iod.3 for ; Sat, 15 Aug 2015 15:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qTmT16EmGvZ3usewRSR/2XJ2jLzhp5EjL+DVJ6dwR3Y=; b=Nr6xc1PeTb9frmEKJbvH4tToz36GnhV7C+YWUht9C/J773DXR6+eXki9ZBj7E2loY7 ol7024ejI495TwgZ8msVkHI3bH9Enh0WnUXVa9e3VrgujJQWEjchTSryOIpht3i0gm9v 3JlFYzUAYnzsqo7z3+g4YNssqrFVIUWv2IL6pPDr/o/jAb8incLJmsPVXT52SZ0YU4f+ u5Pc1jLhqFFPO7x3zJzVXIFA1JAQ2Na/BimX1GjgX36xvJNw9Ib1U+yCJirI0jaBsJbo yGhoTkUBGcN+0LSmgq75utOBBxe5ZVyAQwdQxqXLlgHBBLsKfkotQ4HhBRoethblK6IG A0rA== X-Received: by 10.107.15.39 with SMTP id x39mr13548496ioi.156.1439677640810; Sat, 15 Aug 2015 15:27:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.122.144 with HTTP; Sat, 15 Aug 2015 15:27:01 -0700 (PDT) In-Reply-To: References: From: Angel Leon Date: Sat, 15 Aug 2015 18:27:01 -0400 Message-ID: To: Eric Lombrozo Content-Type: multipart/alternative; boundary=001a113ed93a5f29d0051d61120e 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 Cc: Bitcoin Dev 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 22:27:22 -0000 --001a113ed93a5f29d0051d61120e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "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 p= ushed that is deeply problematic." As a developer on the side lines, bitcoin holder, bitcoin entrepreneur, and someone who thinks block size limits should be dynamic, I applaud Mike and Co. for this initiative, some of us that have different ideas on how to deal with the blocksize issue will certainly not be afraid of wasting time sending patches to the Bitcoin XT project where it seems they're a bit more open minded about this issue. I bet sending the same patch to Bitcoin-Core would be rejected on the spot. Bitcoin XT, I hope, will give room to allow for scalability, it seems the other camp is bent on using Bitcoin their own way and their own way only and that's far more problematic because that will allienate the entire user base eventually. http://twitter.com/gubatron On Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> 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 > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a113ed93a5f29d0051d61120e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"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."

As a developer on the side lines, bitcoin holder,= bitcoin entrepreneur, and someone who thinks block size limits should be d= ynamic, I applaud Mike and Co. for this initiative, some of us that have di= fferent ideas on how to deal with the blocksize issue will certainly not be= afraid of wasting time sending patches to the Bitcoin XT project where it = seems they're a bit more open minded about this issue. I bet sending th= e same patch to Bitcoin-Core would be rejected on the spot. Bitcoin XT, I h= ope, will give room to allow for scalability, it seems the other camp is be= nt on using Bitcoin their own way and their own way only and that's far= more problematic because that will allienate the entire user base eventual= ly.


On Sat, Aug 15, 2015 at 6:16 PM, Eric Lombro= zo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.= org> 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, c= onsensus is reached around larger blocks. If it is rejected, the status quo= will remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is t= he only thing that matters, and those that go against network consensus wil= l be severely punished with complete loss of income.
<= /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 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 appointed the core devs some sort of Bitcoin Gods that can hold u= p any change that they happen to disagree with. It seems like the core devs= are scared to death that the bitcoin network may change without their bles= sing, so they go on and on about how terrible hard forks are. Hard forks ar= e 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 oppo= nents to a reasonable blocksize increase work for a company (Blockstream) t= hat stands to profit directly from artificially 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 typ= e of stuff that I hoped would end with Bitcoin, but alas, I guess human nat= ure never changes.

=
For the record, I do not work for Blockstream. Neither do a bunch of o= ther people who have published a number of concerns. Very few of the concer= ns I=E2=80=99ve seen from the technical community seem to be motivated prim= arily 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 falls on those who want to make= the change. Again, the risk of permanent ledger forks far outweighs whatev= er 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 competit= ion with the lightning network and sidechains for fees. Miners, ask yoursel= ves if you think you'll earn more fees with 1 MB blocks and more off-ch= ain transactions or with 8 MB blocks and more on-chain transactions=E2=80= =A6

Miners are NOT in dire= ct 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 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 m= ore I agree with BIP 100 and Jeff Garzik because the core devs are already = being influenced by outside forces and should not have complete control of = the blocksize. It's also interesting to note that most of the mining ha= shpower is already voting for 8MB blocks BIP100 style. =C2=A0

I don=E2=80=99t think the concern he= re is so much that some people want to increase block size. It=E2=80=99s th= e *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:
Yo= u deeply disappoint me, Mike.

Not only do you misr= epresent many cogent, well thought out positions from a great number of peo= ple who have published and posted a number of articles detailing an explain= ing in-depth technical concerns=E2=80=A6you also seem to fancy yourself mor= e capable of reading into the intentions of someone who disappeared from th= e scene years ago, before we even were fully aware of many things we now kn= ow 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 your protestations to the contrary, YOU are the one= who is proposing a radical departure from the direction of the project. Al= so, 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 - there= =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 invention do not believe doing this is a good idea should give y= ou pause.

Please stop using Bitcoin as your own po= litical football=E2=80=A6for the sake of Bitcoin=E2=80=A6and for your own s= ake. Despite your obvious technical abilities (and I sincerely do believe y= ou have them) you are discrediting yourself and hurting your own reputation= .


- Eric

<= div>
On Aug 15, 2015, at 10:02 AM, Mike Hearn= via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hello,

As promised, we hav= e released Bitcoin XT 0.11A which includes the bigger blocks patch set. You= can get it from

=C2=A0 =C2=A0 =C2=A0https://bitcoinxt.software/





It ma= kes no attempt to be neutral: this explains things from our point of view.<= /div>

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 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


--001a113ed93a5f29d0051d61120e--