4 ms·

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 t

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 https://bitcoin.org/en/bitcoin-core/capacity-increases-faq

mike_hearn 11y ago
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.
- kanzure 11y ago
  > 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.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0099.mediawi... https://www.reddit.com/r/bitcoinxt/comments/3t21dh/dangerous_homebrew_cryptography_in_blockstream/cx586r1 https://www.reddit.com/r/bitcoinxt/comments/3t21dh/dangerous... https://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_forks_by_mike_hearn/cu0yv0r 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.
- wraithm112 11y ago
  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.
  - mike_hearn 11y ago
    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.
    - deleted 11y ago
      [deleted]
    - jcansdale 11y ago
      Would it be fair to say it was a deliberate hard rule change that because it was rolled out in a controlled manner didn't manifest itself as a hard-fork? IMHO there are ways to mitigate the dangers of an hard rule change so that a hard-fork never actually happens. For example, a notification period followed by a version based soft-fork should be able to get an overwhelming majority of miners on board. If blocks on the minority chain are taking over a day to generate and there is a massive transaction backlog, the minority chain is unlikely to make it to 6 blocks. Does that make sense? A hard rule change without a hard-fork?

mike_hearn 11y ago

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.

kanzure 11y ago
> 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.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0099.mediawi... https://www.reddit.com/r/bitcoinxt/comments/3t21dh/dangerous_homebrew_cryptography_in_blockstream/cx586r1 https://www.reddit.com/r/bitcoinxt/comments/3t21dh/dangerous... https://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_forks_by_mike_hearn/cu0yv0r 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.
wraithm112 11y ago
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.
- mike_hearn 11y ago
  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.
  - deleted 11y ago
    [deleted]
  - jcansdale 11y ago
    Would it be fair to say it was a deliberate hard rule change that because it was rolled out in a controlled manner didn't manifest itself as a hard-fork? IMHO there are ways to mitigate the dangers of an hard rule change so that a hard-fork never actually happens. For example, a notification period followed by a version based soft-fork should be able to get an overwhelming majority of miners on board. If blocks on the minority chain are taking over a day to generate and there is a massive transaction backlog, the minority chain is unlikely to make it to 6 blocks. Does that make sense? A hard rule change without a hard-fork?