fix(core): key CX-receipt spent-marker off the signed header, not MerkleProof - #8
Open
Frozen wants to merge 1 commit into
Open
fix(core): key CX-receipt spent-marker off the signed header, not MerkleProof#8Frozen wants to merge 1 commit into
Frozen wants to merge 1 commit into
Conversation
…kleProof IsSpent and WriteCXReceiptsProofSpent only derived the spent-marker key from the signed block.Header (ShardID/Number) from IsCXMerkleProofReplayFixEpoch onward. For any proof whose Header.Epoch() precedes that fork epoch, the key fell back to CXMerkleProof.ShardID/BlockNum -- fields that ValidateCXReceiptsProof never binds to the Header for those epochs. Since the Header (and therefore its signature) can't be altered without invalidating VerifyHeaderSignature, but MerkleProof.ShardID/BlockNum are otherwise unauthenticated, a genuine, already-applied CXReceiptsProof could be resubmitted with a mutated MerkleProof identity: each resubmission hashed to a different, "unspent" key, letting ApplyIncomingReceipt credit the destination again with no corresponding source debit. Always derive the spent-marker key from the Header. This doesn't change what ValidateCXReceiptsProof accepts, and is a no-op for honestly generated proofs -- MerkleProof.ShardID/BlockNum are naturally populated from the same source block as the Header, so the on-disk key is unchanged for real historical data; only a proof with a deliberately mismatched MerkleProof identity resolves to a different (correct) key than before. Add TestIsSpentIgnoresMutatedMerkleProofIdentity covering the replay case.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
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.
Summary
Independent of #6 (quorum-mask fix). Closes a replay path against genuine, validly-signed CX-receipt proofs, distinct from the forged-signature bug.
Fix
Always derive the spent-marker key from `Header.ShardID()`/`Header.Number()`, dropping the epoch gate.
Why this is safe without a new fork-epoch: this only changes internal bookkeeping (which key records "already applied"), not `ValidateCXReceiptsProof`'s acceptance criteria — no new rejection path is introduced, so it can't cause a resyncing node to reject an already-finalized historical block. For every honestly-generated proof, `MerkleProof.ShardID`/`BlockNum` are naturally populated from the same source block as `Header`, so the on-disk key is byte-identical to what's already stored — no migration needed. Only a proof with a deliberately mismatched `MerkleProof` identity now resolves to the (correct) `Header`-derived key instead of an attacker-chosen one.
Test plan
🤖 Generated with Claude Code