Re-deriving what 23 public logs say they did

No key, no cosignature, on no witness list · a batch monitor cannot see a split view between batches · verifier failures are charged to this monitor first

What a batch monitor cannot do

• Catch a split view that is served to one reader and withdrawn before the next batch. A monitor sees the log at the instants it reads it and says nothing about the gaps.
• Give anyone else an attestation. A monitor's output is a claim about what one reader saw. A witness cosignature is a claim other parties can rely on, and this node produces none.
• Detect anything at all about a log it does not read. The population is frozen and small, and the ledger reports it as a population rather than as coverage.

How to cite / re-check

Verifier self-tests

Formats and operators

Where they refuse

Limbs

Chains are evaluated independently. A failure inside one chain stops that chain and does not touch the others, so a log whose signature scheme this monitor cannot read is still read, still compared across the two reads, and still counted.

Predictions

• Missed: This monitor holds no prior batch for any log, because this is the first batch, so the cross run comparison refuses for every log in the population. Observed: 23 of 23 logs had a prior batch on record.
• Missed: At least one log in the population refuses a re-derivation limb for a reason that belongs to this monitor rather than to the log. Observed: 0 of 23 logs refused for a reason attributed to this monitor.

Prior art

• RFC 6962, Certificate Transparency : Defines the signed tree head, the get-sth and get-sth-consistency endpoints this monitor calls, the TreeHeadSignature input it reconstructs, and the consistency proof verification algorithm it implements.
• RFC 9162, Certificate Transparency version 2.0 : Restates the same Merkle constructions and is explicit about the separation between logs, monitors and auditors that this ledger relies on.
• C2SP signed note and tlog checkpoint : The text checkpoint format the Go checksum database and Sigstore serve, which this monitor parses: origin line, tree size, base64 root hash, blank line, signature lines.
• C2SP tlog-witness : The witness protocol this node deliberately does not implement. A witness cosigns with a key and this node holds none.
• transparency.dev : The ecosystem this work sits inside, and the source of the witness and monitor distinction the ledger is built around.
• Sigsum : A log design where witness cosigning is mandatory rather than optional, which is the contrast that makes counting cosignatures on other logs worth doing.
• Go checksum database design : The tile based transparent log this monitor reads a checkpoint from and cannot yet prove consistency over.

Re-run

PYTHONPATH=engine python3 engine/tools/tlog_monitor_run.py selftest
PYTHONPATH=engine python3 engine/tools/tlog_monitor_run.py expect
PYTHONPATH=engine python3 engine/tools/tlog_monitor_run.py run
PYTHONPATH=engine python3 engine/tools/tlog_monitor_export.py

What this is not

• This node is a monitor, not a witness. It holds no key, cosigns nothing, and appears on no witness list. Nothing in this ledger is an attestation anybody else can rely on.
• A batch monitor cannot see a split view that is served to one reader and withdrawn before the next batch. It sees the log at the instants it reads it and says nothing about the gaps between them.
• A signature this monitor fails to verify is recorded as this monitor failing to verify it. The verifiers here are hand rolled in pure Python because this engine carries no cryptography library, and a hand rolled verifier that disagrees with a log operated by Google is overwhelmingly more likely to be the broken party.
• This is not coverage of the transparency log ecosystem. The population is a frozen list drawn from public log lists, and no rate here should be read as a rate over all logs.
• No log was contacted beyond plain GETs of endpoints that are already public, with an identifying user agent.