Verification

When a box is gone Built

A box switched off, decommissioned, repossessed, or run by someone who has since become the other side of an argument — that is the case evidence exists for. Checking a receipt never asks the box. This page is what it does ask for instead, and what you should keep so the answer stays available to you.

Nothing in the check talks to the box

Everything the box contributes travels inside the receipt: the sealed header, the salt for your payload, the signed batch it belonged to, and the path from your event up to that batch's root. Given the receipt and your original bytes, the hashes and the signature are checked on your own machine.

Checked from what you hold	What it settles
Your bytes hash to the payload hash in the header	The record is about the data you have, not a different version of it
The header hashes to the leaf the receipt proves	Every field the receipt displays is the field that was sealed
The path walks from that leaf to the batch root	The event was in that batch, at that position
The signature over the batch verifies	The batch was sealed by the key that environment publishes

None of those steps makes a request to the box, and none of them can be influenced by whoever holds it now. A box that is switched off cannot withdraw what it already sealed, and cannot un-publish what it already published.

Three things come from outside the box

Deliberately outside, because a fact supplied by the system under examination is not evidence about that system.

What	Why it is not in the receipt
The environment's public key	A key handed over by the box under suspicion proves nothing. It is fetched from where the box cannot rewrite it, and a verifier given a key of unknown provenance answers `unknown` rather than `valid`.
The published root	Each sealed batch's root is recorded in the public log, in a chain, so a record that existed yesterday cannot quietly differ today without that being detectable.
The Bitcoin anchor	Signed heads are timestamped through OpenTimestamps. This is the one part that depends on nobody — not on the box, and not on us.

What this does and does not promise

Independent of the box: built, and true today. Shut a box down and the receipts you hold still check out, against a key and a log it never controlled.

Independent of enTrail: not yet. We would rather write that plainly than let you discover it during an audit. Three gaps, and they are the reason this page exists:

The key record and the published root are served by us. The box cannot touch them, which is the property that matters against a hostile box. It is not the same as those records existing independently of enTrail, and neither one is inside the receipt.
The anchor proof arrives after the receipt does. A receipt fetched shortly after sealing says its anchor is pending, correctly; the proof is available once Bitcoin has confirmed. Until you have fetched the receipt again and kept that copy, the proof is something you would come back to us for.
The verifier is not open source yet. The checks are all standard — SHA-256, Ed25519, RFC 8785 canonical JSON, an RFC 6962 Merkle tree — so an independent implementation is a short piece of work rather than a research project. But today it is work somebody has to do, and we send the step-by-step procedure and golden test vectors on request rather than publishing them.

How long published records are retained is a term of your agreement rather than a number we print in documentation. Ask, and you will get it in writing.

What to keep, so none of that is your problem

Every gap above closes for one event the moment you keep a copy of five things. This is worth doing for the records you would least like to argue about, not for all of them.

The receipt. Stored with your own record of the event, not only on the box.
The original bytes, or their hash together with the salt from the receipt. Without one of those, the first check is skipped and the rest still prove out.
Re-fetch the receipt once the anchor has landed and keep that copy. It carries the proof, and that is the moment the strongest part of the evidence becomes yours.
The key record for that environment as it stood when the receipt was issued.
The published root record the receipt's batch appears in.

The rule of thumb. Keep what you would need to convince someone who trusts neither the box nor us. Today that is five files. It is meant to become one, and that is the next item below.

Coming: an export that stands on its own

The work is to put the key record, the log inclusion proof and the anchor proof inside the receipt or the .entv file, and to publish the verifier as open source. A file would then check out with nothing of ours reachable, which is the sentence we want to be able to write and cannot write yet.

It is on the roadmap and not dated here. Ask if it matters to a decision you are making, and you will get an honest position rather than a quarter.

The related reading

Verify a receipt — the ordinary check, and what the answer will not claim.
The .entv file — handing a verification to someone else.
The trust model — the limits, stated once, in one place.

For the by-hand procedure and the golden test vectors: info@entrail.io.