# Independent producer-side implementation of draft-fassbender-scitt-time-anchor-03

This deliverable contains an independent implementation of the
producer side of the profile defined in
[draft-fassbender-scitt-time-anchor-03](https://www.ietf.org/archive/id/draft-fassbender-scitt-time-anchor-03.txt)
(Datatracker, 24 July 2026), together with one anchored artifact and
its verified Anchor Proof.

## Interoperability result

Two independently written producer implementations record the
identical operation sequence. Fed the artifact hashes and blinding
nonces of Appendix E.1, the aggregation implemented here
(`anchor.py`, from Appendix D.3 alone) records, for vector 1, an
operation sequence identical byte-for-byte to the first six
operations of the E.5 proof produced by the author's deployment —
two implementations, written without contact, arriving at the same
recorded construction (see `CONSTRUCTION.md`, Section 3).

Cross-verification closes the loop in both directions:

- **This implementation → the author's proofs:** the verifier built
  here returns `valid` for the Appendix E proofs against the live
  Bitcoin chain, meeting all conditions of profile Section 3.1,
  including the header-source and confirmation-depth conditions that
  Appendix C records as not yet evaluated by any deployment described
  in the profile. Closing that gap is what this exercise was for
  (`CONSTRUCTION.md`, Section 4).
- **The author's tooling → this implementation's proof:** the
  OpenTimestamps reference client verifies the proof produced here
  (`ots verify -f artifact.txt artifact.txt.ots` → `Success! Bitcoin
  block 960175`), reaching the same block-height binding as the
  verifier built for this exercise. Neither implementation contacted
  the other's producer.

Together these are evidence of interoperability between independent
implementations, which is what Appendix C invites and does not yet
have.

## What this is

- `artifact.txt` — the anchored artifact (raw bytes; no trailing newline).
- `artifact.txt.ots` — the Anchor Proof binding SHA-256(artifact.txt)
  = `aad94933346aadcaed1b6b5e3e926d9fa0b815fa448cfe3d6168bc0ea81d630a`
  to the Bitcoin block at height 960175 (the block-height binding,
  profile Section 2.6.1). 2588 bytes; SHA-256 of the proof file
  `d37e6075fcb3ac74bb05bbe598a837f7a4567b918bd0225ae86a0cf8c33553e3`.
- `CONSTRUCTION.md` — every step of the construction, reproducible.
- `DEFECTS.md` — specification-ambiguity findings, with citations.
- `SHA256SUMS` — manifest of every file in this deliverable.
- `anchoring-session-clean.log` — the terminal session of the
  anchoring run, filtered of ANSI control sequences.
- `*.py` — the implementation. Written from scratch for this exercise.
  Module docstrings are in English; inline comments are in Portuguese,
  the implementer's working language. Each module carries an SPDX MIT
  identifier.
- `LICENSE` — MIT.

## Independence claim

This implementation was produced exclusively from:

1. the published Internet-Draft (-03) as retrieved from the IETF
   archive, and
2. the OpenTimestamps release pinned by the profile in Section 5.2.1
   (python-opentimestamps v0.4.5; sdist SHA-256
   `56726ccde97fb67f336a7f237ce36808e5593c3089d68d900b1c83d0ebf9dcfa`,
   verified before use), which the profile itself designates as the
   source for the proof serialisation format and the Calendar Server
   protocol (Section 5.2.1; Appendix D, preamble).

No guidance was requested from or provided by the document's author
during implementation. The public SCITT mailing-list announcement of
-03 was available as a documented fallback and was **not** needed.
Ambiguities that could not be resolved from the document alone were
recorded as defects (see `DEFECTS.md`) rather than resolved by asking.

## What the proof establishes — and what it does not

A `valid` result establishes the block-height binding: these exact
artifact bytes were committed to the Bitcoin blockchain in the block
at height 960175, and therefore existed before that block was mined
(Section 2.6.1). It does **not** establish authorship, creation
time, or that the artifact did not exist earlier (Section 2.6.4). The
wall-clock value shown by verifiers is the Reference Wall-Clock
Projection and is informative only (Sections 1.3, 2.6.6).

## How to re-verify

Route 1 — conformant verifier, own node (returns `valid`):

    python3 verify_run.py artifact.txt artifact.txt.ots

Requires a Bitcoin full node you operate (RPC credentials in
`~/.bitcoin/bitcoin.conf`). Per the note on header sources in
Section 3.1, a verifier that cannot place the attested block on the
validated most-work chain returns `unverifiable`, not `valid`; a
public block explorer is therefore not sufficient for `valid`.

Route 2 — OpenTimestamps reference client:

    ots verify -f artifact.txt artifact.txt.ots

Verified successfully during construction, returning block 960175.
Whether this route also completes the ledger check depends on how the
client obtains headers (cf. Appendix E.7, route 4, of the profile).

Route 3 — no software beyond SHA-256: recover the operation sequence
from `artifact.txt.ots` (format per the pinned [OTS] release), replay
append/prepend/SHA-256 from the artifact hash, and compare the result
against the Merkle root of the header at height 960175 from a node you
trust.

## Produced by

Tiago Pinto, Portugal, 2026-07-30. The independence claim above is
also recorded inside the anchored artifact itself, and is therefore
dated by the Bitcoin block it is committed to.