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 speedups > >> and incoming relay improvements make segwit a reasonable risk. BIP9 > >> and segwit will also make further improvements easier and faster to > >> deploy. We’ll 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 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. > > -- > Pieter > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
