Hacker News new | ask | show | jobs
by wraithm112 3810 days ago
This is a fantastic question, not naive at all, and it's really at the heart of what the debate is all about. This is a really complicated issue, hence all of the vitriolic discussion. I'm going to try to take a crack at it and fail. I will mostly be reiterating ideas that are from this[1]. I'll try to be brief, and you can read more from [1]. I am also very opinionated on this issue, and I will try to be as impartial as I can.

Something that's really confusing is that the word "fork" actually means at least two different things in the block-size debate context. The first is forking the bitcoin software, and the second is forking of the bitcoin blockchain/network. Bitcoin XT, Hearn's project, was the former, a software fork, that would cause a "hard-fork" in the blockchain. Hard-forks in Bitcoin are very dangerous. There has never been an intentional hard-fork of the Bitcoin blockchain since its inception 7 years ago.

There's a very difficult question of just simply, "how do hard-fork?" A hard-fork would separate the p2p network into two different networks with incompatible rules. A hasty hard-fork could very easily destroy people's money and bitcoin all together. Many, including myself, strongly disagree with Bitcoin XT's hard-fork procedure.

It's also not clear that this particular software fork, Bitcoin XT, is better. I'm not going to go into that issue here as it's extremely complicated. We have an alternative solution, segregated witness, which is effectively equivalent to Bitcoin XT's short-term plan implemented as a blockchain soft-fork. Soft-forks are significantly less dangerous as they do not segregate the network.

[1] https://bitcoin.org/en/bitcoin-core/capacity-increases-faq

1 comments

It's actually not true that there's never been a hard fork. I know the Core FAQ says that, but it's incorrect. When we moved past Berkeley DB to LevelDB, there was an accidental hard fork that revealed limits in older nodes nobody knew about. But those limits had to go, and so the change was attempted again in a more controlled manner some time later. So it was known that the network would start producing blocks that older nodes would reject. That's a hard fork. It was scheduled in advance and went off smoothly.

The idea that hard forks are dangerous or irresponsible is a belief that is not well supported. However it's a rather good piece of Bitcoin Core propaganda to scare people away from doing what's necessary.

> The idea that hard forks are dangerous or irresponsible is a belief that is not well supported

bip99 - https://github.com/bitcoin/bips/blob/master/bip-0099.mediawi...

https://www.reddit.com/r/bitcoinxt/comments/3t21dh/dangerous...

https://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensu...

> scare people away from doing what's necessary

Most block size hard-forks can be deployed as a soft-fork. "It's necessary" is highly contentious and you have failed to cite any of the arguments you disagree with- you're wasting everyone's time.

I said "intentional hard-fork" for a reason. For everybody's reference, the bdb to leveldb hard-fork happened in early 2013. Everybody acted swiftly to correct the issue by downgrading to 0.7 if I recall correctly.

An accidental hard-fork is a completely different animal from an intentional contentious hard-fork where half of the network goes one way and the other half the other way for the foreseeable future.

So did I. Please re-read my post. The same change that triggered the accidental fork was done smoothly later on, but the change was the same - it was a deliberate hard fork. You probably didn't notice because there was plenty of lead time and I don't think any miners got split off the chain, even though they could have.
Mike, can you imagine any way to run a cryptocurrency so that growth doesn't threaten decentralization?

Could a cryptocurrency not be controlled by those who can afford to spend the most in CPU power (like governments)?

Could consensus occur by human power?