---
title: "Manual verification with the OpenTimestamps client"
manual: "T3Vault"
version: "main"
permalink: "https://docs.typo3.org/permalink/codemacher/t3vault:opentimestamps-manual@main"
source: "Integrity/OpenTimestampsManual.rst"
rendered: "2026-10-01T12:10:44+00:00"
---

# Manual verification with the OpenTimestamps client {#opentimestamps-manual}

You can check `integrity.json.ots` **independently** of T3Vault using the
official OpenTimestamps command-line client. Combined with a hash check of the
backup artefacts, this answers: *has anything in this backup been changed
since it was sealed?*

Upstream project:
[opentimestamps-client](https://github.com/opentimestamps/opentimestamps-client).

For the recommended overall flow, see [How to verify a backup (recommended)](https://docs.typo3.org/permalink/codemacher/t3vault:integrity-how-to-verify@main).

## Install the client {#opentimestamps-install}

Python package (typical on Debian/Ubuntu):

```bash
sudo apt install pipx
pipx install opentimestamps-client
# or: pip install opentimestamps-client
```

Confirm the binary:

```bash
ots --help
```

## What was stamped? {#opentimestamps-what-is-stamped}

T3Vault stamps **only** `integrity.json` (not the ZIP files themselves).
The ZIP digests are listed *inside* `integrity.json`. Therefore:

1.  Confirm artefact hashes still match `integrity.json` (re-hash yourself
    or use [Verify with T3Vault CLI](https://docs.typo3.org/permalink/codemacher/t3vault:verify-cli@main)).
1.  Confirm `integrity.json.ots` is a valid OpenTimestamps proof for that
    exact `integrity.json` file.

Always keep `integrity.json` and `integrity.json.ots` side by side
in the same directory (the `ots` client assumes the target file name by
stripping `.ots`).

## Check that files were not modified {#opentimestamps-manual-hash-check}

Independently of `ots`, confirm that backup artefacts match the seal:

```bash
cd /path/to/backup_YYYYMMDD_HHMMSS_<id>
sha256sum integrity.json
# Compare with digests listed under "files" in integrity.json, e.g.:
sha256sum database.zip MANIFEST.json *_part_*.zip
```

If any artefact hash differs from `integrity.json`, the archive was
modified after sealing — do **not** restore it, regardless of OTS status.

Prefer the bundled verifier for the same check:

```bash
php t3vault-verify.phar /path/to/backup_YYYYMMDD_HHMMSS_<id>
```

## Verify the OpenTimestamps proof {#opentimestamps-verify}

`ots verify` checks that `integrity.json` still matches the proof and
(when Bitcoin Core RPC is available) that the attestation is anchored in a
Bitcoin block:

```bash
cd /path/to/backup_YYYYMMDD_HHMMSS_<id>
ots verify integrity.json.ots
```

Expected success:

```text
Assuming target filename is 'integrity.json'
Success! Bitcoin block <height> attests existence as of <date>
```

Pass the target explicitly if needed:

```bash
ots verify -f integrity.json integrity.json.ots
```

Inspect the proof without a Bitcoin node:

```bash
ots info integrity.json.ots
```

Without installing `ots`, you can also use the browser verifier — see
[Verify in the browser (opentimestamps.org)](https://docs.typo3.org/permalink/codemacher/t3vault:opentimestamps-web@main).

## Verify in the browser (opentimestamps.org) {#opentimestamps-web}

The official site [opentimestamps.org](https://opentimestamps.org/) can
verify an `.ots` proof without Bitcoin Core or the `ots` CLI. Hashing runs
in your browser (the stamped file content is not uploaded for hashing beyond
what the page needs locally).

Steps:

1.  Open the backup directory and keep both files ready:
    `integrity.json` and `integrity.json.ots`.
1.  Open [https://opentimestamps.org/](https://opentimestamps.org/) and use **Stamp & Verify**.
1.  Drop (or select) `integrity.json.ots` as the **proof** (`.ots`).
1.  Drop (or select) `integrity.json` as the **stamped file** when the
    page asks for it.

A successful chain confirmation shows the OpenTimestamps UI label
**Bitcoin Attestation** (block / time). Pending calendars may still show
**Pending/Other Attestation** until the proof is confirmed on the Bitcoin
blockchain.

### What to watch out for {#what-to-watch-out-for}

-   **Only** `integrity.json` was stamped — never drop a ZIP,
    `MANIFEST.json`, or the whole `.t3vault.tar` as the stamped file.
    Those will not match the proof.
-   Use the **exact** `integrity.json` from the same backup as the
    `.ots` file. Any edit (whitespace, re-save) changes the digest and
    verification fails.
-   The website checks the **seal** (`integrity.json` ↔ `.ots`). It does
    **not** re-hash `*_part_*.zip` / `database.zip`. Always run
    [Verify with T3Vault CLI](https://docs.typo3.org/permalink/codemacher/t3vault:verify-cli@main) (or the manual hash check above) as well if you need to
    know the archive contents were not modified.
-   Right after backup creation the proof may still be **pending**. That is not
    the same as “tampered”; wait for calendar → Bitcoin confirmation and try
    again, or rely on the hash check in the meantime.
-   Do not use the site’s **stamp** action on backup files — T3Vault already
    created the proof. You only need **verify**.

## Bitcoin node for `ots verify` {#opentimestamps-bitcoin-node}

Full CLI `ots verify` needs Bitcoin Core RPC (local node or remote URL).
Without it you typically see:

```text
Could not connect to Bitcoin node: Cookie file unusable
([Errno 2] No such file or directory: '/home/…/.bitcoin/.cookie')
and rpcpassword not specified in the configuration file: '…/bitcoin.conf'
```

That error means the Bitcoin-blockchain time stamp was not checked — it does
**not** mean the backup files were modified. For the “unchanged files”
question, rely on the hash check / [Verify with T3Vault CLI](https://docs.typo3.org/permalink/codemacher/t3vault:verify-cli@main). For the seal without a
local node, use [Verify in the browser (opentimestamps.org)](https://docs.typo3.org/permalink/codemacher/t3vault:opentimestamps-web@main).

**Local Bitcoin Core** (default cookie auth under `~/.bitcoin/`):

```bash
# bitcoind must be running and synced far enough for the attested height
ots verify integrity.json.ots
```

**Explicit RPC URL** (local or remote):

```bash
ots --bitcoin-node http://USER:PASS@127.0.0.1:8332/ verify integrity.json.ots
```

## Recommended independent workflow {#opentimestamps-workflow}

1.  Open the backup directory (from `.t3vault.tar` if needed).
1.  Confirm artefact SHA-256 digests match `integrity.json`
    (`php t3vault-verify.phar .` or manual `sha256sum`).
1.  Optionally confirm the seal:
    [Verify in the browser (opentimestamps.org)](https://docs.typo3.org/permalink/codemacher/t3vault:opentimestamps-web@main), or `ots verify` with Bitcoin Core RPC.

This proves **content integrity** (hashes). The OTS step additionally proves
the seal existed at a point in Bitcoin-blockchain time, without trusting the
original TYPO3 server.

## Troubleshooting {#opentimestamps-troubleshooting}

| Symptom | Meaning / next step |
| --- | --- |
| Hash mismatch vs. `integrity.json` | Archive altered — do not restore |
| Web verifier: stamped file does not match | Wrong file dropped — use `integrity.json` from the same backup |
| Web verifier: pending / no chain time stamp yet | Proof not on-chain yet; hashes may still be OK |
| `Could not connect to Bitcoin node` / missing | Use |
| `.cookie` | [Verify in the browser (opentimestamps.org)](https://docs.typo3.org/permalink/codemacher/t3vault:opentimestamps-web@main) or configure RPC |
| `ots` not found under `sudo` | `pipx` installs for your user only — run without `sudo` |