Transparency logs

A transparency log is an append-only public record of every operation a system performs. The point: anyone can audit the log to see what happened, and the log operator cannot undetectably rewrite history.

Confium’s transparency log implements RFC 6962 — the same standard Certificate Transparency is built on.

Why transparency matters

A certificate proves “this was signed by the issuer”. It doesn’t prove:

  • “This is the only certificate the issuer ever signed for this subject.”
  • “This is the same certificate every other verifier sees.”

Without transparency, a compromised CA can issue certificates silently. Verisign did this in 2015; Symantec did it repeatedly between 2015 and 2018. The affected parties had no way to know.

With transparency, every issuance lands in a public log. Anyone can monitor the log and see what’s being issued. A verifier can demand an inclusion proof that the certificate it’s verifying is in the log.

Merkle trees

The log is a Merkle tree built from SHA-256 hashes:

  • Each leaf is SHA-256(0x01 || entry_hash).
  • Each internal node is SHA-256(0x02 || left_child || right_child).
  • The root hash commits to the entire set of leaves.
RFC 6962 Merkle tree: leaves hashed with 0x01 prefix, internal nodes with 0x02 prefix; root commits to the entire set. ROOT H(01|L|R) H(01|L|R) H(01|..) H(01|..) H(01|..) H(01|..) 0x01 entry[0] 0x01 entry[1] ★ 0x01 entry[2] 0x01 entry[3] inclusion proof for entry[1] root = commitment to all leaves

The diagram shows a 4-leaf tree. The gold path traces the inclusion proof for entry[1]: the verifier starts with the leaf hash, combines it with each sibling up the tree, and checks the final result equals the published root.

Domain separation (0x01 for leaves, 0x02 for internal nodes) prevents leaf values from being interpreted as internal nodes and vice versa.

Changing any leaf, or reordering leaves, changes the root hash. The root is the cryptographic commitment to the log’s full state.

Inclusion proofs

An inclusion proof demonstrates that a specific entry is in the log without revealing anything else. The proof is a sequence of (sibling_hash, side) pairs:

To prove entry[3] is in the log:
  start with hash(entry[3])
  combine with sibling at level 0 (right side): SHA-256(0x02 || current || sibling0)
  combine with sibling at level 1 (left side):  SHA-256(0x02 || sibling1 || current)
  ...
  final hash should equal the published root

The verifier doesn’t need the full log — just the proof (~log N hashes) and the published root.

Consistency proofs

A consistency proof shows that the tree at size N+1 extends the tree at size N — the first N entries are identical. This is what makes split-view attacks detectable.

If a log operator presents tree head N to verifier A and a different tree head N to verifier B, at least one of them will fail a consistency check against the true history.

The split-view attack

Without consistency proofs, a log operator can present two different tree heads to different verifiers, and nobody can detect it:

Split-view attack on a transparency log, and how consistency proofs + witness gossip detect it. THE ATTACK Log operator compromised head A root=0xab... head B root=0xcd... Verifier A Verifier B silent insertion / omission undetected without defense THE DEFENSE Witness network gossips heads hourly head A head B ⚠ DIVERGENCE DETECTED + OTS anchoring in Bitcoin for irrefutable time proof DEFENSE IN DEPTH 3 layers, each adds assurance

The left side shows the attack: a compromised log operator presents head A to verifier A and head B (with a different root) to verifier B. Both can verify their own inclusion proofs against their own heads. Neither knows the other’s head exists.

The right side shows the defense: witnesses gossip heads between coordinators. If two coordinators have different heads for the same tree size, the witnesses detect the divergence.

  1. Verifier A receives tree head N.
  2. Verifier B receives a different tree head N’ (with a different root).
  3. Both verifiers can verify their own inclusion proofs against their own heads. Neither knows the other’s head exists.
  4. The log operator can insert or omit entries selectively per audience.

Defense in depth

Consistency proofs alone are necessary but not sufficient — verifiers must also communicate (gossip) so they know about each other’s heads. Three layers:

Defense in depth against split-view attacks: consistency proofs, witness gossip, OTS anchoring. ADVERSARY MUST DEFEAT ALL THREE 1 Consistency proofs RFC 6962 §2.1.2 — every new tree head extends the previous one. Defeats: silent rewriting of history. 2 Witness gossip Coordinators share heads periodically; witnesses detect divergence. Defeats: log presenting different views to different verifiers. 3 OTS anchoring in Bitcoin Tree heads timestamped in Bitcoin blockchain — irrefutable time proof. Defeats: adversary who controls log AND all witnesses. REMAINING ATTACK COST ≥ CONTROLLING BITCOIN HISTORY
  1. Consistency proofs — every new tree head extends the previous one. Implemented in confium-transparency.
  2. Witness gossip — coordinators share tree heads with each other periodically. If two coordinators have different heads for the same tree size, the witnesses detect the inconsistency.
  3. OTS anchoring — tree heads are timestamped in the Bitcoin blockchain via OpenTimestamps, providing an irrefutable “what head existed at time T” record.

The combination defeats any adversary who doesn’t simultaneously control the log operator, all witnesses, and has the ability to rewrite Bitcoin history.

See also