Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0995EA95 for ; Mon, 21 Dec 2015 04:44:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5032DEE for ; Mon, 21 Dec 2015 04:44:50 +0000 (UTC) Received: by mail-io0-f180.google.com with SMTP id o67so143323196iof.3 for ; Sun, 20 Dec 2015 20:44:50 -0800 (PST) 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=XPtcRr5j0hMJbD9o2KopS5Eo3FxuSILrHa7IGwbeFKM=; b=N1YsRm9fhNrnOYXG/rry+LCMYiLCJdtkQm7CCR7z1FeT32yX8ZwTkBQNGLC4B1VLeR japPctog8H6Ts1epkLcILiWhuDsKpDtigUUWfKlpyh/Fdc9FJFS1q1QWL4KHaL2VxMIu f9WBhR60ga3Pst51kSqfTUy7VxobRmwQuJFFmgYFlj3kKKBvUBseD+Tn2oqjqv134t94 ej1A0DMI+qW1eEQ+T8eYz78P/XTSmvSnJvyMfxPxds5qw/J08SMn7TYJZwqgBpyja037 4sMq1A0aC1PyQucaJxPMRA5tuI1WjJZc/d1NKvHyA8DIBb7A6vfJyCoOym9r3TaiNZB6 f9DQ== MIME-Version: 1.0 X-Received: by 10.107.39.193 with SMTP id n184mr17497568ion.14.1450673089842; Sun, 20 Dec 2015 20:44:49 -0800 (PST) Received: by 10.64.25.18 with HTTP; Sun, 20 Dec 2015 20:44:49 -0800 (PST) In-Reply-To: References: <20151208110752.GA31180@amethyst.visucore.com> Date: Sun, 20 Dec 2015 23:44:49 -0500 Message-ID: From: Alex Morcos To: Pieter Wuille Content-Type: multipart/alternative; boundary=001a11407fec3492ec05276126b5 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 , Gregory Maxwell Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system. 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: Mon, 21 Dec 2015 04:44:51 -0000 --001a11407fec3492ec05276126b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm also strongly in favor of moving forward with this plan. A couple of points: 1) There has been too much confusion in looking at segwit as an alternative way to increase the block size and I think that is incorrect. It should not be drawn into the block size debate as it brings many needed improvements and tools we'd want even if no one were worried about block size now. 2) The full capacity increase plan Greg lays out makes it clear that we can accomplish a tremendous amount without a contentious hard fork at this point. 3) Let's stop arguing endlessly and actually do work that will benefit everyone. On Sun, Dec 20, 2015 at 11:33 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wrote: > > On Mon, Dec 07, 2015 at 10:02:17PM +0000, Gregory Maxwell via > bitcoin-dev wrote: > >> TL;DR: I propose we work immediately towards the segwit 4MB block > >> soft-fork which increases capacity and scalability, and recent speedup= s > >> and incoming relay improvements make segwit a reasonable risk. BIP9 > >> and segwit will also make further improvements easier and faster to > >> deploy. We=E2=80=99ll continue to set the stage for non-bandwidth-incr= ease-based > >> scaling, while building additional tools that would make bandwidth > >> increases safer long term. Further work will prepare Bitcoin for furth= er > >> increases, which will become possible when justified, while also > providing > >> the groundwork to make them justifiable. > > > > Sounds good to me. > > Better late than never, let me comment on why I believe pursuing this pla= n > is important. > > For months, the block size debate, and the apparent need for agreement on > a hardfork has distracted from needed engineering work, fed the external > impression that nothing is being done, and generally created a toxic > environment to work in. It has affected my own productivity and health, a= nd > I do not think I am alone. > > I believe that soft-fork segwit can help us out of this deadlock and get > us going again. It does not require the pervasive assumption that the > entire world will simultaneously switch to new consensus rules like a > hardfork does, while at the same time: > * Give a short-term capacity bump > * Show the world that scalability is being worked on > * Actually improve scalability (as opposed to just scale) by reducing > bandwidth/storage and indirectly improving the effectiveness of systems > like Lightning. > * Solve several unrelated problems at the same time (fraud proofs, script > extensibility, malleability, ...). > > So I'd like to ask the community that we work towards this plan, as it > allows to make progress without being forced to make a possibly divisive > choice for one hardfork or another yet. > > -- > Pieter > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a11407fec3492ec05276126b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm also strongly in favor of moving forward with this= plan.

A couple of points:
1) There has been t= oo much confusion in looking at segwit as an alternative way to increase th= e block size and I think that is incorrect.=C2=A0 It should not be drawn in= to the block size debate as it brings many needed improvements and tools we= 'd want even if no one were worried about block size now.
2) = The full capacity increase plan Greg lays out makes it clear that we can ac= complish a tremendous amount without a contentious hard fork at this point.=
3) Let's stop arguing endlessly and actually do work that wi= ll benefit everyone.




On Sun, Dec 20,= 2015 at 11:33 PM, Pieter Wuille via bitcoin-dev <bitc= oin-dev@lists.linuxfoundation.org> wrote:

On Tue, Dec 8, 2015 at 6:07 = AM, Wladimir J. van der Laan wrote:
> On Mon, Dec 07, 2015 at 10:02:17PM +0000, Gregory Maxwell via bitcoin-= dev wrote:
>> TL;DR: I propose we work immediately towards the segwit 4MB block<= br> >> soft-fork which increases capacity and scalability, and recent spe= edups
>> and incoming relay improvements make segwit a reasonable risk. BIP= 9
>> and segwit will also make further improvements easier and faster t= o
>> deploy. We=E2=80=99ll continue to set the stage for non-bandwidth-= increase-based
>> scaling, while building additional tools that would make bandwidth=
>> increases safer long term. Further work will prepare Bitcoin for f= urther
>> increases, which will become possible when justified, while also p= roviding
>> the groundwork to make them justifiable.
>
> Sounds good to me.

Better late than never, let me comment on why I believe purs= uing this plan is important.

For months, the block size debate, and the apparent n= eed for agreement on a hardfork has distracted from needed engineering work= , fed the external impression that nothing is being done, and generally cre= ated a toxic environment to work in. It has affected my own productivity an= d health, and I do not think I am alone.

I believe that soft-fork segwit can help us out of this dead= lock and get us going again. It does not require the pervasive assumption t= hat the entire world will simultaneously switch to new consensus rules like= a hardfork does, while at the same time:
* Give a short-term capacity bump
* Show the world that scalability is being worked on
* Actually improve scalability (as opposed to just scale) by reducing bandw= idth/storage and indirectly improving the effectiveness of systems like Lig= htning.
* Solve several unrelated problems at the same time (fraud proofs, script e= xtensibility, malleability, ...).

So I'd like to ask the community that we work towards th= is plan, as it allows to make progress without being forced to make a possi= bly divisive choice for one hardfork or another yet.

-= -
Pieter


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


--001a11407fec3492ec05276126b5--