Follow the v1.1 correction through the docs and the Python binding - #59
Merged
Merged
Conversation
Three things a normative change is not finished without. 1. docs/security.md stated, as a mitigation against a compromised high-volume issuer: "Even if one issuer submits 1000 receipts, it cannot exceed 40% of the aggregate weight." That was not true of v1.0 — 50 receipts reached roughly 87% — so anyone who read that section received an assurance the algorithm did not provide. The claims now name the version they hold from, the residual-risk note is corrected, and a dated correction explains what was wrong and points at the vector that pins the fixed behaviour. A security guarantee that silently starts being true is worse than one that says when it started. 2. sdk/python/aggregate.py implements the same algorithm, so both bindings carry the normative one rather than only the JavaScript side. All eleven vectors run against it. 3. The parity gate now covers aggregation as well as the AGT bridge: 59 checks across both languages, including the capped-issuer case. Verified it catches drift — moving the Python cap to 0.45 fails with the divergence named. CI compiles and tests the new module. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
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.
Three things a normative change isn't finished without. Follows #58.
1. The security doc was making a promise the algorithm didn't keep
docs/security.md§3, as a mitigation against a compromised high-volume issuer:That was not true of v1.0. Fifty receipts from one issuer reached roughly 87%. Anyone who read that section got an assurance the algorithm did not provide, and §1.1 item 9 ("Single-issuer resistance") rested on the same claim.
Now: the guarantees name the version they hold from, the residual-risk note is corrected (a compromised issuer key could reach ~87%, not 40%), and a dated correction explains what was wrong and points at
agg-009, the vector that pins the fixed behaviour.A security guarantee that silently starts being true is worse than one that says when it started — anyone who deployed on v1.0 and relied on the 40% bound needs to know to re-evaluate.
2. Python carries the normative algorithm too
sdk/python/aggregate.pyimplements v1.1 step for step. All eleven vectors run against it, plus the property tests. Both bindings now implement the normative algorithm rather than just the JavaScript side.3. The parity gate covers aggregation
59 checks across both languages now — AGT bridge and trust aggregation, including the capped-issuer case that v1.0 got wrong.
Verified it bites: moving the Python
max_issuer_weightto 0.45 fails withCI compiles and tests the new module.
194 JS tests, 25 Python tests, 59 parity checks.
🤖 Generated with Claude Code