checkpoints should explicitly declare transactions/blocks that are part of the history but would no longer verify #136
Labels
A-consensus
Area: Consensus rules
C-future-proofing
Category: Changes that minimise the effects of shocks and stresses of future events.
M-requires-zip
This change would need to be specified in a ZIP.
network upgrade management
not in 1.0
notary related
special to Daira
use case
Suppose that we want to fix a bug or irregularity in the consensus protocol, but there are transactions or blocks in the consensus block chain history that took advantage of that bug/irregularity. We ideally want it to be possible to verify the entire history using the current protocol, but that is a potential obstacle to making consensus protocol changes, particularly changes that tighten the acceptance rules.
If we include hashes of known transactions and blocks that wouldn't verify under the new rules as part of a checkpoint, that tells any new verifier that their nonverifiability is intentional and not a mistake, thus giving us more flexibility to change the consensus algorithm. The specific reasons why they no longer verify should be documented.
The text was updated successfully, but these errors were encountered: