Koch Laboratory

Time as an agreed unit and as evidence

Six directions on a time service whose statement is meant to hold for someone who trusts neither us nor our server: a zone-free unit, a clock that ticks without asking the server and publishes its own error, a weekly Merkle log, anchoring in a bank transfer reference beside Bitcoin, a draw nobody can steer, and proof of co-stamping a moment without identity.

Koch Laboratory — time as an agreed unit and as evidence

This direction started from a practical question: why does agreeing on a single moment between two people in different time zones require a translation rather than a reading? It ended at a harder one: what must a time service be for its statement to carry evidential value for someone who trusts neither us nor our server?

Method. As in the rest of the laboratory: problem → hypothesis → falsifiable criterion → method → result with boundary conditions. Statuses are stated openly: “implemented” means running at a public address, “design work” means no measured result.

1. Direction 1 — a unit of time that can be spoken without context

Research question. Can a moment be stated so that the recipient needs to know neither the sender’s zone nor their own — without losing reversibility against UTC? Why it is hard. Time zones are not a function of geography but of political decisions: they change from year to year, include half-hour and seasonal offsets, and the rule base is a moving target. Every local notation therefore needs extra state to be understood — and that state is sometimes out of date. State of the art (published). ISO 8601 and UTC (correct, but conversion happens at the recipient); Swatch Internet Time from 1998 — a zone-free unit, but anchored in BMT (UTC+1, the company’s own seat) and without an open interface; TAI and Unix time as technical foundations, never meant to be spoken. Success criterion. Reversible, test-covered conversion UTC↔unit with no dependency on any zone database; the unit coarse enough to be spoken in conversation (1/1000 of a day = 86.4 s) and fine enough to agree on a meeting to the minute. Result. Confirmed within the criterion: anchored in UTC/Greenwich rather than BMT, an open API (now, convert, sync, health), the conversion core as a pure, tested module. Boundary condition: the unit does not replace ISO 8601 in machine records — it is a speakable layer, not a storage format. Status: implemented.

2. Direction 2 — a clock that ticks without asking the server

Research question. Can a public clock run without network traffic while it runs — hence without telemetry and without a scaling cost — and stay accurate enough for the chosen unit? Why it is hard. A clock that queries the server every tick is also a visitor counter: every tick leaves an IP address in someone else’s log. A purely local clock, on the other hand, inherits the error of a device clock we neither control nor know. State of the art (published). SNTP/NTP as the model of one-off offset synchronisation; web clocks that typically poll a server on a cycle. Success criterion. Zero network requests after start-up; explicit measurement and publication of our own error instead of a silent assumption of correctness. Result. Confirmed: the client fetches the offset once and ticks locally (the SNTP model), working offline. In addition, a periodic task measures the host clock’s drift against NTP and exposes it in /api/health — a time service that publishes its own error rather than hiding it. Boundary condition: client-side accuracy remains bounded by the device clock; for a unit of 86.4 s that is irrelevant, for evidential use it is not — which is why the proof of time (direction 3) never rests on the client’s clock. Status: implemented.

3. Direction 3 — a public stamp log: existence without disclosing content

Research question. Can one demonstrate that a document existed in a given week without revealing its content and without trusting the operator of the service? Why it is hard. An operator who can insert entries retroactively is useless as a witness — and the operator’s own signature does not rule that out. The log must therefore be closed in time and verifiable by someone with no database access; at the same time, no verification may require producing the document. State of the art (published). RFC 3161 (TSA — credibility reduced to trusting the authority), Certificate Transparency (Merkle trees with inclusion proofs), OpenTimestamps. Success criterion. Only SHA-256 is recorded; the weekly root is frozen once the week has ended and signed with Ed25519; for any hash an inclusion path is reconstructible and checkable without access to the system. Result. Confirmed: a weekly Merkle tree, a root frozen at week close, an Ed25519 signature, an inclusion path per digest, deduplication as “first seen”. Boundary condition: the granularity of the proof is a week — the service proves “no later than”, not “exactly at”. Status: implemented.

4. Direction 4 — anchoring in a register the operator does not control

Research question. What should the weekly root be anchored in so that the proof survives the loss of trust in the service — and does not depend on a single technical world of our own choosing? Why it is hard. The anchor must land in a register dated by a third party, resistant to retroactive change, cheap, and repeatable weekly for years. A blockchain satisfies the first three conditions but introduces a dependency on one ecosystem and its cost; publication in the press (the classic Surety solution of the 1990s) is expensive and hard to automate. State of the art (published). OpenTimestamps anchored in Bitcoin; the historical practice of publishing hashes in newspaper advertisements; commercial timestamping authorities. Success criterion. At least two independent anchoring channels, neither controlled by the operator of the service, each verifiable on its own. Result. Confirmed: the first channel is OpenTimestamps. The second is the reference line of a bank transfer — the weekly root written as MROOT <YEARWnn> <8 groups of 8 hex characters> (85 characters, fitting the 140-character reference field), booked by a regulated institution that keeps its own record of time, independent of us, and has no reason to alter it on our behalf. Boundary condition: the banking channel has booking granularity (business days) and requires a manual confirmation of the reference; it is cheap and entirely independent of cryptocurrencies, but it is not immediate. Status: implemented.

5. Direction 5 — a draw nobody controls, ourselves included

Research question. Can a public random value be derived from material that the operator cannot select towards a predetermined outcome? Why it is hard. Any server-side draw is unverifiable, and any “draw from a seed” is steerable if the seed is chosen by whoever announces the result. Commit-reveal schemes require discipline and another round of trust. State of the art (published). Public randomness beacons (drand, the NIST beacon among others), commit-reveal schemes, deriving randomness from block headers. Success criterion. The result is recomputable by anyone from material already published and already signed, with no server-side state whatsoever. Result. Partial — and worth publishing as such. The value of the day is a function of the root of the last closed week and the date (beattime-thebeat-v1|<root>|<date>, SHA-256, first 6 bytes mod 1000). What is achieved is unsteerability and full verifiability: the operator cannot select the outcome, because the root was frozen and signed before the date came around. What is not achieved is unpredictability — the root is public, so anyone can compute the whole coming week’s values in advance. We state this explicitly, because conflating the two properties is the most common error in this class of solutions. Status: implemented, with an explicitly bounded property.

6. Direction 6 — proof of co-stamping a moment without the parties’ identity

Research question. Can two people jointly record a single moment such that the proof is publicly verifiable and the service never learns who they are? Why it is hard. The obvious solutions (accounts, phone numbers, contact lists) solve identity by transferring it to the operator — and create exactly the register we want to avoid. Without identity, however, linkability disappears: “the same person for the fifth time” becomes indistinguishable from five strangers. State of the art (published). Proximity proof protocols (BLE, audio), Ed25519 signatures, C2PA as a provenance standard. Success criterion. The service stores only two random salts and the resulting hash; neither party could have produced the hash alone before the meeting; key continuity replaces the name. Result. Confirmed: the hash is derived from both salts and the time issued by the server; version v2 additionally binds the raw public keys of both parties, and possession of the keys is proven by signature. Descriptions of “with whom” exist only on the phones. A boundary stated openly: the proof shows that two parties co-stamped the same moment — it does not show physical proximity; the same protocol can be run remotely, and it should be read that way. Status: implemented (v1 and v2).

Status of the direction. The time core, the public log, the anchoring and the co-stamping protocol are running publicly; the application layers (Android, wear, extension, SDK) are under construction. Next research step: content provenance (C2PA) as a layer above the existing log — added as a layer, never as a foundation.