4 ms·

It has not. You have been misinformed.

• ptrincr 9y ago
  On 16 August, 2013 block 252,451 (0x0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07) was accepted by the main network, forking unpatched nodes off the network. From https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0050.mediawi...
  • kobeya 9y ago
    That was not a hard fork, and the recovery from it was not a hard fork. Notably there are still bitcoin nodes from before then synced to the network, although they require some care and attention to maintain. What happened was the behavior became probabilistic based on the state of the machine it was running on and the how much block history was being rewritten due to a recent reorg, etc. Usually if the node was restarted, it synced and ran just fine. The recovery didn't change the bitcoin consensus rules as seen by existing clients. There was just a temporary extra limit put in place (a soft-fork) to keep blocks small while the issue was sorted out, then lifted.
• blusterXY 9y ago
  It has had forks which have produced blocks which: (1) would not have been produced by any previous nodes in the network, and (2) forced the updated software to ignore the original majority chain. If you check the software, you'll see explicit checkpoints at which the client is told to ignore certain blocks (identified by their hash). Breaking the ability of the network to follow a valid majority chain is breaking backward compatibility. It's disingenuous to claim otherwise simply because the forked version eventually ended up with the longest chain.
  • kobeya 9y ago
    Point me to the code. I think you will find it does not exist.