Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4CA05E90 for ; Mon, 21 Dec 2015 05:22:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3E03910C for ; Mon, 21 Dec 2015 05:22:16 +0000 (UTC) Received: by mail-wm0-f54.google.com with SMTP id p187so53304558wmp.1 for ; Sun, 20 Dec 2015 21:22:16 -0800 (PST) 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=tbVYj0PzhvuxYQzIBFaS9TT/f2l8WgaNKpmta0hMwHs=; b=DOuY/r8eomUNXzdrDoWRyVgPW05RCQof8qIZaVfi4qPsD0hluN1/ikSxBv8+jXg7rf N/uhrD5+L3gm4fEnJItsC0gMz1a+3v07Z98hHJqGsp6OiSdKkvXA7yQljUwA2dTKcz4V w7a9amWsn0UxG4HO45H3+kHwNMDxb+yG3ua6klCDvIjuN0IR6jaashTf7dUWEEu/xTE2 PMD6HspprVBQXuVztiDXCDkR008IJEmxqoUmrFSidFI3BTuCiDNQ6j257DORwQMTqmnw ixT1lYzhIUooFkGfW8mVHzZ2ovIyxCGQOIhbfBmr/j0ELshvRVyTMarmvtLpMh0/FyGi q9qQ== X-Received: by 10.194.116.40 with SMTP id jt8mr20266270wjb.57.1450675334873; Sun, 20 Dec 2015 21:22:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.111.149 with HTTP; Sun, 20 Dec 2015 21:21:55 -0800 (PST) In-Reply-To: References: <20151208110752.GA31180@amethyst.visucore.com> From: Btc Drak Date: Mon, 21 Dec 2015 05:21:55 +0000 Message-ID: To: Pieter Wuille Content-Type: multipart/alternative; boundary=001a1130d0ae0506ae052761ace7 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, 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 05:22:17 -0000 --001a1130d0ae0506ae052761ace7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 21, 2015 at 4:33 AM, 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. > Thank you for saying this. I also think the plan is solid and delivers multiple benefits without being contentious. The number of wins are so numerous, it's frankly a no-brainer. I guess the next step for segwit is a BIP and deployment on a testnet? --001a1130d0ae0506ae052761ace7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 21, 2015 at 4:33 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

On Tue, Dec 8, 201= 5 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 need for= agreement on a hardfork has distracted from needed engineering work, fed t= he external impression that nothing is being done, and generally created a = toxic environment to work in. It has affected my own productivity and healt= h, 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.

T= hank you for saying this. I also think the plan is solid and delivers multi= ple benefits without being contentious. The number of wins are so numerous,= it's frankly a no-brainer.

I guess the ne= xt step for segwit is a BIP and deployment on a testnet?
=C2=A0

--001a1130d0ae0506ae052761ace7--