undefined | Better HN

0 pointskobeya8y ago0 comments

It has not. You have been misinformed.

0 comments

4 comments · 2 top-level

blusterXY8y ago· 1 in thread

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.

kobeyaOP8y ago

Point me to the code. I think you will find it does not exist.

ptrincr8y ago· 1 in thread

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.mediawi...

kobeyaOP8y 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.

j / k navigate · click thread line to collapse