Author: Matt Corallo 2021-02-22 06:44:55
Published on: 2021-02-22T06:44:55+00:00
In a recent discussion, it was suggested that skipping the headers issues by not persisting them can be a solution, but there are still other concerns. One of these concerns is whether information about a node feeding invalid headers and causing a ban is still persisted. Additionally, nodes on both sides of the fork need to find each other, which requires forking the address database, DNS seeds, and defining a new protocol magic. A previous statement that Bitcoin Core does not have the infrastructure to handle switching consensus rules with the same datadir was challenged in the discussion. With the current proposed bip8 code, lockinontimeout=true will cause headers to be marked as invalid, but they won't be added to the block index at all. So a node restart should always allow it to be reconsidered. The test case in the discussion's reference link tests that a node that had rejected a chain due to lockinontimeout=true will reorg to that chain after being restarted. However, if you switch from lockinontimeout=false to lockinontimeout=true and the tip of the current most work chain did not lockin, then you will continue following that chain until a taproot-invalid transaction is included, rather than immediately reorging to a shorter chain that complies with the lockinontimeout=true rules.
Updated on: 2023-05-21T00:58:51.098417+00:00