Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 41C0DCB5 for ; Mon, 21 Dec 2015 04:50:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 584D7EE for ; Mon, 21 Dec 2015 04:50:23 +0000 (UTC) Received: by mail-io0-f179.google.com with SMTP id e126so143577323ioa.1 for ; Sun, 20 Dec 2015 20:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3dIT3D9CcbSq/lRXhpr5cMbkf8NwGa1oHNs+CtEMayM=; b=oMoSKtRHwgpDYodoz42GpRyyOB4lpe0cig5WCrHxkK3qsWbWuzcAj08GLRzBPo9uD1 qacIuAmyrIYCcvO+dfirUhUAuI/Di3F4L3GslLKvKUApvjd4tKioLCQw0VWjPhSmj9js WPdG3GRrtjw6hLZ9BDWTZ1E9vHwb14wW4KdTjbZjsjhbwAGT/BSoABAmxOVAqGvTyPSo kb/7e9HcUIcPF0h64PEx7p8bK7S34ik0iLOCcITsbcS2Jn5kT5DPP1tvtmyQhqbhD/Q2 obLp9rNk2F9vXbsvTI4+MxY+rmWtrdOc10AAp08nyZuNc+qYZ/hsKrRaPvzqdpK1aatX 1cPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3dIT3D9CcbSq/lRXhpr5cMbkf8NwGa1oHNs+CtEMayM=; b=Pd7+loDHdJmTSuODmIGGkdIOLr/1nnO+IuHDXJWaObIIoyWCq92RjySMjxvNkP/+PY ZcyoWvVP8CpnShX7M2vJHxF52/nZNYOl7jk7PsP8bVwZCSfma+cx6S2Kolt21ToXUGS6 safyzLrsYnVZogs/SPsr6FgsLDMGQTAv6Qfi9ouXItW7wLht/qTpQwn2tfDgj6ylKBDe z9khd7NqrE4epPNibwyuXsqvpuXI0t27dk+cpKPnYTGsLoIBDvNL+dKG+JfiRYmFCC2h IV+sSLsUUkIKd+C4nebe6a56Avu6YC0HFAvmUrkjzT3DywAo+ZF+83viaNIV06nr2HIA 1K1g== X-Gm-Message-State: ALoCoQklpfnZP5WL5U9L5K+ovTOezcwbvbaqHMI2kk7frljZZTkccDLdxlBY/j7eDXwiECulUF1934wp3CNbd6cSPPCltr0NLg== X-Received: by 10.107.130.90 with SMTP id e87mr2057889iod.77.1450673422717; Sun, 20 Dec 2015 20:50:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.132.193 with HTTP; Sun, 20 Dec 2015 20:50:03 -0800 (PST) X-Originating-IP: [49.218.55.28] In-Reply-To: References: <20151208110752.GA31180@amethyst.visucore.com> From: Mark Friedenbach Date: Mon, 21 Dec 2015 12:50:03 +0800 Message-ID: To: Pieter Wuille Content-Type: multipart/alternative; boundary=001a113eb42a0becbf0527613a91 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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:50:25 -0000 --001a113eb42a0becbf0527613a91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am fully in support of the plan laid out in "Capacity increases for the bitcoin system". This plan provides real benefit to the ecosystem in solving a number of longstanding problems in bitcoin. It improves the scalability of bitcoin considerably. Furthermore it is time that we stop bikeshedding, start implementing, and move forward, lest we lose more developers to the toxic atmosphere this hard-fork debacle has created. On Mon, Dec 21, 2015 at 12: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 > > --001a113eb42a0becbf0527613a91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am fully in support of the plan laid out in "C= apacity increases for the bitcoin system".

This plan prov= ides real benefit to the ecosystem in solving a number of longstanding prob= lems in bitcoin. It improves the scalability of bitcoin considerably.
Furthermore it is time that we stop bikeshedding, start implementing, and= move forward, lest we lose more developers to the toxic atmosphere this ha= rd-fork debacle has created.

On Mon, Dec 21, 2015 at 12:33 PM, Pieter Wuille via bi= tcoin-dev <bitcoin-dev@lists.linuxfoundation.org&g= t; 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 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


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


--001a113eb42a0becbf0527613a91--