Btc Drak [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-21 📝 Original message:On Mon, Dec 21, 2015 at ...
📅 Original date posted:2015-12-21
📝 Original message:On Mon, Dec 21, 2015 at 4:33 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at 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.
>
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151221/c11d08e4/attachment.html>;
📝 Original message:On Mon, Dec 21, 2015 at 4:33 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at 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.
>
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151221/c11d08e4/attachment.html>;