Bug in history proof verification
kevinlewi opened this issue · comments
For key history proofs, the server should generate non-membership proofs for the epochs up until the next power of 2, and then for each power of two until the current epoch. Right now, the existing logic has some off-by-one errors which need to be fixed.
Example 1: Let’s say a user has a value that is on version 11, and the current epoch is 65.
Expected behavior: A key history proof for this value should include:
- For each i in the range [1, 11], a membership proof for version #i being marked as “fresh”
- For each i in the range [2, 11], a membership proof for version #i-1 being marked as “stale”
- For each i in the range [12, 15], a non-membership proof for version #i being marked as “fresh”
- For each i in the set {16, 32, 64}, a non-membership proof for version #i being marked as “fresh” (as a marker node)
Actual behavior: The current logic fails to provide a non-membership proof for version 16 due to an off-by-one error.
Example 2: Let’s say a user has a value that is on version 8, and the current epoch is 65.
Expected behavior: A key history proof for this value should include:
- For each i in the range [1, 8], a membership proof for version #i being marked as “fresh”
- For each i in the range [2, 8], a membership proof for version #i-1 being marked as “stale”
- For each i in the range [9, 15], a non-membership proof for version #i being marked as “fresh”
- For each i in the set {16, 32, 64}, a non-membership proof for version #i being marked as “fresh” (as a marker node)
Actual behavior: Actually, I think this one is correctly handled, but we should add a test case to double-check.