Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recovering from unintended inconsistencies #171

Open
vqhuy opened this issue Mar 13, 2017 · 0 comments
Open

Recovering from unintended inconsistencies #171

vqhuy opened this issue Mar 13, 2017 · 0 comments

Comments

@vqhuy
Copy link
Member

vqhuy commented Mar 13, 2017

See Arlo's comment in 80e453c#commitcomment-19804686

We're only returning the STR with the response as an optimization (consciously or not), since an omniscient client would know which epoch we're in and when exactly to fetch the new STR. See the discussion here about syncing clocks in practice though #74 (comment)
Any STR that passes the checks in updateSTR will be stored and used by the client, regardless of whether the rest of the checks pass / fail, and that's fine since it contains proof of being issued. The rest of the checks are tangential to maintaining the STR hash chain and knowing which epoch we're in.
There are questions about how the client recovers in the face of equivocation and whatnot

Also, open problem from coniks.org (https://coniks.cs.princeton.edu/research.html#openproblems)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant