Skip to content
Agent Identity
Skip navigation

The Transparency Log

How an issuance becomes a leaf, what a checkpoint commits to, and why a shredded entry leaves the proofs intact.

Published

On this page (5)

The Transparency Log Documentation

The registry says what is true now. Every issuance and every revocation also becomes a leaf in a tamper-evident, signed transparency log, so a relying party can show that the identity it verified today is the identity that was issued, and that nothing was rewritten in between.

What a leaf is

The log is a Merkle tree in the RFC 6962 style. A leaf commits to one event; interior nodes commit to their two children; the root commits to everything.

text
leaf      = sha256(0x00 || sha256(salt || event))
interior  = sha256(0x01 || left || right)

The inner hash is what matters for privacy. An event is salted before it is hashed, so the leaf is a commitment rather than a copy. Destroying the salt destroys the ability to read the event back, while every hash above it stays valid. That is what makes an erasure request compatible with an append-only log: the record can be shredded and the tree still proves its own shape.

What a checkpoint says

A checkpoint is a signed statement of the form "at this size, the root is this". It is signed with Ed25519 and served in the C2SP tlog-tiles format, so ordinary transparency-log tooling reads it without anything Whisper-specific.

bash
curl -s https://whisper.online/checkpoint

Keep two values from it: the tree size, which says how many leaves existed when it was signed, and the root hash, which every later proof is checked against. The signing key is published as a TXT record under _whisper-ledger.whisper.online, so the key that signs the checkpoints is itself anchored in DNSSEC. Checkpoints are also stamped into Bitcoin through OpenTimestamps, which gives each one an independent lower bound on its age.

The two proofs you will actually use

An inclusion proof answers "is this leaf in that tree". You give the leaf, you get the sibling hashes that reconstruct the root, and you check them against a checkpoint you already hold.

A consistency proof answers the harder question: "is the tree I see now an append-only extension of the tree I saw before". You give the earlier size as from and the later size as to. If a leaf were ever removed or altered, that proof could not be produced. It is the check that turns a signature into evidence.

The per-identity view

Walking the global tree to answer a question about one address is more work than the question deserves, so the registry carries a per-identity arm: the events for a single allocation, each with its proof, under a signed root.

bash
curl -s https://rdap.whisper.online/ip/2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478/transparency | jq .

Attach this to an incident writeup or an audit finding: it is scoped to the identity under discussion and it is self-contained. RDAP and WHOIS documents the response.

Revocation has its own list

A revocation is an event like any other, and it is also published in a signed status list, so a relying party can ask "has this been withdrawn" without walking the tree. Revoke an Identity uses that list as the last step of its proof.

Every endpoint named here, with its parameters and its status codes, is in Keyless Endpoints.