Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EEFF24D3 for ; 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 ; Sat, 15 Aug 2015 22:28:17 +0000 (UTC) Received: by lagz9 with SMTP id z9so60546806lag.3 for ; 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: References: Date: Sat, 15 Aug 2015 18:28:15 -0400 Message-ID: From: Ken Friece To: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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.

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.

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.

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

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

If anything we should attempt a hard fork with a = less contentious change first, just to test deployability.
<= br>
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.

Again, let=E2=80=99s figure out a hard fork mech= anism and test it with a far less contentious change first

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.

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.

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.

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

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

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

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.

On S= at, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
You deepl= y disappoint me, Mike.

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.

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

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.


- Eric

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

<= div>
Hello,

As promised, we have release= d Bitcoin XT 0.11A which includes the bigger blocks patch set. You can get = it from

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

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.

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

The article is here:


It makes no at= tempt 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 longe= r serving the interests of Bitcoin users, come join us. We don't bite.<= /div>

_______________________________________________
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


--089e013d203ca700f0051d6115f4--