MIME-Version: 1.0
In-Reply-To: <CAPg+sBig9O5+he0PWhTkX5iin14QLz5+eCCu6KfwU=DxntKYtg@mail.gmail.com>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
	<20151208110752.GA31180@amethyst.visucore.com>
	<CAPWm=eUomq6SBC0ky0WSs5=_G942vigm4RmgYuq0O-yJ-vqC2A@mail.gmail.com>
	<CAPg+sBig9O5+he0PWhTkX5iin14QLz5+eCCu6KfwU=DxntKYtg@mail.gmail.com>
Date: Mon, 21 Dec 2015 05:33:16 +0100
Message-ID: <CAPg+sBhQN2HDvH8dfq2VsQ0dTA9V=HgQsCJdP6B72fj1SDA4yw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11421f2eedb4d4052760fcb5
Cc: Gregory Maxwell <gmaxwell@gmail.com>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Precedence: list

--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

<p dir=3D"ltr">On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wro=
te:<br>
&gt; On Mon, Dec 07, 2015 at 10:02:17PM +0000, Gregory Maxwell via bitcoin-=
dev wrote:<br>
&gt;&gt; TL;DR: I propose we work immediately towards the segwit 4MB block<=
br>
&gt;&gt; soft-fork which increases capacity and scalability, and recent spe=
edups<br>
&gt;&gt; and incoming relay improvements make segwit a reasonable risk. BIP=
9<br>
&gt;&gt; and segwit will also make further improvements easier and faster t=
o<br>
&gt;&gt; deploy. We=E2=80=99ll continue to set the stage for non-bandwidth-=
increase-based<br>
&gt;&gt; scaling, while building additional tools that would make bandwidth=
<br>
&gt;&gt; increases safer long term. Further work will prepare Bitcoin for f=
urther<br>
&gt;&gt; increases, which will become possible when justified, while also p=
roviding<br>
&gt;&gt; the groundwork to make them justifiable.<br>
&gt;<br>
&gt; Sounds good to me.</p>
<p dir=3D"ltr">Better late than never, let me comment on why I believe purs=
uing this plan is important.</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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:<br>
* Give a short-term capacity bump<br>
* Show the world that scalability is being worked on<br>
* Actually improve scalability (as opposed to just scale) by reducing bandw=
idth/storage and indirectly improving the effectiveness of systems like Lig=
htning.<br>
* Solve several unrelated problems at the same time (fraud proofs, script e=
xtensibility, malleability, ...).</p>
<p dir=3D"ltr">So I&#39;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.</p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>

--001a11421f2eedb4d4052760fcb5--