Nolan suggests that a hard fork with a slim chance of practical effect is preferable to adding a checkpoint. The argument is that if the re-org does occur, a hard fork would introduce a potential hard fork between new and old clients, but that such an event is unlikely to cause significant confusion or usability issues. In any case, coordination would be required to upgrade to software that supports the new rules. Additionally, Nolan proposes treating soft forks like BIP30 and introducing further soft forks that apply to all blocks except for historical exceptions. However, this is not practical for at least BIP34 without storing the hashes of all 200K blocks that do not meet the requirement. Eric Voskuil suggests including a checkpoint, which would make the change a soft-fork rather than a hard fork, protecting all earlier blocks. Chains that do not go through the checkpoint would be rejected, but no new chains would be allowed.