[ots-dev] Should we drop the distinction between calendars and aggregators?
pete at petertodd.org
Mon Jul 31 11:38:08 AEST 2017
While reworking how the calendar whitelist is handled(1) I noticed that the
stamp subcommand and git gpg wrapper were using the term "calendar" when they
really meant "aggregator"
While I've done a pull-req to fix this(2), I also thought it'd be worth taking
this issue to the OTS community for feedback.
To recap, I've used the term "calendar" in OTS to refer to the data structure
and associated server that stores per-second commitments indefinitely, with a
promise to eventually timestamp those commitments in Bitcoin and/or other
blockchains, and make those finalized timestamps available indefinitely.
I've used the term "aggregator" to refer to the servers that accept digests
from OTS clients and build merkle trees of those digests.
Currently, the opentimestamps-server implementation combines those two roles
into one process. My assumption has been that those roles would eventually be
separated, with multiple layers of aggregation for scalability; aggregation is
a completely trustless operation modulo DoS risk, while calendars are trusted
to do their job, so it's less risky to accept offers of aggregator hosting than
it is calendars.
However, I'm increasingly thinking this distinction is confusing for users.
Notably, even I often catch myself saying things like "submit to a calendar"
when in fact I really mean "submit to an aggregator". It's also notable how the
proposed m-of-n handling in (2) is wrong: it needs to have a separate "trusted
calendar" list that ensures the aggregators actually return a timestamp with
pending attestations from the right calendars... and since those attestations
aren't signed, there's no way of knowing if that was actually done!
An alternative approach would be to make calendars be an authenticated
datastructure, with every per-second commitment signed. This would allow
pending attestations to be verified as actually coming from a trusted calendar,
removing the current trust placed in the transport layer.
In this approach the actual calendars themselves would be hosted separately,
with the URLs to access them mapping to a horizontally scalable set of
servers that both cached calendar requests, and performed per-second
All the above can be done in a somewhat less secure fashion by omitting the
commitment signatures. However added them would be a good opportunity to
implement my previously discussed(3) discardable keys trusted timestamping
proposal, allowing the signature to both attest to the time, and a promise to
eventually timestamp the commitment.
Unfortunately the above would still leave us with a source of terminology
confusion: we'll end up with a distinction between the calendar data structure,
and the _calendar servers_ that provide access to calendar data structures.
Notably, we'd expect calendar servers to frequently provide access to multiple
calendars at a time, both for mirroring, and for special use-cases such as
sub-second latency timestamping. But I think that architecture is easier to
explain - "you can access a calendar through a calendar server" - than the
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 455 bytes
Desc: Digital signature
More information about the ots-dev