You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
incompleteProof: fileOts,
timestampedValue: signedAttCID,
submitted: new Date().toISOString(),
However, as outlined in the 3/8/23 presentation, ideally, the timestamping service would work slightly differently. The timestamping service would have its own single-writer blockchain, which it anchors in various ways: on an L1 like Bitcoin (like OTS), in a newspaper (like Surety), etc. See Option C below compared to OpenTimestamps (Option B)
Importantly, the ideal timestamping service would immediately give us a "certificate of inclusion". A certificate of inclusion is a message digitally signed by the timestamping service that contains the following:
The hash the timestamping service was given
The block number of the block the hash was put in, in the TSS blockchain
Absolute time according to TSS
The header hash of that block (the latest block in the TSS blockchain at that point in time)
Secondly, the timestamping service blockchain would itself be explorable, and the timestamping service would be able to give a proof to customers that creates a chain of hash pointers from their submitted hash up to a block hash anchored in a medium that they trust (such as Bitcoin). This is equivalent to the OTS complete proof.
Benefits
If we were to implement the "ideal" timestamping service, we would have:
an signed absolute timestamp from the timestamping service, that would make things much easier for users willing to trust the timestamping service itself
the ability to prove misbehavior if it occurs, since the "proof of inclusion" is a promise to include the hash, and digital signatures are nonrepudiable.
The ability to tweak the parameters of the timestamping service based on the user's needs when it comes to the cadence of anchoring, which mediums to anchor on, etc.
The text was updated successfully, but these errors were encountered:
katelynsills
changed the title
Implement "ideal" timestamping service
Implement "ideal" timestamping service [Nice to have]
Apr 21, 2023
Currently in the demo, we are submitting signed attestations to OpenTimestamps in order to receive an incomplete OTS timestamping proof, which we store directly in the Hyperbee instance. What we currently store is:
However, as outlined in the 3/8/23 presentation, ideally, the timestamping service would work slightly differently. The timestamping service would have its own single-writer blockchain, which it anchors in various ways: on an L1 like Bitcoin (like OTS), in a newspaper (like Surety), etc. See Option C below compared to OpenTimestamps (Option B)
Importantly, the ideal timestamping service would immediately give us a "certificate of inclusion". A certificate of inclusion is a message digitally signed by the timestamping service that contains the following:
Secondly, the timestamping service blockchain would itself be explorable, and the timestamping service would be able to give a proof to customers that creates a chain of hash pointers from their submitted hash up to a block hash anchored in a medium that they trust (such as Bitcoin). This is equivalent to the OTS complete proof.
Benefits
If we were to implement the "ideal" timestamping service, we would have:
The text was updated successfully, but these errors were encountered: