OpenTimestamps is the anchor. Receipts.you wraps it for screenshots.
OpenTimestamps is the underlying cryptographic-timestamping protocol receipts.you uses as its external anchor. The OTS reference client (open-source CLI, Peter Todd's project) lets you timestamp any file against the public-blockchain timestamp tree directly — no wrapper, no third party. Receipts.you adds layers around OTS: ECDSA signing of the file hash by our key, perceptual hashing for recompression-resilient verification, QR-stamping for shareable composites, a receipt-page verifier UX, and a verdict ladder for the recompressed-vs-similar-vs-mismatch case that bare OTS doesn't address. If you're a power user who wants the raw cryptographic floor and is comfortable with command-line tools and Bitcoin-block-confirmation waits, the OTS CLI is the no-trust-required answer. If you want browser-side seal, instant signed timestamp (before the anchor cures), a shareable verifier page, and perceptual-hash verdicts — receipts.you is the wrapper that fits.
If you're a Bitcoin-comfortable security engineer sealing files for personal-archive use, the OTS CLI is the minimal-trust answer. If you want a browser-side seal with signing, perceptual hashing, QR-stamped composites, and a shareable verifier — use receipts.you (which uses OTS internally for the external anchor).
Pick receipts.you if…
- You want to seal a screenshot in your browser without installing tools.
- You want a shareable verifier URL non-technical recipients can use.
- You need perceptual-hash recompression resilience (bare OTS only proves byte-exact match).
- You need a QR-stamped composite for sharing the receipt visually.
- You want an immediate signed timestamp at seal-time (OTS-only takes an hour or so to confirm).
Pick OpenTimestamps CLI if…
- You're a security engineer who doesn't want any third-party signing surface in the chain.
- You're comfortable with command-line workflows and Bitcoin-block-confirmation timing.
- You're sealing files (not screenshots) and don't need recompression resilience.
- You want absolute minimum-trust evidence with no intermediary at all.
- You're integrating cryptographic timestamping into a custom pipeline where adding a JSON-wrapper adds no value.
Axis by axis
| Axis | receipts.you | OpenTimestamps CLI | Edge |
|---|---|---|---|
| Setup | Open URL, drop file. | Install Python/Rust OTS client; configure calendar servers. | receipts.you |
| External anchor | OpenTimestamps (uses OTS internally). | OpenTimestamps (you're using OTS directly). | both / tie |
| ECDSA signing | Yes — our key signs the hash + timestamp. | No — no provider signature; the OTS proof is sufficient on its own. | both / tie |
| Perceptual hash verdicts | Yes — pHash + dHash, AND-gated. | No — exact-SHA match only. | receipts.you |
| Shareable verifier page | Yes — receipts.you/r/<id>, works in any browser. | No — verification is CLI-only. | receipts.you |
| QR-stamped composite | Yes — automatic. | No. | receipts.you |
| Browser-side workflow | Yes — primary path. | No — CLI-native. | receipts.you |
| Time to provable anchor | ~30 min (OTS cron cycle). | Same — both anchor to the same OTS calendars. | both / tie |
| Trust surface | Trust our signing key + OpenTimestamps + the public chain. | Trust OpenTimestamps + the public chain. | the other tool |
| Cost | Free. | Free. | both / tie |
Specific questions about this comparison
If receipts.you uses OTS, why not just use OTS directly?
If you want the minimal-trust raw anchor and you're comfortable with CLI tooling, use OTS directly. The wrapper exists for everyone else — non-technical users, recipients who don't have OTS installed, situations where a shareable verifier URL matters, and the perceptual-hash recompression case (which bare OTS doesn't address).
Can I verify a receipts.you receipt with the OTS CLI?
Yes — partially. The OTS proof embedded in each receipt is a standard OTS attestation; the OTS CLI can verify it independently of our service. The ECDSA signature requires our public key (published at /.well-known/receipts-pubkey.pem); openssl verifies that separately. Two CLI commands together replicate our receipt-page verification.
Is there ever a case where I shouldn't trust the wrapper?
If you require zero-third-party-trust for a high-security personal archive, the OTS CLI alone is cleaner. The signature receipts.you adds isn't strictly necessary if OTS-only is sufficient for your threat model. For most use cases the wrapper's UX wins outweigh the minor added trust surface, but the architectural honesty matters.
Will receipts.you ever offer 'OTS-only' mode without our signature?
Not currently. The signature provides immediate verifiability (before OTS confirms ~30 min later) and signed timestamp evidence even if the OTS chain hypothetically failed. For users who want signature-free anchoring, the OTS CLI is the right tool.
Can I use OTS CLI to seal screenshots?
Yes — OTS hashes any file. But it won't give you perceptual-hash resilience to platform recompression, QR-stamped composites, or a shareable verifier URL. For pure file-archival timestamping where you'll always have the byte-identical file, OTS CLI works. For real-world screenshot evidence that travels through messaging platforms, the perceptual-hash layer earns its keep.
The wrapper makes OTS usable for screenshots.
If you want raw OTS, use the CLI. If you want browser-side screenshot sealing with signing, perceptual hashes, and a shareable verifier — receipts.you is the wrapper.