Two packages for signing and checking evidence files
The two packages’ test suites, run in a fresh checkout
- Tests passing, as first run
- 96
- Tests passing, after building the one missing library
- 97
Code with its suites run, not a deployed service; no external anchor exists.
Two standalone code packages for signing and checking the lab's evidence files run their test suites; they claim no external timestamp anchor, and several parts are taken from earlier code
What it does not claim
No external anchor exists. Several primitives are taken from the lab's earlier code. Keys and trust operations are left to whoever deploys the packages, and they are not a deployed network. The lab's code is not public yet.
The limits, in the lab’s words:
'Externally anchorable' is NOT evidence of a live Bitcoin or OpenTimestamps anchor — NO EXTERNAL ANCHOR EXISTS.
Keys and external trust operations are deployment responsibilities.
The README's 'network' label overstates deployment.
Excerpts, word for word from the published file, where the full text can be read.
Evidence files are only useful if a reader can check they are the files the lab produced. The lab built two small packages for this: canonical JSON, two independent digests, signatures, signed statements of where a file came from, verification that refuses on any doubt, and Merkle inclusion proofs of the kind certificate logs use.
What it shows
In this measurement: the two packages' own test suites, run in a fresh checkout.
The lab's limits record the suite at 96 passing tests with one skipped and one failing, because one test needs a Lean library that is not built by default, and 97 passing once that library is built. The command the lab records now builds it first.
Why it matters, and to whom
For a buyer checking this lab's results, the packages are how a served file is tied to what the lab produced. They narrow what has to be trusted; they do not remove the need to trust the keys and whoever holds them.
Why now
More results are now shipped as files with signatures and logs, as certificate transparency did for web certificates, and a buyer needs to know which parts of that chain exist and which do not.
How it was checked
The lab ran both suites in a fresh checkout and recorded the counts, the one failure and its cause.
How to reproduce
The measured results name the lab's command and commit, and the lab's claim and limits are published word for word. Each is listed with its hash in the site's receipt manifest.
The result, in the lab’s exact words
Read it with this condition: the packages are code with their test suites run, not a deployed service; nothing is anchored to an outside timestamp, keys are left to whoever deploys them, and some parts come from the lab's earlier code.
Two standalone packages that are real code and not scaffolding — canonical JSON, dual digests, signatures, signed provenance statements, fail-closed verification, Lean-to-gate extraction and RFC-6962-style inclusion proofs — with their suites executed.
Quoted word for word from the lab’s published claim and limits.
Prior art
- Laurie, Langley and Kasper, "Certificate Transparency" (IETF RFC 6962, 2013): the Merkle inclusion proofs the packages implement
- OpenTimestamps: an external timestamp anchor of the kind the lab says it does not have
Evidence
- The measured results behind this page, read from the lab’s own files at a named version.
- The lab’s current claim and limits, word for word.
- Every file this site publishes.