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

Logic of is_timestamp_complete #28

Open
RCasatta opened this issue Nov 30, 2016 · 1 comment
Open

Logic of is_timestamp_complete #28

RCasatta opened this issue Nov 30, 2016 · 1 comment

Comments

@RCasatta
Copy link
Member

According to the is_timestamp_complete function you need one BitcoinBlockHeaderAttestation to consider the timestamp complete. However it could happen than another calendar server (in PendingAttestation) has a BitcoinBlockHeaderAttestation which has an eventually lower than the first height returned.
This information will never be asked to the calendar if I have a timestamp upgraded from the other calendar.
What about having an option in upgrade to consider a timestamp complete if all PendingAttestation are served?

@petertodd
Copy link
Member

Yup, I think that makes sense - it's not complete until you have attestations for every pending attestation.

Equally, like I mentioned in
#27, the upgrade command should always try to get new attestations even if the timestamp is complete: the calendar might be returning an even earlier timestamp than it previously did.

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

No branches or pull requests

2 participants