Daily logs for Nov 1, 2026

Written by: Tushar Sharma

Featured image for Daily logs for Nov 1, 2026

Dear Vishi, dear logs for today.

Reading How to Time-Stamp a Digital Document by Stuart Haber and W. Scott Stornetta

Link: https://staroceans.org/e-book/Haber_Stornetta.pdf

We will start by designing a Time-Stamping Service (TSS). A client sends a document to the TSS, and the TSS returns an acknowledgment that proves the document existed at a particular time.

The first challenge is that we don't want to send the whole document to the TSS. That would take a lot of bandwidth and reveal the document's contents. Instead, we hash the document and send only its hash. What is a hash?

A hash is a collision-resistant, one-way function. You pass it an input of arbitrary length, and it returns an output of fixed length. Some properties are:

It is easy to compute hash(x).
It is computationally infeasible to find two different inputs, x and x', such that hash(x) = hash(x').
Given y = hash(x), it is computationally infeasible to recover x.

The client sends the document's hash and a unique client ID to the TSS. Why not encrypt the document instead? Encryption hides the contents, but it doesn't reduce the document's size. A hash does both jobs needed here: it hides the original contents and gives the TSS a small, fixed-length value to timestamp.

The TSS sends back a certificate containing (n, t_n, L_n, ID_n, y_n), protected by the TSS's digital signature sigma.

n: sequence number
t_n: timestamp
ID_n: client ID
y_n: hash of the client's document
L_n: information linking this certificate to the previous certificate, including the previous timestamp, client ID, document hash, and link value

Q: How does the client know that the response came from the TSS?

A: The client can verify the TSS's digital signature.

Q: How does the client know that the TSS didn't backdate or forward-date a timestamp?

A: Each certificate is linked to the certificates before and after it. Changing one timestamp would break this chain, so the TSS would also need to rewrite the surrounding certificates. Those certificates have already been sent to other clients, who hold evidence of the original chain.

We can also distribute trust instead of relying on one TSS. A pseudo-random function G(y_n) selects k clients from the document hash. The TSS sends the certificate to those clients, and they keep copies. This feels similar to the role of validators now.

How do we select the k clients, and why should we trust them?

The document hash determines the selection, so the TSS cannot freely choose friendly clients after seeing the request. We don't have to trust each selected client individually. We rely on the random selection making it unlikely that all k clients will collude with the TSS. The clients' copies make it harder for the TSS to change the timestamp history later.