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 615F371F for ; Thu, 23 Jul 2015 18:10:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1879516A for ; Thu, 23 Jul 2015 18:10:24 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so5114830wib.1 for ; Thu, 23 Jul 2015 11:10:23 -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 :cc:content-type; bh=UxqRuImyl4n6xb8YspdOMXkUQ6xTiaG2QD6dC/G3E9Y=; b=SzwPGLrIdHU8BYrf6iPlMU2O6IuixvJdbeOFY7d5eHsbojo4/MkFx9x6J1X7LsOGMe 0jp0pQyOiX3CaWDX8f2I+DNqze1HH2O3N1cKmj/1MXLCnVBssagnGyYtO12jWAnKhiPr wecmblk42WDgZokpvt+vAiXG4T4oi7j7VEsFfE6zSNHRteR3Mzcj0ASJmVhME8ugCdKO mLAEyNDZSSx47HoFHX7/yesISA4gxBu2PBJzmvj54FOJtgCXISz3C5MChL5pClqBLdEG Tmta9tuXLpSEtD35fJWoEgbnmaz5i5lq3V7tqrBh/xOko3obZzUh0GVNe35TuQrdgUAs Zm6A== MIME-Version: 1.0 X-Received: by 10.180.86.129 with SMTP id p1mr53815114wiz.71.1437675022916; Thu, 23 Jul 2015 11:10:22 -0700 (PDT) Received: by 10.27.171.138 with HTTP; Thu, 23 Jul 2015 11:10:22 -0700 (PDT) In-Reply-To: References: <55B113AF.40500@thinlink.com> Date: Thu, 23 Jul 2015 14:10:22 -0400 Message-ID: From: Jameson Lopp To: Eric Lombrozo Content-Type: multipart/alternative; boundary=f46d044286300b226a051b8ecd9c 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks 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: Thu, 23 Jul 2015 18:10:25 -0000 --f46d044286300b226a051b8ecd9c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 23, 2015 at 1:43 PM, Eric Lombrozo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > I'd really like to move from "IMPOSSIBLE because... (electrum hasn't bee= n > optimized > (by the way: you should run on SSDs, LevelDB isn't designed for spinning > disks), > what if the network is attacked? (attacked HOW???), current p2p network > is using > the simplest, stupidest possible block propagation algorithm...)" > > ... to "lets work together and work through the problems and scale it up.= " > > > Let=E2=80=99s be absolutely clear about one thing - block size increases = are *not* > about scaling the network. Can we please stop promoting this falsehood? I= t > doesn=E2=80=99t matter by what number we multiply the block size=E2=80=A6= we can NEVER > satisfy the full demand if we insist on every single transaction from eve= ry > single person everywhere in the world being on the blockchain=E2=80=A6it= =E2=80=99s just > absurd. > > Increasing block size only temporarily addresses one significant issue - > how to postpone having to deal with transaction fees, which by design, ar= e > how the cost of operating the Bitcoin network (which is already very > expensive) is supposed to be paid for ultimately. Suggesting we avoid > dealing with this constitutes a new economic policy - dealing with it is > the default economic policy we=E2=80=99ve all known about from the beginn= ing=E2=80=A6so > please stop claiming otherwise. > > Larger block sizes don't scale the network, they merely increase how much load we allow the network to bear. On the flip side, the scalability proposals will still require larger blocks if we are ever to support anything close to resembling "mainstream" usage. This is not an either/or proposition - we clearly need both. - Jameson > On Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Why not help on a project that actually seems to offer great scalability > like the lightning network? There have been great progress there. > > > Exactly. There=E2=80=99s been tremendous progress here in addressing scal= ability, > yet I don=E2=80=99t see you participating in that discussion, Gavin. > > On Jul 23, 2015, at 5:17 AM, Jorge Tim=C3=B3n via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > But it seems to me that the "not now side" has no centralization > concerns at all and their true position is "not ever hit the blocksize > limit", that's the only explanation I can find to their lack of > answers to the "when do you think we should allow users to notice that > there's a limit in the blocksize to guarantee that the system can be > decentralized?". > > > I agree with what you=E2=80=99re saying, Jorge=E2=80=A6but It=E2=80=99s e= ven worse than that. The > July 4th fork illustrated that the security model of the network itself > could be at risk from the increasing costs in validation causing people t= o > rely on others to validate for them=E2=80=A6and increasing block size onl= y makes > the problem worse. > > - Eric Lombrozo > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --f46d044286300b226a051b8ecd9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 23, 2015 at 1:43 PM, Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

On Jul 23, 2015, at 9:28= AM, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.o= rg> wrote:

I'd really like to move f= rom "IMPOSSIBLE because... =C2=A0(electrum hasn't been optimized
(by the way: you should run on SSDs, LevelDB isn't de= signed for spinning disks),
what if the network is attac= ked? =C2=A0(attacked HOW???), current p2p network is using
the simplest, stupidest possible block propagation algorithm...)"<= /div>

... to "lets work together = and work through the problems and scale it up."

Let=E2=80=99s be absolutely clear about one thing -= block size increases are *not* about scaling the network. Can we please st= op promoting this falsehood? It doesn=E2=80=99t matter by what number we mu= ltiply the block size=E2=80=A6we can NEVER satisfy the full demand if we in= sist on every single transaction from every single person everywhere in the= world being on the blockchain=E2=80=A6it=E2=80=99s just absurd.
= =C2=A0
Increasing block size only temp= orarily addresses one significant issue - how to postpone having to deal wi= th transaction fees, which by design, are how the cost of operating the Bit= coin network (which is already very expensive) is supposed to be paid for u= ltimately. Suggesting we avoid dealing with this constitutes a new economic= policy - dealing with it is the default economic policy we=E2=80=99ve all = known about from the beginning=E2=80=A6so please stop claiming otherwise.


Larger block sizes don't scale the network, they merely increase= how much load we allow the network to bear. On the flip side, the scalabil= ity proposals will still require larger blocks if we are ever to support an= ything close to resembling "mainstream" usage. This is not an eit= her/or proposition - we clearly need both.

- James= on=C2=A0
On Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev <bitcoi= n-dev@lists.linuxfoundation.org> wrote:

Why not help on a= project that actually seems to offer great scalability like the lightning = network? There have been great progress there.

Exactly. There=E2= =80=99s been tremendous progress here in addressing scalability, yet I don= =E2=80=99t see you participating in that discussion, Gavin.

On Jul 23, 2015, at 5:17 AM, Jorge Tim=C3=B3n via bitco= in-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

<= div>But it seems to me = that the "not now side" has no centralization
concerns at all and their true p= osition is "not ever hit the blocksize
limit", that's the only explanation= I can find to their lack of
answers to the "when do you think we should allow user= s to notice that
there's a limit in the blocksize to guarantee that the system can b= e
decentraliz= ed?".

I agree with what you=E2=80=99re saying, Jorg= e=E2=80=A6but It=E2=80=99s even worse than that. The July 4th fork illustra= ted that the security model of the network itself could be at risk from the= increasing costs in validation causing people to rely on others to validat= e for them=E2=80=A6and increasing block size only makes the problem worse.<= /span>

- Eric = Lombrozo

____________________________________________= ___
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--f46d044286300b226a051b8ecd9c--