Open petertodd opened 6 years ago
We could have clients fetch block headers from calendars (and potentially other sources), and then save only the chain with the biggest cumulative proof-of-work. The response could then be validated against that. Block headers are small and easy to cache (both client and server side).
This would make most (all?) pentential errors and attack very expensive to get away with, and no further sanity check would be needed.
I'm not proposing this for the actual timestamp verification, just as a thorough validation on upgrade. Doing otherwise feels like moving the problem, because we wouldn't know if the headers are from valid block, and trying to track consensus from this library feels like a really bad idea.
@cloutier I'm talking about a different type of attack actually - nuisance attacks that make timestamps bigger than necessary, or try to exploit bugs in validation logic.
But yes, when getting timestamps for upgrades it's definitely worthwhile to verify them if possible! :) I'd like to just solve this once, with a reasonably secure semi-trusted lite client mode; I have a few ideas for that already.
@petertodd Oh, thanks for the clarification!
Completely aggreed for the restricting the rules to avoid potential holes. However, how do you define bigger than necessary, especially in periods of high demand for timestamps?
@cloutier For example, even though a merkle tree proof shouldn't be more than about 1KB of data, the current codebase will accept up to 10KB of data; remember that proof size should be logarithmic with the number of timestamps as it's a merkle tree.
Currently the only sanity check that
RemoteCalendar
does is to reject responses larger than 10KB.For submission, we should verify/filter the following:
PendingAttestation
matches expected whitelist (URL is unauthenticated!)PendingAttestation
's is reasonableAnd when getting timestamps:
PendingAttestation
's (allowing loops greatly complicates the logic)