DCKR scheduling and chain refresh

I recently posted a proposal for delayed chained key revelation (DCKR). I should point out a couple details which might or might not be obvious.

First: it is necessary for the public to have some rough idea of the maximum age of a revealed key.  If an asserted chain has a last key of maximal age A seconds at time of first awareness, then a user must wait until they have knowledge of a key that was publicly revealed only after more than A seconds later. Otherwise, it would be possible that the chain they are confirming was fraudulently created using knowledge perhaps not yet known to the user, but knowledge that was already public nevertheless.

There are many ways to do this. One of the simpler ways is for the signer to simply precommit to a schedule of earliest release by key index.

Another question is what to do when the signer runs out of pregenerated keys.  This is also easily addressed: the signer could include the last of a new chain of hashes in the previously described signed structure as they near the end of a prior chain.

Although I have only described chains so far, trees could also be used so as to conceptually mimic BIP 32 run backwards (but without asymmetric algorithms in the traditional sense.)