Author: Mike Hearn 2014-10-03 20:58:28
Published on: 2014-10-03T20:58:28+00:00
The discussion begins with the suggestion of setting a time limit to prevent outputs being locked for 100 years. However, it is questioned whether Bitcoin will even exist in 100 years, as computing history is relatively short. The focus then shifts to the deployment discussion and the fact that Bitcoin works best when everyone is following the same rules. Soft forks work against this principle by allowing nodes to think they are following the majority ruleset when they are not, effectively downgrading their security. In contrast, hard forks have desirable properties as they allow nodes to detect when they are no longer in consensus and trigger alerts, which minimizes the risk of loss. Furthermore, forcing old peers to fall behind means that SPV clients can easily choose to ignore transactions relayed by peers that are too far behind, avoiding monetary loss. The main justification for a soft fork is backwards compatibility, but this is not ideal for a system like Bitcoin where running behind the consensus can cause problems. Hard forks should not be scary as mechanisms are in place to warn people and they can be scheduled with plenty of time in advance.
Updated on: 2023-06-09T02:53:14.974819+00:00