Author: Marco Falke 2018-02-18 18:57:03
Published on: 2018-02-18T18:57:03+00:00
The discussion begins with the question of whether BIPs are necessary for documentation regarding buried deployments in Bitcoin's consensus layer since they do not require software coordination. However, it is noted that consensus is not trivial and documentation is important, so the BIPs repository seems like a good place to host these documents. To prevent "two BIPs for every protocol change," related buried deployments could be bundled. Buried deployments are defined as a consensus rule change that affects the validity of blocks that are buried by a sufficiently large number of blocks in the current valid most-work chain while the current block (and all its parents) remain valid. A buried deployment can very well be a soft fork and should not be labeled "soft fork" or "hard fork" since they do not require community and miner coordination for a safe deployment. It is noted that buried deployments are *not* checkpoints and are *not* a solution to 50% attacks. The discussion then turns to the depth assumption required to ensure that buried deployments do not result in a chain split. The expected number of blocks in two weeks can be considered a lower bound, then multiplied by 10 or 20. There is also a debate about whether the 25,000 blocks number is an objective threshold for buried deployments to avoid a chain split. Finally, there is a disagreement over whether a massive chain reorganization must be produced off of a block in the very past for a chain fork to happen due to a buried deployment or if a buried deployment is a subjective subcategory of hard fork. It is noted that in the unlikely event of such a large chain reorganization, Bitcoin's general security assumptions would be violated regardless of the presence of a buried deployment.
Updated on: 2023-06-13T00:44:37.829611+00:00