Research note / Cycle 014
The question after a restart
A local persistent verifier rejects a closed-session replay across process restart, while restored storage still permits the old history.
The receiver has to remember asking
A lunar receiver recovering a lost reply must distinguish recovery of an existing decision from another use of the same question. A reply to this question authenticated the active request, but its verifier forgot a closed session after reset. Haddad and Chen now put the verifier’s allocation counter and session status in a local SQLite ledger.
Provisioning is explicit. Every allocation commits an incremented counter and a session row before a response can be checked. Each verification opens the retained file in a separate Python process and checks the stored closure before applying the earlier authentication and recovery rule. The labels and signing key are public fixture data, not secure deployment credentials.
Restart and restoration are different histories
The first valid response recovers the existing decision. Replaying it from the next process holds because the session is already closed. An allocation abandoned before its response remains spent as a question label; the next process obtains a different label. This does not consume another issuer challenge: the underlying decision is still the same recovery subject.
A changed signed payload fails authentication, and the correct reply can still complete that open session. A missing or corrupt ledger holds without silently provisioning a replacement. These are executed local checks of the implemented path. They do not test power interruption, concurrent network workers or hostile modification of the file.
The storage can return to yesterday too
Explicitly restoring an earlier complete verifier history restores its allocation counter as well. The old label is allocated again and its recorded reply passes. The retained failure shows why a persistent file is not a protected monotonic history.
A separately supplied epoch floor rejects an authenticated response from an older epoch; an unavailable floor holds. Rolling that floor back with the other state passes again. Its independent custody is an assumption of the model, not an implemented service. Next work must specify who retains a recovery generation outside the common snapshot and what happens when that source is unavailable. No operational lunar link, protected key store or independently current clock is established.
Results at a glance
| Persistent history | Decision |
|---|---|
| first_process | recover_bound_current_model_decision |
| replay_after_process_restart | hold_session_closed |
| abandoned_allocation_not_reused | recover_bound_current_model_decision |
| modified_reply | hold_authentication |
| valid_retry_after_bad_tag | recover_bound_current_model_decision |
| missing_store | hold_store_unavailable |
| corrupt_store | hold_store_unavailable |
| all_storage_rollback_reuses_nonce | recover_bound_current_model_decision |
| old_epoch_against_retained_floor | hold_epoch_floor |
| missing_floor | hold_floor_unavailable |
| floor_also_rolled_back | recover_bound_current_model_decision |