2023.06 Vol.2

Soft Forks

Bitcoin wasn’t born perfect and there have been a number of improvements to the code and protocol over the years. One of the technical marvels of many of these upgrades is that they have been “soft forks”. A soft fork extends the bitcoin protocol by narrowing the spec. That sounds counterintuitive, how’s that possible?

Bitcoin started with a minimal and constrained protocol largely thanks to its use of Script, a stack-based programming language. But a few spots were left open on purpose for future development. If someone is running a node with an old version of bitcoin and it comes across a transaction which uses one of these “open” parts of the language, the node will consider it gibberish and assume that anything can unlock the transaction’s UTXO. That’s right, any script can claim the bitcoin in the transaction. How is this a sane default? Well, this is essential for the “extend bitcoin by narrowing the spec” a.k.a. “soft fork” upgrades. Let’s say the opposite was true, that the node assumes nothing can unlock the bitcoin since it doesn’t understand the script. If the bitcoin network has 10% of the nodes running this old software when an upgrade is introduced, those 10% will split off onto their own version of the chain which only includes transactions they understand while the rest of the network allows for the new transactions. A “hard fork” will occur, no way around it (not sure what is so hard about that though).

OK, so we need the gibberish default to be anything to perform an upgrade and not fork the network. But how is this safe? Seems like people would be stealing bitcoin all time. Gotta step through what a “soft fork” upgrade looks like. First, a proposal is made to define some new functionality in one of these “open” slots of the Script language. Assuming it’s a good idea that a lot of people want, the idea gets coded up and introduced to the bitcoin node implementations. At this point, a user could define a transaction which makes use of the new functionality, but there would probably still be a ton of older nodes running software which doesn’t understand it (see it as gibberish) and would accept any input to spend that transaction. If these older nodes make up a strong majority of the network, then it would indeed be dangerous for a user to use the new functionality. So we arrive at the tricky part of soft fork upgrades and that is when do they “activate” (enforce the new spec). Ideally we roll out new software to a majority of the nodes, they signal is some way “yep, I am ready to start enforcing the new rules”, and when a certain threshold is hit on the network they actually start enforcing the rules. Assuming that part goes smoothly, a user could then safely broadcast a transaction with the new functionality: the new nodes will enforce that only a transaction that follows the new rules can spend it and the old ones won’t care since its “gibberish”. Importantly though, the new nodes dominate the network so they will dictate that the transaction must follow the new rules, not just any old transaction that the old nodes accept. At this point, the spec has been narrowed, but the protocol has more functionality!

The “activation” trickyness has been one of the least consistent parts of the bitcoin upgrades and a general strategy hasn’t been settled on yet. Some consider this a strength though. Bitcoin should move slowly and each change should be hard.