Author: Matt Corallo 2017-04-07 10:14:07
Published on: 2017-04-07T10:14:07+00:00
A recent email on the bitcoin-dev mailing list by Johnson Lau has called for a redefinition of the terminology surrounding hard and soft forks. Rather than describing the changes to block validity that define these terms, he argues that they should be defined in terms of software upgrade necessity and difficulty. Under this system, soft forks are consensus rule changes that non-upgraded software can still use, while hard forks require upgraded software to function. There is a continuum between the two, which Lau calls "hardfork-ness." This means that there are three levels of hardfork-ness for mining nodes, non-mining full nodes, fully validating wallets, and fake SPV wallets. The costs of running a border node can also help to further define the hardfork-ness of soft forks. For example, things like BIP34, 65, 66, and CSV have trivial resources use, so they have low hardfork-ness. In comparison, the extension block proposal has high hardfork-ness for wallets because legacy wallets will frequently and suddenly find that incoming and outgoing transactions become invalid, and need to sign invalidated transactions again, even though nobody is trying to double spend. Lau also examines some other interesting cases, such as soft-hardforks, which would require miners to mine empty blocks with zero reward, and put the transaction merkle tree in the legacy coinbase. While they are technically softforks in terms of block validity, they are actually hardforks in practice. On-chain KYC, blacklist, and account freezing are also technically softforks, but they are highly disruptive hardforks in terms of user experience. Lightning network and side chains are not consensus rule changes and could provide new features without any hardfork-ness.
Updated on: 2023-05-20T01:56:39.759288+00:00