Component: lib/src/bip448_statechain/script.rs (constants), lib/src/bip448_statechain/deposit.rs (sample_initial_state_locktime)
Severity: Design risk (makes the missing watcher the entire theft defense)
Summary
State locktimes are sampled from INITIAL_STATE_LOCKTIME_MIN..=MAX = 500_000_000..1_000_000_000 (timestamps in 1985–2001), and future strides are ≤ 65,536 seconds. As a result:
- Every state-update CLTV gate (
L+1) is satisfiable at all times on any present-day chain.
validate_immediately_final is vacuous in practice — every state is "immediately final" the moment it's created.- A stale owner can broadcast an old update
U(k) at any moment, with no time disadvantage whatsoever. The only defenses are signature-count ordering and the newest owner rebinding a newer update over the confirmed stale state.
Combined with the missing stale-state watcher (see tracking issue), the ratchet provides no time-based protection at all; protection is purely reactive.
Suggested direction
Consider whether future states should carry genuinely future locktimes (e.g., initial locktime near deposit time + per-state stride), so a stale update at least races the honest party's clock rather than being permanently open. This changes the recovery-finality model, so it needs a design decision.
Found during security review of feature/bip448-web-wallet-mutinynet @ 64d2423.
Component:
lib/src/bip448_statechain/script.rs(constants),lib/src/bip448_statechain/deposit.rs(sample_initial_state_locktime)Severity: Design risk (makes the missing watcher the entire theft defense)
Summary
State locktimes are sampled from
INITIAL_STATE_LOCKTIME_MIN..=MAX = 500_000_000..1_000_000_000(timestamps in 1985–2001), and future strides are ≤ 65,536 seconds. As a result:L+1) is satisfiable at all times on any present-day chain.validate_immediately_finalis vacuous in practice — every state is "immediately final" the moment it's created.U(k)at any moment, with no time disadvantage whatsoever. The only defenses are signature-count ordering and the newest owner rebinding a newer update over the confirmed stale state.Combined with the missing stale-state watcher (see tracking issue), the ratchet provides no time-based protection at all; protection is purely reactive.
Suggested direction
Consider whether future states should carry genuinely future locktimes (e.g., initial locktime near deposit time + per-state stride), so a stale update at least races the honest party's clock rather than being permanently open. This changes the recovery-finality model, so it needs a design decision.
Found during security review of
feature/bip448-web-wallet-mutinynet@ 64d2423.