What is OpenTimestamps?

OpenTimestamps is an open standard and a free service that anchors arbitrary data into the Bitcoin blockchain via a Merkle aggregation. Verification only requires the OpenTimestamps client and access to a Bitcoin node (or a trusted block-header source). It is independent of any single calendar server or commercial vendor.

Why does ExistBefore offer .ots downloads?

Long-term proof of existence should not depend on a single vendor. By exposing the OpenTimestamps file produced by the T2 layer, ExistBefore lets you verify the Bitcoin anchor with a third-party client that has nothing to do with CertiSigma or ExistBefore. If both companies disappeared tomorrow, the .ots file plus the original content would still prove the timestamp.

Does T0 (ECDSA) or T1 (eIDAS) export to OpenTimestamps?

Not yet. The T0 layer is an ECDSA signature and is verified offline against the embedded public key (see the verify page). The T1 layer is an eIDAS qualified timestamp; the registry currently exposes T1 metadata (timestamp, provider, Merkle inclusion proof) but not the raw RFC 3161 token. T1-to-OpenTimestamps export and standalone RFC 3161 download are on the roadmap. T2 (Bitcoin via OpenTimestamps) is the layer that already exports today.

How long does T2 take?

T2 is anchored every Bitcoin block (~10 minutes), but the .ots file becomes verifiable only after enough confirmations land — typically 1 to 6 hours after the attestation. The proof page shows the exact block height and confirmation count when T2 is complete.

OpenTimestamps interop

Verify your Bitcoin anchor with the standard OpenTimestamps client.

Every ExistBefore attestation eventually reaches T2 — a Bitcoin anchor, computed via OpenTimestamps. The proof page exposes that anchor as a downloadable .ots file you can verify on your own machine, with software that has nothing to do with CertiSigma or ExistBefore. If both companies disappeared tomorrow, the file plus the original bytes would still prove the timestamp.

Where OpenTimestamps fits in the three-layer proof.

An ExistBefore attestation accrues evidence over time. Each layer is independently verifiable; OpenTimestamps interop covers the strongest one.

T0 — ECDSA registration (milliseconds). A signature over the SHA-256, produced by the CertiSigma registry. Verified offline against the embedded public key on the verify page. Not exported to OpenTimestamps (it is not a Bitcoin anchor).
T1 — eIDAS qualified timestamp (≈1 hour). A qualified-trust-service timestamp issued under EU regulation. The registry exposes T1 metadata (timestamp, provider, Merkle inclusion path); standalone RFC 3161 token download and OpenTimestamps export are on the roadmap.
T2 — Bitcoin anchor (1–6 hours). An OpenTimestamps proof that ties the attestation hash to a specific Bitcoin block. This is the layer the .ots download exposes today.

Download and verify in three commands.

Open the proof page for an attestation that has reached T2. The button "Download .ots proof (Bitcoin)" appears on the actions row only when T2 is complete. Save the file as existbefore-att_xxx.ots.
Re-fetch the original content — the same bytes you attested, byte-for-byte. The .ots proof binds the SHA-256 of those bytes; if the bytes differ in any way, verification will fail.
Run the standard OpenTimestamps client. Install with pip install opentimestamps-client (or use a binary release), then:
```
ots verify existbefore-att_xxx.ots -f your-original-file
```
Connect to a Bitcoin node (or use a trusted block-header source) when prompted. The client prints the Bitcoin block height and the UTC timestamp of the block that anchors your hash.

No CertiSigma server is contacted during verification. The only network calls are to a Bitcoin source of your choosing.

Why a Bitcoin-anchored receipt matters.

An ECDSA signature proves "the registry signed this hash". A qualified eIDAS timestamp proves "a regulated trust service witnessed this hash at this time". Both are valuable; both ultimately depend on a third party staying in business and on its private keys staying uncompromised.

A Bitcoin anchor is different. It proves "this hash was committed to the Bitcoin blockchain before block N", which means "before any human could have crafted a false claim about its existence". That property is enforced by tens of thousands of independent nodes, costs roughly the global hash-rate to forge, and survives the disappearance of every commercial party involved.

OpenTimestamps lets you verify that property without trusting OpenTimestamps either: the client computes the Merkle path locally and checks it against block headers you can fetch yourself.

Roadmap — extending interop to T0 and T1.

Today the .ots download is T2-only. Two extensions are in design:

T1 RFC 3161 token download. The eIDAS qualified-timestamp layer is currently surfaced in the registry as parsed metadata (issuer, timestamp, Merkle inclusion path). A future release will expose the raw application/timestamp-reply token as a standalone .tsr download, verifiable with openssl ts -verify and other RFC 3161 clients.
T1 → OpenTimestamps bridge. When the raw token is exposed, an in-browser bridge can synthesise an OpenTimestamps proof that anchors the eIDAS digest into the same proof structure used by T2 — letting users verify both layers with a single command.

Both extensions preserve the privacy invariant (the original content never leaves your device) and require no new client-side dependencies beyond the standard OpenTimestamps client.

References

OpenTimestamps homepage: https://opentimestamps.org/
OpenTimestamps client (Python): github.com/opentimestamps/opentimestamps-client
JavaScript client (browser-friendly): github.com/opentimestamps/javascript-opentimestamps
RFC 3161 (Time-Stamp Protocol): rfc-editor.org/rfc/rfc3161
ExistBefore three-layer timestamping · proof of existence vs. copyright · build integrity audit