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 583B5FED for ; Mon, 21 Dec 2015 04:33:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DE68CE0 for ; Mon, 21 Dec 2015 04:33:17 +0000 (UTC) Received: by mail-io0-f182.google.com with SMTP id e126so143324126ioa.1 for ; Sun, 20 Dec 2015 20:33:17 -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=jC3N+4yH0gyhrSKwnJKcf1j8T4BnVBGamXIBwSD9xZ4=; b=IFfKfMfZ77rKHjpSfPhRjIIwCVsSddQWyv68qeoGAT4m8FYuXV2MOWuK4IhqaYq+jt y4dL823BuEckNn52pmEkrmJNOaCrPjXnIqbiRRcMWKoqsshbI7z4xHE7g0tMcvzAKrXA 0NT6YTq/IFEUFO8HRRCP2nOzzld+90LsaVNmpKMhq0G1U7ciVZDD/cVxhN6kJfvc5YFK LypvkpofN+dJaj9vorRxARGaS0Z5SD97iDLOJxXFim+aVEzi4zISLktZBTJUD4foxeo2 g6bGrwjWQFMIW4mEaDiSnlNPvJsHFdUZCU/k7p4n2VR1zv05MncD1xAucy7Gh4fqfuJU MJmA== MIME-Version: 1.0 X-Received: by 10.107.168.5 with SMTP id r5mr17356357ioe.126.1450672397331; Sun, 20 Dec 2015 20:33:17 -0800 (PST) Received: by 10.36.80.6 with HTTP; Sun, 20 Dec 2015 20:33:16 -0800 (PST) Received: by 10.36.80.6 with HTTP; Sun, 20 Dec 2015 20:33:16 -0800 (PST) In-Reply-To: References: <20151208110752.GA31180@amethyst.visucore.com> Date: Mon, 21 Dec 2015 05:33:16 +0100 Message-ID: From: Pieter Wuille To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11421f2eedb4d4052760fcb5 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: 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:33:18 -0000 --001a11421f2eedb4d4052760fcb5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 speedups >> 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-increa= se-based >> scaling, while building additional tools that would make bandwidth >> increases safer long term. Further work will prepare Bitcoin for further >> 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 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 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, and 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. --=20 Pieter --001a11421f2eedb4d4052760fcb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wro= te:
> 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.

--
Pieter

--001a11421f2eedb4d4052760fcb5--