Why a seal needs witnesses

Every Plimsoll SI run is sealed. A seal shows that a record has not changed since it was sealed. It cannot show that whoever holds the record did not rewrite the whole history and seal it again. That needs someone else to have seen the history first.

The weakness of a chain

Delete a record, recompute every hash after it, sign the result, and a plain hash chain verifies perfectly. We measured it over 1,000 randomised trials per attack, on logs of 8 to 600 real records. After every rewrite, deleting a record, flipping an outcome, swapping two neighbours or truncating, the chain verified clean.

What a witness does

Our witnessed log is an append only Merkle tree built to RFC 9162. The log signs checkpoints: a size, a root and a time. A witness is a separate party that keeps the last checkpoint it cosigned for each log, and cosigns a new one only if the log's signature holds, the size has not shrunk, time has not run backwards, and a consistency proof links its stored checkpoint to the new one. The old size is always the witness's own, never one the log names.

The control row is the honest limit. Entries appended since the last cosigned checkpoint are unprotected, and the window is exactly the interval between checkpoints. A verifier holding one trusted chain head and replaying the whole prefix would also catch the first four attacks; what the witnessed log adds is a check that costs a logarithm instead of a replay, made before anything is cosigned, by many parties at once.

Forks need comparison

An operator can show one branch to one witness and another branch to another. Each witness alone sees a consistent history: no single witness caught any of 1,000 such forks. Witnesses comparing checkpoints caught 1,000 of 1,000. Relying parties that accepted one cosignature took both branches in every trial; a majority quorum accepted neither in any trial. That result changed our default: the quorum is now a strict majority of the witnesses a reader knows.

What it costs

Proofs grow with the logarithm of the log. At one million entries the longest inclusion proof was 20 hashes, 640 bytes, verified in about 21 microseconds. Checking one record against a linear chain means replaying about half of the later records. A second implementation written straight from the RFC agreed with ours on every inclusion and consistency proof for every size from 1 to 300: 90,600 pairs, 0 disagreements.

Where it sits in a run

A seal with an Ed25519 signature is verified only against a public key the reader pins, never against a key the file names. A seal made with a shared secret says it is not a signature, because whoever can check it can forge it. And the nonce of a commitment, consumed in a witnessed log, is what makes a quiet second attempt visible.

What this does not show

• Witnessing is an option of the engine, for a validator who cosigns a commitment before the run. Passports from the hosted product are sealed and signed today; they are not yet witnessed.
• A witness accepts its first checkpoint for a log without a proof, so history written before first contact is unprotected. Witnesses should be enrolled when the log is created.
• A log proves what was submitted and in what order. It does not prove that everything was submitted, or that a record was true when it was written.
• Timestamps are the operator's claims. The only outside time bound is a witness cosignature: the entries existed by then.
• This release has no network transport and no gossip between witnesses. Witnesses compare checkpoints once they have exchanged them by other means.