Skip to content

Implement "ideal" timestamping service [Nice to have] #22

@katelynsills

Description

@katelynsills

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:

    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)

Screenshot 2023-04-21 at 2 21 32 PM
Screenshot 2023-04-21 at 2 21 06 PM
Screenshot 2023-04-21 at 2 21 12 PM

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:

  1. an signed absolute timestamp from the timestamping service, that would make things much easier for users willing to trust the timestamping service itself
  2. 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.
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions