Comment by nadaviv | Hacker News Reader

Comment by nadaviv | Hacker News Reader

Parent Full thread

> To say that centralization increases dramatically at 2 MB just isn't the case.

No one is saying that. Core's SegWit proposal also gives us an effective blocksize of ~2mb, the same as Classic - only without requiring a coordinated network-wide upgrade and without the risk of splitting the payment network and currency in two if everyone doesn't upgrade in time. This is the more responsible way to deploy such an upgrade, especially if you consider the capacity bump to be urgent. (a safe hard-fork would require a grace period of 6-12 months to wait for everyone to upgrade, and so would be much slower to roll out than SegWit)

Also, several of the Bitcoin Core members have committed to coding an hard-fork proposal for raising the block size limit within a few months, and to bring it up to the wider development community to gather consensus.

I do agree that this isn't about the technical issues, but about control. The bitcoin development community has been very responsive and insightful throughout the scaling debate, and has provided us with great technical solutions to some very difficult problems. The ones opposing the Bitcoin Core development community seem to disregard the technical merit of their proposals in favor of repeating personal attacks, conspiracy theories and toxicity. This is creating an hostile environment that developers will start running away from... which is a shame, because we don't really have any developers to spare - people with intersection of the domain knowledge required to work on Bitcoin (cryptography, distributed networks, game theory, economics, computer science, etc) are VERY rare.

>No one is saying that. Core's SegWit proposal also gives us an effective blocksize of ~2mb, the same as Classic - only without requiring a coordinated network-wide upgrade and without the risk of splitting the payment network and currency in two if everyone doesn't upgrade in time.

If that is such a huge concern then why is core proposing a hard-fork to change the way the difficulty is adjusted? [0] If they are for adjusting the difficulty computation why not raise the block size at the same time?

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016...

"Core" is not proposing anything, that difficulty adjustment hard-fork proposal was brought up on the mailing list by a member of the community and is in early discussion stages. There's no consensus that this change is necessary, and there hasn't been an in-depth discussion about how and when it should be incorporated (if accepted) and whether it should be alongside the block-size hard-fork or separately.

That was made by Luke-jr one of the more influential and out spoken developers who is strongly opposed to a block size increase. He's also associated with Blockstream.

"Core" isn't proposing a hard-fork to change the way difficulty is adjusted, one developer was and he changed his mind after realising this wasn't practical: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016... (Also, that's Luke-Jr who I guess technically counts as a Bitcoin Core developer, but uses his own heavily modified client.)

But isn't the coordinated network upgrade problem already solved? In the Bitcoin XT (sp?) thing, the solution was to not switch over until over 50% of participants reported being in a version that supported 2MB blocks.

Core has offered a solution, but only 6 months after another equivalent solution was made and basically deployed...

Segwit will increase capacity to 2MB, if and only if all the creator of transactions (wallet, exchange, ...) switch to the new way of encoding. So it is going to take even more time than classic.

Reply on news.ycombinator.com