To assert with certainty the accuracy, integrity, and timeliness of a document timestamped with OpenTimestamps, the process relies on two key concepts: the immutability of the mathematical path (the Merkle tree) and the irreversibility of the Bitcoin network. [1, 2, 3, 4]
During the hours between the ots stamp command and confirmation on the blockchain, several timestamps occur in succession. Here are the data points and the various dates to consider for your demonstration: [5, 6]
The only date that is legally and mathematically indisputable
- The Bitcoin block date (Final Certification)
This is the only date set in stone. It corresponds to the moment when the block containing the Bitcoin transaction was mined.- What it proves: It provides absolute proof of priority (the document must have existed before this date).
- How to read it: After running the command
ots upgrade, the commandots verifyqueries the blockchain (via your node or an explorer). It will display a message such as:Success! Bitcoin block 880123 attests existence as of [Date/Time]. [2, 3, 4, 6, 7, 8]
Intermediate dates (Useful for context, but based on trust)
While the transaction is “pending,” the initial .ots file contains what are called Pending Attestations. Two other dates appear at this stage: [9, 10]
- The local creation date (the
ots stampcommand)
This is the time you ran the command on your computer.- What it’s worth: It has no evidentiary value to a third party, since a local computer’s clock can easily be tampered with (backdated).
- The date from the calendar servers (OTS Calendars)
When you runots stamp, the hash of your document is immediately sent to public calendar servers (managed by OpenTimestamps). These servers timestamp the receipt and commit to including it in their next Merkle tree.- What it’s worth: This is “semi-trusted” evidence. It indicates, down to the minute, when the server received your hash. However, for absolute proof in a court of law or before a meticulous auditor, one does not rely on the word of these servers, but solely on the blockchain. [1, 2, 3, 5, 11, 12]
Technical Data Essential for Proof
To assert complete integrity during this time period, the date alone is not sufficient. The OpenTimestamps architecture transmits the following data in the .ots file:
The SHA-256 hash of your file: Calculated locally, it guarantees that the document has not been altered in the slightest. If the file changes, its hash changes, and the proof becomes invalid. [3, 5, 8, 12]
The operation path (the submission receipt): The .ots file contains the sequence of mathematical operations (the adjacent hashes of the Merkle tree) that link the hash of your unique document to the root, which will ultimately be published on the blockchain. [3, 13]
Summary: The Lifecycle of Key Dates
- T = 0 (
ots stamp): You create the hash. The OTS calendar promises to integrate it (Calendar date = approximate). - T + a few hours: The Bitcoin miner validates the block.
- After confirmation (
ots upgradethenots verify): The Bitcoin block date becomes your official and immutable reference point. It retroactively validates the entire process starting from T=0. [1, 3, 6, 7, 8, 9]
[4] https://opentimestamps.org
[9] https://blog.eternitywall.com
[10] https://blog.eternitywall.com
[11] https://www.dgi.io
[12] https://forum.dfinity.org
To inspect the internal structure of your proof file before it is permanently validated on the blockchain, you must use the ots info command.
Here’s how to run it and interpret its text output:
- 🛠️ The command to run
Open your terminal or command prompt in the folder where your file is located and type:
ots info filename.txt.ots
- 🔍 Decoding the text output (Intermediate steps)
The output generated by this command is read from top to bottom, like an inverted family tree. Here are the key elements to look for to follow the mathematical path:
File sha256: 4a2d8b… (The unique hash of your original document)
append 1d8f…
sha256
prepend 9c3b…
sha256
…
- The mathematical operations (append, prepend, sha256): Each line shows how your document’s fingerprint is combined (concatenated to the left or right) with other fingerprints on the calendar servers to form a new hash. This is the construction of the Merkle tree.
- The calendar root (The waiting point): At the end of this sequence of operations, you’ll see a section that looks like this:
- Pending attestation: https://opentimestamps.org
What this means: This line proves that the final hash (the root) was successfully received and processed by the specified calendar server. This is the intermediate step that attests to the existence of your file while awaiting the Bitcoin snapshot.
- ⏳ What Changes After Validation (The Bitcoin Block)
Once the Bitcoin transaction is confirmed and you’ve updated your file with the `ots upgrade` command, run `ots info` again. You’ll notice that the line Pending attestation has disappeared and been replaced by:
Bitcoin attestation: block 880123
At this point, the computation tree no longer relies on a server’s promise but is directly anchored to the specified Bitcoin block header.
If you’d like, you can copy and paste the text output returned by your `ots info` command here. That way, I can help you precisely identify the calendar address used and verify whether the file already contains any block attestations.
Since the image provided is completely white, please use plain text instead!
To inspect the internal structure of your proof file before its final validation on the blockchain, you must use the command ots info.
Here’s how to run it and interpret its text output:
🛠️ The command to run
Open your terminal or command prompt in the folder where your file is located and type:
ots info filename.txt.ots🔍 Decoding the text output (Intermediate steps)
The output generated by this command is read from top to bottom, like an inverted family tree. Here are the key elements to look for to follow the mathematical path:
File sha256: 4a2d8b... (The unique hash of your original document)append 1d8f...sha256prepend 9c3b...sha256...- The mathematical operations (
append,prepend,sha256): Each line shows how your document’s fingerprint is combined (concatenated to the left or right) with other fingerprints on the calendar servers to form a new hash. This is the construction of the Merkle tree. - The calendar root (The pending point): At the end of this sequence of operations, you’ll see a section that looks like this:
· Pending attestation: https://opentimestamps.orgWhat this means: This line proves that the final hash (the root) was successfully received and processed by the specified calendar server. This is the intermediate step that attests to the existence of your file while awaiting the Bitcoin snapshot.
What Changes After Validation (The Bitcoin Block)
Once the Bitcoin transaction is confirmed and you’ve updated your file with the command ots upgrade, run ots infoagain. You’ll notice that the line Pending attestation has disappeared and been replaced by:
Bitcoin attestation: block 880123At this point, the proof-of-work tree no longer relies on a server’s promise but is directly anchored in the Bitcoin block header specified.
If you’d like, you can copy and paste the text output returned by your ots infocommand here. This will allow me to help you precisely identify the calendar address used and verify whether the file already contains block attestations. Since the provided image is completely blank, please use plain text instead!
To inspect the internal structure of your proof file before its final validation on the blockchain, you must use the ots info command.
Here’s how to run it and interpret its text output:
🛠️ The command to run
Open your terminal or command prompt in the folder where your file is located and type:
ots info your_file_name.txt.ots🔍 Decoding the text output (Intermediate steps)
The output generated by this command is read from top to bottom, like an inverted family tree. Here are the key elements to look for to follow the mathematical path:
File sha256: 4a2d8b... (The unique hash of your original document)append 1d8f...sha256prepend 9c3b...sha256...- The mathematical operations (
append,prepend,sha256): Each line shows how your document’s fingerprint is combined (concatenated to the left or right) with other fingerprints on the calendar servers to form a new hash. This is the construction of the Merkle tree. - The calendar root (The pending point): At the end of this sequence of operations, you’ll see a section that looks like this:
· Pending attestation: https://opentimestamps.orgWhat this means: This line proves that the final hash (the root) was successfully received and processed by the specified calendar server. This is the intermediate step that attests to the existence of your file while awaiting the Bitcoin snapshot.
⏳ What Changes After Validation (The Bitcoin Block)
Once the Bitcoin transaction is confirmed and you’ve updated your file with the command ots upgrade, run ots infoagain. You’ll notice that the line Pending attestation has disappeared and been replaced by:
Bitcoin attestation: block 880123At this point, the proof-of-work tree no longer relies on a server’s promise but is directly anchored in the Bitcoin block header specified.
If you’d like, you can copy and paste the text output returned by your ots infocommand here. This will allow me to help you precisely identify the calendar address used and verify whether the file already contains any block attestations. Since the provided image is completely blank, please use plain text instead!
The key date to remember: The Bitcoin block
In your log, the crucial line to look for is this one:
verify BitcoinBlockHeaderAttestation(968251)
- The key data: The Bitcoin block number is
968251. - The date to note: This is the exact date and time this specific block was mined. To find it, simply enter the number
968251into any Bitcoin blockchain explorer (such as mempool.space or blockchain.info). - Legal/technical significance: This date serves as the benchmark for your proof of prior existence. You can scientifically assert that your document existed before this block was finalized.
Integrity data: The original fingerprint
File sha256 hash: ca9232779208fa5a222cfb1d85f8cc9eba6ae84e332ce00782d6e26b30fd1193
- The value: This is the digital signature (SHA-256) of your original file.
- The demonstration: To prove integrity, you must locally recalculate the SHA-256 hash of the document you are presenting today. If it yields exactly this sequence of characters beginning with
ca9232..., you have demonstrated that it has not been altered by a single pixel or a single comma since it was anchored.
The Intermediate Mathematical Chain (The “Recipe”)
The log shows how we mathematically move from your file to the Bitcoin block. The key elements that tie everything together are:
- The intermediate Bitcoin transaction:
# Transaction ID 909151f7b2da55ce4b560c0f0b5808042dce6f0cefadd1c8e18c84f245eb40e6
The “Alice” calendar server combined your hash with thousands of others and injected the result into this specific transaction. - The Merkle root of the block:
# Bitcoin block Merkle root cc830771a50786a9982b0d8f6b042b29bcc40653f6eaf8e3e2fa98579977caa2
This root is the mathematical summary of all transactions in block968251. It indirectly includes (via the sequence of operationsappend,prepend,sha256visible in your text) the signature of your document.
📌 Summary for your demonstration
To summarize your proof to an auditor, you must highlight and present these three elements in the following order:
- Integrity: My current document generates the hash
ca9232..., which is identical to the original hash in the.otsfile. - Link: The
.otsfile demonstrates, through successive SHA-256 calculations, that this hash is linked to Bitcoin transaction909151.... - Priority: This transaction was sealed in Bitcoin block 968251. The date of this block (calculated by the decentralized network) provides the document’s guaranteed minimum age, making any tampering or backdating impossible.
Bitcoin block 968251 was mined on Wednesday, September 23, 2026, at approximately 1:52 p.m. (Paris time). The block was validated by the ViaBTC mining pool. [1, 2, 3]
📝 How to include this in your report:
For your proof of prior existence, you can now complete your data as follows:
- Original file:
ca9232779208fa5a222cfb1d85f8cc9eba6ae84e332ce00782d6e26b30fd1193 - Blockchain Anchor: Bitcoin transaction
909151f7b2da55ce4b560c0f0b5808042dce6f0cefadd1c8e18c84f245eb40e6 - Certification Date: September 23, 2026, 1:52 PM CEST [1, 2, 3]
Certified Proof of Prior Art: Block No.
968251
All of this information is publicly verifiable by any third party by entering the block number or transaction ID into an independent blockchain explorer such as mempool.space or Blockchain.com. Your document is now mathematically protected against any temporal disputes.
