[amluto]

I'm curious why the clients chain requests but the servers don't chain replies. It would be straightforward for servers to emit a CT-style log as they go, thus forcing servers to prove that all their timestamps are in order. With a bit of refinement, it would also allow servers to prove that they didn't generate, say, Thursday's timestamp prior to learning a nonce that was sent to them on Wednesday. If nothing else, this would substantially strengthen its use as a timestamping service.

Also:

> It is the case that the signature, even assuming one request per batch, will add some number of microseconds of latency to the reply. Roughtime is not going to displace PTP for people who care about microseconds.

I'm not convinced that this should prevent extremely precise timestamping a la PTP. The server just needs to indicate, outside the signature, how long its processing took. Sure, this prevents authentication of the fine-grained time, but a client could easily bound the amount that a server can cheat.

[pcl]

I'm curious why the clients chain requests but the servers don't chain replies.

One challenge would be around server scale -- for the servers to maintain a strict chain, they would need to coordinate amongst themselves, which can be costly. The proposed approach doesn't introduce that requirement.

But they could get close by maintaining a branching history, like what you might see in a git history, or a vector clock. Neither of those approaches provides the same causality assurances as your proposal, but either would provide something close without incurring any blocking server-side state management.

[amluto]

I just meant for servers to maintain a local chain. Cross-server checking would be free, sort of, as clients that talk to multiple servers would inject the chain state from the first server into the second via their nonces.

[pcl]

At scale, a time server's DNS address will likely either be a reverse proxy or a multi-valued A record. The coordination amongst those separate physical servers that are serving requests for the same DNS name would become a scale challenge if they needed to share state.

[amluto]

But they wouldn't need to share state. They could run independently, and any client that wanted to tie their clocks together could request the signed time from one and then send it to the other, causing it to get logged in the other server's chain.