Jul 18, 2026

Breaking changes to table configuration (bucket count) is guarded against, as is a body size that disagrees with its header's recorded body size. But changes to the above fork configuration is not guarded. We would not implement a feature to "reindex" the chain, since it's generally faster to download it. But also as each header is archived with the fork flags that are active for it. These don't change in the past - ever, so retroactively changing consensus rules is just user error. And knowing what is "the past" for a given consensus rule can require evaluation of the chain from genesis. So the rule is, either set the rule before it's active on your chain, or resync your chain. We don't have a general cache of non-table data, like for initial config values. However I devised a mechanism for this due to the necessity of knowing the configured Electrum full chain Merkle root optimization interval. That's one byte stored in the genesis block's txs association. Since that's blob storage and only set on store creation, it's the ideal location. I'll eventually expand this to retain the fork flags (32 bits), which will allow startup to warn against changes to rule configuration. However this would never go away, since it's not modifiable. So you would perpetually get warned that you modified your fork state and that consensus reliability is based on your expertise if you modify it. And then of course if you de-modify it the warning goes away. Which you would of course be initially warned about 🙂.