§8.3's second algorithm: owner monitoring, and §12.3.6's incomplete list - #22
Merged
Conversation
…the proof §8.3's second algorithm inverts the relationship every other operation has with its proof. Step 4 makes the user's only stop condition "having consumed all of the Transparency Log's response", because §8.3 tells the log to limit how many distinguished entries it covers and the user simply asks again. So the element count decides when the walk stops. That costs the verification technique its teeth, and the check says so rather than pretending otherwise. Everywhere else §12.3's exact-count rule turns a misreading of the ordering into a leftover element; here the walk consumes whatever it is given by construction. What still catches a misreading is the ladders — an element attributed to the wrong entry evaluates to a prefix tree root that entry never had — so the recorded check reads "to exhaustion" rather than "exactly". Three things had to be right before the recorded case would replay, and two of them are not where a reader would look. The step 5 ladder targets the greatest version expected at *that entry* from the owner's own record of when it created each version, not one global greatest. §8.3 says so; it is easy to read past, and using the global version gives ladders of the wrong length at every entry but the last. The owner needs VRF outputs for versions that have never existed, because a ladder for version 3 reaches for version 7. §8.3 step 3 supplies exactly that set during initialization and a client retains it — which is the sentence that turned this from a suspected specification gap into a modelling error in the harness. Checked before filing anything. And §12.3.6's list of what a proof contains is incomplete: it gives a timestamp for each entry that causes a recursion and, separately, a proof for each entry reaching step 5. An entry that reaches step 5 without recursing therefore gets a proof and no timestamp — and cannot be placed in the log tree at all, since §11.8's leaf hashes a timestamp together with a prefix tree root and §12.3 ties inclusion to the leaves whose timestamps were provided. §12.3.3 lists both for a fixed-version search. Resolved by measurement rather than filed, since the peer sends them and sends them in a determinable position: recorded as DRAFT-10, and the case that pins it is the only one where an entry reaches step 5 without recursing. That case had to be built deliberately. With a week-long window only the root of a seven-entry log is distinguished, so the first recorded owner monitor walked one step right, found nothing distinguished and checked no ladders at all — the same degenerate shape §8.2 had. Spacing the entries and shrinking the window gives the walk something to do. Both shapes are kept. All eight monitoring cases now replay, and §8 is complete. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
§8.3's second algorithm inverts the relationship every other operation has with its proof. Step 4 makes the user's only stop condition "having consumed all of the Transparency Log's response" — because §8.3 tells the log to limit how many distinguished entries it covers, and the user just asks again. So the element count decides when the walk stops.
That costs the verification technique its teeth, and the check says so rather than pretending otherwise. Everywhere else §12.3's exact-count rule turns a misreading into a leftover element; here the walk consumes whatever it's given by construction. What still catches a misreading is the ladders — an element attributed to the wrong entry evaluates to a prefix tree root that entry never had. The recorded check reads "to exhaustion" rather than "exactly".
Three things had to be right, two of them not where you'd look
The step 5 target is per-entry. The ladder targets the greatest version expected at that entry, from the owner's own record of when it created each version — not one global greatest. §8.3 says so; it's easy to read past, and the global version gives ladders of the wrong length at every entry but the last.
The owner needs VRF outputs for versions that never existed — a ladder for version 3 reaches for version 7. §8.3 step 3 supplies exactly that set during initialization, and a client retains it. That sentence turned this from a suspected spec gap into a modelling error in my harness. Checked before filing anything.
DRAFT-10: §12.3.6's list is incomplete. It gives a timestamp for each entry that causes a recursion and, separately, a proof for each entry reaching step 5. An entry that reaches step 5 without recursing gets a proof and no timestamp — and can't be placed in the log tree at all, since §11.8's leaf hashes a timestamp together with a prefix root and §12.3 tiesinclusionto leaves whose timestamps were provided. §12.3.3 lists both for a fixed-version search. Resolved by measurement, not filed: the peer sends them, in a determinable position.The case had to be built deliberately
With a week-long window only the root of a seven-entry log is distinguished, so the first recorded owner monitor walked one step right, found nothing distinguished, and checked no ladders at all — the same degenerate shape §8.2 had. Spacing the entries and shrinking the window gives the walk something to do. Both shapes are kept.
All eight monitoring cases replay. §8 is complete.
6706 checks / 789 cases / 18 suites, 0 disagreements.
cargo fmt,clippy -D warnings, 176 kt-tree tests green; line coverage 97.7%.🤖 Generated with Claude Code