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 aggregation. 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 calendar/aggregator distinction. 1) https://github.com/opentimestamps/opentimestamps-client/pull/59 2) https://github.com/opentimestamps/opentimestamps-client/pull/60 3) https://lists.opentimestamps.org/pipermail/ots-dev/2017-May/000001.html -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: Digital signature
