Hacker News new | past | comments | ask | show | jobs | submit login

There was technically a second hard fork a couple of months after the accidental one in order to carry out the change that caused the first one in a more controlled and planned manner. Sticking with the existing code was not an option for technical reasons: "This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page)."

Also, there was technically also one way back in 2010 to fix an integer overflow bug that allowed large amounts of BTC to be created from thin air: https://bitcointalk.org/index.php?topic=823.0




I've seen bitcoin developers saying that wasn't really a hard fork because the previous behavior wasn't well defined.

The second is a soft fork, not a hard fork.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: