Author: Pieter Wuille 2015-12-18 02:30:38
Published on: 2015-12-18T02:30:38+00:00
The author of this message questions their previous belief that soft forks are a mild security reduction for old full nodes. They present four failure modes and analyze the risks associated with them. The first two modes involve the risk of an old full node wallet accepting an invalid transaction due to new rules. However, the receiver wallet chooses what address or script to accept coins on, so it is not a problem. The third mode involves the risk of an SPV node wallet accepting an unconfirmed transaction that is invalid to new nodes, but this does not change with the introduction of new consensus rules as SPV wallets do not validate them anyway. The fourth mode involves the risk of an SPV node wallet accepting a confirmed transaction that is invalid to new nodes, which can only occur if miners create a blockchain that violates the new rules and still get it accepted. This requires a hash rate majority and sufficiently few economically important full nodes that forking them off is a viable approach.Although we would prefer all full nodes to enforce all rules, the security reduction is not large and there are also security advantages that soft forks offer. Soft forks do not require the pervasive consensus that hard forks need, keeping up with hard forking changes puts load on full node operators, who may choose to instead switch to delegating full validation to third parties, which is worse than just validating the old rules. Hardfork coordination has a centralizing effect on development, whereas something like BIP9 supports having multiple independent softforks in flight that nodes can individually choose to accept or not. If you are concerned about the security degradation a soft fork might bring, you can always configure your node to treat a (signalled) softfork as a hardfork and stop processing blocks if a softfork condition is detected.
Updated on: 2023-05-19T22:56:47.195495+00:00