Independent implementation

draft-fassbender-scitt-time-anchor-03 — Bitcoin-Anchored Temporal Proof for Transparency Services

What this is

An independent implementation of the producer side of the profile defined in draft-fassbender-scitt-time-anchor-03 (individual Internet-Draft, 24 July 2026), together with one anchored artifact, its verified Anchor Proof, the reproducible construction steps, and one specification defect report.

It was written at the invitation of the document's author, under one condition proposed by this implementer and accepted by her: the implementation would be built from the published document alone, with no guidance from the author. Where the document could not be resolved without asking, the ambiguity was recorded as a defect rather than resolved by asking.

Interoperability result

Two independently written producer implementations record the identical operation sequence. Fed the artifact hashes and blinding nonces of the profile's Appendix E.1, the aggregation implemented here records, for vector 1, an operation sequence identical to the first six operations of the Appendix E.5 proof produced by the author's own deployment.

The cross-checks close in both directions. The verifier built here returns valid for the profile's Appendix E proofs against the live Bitcoin chain, meeting the header-source and confirmation-depth conditions of Section 3.1. The OpenTimestamps reference client, in turn, verifies the proof produced here. Neither implementation contacted the other's producer.

Appendix C of the profile records that the deployments described in it do not yet evaluate the promotion gates: no anchoring worker compares the replayed digest against the block header, nor establishes confirmation depth, before marking a proof as anchored. This implementation does both, against a Bitcoin full node operated by the implementer. Closing that gap is what the exercise was for.

The anchored artifact

SHA-256 of the anchored artifact artifact.txt aad94933346aadcaed1b6b5e3e926d9fa0b815fa448cfe3d6168bc0ea81d630a
Block-height binding:
block 960175 (normative, profile Section 2.6.1).
Reference Wall-Clock Projection:
2026-07-30T00:16:15Z (informative only, Sections 1.3 and 2.6.6).
Promotion:
2026-07-30, after this implementation compared the replayed digest against the header Merkle root at the attested height and established at least six confirmations.
Anchoring protocol:
OpenTimestamps (opentimestamps.org), release pinned by the profile in Section 5.2.1.
Anchoring network:
Bitcoin mainnet.
Proof file:
2588 bytes; SHA-256 d37e6075fcb3ac74bb05bbe598a837f7a4567b918bd0225ae86a0cf8c33553e3.

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. It does not establish authorship, creation time, or that the artifact did not exist earlier (Section 2.6.4).

Files

Every file below is listed in SHA256SUMS. Download the whole set into one directory and run sha256sum -c SHA256SUMS to confirm integrity; the manifest lists plain file names, with no paths.

Two distinct anchors are published here, and they answer different questions. artifact.txt.ots was produced by this implementation and is what the exercise set out to demonstrate. SHA256SUMS.ots was produced by the OpenTimestamps reference client and establishes only that this package existed in this exact form on 30 July 2026.

The implementation itself, nine Python modules with no dependencies beyond the standard library:

How to re-verify

Route 1 — conformant verifier with your own node

Returns valid. Requires a Bitcoin full node you operate, with RPC credentials in ~/.bitcoin/bitcoin.conf.

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

Per the note on header sources in Section 3.1 of the profile, 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.

Route 3 — nothing beyond SHA-256

Recover the operation sequence from artifact.txt.ots (format per the pinned OpenTimestamps release), replay append, prepend and SHA-256 from the artifact hash, and compare the result against the Merkle root of the header at height 960175, in internal byte order, from a node you trust.

Defect report

One entry, minor. The NULL return condition of OTS-UPGRADE admits two readings that diverge for a proof that already carries a Bitcoin attestation but was left pending by the confirmation-depth gate. Under the reading implied by the comment at Appendix D.2 step 2b, such a proof is eventually marked failed, which contradicts the definition of failed in Section 2.4.1. Under the strict reading of Section 1.4, the step 2c branch becomes unreachable. The full statement, with citations and the resolution adopted here, is in DEFECTS.md.

Appendices D.1 to D.3 are declared informative by the profile, so no proof's validity turns on this.

Independence

The implementation was produced exclusively from the published Internet-Draft and the OpenTimestamps release the profile pins in Section 5.2.1 (release identified there by SHA-256, verified before use). No guidance was requested from or provided by the document's author during implementation. The public mailing-list announcement of the revision was available as a documented fallback and was not needed.

The independence statement is also recorded inside the anchored artifact itself, and is therefore dated by the Bitcoin block it is committed to.

Source

Produced by Tiago Pinto, Portugal, July 2026. Code is MIT-licensed. This page is served from the author's own server, in static HTML, without JavaScript, without analytics, without cookies, without external dependencies.