Checkpoints have been used as a way to prevent attacks, but Wuille argues that they are not necessary and can be removed. He suggests that users validate the full chain without checkpoints and select their own checkpoints instead.Voskuil expresses concern that this could lead to centralization of control over the "true chain", but Wuille counters that developers already have this power and good review and release practices can mitigate the risk.The conversation also touches on buried softforks, which modify the validity of a theoretically construable chain from invalid to valid. Wuille believes that avoiding certain checks for BIP34 and BIP66 could improve performance optimization, but Voskuil disagrees and sees no benefit in this approach.Another topic of discussion is the comparison between BIP30 and BIP34. Voskuil clarifies that duplicate transaction hashes can still occur in Bitcoin even with the activation of BIP34, and that BIP30 is not validated after BIP34 is active because blocks complying with BIP34 will always comply with BIP30.The email exchange also involves a discussion about a recent change in Bitcoin Core regarding the deployment of BIPs 34, 66, and 65. The change replaces the trigger mechanism with cached block heights, simplifying and optimizing the process. Voskuil initially opposes the change, but others argue that it doesn't represent a performance improvement and merely cements attributes of the blockchain's history. There is also mention of BIP30 and BIP50, which were given similar treatment after a reasonable amount of time had passed.In addition, there are discussions about reducing code complexity, defining maximum depth of reorganization, and the definition of "BIP" itself. The conversation provides different perspectives on these topics, with some arguing for the elimination of checkpoints and others highlighting potential issues and complexities.Bitcoin Core has recently merged a simplification to the consensus rules surrounding the deployment of BIPs 34, 66, and 65. This change replaces the trigger mechanism for prior soft forks by caching the block heights at which those consensus rules became enforced. The purpose of this change is to simplify and optimize the trigger mechanism. However, this proposal has been met with criticism from Eric Voskuil, who calls it a "horrible precedent" and argues that it is not a significant performance optimization. Despite the debate, the change has already been merged into Bitcoin Core.The change is considered a minor one, but the rationale behind it has been documented in a BIP for posterity. Prior soft forks were activated via miner signaling in block version numbers. Now, with the chain having passed the blocks where those consensus rules were triggered, caching the block heights at which those rules were enforced is seen as a more efficient solution. This change solidifies certain attributes of the blockchain's history that are not disputed. It is widely agreed upon that BIP34 was activated at block 227931, BIP65 at block 388381, and BIP66 at block 363725. While this change does not provide justification for the consensus rule change, it ensures that any reorganization that disconnects the activating block will raise concerns about the security assumptions of Bitcoin.Despite potential concerns about a consensus split, the change is not expected to cause fundamental security concerns in Bitcoin. The proposal suggests that including at least one checkpoint to directly verify that no 50k reorganizations will occur would make the change a soft fork instead of a hard fork. Chains that do not go through the checkpoint would be rejected, but no new chains would be allowed. The purpose of the checkpoint is to validate the assumption that no such large reorganizations will happen. However, many people still want to verify the legacy chain. This checkpointing process would only be necessary during the headers-first part of the download.The simplified consensus rules have not yet appeared in any released software but are expected to be included in the next release, 0.14.0. Despite concerns raised about the performance optimization and the process followed for this change, the developer responsible has agreed to modify the BIP draft to de-emphasize the performance aspect. The full draft of the BIP can be found on GitHub.In summary, Bitcoin Core has merged a simplification to the consensus rules surrounding the deployment of certain BIPs. This change replaces the trigger mechanism for prior soft forks by caching the block heights at which those rules were enforced. While there has been criticism regarding this change, it has already been merged into Bitcoin Core. The purpose of this change is to simplify and optimize the trigger mechanism, although concerns have been raised about its performance optimization and the process followed. The full draft of the BIP can be found on GitHub, and the change is expected to be included in the next software release.