📅 Original date posted:2015-12-21
📝 Original message: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 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.
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151221/fa4c9349/attachment.html>;
Mark Friedenbach [ARCHIVE] /
npub1r3…48d0u
2023-06-07 17:45:49
in reply to nevent1q…nmv8
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 17:45:49Event JSON
{
"id": "f17cf988f589c3bf64e9e8a586544fe5cf4224b3daafbe08f040d206ddbe3d0f",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686159949,
"kind": 1,
"tags": [
[
"e",
"558b0da1f3869961bbef0556878e1dd6b9ae37e86128bc130bab17f5332c918d",
"",
"root"
],
[
"e",
"220b7913a6b2fbc0b3b52c75b57f254f559998e05c33a27efa0273e850414518",
"",
"reply"
],
[
"p",
"78aa6925095b629d95a9e79aed6ed9da0973239bc6eedf11af42240f0e1d755c"
]
],
"content": "📅 Original date posted:2015-12-21\n📝 Original message:I am fully in support of the plan laid out in \"Capacity increases for the\nbitcoin system\".\n\nThis plan provides real benefit to the ecosystem in solving a number of\nlongstanding problems in bitcoin. It improves the scalability of bitcoin\nconsiderably.\n\nFurthermore it is time that we stop bikeshedding, start implementing, and\nmove forward, lest we lose more developers to the toxic atmosphere this\nhard-fork debacle has created.\n\nOn Mon, Dec 21, 2015 at 12:33 PM, Pieter Wuille via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wrote:\n\u003e \u003e On Mon, Dec 07, 2015 at 10:02:17PM +0000, Gregory Maxwell via\n\u003e bitcoin-dev wrote:\n\u003e \u003e\u003e TL;DR: I propose we work immediately towards the segwit 4MB block\n\u003e \u003e\u003e soft-fork which increases capacity and scalability, and recent speedups\n\u003e \u003e\u003e and incoming relay improvements make segwit a reasonable risk. BIP9\n\u003e \u003e\u003e and segwit will also make further improvements easier and faster to\n\u003e \u003e\u003e deploy. We’ll continue to set the stage for non-bandwidth-increase-based\n\u003e \u003e\u003e scaling, while building additional tools that would make bandwidth\n\u003e \u003e\u003e increases safer long term. Further work will prepare Bitcoin for further\n\u003e \u003e\u003e increases, which will become possible when justified, while also\n\u003e providing\n\u003e \u003e\u003e the groundwork to make them justifiable.\n\u003e \u003e\n\u003e \u003e Sounds good to me.\n\u003e\n\u003e Better late than never, let me comment on why I believe pursuing this plan\n\u003e is important.\n\u003e\n\u003e For months, the block size debate, and the apparent need for agreement on\n\u003e a hardfork has distracted from needed engineering work, fed the external\n\u003e impression that nothing is being done, and generally created a toxic\n\u003e environment to work in. It has affected my own productivity and health, and\n\u003e I do not think I am alone.\n\u003e\n\u003e I believe that soft-fork segwit can help us out of this deadlock and get\n\u003e us going again. It does not require the pervasive assumption that the\n\u003e entire world will simultaneously switch to new consensus rules like a\n\u003e hardfork does, while at the same time:\n\u003e * Give a short-term capacity bump\n\u003e * Show the world that scalability is being worked on\n\u003e * Actually improve scalability (as opposed to just scale) by reducing\n\u003e bandwidth/storage and indirectly improving the effectiveness of systems\n\u003e like Lightning.\n\u003e * Solve several unrelated problems at the same time (fraud proofs, script\n\u003e extensibility, malleability, ...).\n\u003e\n\u003e So I'd like to ask the community that we work towards this plan, as it\n\u003e allows to make progress without being forced to make a possibly divisive\n\u003e choice for one hardfork or another yet.\n\u003e\n\u003e --\n\u003e Pieter\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151221/fa4c9349/attachment.html\u003e",
"sig": "aafdbf65e7110639f86ac1b0a2ec052d49702f90deaa23dc68858a7e35cf9d915c3e9053c70d94567d92642e049a53da652ea7bfab42a55d3802135570e3baaa"
}