I wrote a thing to keep the prison index service prototype up-to-date. It works by polling the RSF for updates, and only downloads new entries.
However, the prison register is in discovery and I’m told it will be deleted and reloaded (possibly a number of times). This means that if I only download entries from the last entry number I saw, I’ll miss the entries which have been completely rewritten.
I thought about using the consistency proof endpoint to check for this: if the register has only been appended to, the consistency proof will be valid, but if the register has been completely rewritten, the consistency proof will fail, so we throw everything away and start again from the beginning.
Unlike the CT signed tree head API, the register proof API doesn’t state the register size. This introduces timing issues, where if you make separate requests to get the register proof and the register size, the register might have changed in between. For example, you ask for the register proof at size=10, but someone mints something in between, so when you ask for the register size it says 11.
The assert-root-hash commands in the RSF aren’t particularly useful to my code as it currently is. I don’t keep a local verifiable log, and without that, it’s impossible to verify the assert-root-hash commands.
The consistency proof API, in principle, doesn’t require me to keep my own verifiable log – I just grab the old root hash, the new root hash, and check the consistency between them.
Here’s the workflow I think I want:
- I remember the old register-size and root-hash that I last saw
- I request the latest root-hash + register-size (atomically, so they are consistent with each other)
- I request a consistency proof for (old-register-size) to (new-register-size), which I can use to verify the (old-size,old-root,new-size,new-root) tuple
- I request the RSF for (old-size) to (new-size).
Note that I’m not too bothered about actually checking the data served in the RSF actually matches the register proofs. I’m mainly using this as a data integrity defence, rather than a malicious actor defence. (That is, I’m defending against Murphy, not Macchiavelli.)
I think this can be achieved with one change: add the register size to the register proof endpoint. Then I can do the complete workflow under “what I want” above.
There is an argument that maybe I should be keeping my own verifiable log, because checking the consistency proof without checking that the data matches the root hashes is not really guaranteeing the integrity of the data. However this is either a lot of extra data, or a dependency on my python library :)