The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug



Summary:

In an email exchange in 2014, Bitcoin developer Jeff Garzik discussed the difference between soft and hard forks. While hard forks are "much cleaner" and allow for problem solving that wouldn't be possible otherwise, they also carry significant risks. The biggest risk is that once the door to a hard fork is opened, anything can happen and any rule, no matter how sacred, can be changed. However, these risks could be managed with appropriate effort, and major players could publicly commit to a set of ground rules concerning what categories of changes are and are not acceptable. Garzik suggested scheduling protocol upgrades every two years for the foreseeable future, spending one year achieving broad consensus regarding changes to make in the next upgrade, followed by one year in feature freeze before executing the upgrade. The top priority should be fixing bugs that make specifying and re-implementing the protocol nearly impossible. These types of changes should have little difficulty achieving near-unanimous consensus. Garzik argued that it shouldn't be difficult to separate obviously-needed changes from those that would let third parties blacklist coins or allow a majority of miners to vote to confiscate block rewards from minority, tamper with the issuance schedule, etc.


Updated on: 2023-06-09T03:52:06.698131+00:00