Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Btc Drak <btcdrak@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]

On Fri, Feb 5, 2016 at 8:51 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This has been reviewed by merchants, miners and exchanges for a couple of
> weeks, and has been implemented and tested as part of the Bitcoin Classic
> and Bitcoin XT implementations.
>
> Constructive feedback welcome; argument about whether or not it is a good
> idea to roll out a hard fork now will be unproductive, so I vote we don't
> go there.
>
> Draft BIP:
>   https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki
>
> Summary:
>   Increase block size limit to 2,000,000 bytes.
>   After 75% hashpower support then 28-day grace period.
>   With accurate sigop counting, but existing sigop limit (20,000)
>   And a new, high limit on signature hashing
>
> Blog post walking through the code:
>   http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
>
> Blog post on a couple of the constants chosen:
>   http://gavinandresen.ninja/seventyfive-twentyeight
>

It's great to finally see a BIP, although seems strange to ask for feedback
after releasing binaries.

In any case, the issue isn't about "whether or not it is a good idea to
roll out a hard fork", the question has always been about how to do safe
hard fork deployment and what the technological requirements are for doing
so. Your BIP/blogs do not actually address any of this. 75% miner
signalling with a 28 day flag day thereafter gives virtually no time for
the entire ecosystem to migrate and is widely considered unsafe. It's
plainly obvious that an entire ecosystem of 5000 full nodes cannot be
prepared in a month.

[-- Attachment #2: Type: text/html, Size: 2629 bytes --]