Defensive Publication: Binding a Computation Execution Receipt Hash to an Independent External Timestamp Anchor for Tamper-Evident Third-Party Verification

Abstract

A method for converting a self-contained, content-hashed computation execution receipt into independently verifiable, tamper-evident evidence by binding the receipt's execution_hash to one or more external, third-party-operated timestamp anchors (e.g. RFC 3161 Time-Stamp Authorities, the OpenTimestamps Bitcoin-anchoring protocol, or RFC 9162 Certificate Transparency logs), such that any holder of the receipt can prove - without trusting the party who generated the receipt - that the receipt's content existed no later than a specific, externally attested point in time, and has not been altered since.

Field and problem

A computation execution receipt (a structured record of a deterministic computation's inputs, outputs, and a content hash covering them) is only as trustworthy as the party who produced it, unless its existence-at-a-point-in-time can be independently corroborated. Without an external anchor, a receipt's timestamp field is a bare, self-reported assertion: the producer could, in principle, generate or alter a receipt after the fact and simply write an earlier-looking timestamp into it. Systems that log computation results (audit logs, application logs, blockchain-native attestations tied to a single chain) either omit third-party time attestation altogether, or couple the evidence to a single specific external system (e.g. only a private ledger), rather than treating anchoring as a generic, swappable binding step applicable to any content-hashed receipt regardless of anchor provider.

Detailed description of the novel mechanism

1. Receipt production. A deterministic computation produces an execution receipt containing, among other fields, a canonicalized content hash (execution_hash) covering the receipt's inputs, outputs, and metadata.
2. Anchor submission. The execution_hash (or a Merkle root covering a batch of receipts including it) is submitted to one or more independent external timestamp services, selected from a class that includes: (a) an RFC 3161-compliant Time-Stamp Authority, which returns a signed token asserting the hash existed at a specific time; (b) the OpenTimestamps protocol, which aggregates the hash into a Merkle tree ultimately anchored in a Bitcoin block, providing a decentralized, fee-minimal time proof; and/or (c) submission as a leaf to a Certificate Transparency log conformant with RFC 9162, which publishes an append-only, publicly auditable, gossiped log of included hashes.
3. Anchor-proof attachment. The response from the anchor service (the TSA token, the OpenTimestamps proof file, or the CT log's signed inclusion proof / consistency proof) is attached to or referenced from the receipt as a distinct anchor_proof structure, which itself is self-verifying against the anchor service's independently known public key or the target chain's public state - the receipt producer does not need to be trusted to validate it.
4. Independent verification. A third party holding only the receipt and its anchor_proof can: (a) recompute the execution_hash from the receipt's own content and confirm it matches; (b) verify the anchor_proof against the anchor service's public verification material (TSA public key, Bitcoin block header, or CT log's signed tree head) without contacting the original receipt producer; and (c) conclude, from (a) and (b) jointly, that the exact receipt content existed no later than the anchor's attested time and has not been modified since, because any modification would change the execution_hash and invalidate the anchor-proof match.
5. Multi-anchor redundancy. The same execution_hash may be submitted to more than one anchor class concurrently (e.g. both an RFC 3161 TSA and OpenTimestamps), so that the tamper-evidence claim survives the compromise, cessation, or non-recognition of any single anchor provider - verification succeeds if any one attached anchor_proof validates.
6. Anchor-agnostic binding layer. The binding mechanism (hash-in, anchor-proof-out, attach-to-receipt) is decoupled from which specific anchor service is used, so new anchor classes can be added without changing the receipt schema - only the anchor_proof structure's own internal type field changes, keeping the receipt format stable across anchor-provider generations (including anchors not yet in common use at time of publication).

Variations

• The anchored unit may be a single receipt's hash, or a Merkle root over a batch of receipts, with individual receipts carrying only their Merkle inclusion path rather than a full separate anchor submission each, reducing anchor-service load and cost.
• Anchor upgrade: an already-anchored receipt may later be re-anchored under a longer-term or higher-assurance anchor class (e.g. upgrading an RFC 3161 token to a long-term-validation form, or adding an OpenTimestamps Bitcoin confirmation once available) without invalidating the original proof, by treating anchor_proof as an append-only list rather than a single value.
• The verification step may be performed fully offline given only the receipt, its anchor_proof, and publicly published anchor-service verification material (no live network call to the receipt producer required).

Prior-art context

RFC 3161 timestamping, the OpenTimestamps protocol, and RFC 9162 Certificate Transparency are each independently well known as general-purpose time-attestation or append-only-log mechanisms. Blockchain-anchored audit-log products exist that couple evidence to a single specific chain or anchor provider. This disclosure is specific to treating anchor-binding as a generic, provider-agnostic layer applied uniformly to a content-hashed deterministic-computation execution receipt, with multi-anchor redundancy and anchor-upgrade-without-invalidation as part of the same binding mechanism.