Author: Anthony Towns 2021-04-08 11:11:06
Published on: 2021-04-08T11:11:06+00:00
A recent discussion on the bitcoin-dev mailing list has centered around the best way to establish developer and user consensus for Bitcoin. One possible approach is to create a contingency plan for a chain split, which some argue is not brinkmanship but rather good preparation. However, others suggest that this doesn't address the underlying issue of how to establish consensus in the first place. Ideally, users should be able to download any version of bitcoind and run it with default settings and be confident that their payments are valid. While there are third-party explorers that can help track the cumulative work on invalid chains, these measures are only useful after a chain split has occurred. The risk of a chain split is even greater in the event of an attack on Bitcoin, with someone dedicating $200M+ per week to attacking the network. In such a scenario, contingencies would need to be put in place to protect against the possibility of a chain split. One suggestion is to implement lockinontimeout, which would ignore one side of a split if it were to occur. However, this is not seen as the ideal solution since it could lead to enormous difficulties getting blocks at all if your side of the split isn't in the majority. Ultimately, bitcoin users are the ultimate decider, but this decision-making process needs to be more streamlined. Businesses accepting payments via Bitcoin need to know what software to run to stay in consensus with everyone else running Bitcoin so they can ensure that the payments they receive are valid. One possible solution is to implement an approach to dealing with miners who don't upgrade to enforce a soft-fork quickly, which could simplify the consensus-building process.
Updated on: 2023-05-21T02:03:20.934646+00:00