Peter Todd

Imagine needing to show that a particular version of a contract existed before a dispute began. OpenTimestamps, a project associated with Peter Todd, addresses precisely that question. His historical announcement in 2016 introduced a public alpha and thanked Riccardo Casatta for development and testing. It records collaboration at that time; it does not mean the project remained experimental. Todd also worked on conditions for future spending and on payments awaiting confirmation. Those two areas provide a useful starting point before returning to documents. [1]

Todd’s BIP 65 introduced OP_CHECKLOCKTIMEVERIFY, or CLTV. This instruction can make a particular spending path depend on reaching a block height or time. Think of a backup route to shared savings that a recipient may use only later. Until then, the time condition blocks that route. Satisfying it does not send coins automatically: someone must still create a valid transaction and meet the other requirements, such as providing a signature. If the arrangement has another spending path, that path has its own conditions; the lock does not necessarily cover every way of spending the funds. [2]

A time lock does not simply follow the clock displayed by a wallet. BIP 65 checks the relationship between the script—the spending instructions—and the transaction’s nLockTime field. Both must use the same kind of boundary: block height or time. The input’s nSequence field must also not use the final value that would defeat the check. This is an absolute boundary, not relative output age measured from confirmation. Meeting the conditions still does not promise inclusion at a precise second; a miner must include the transaction in a valid block. [2]

A broadcast transaction can wait in a mempool, a node’s collection of unconfirmed transactions. If fees rise, its sender may want to offer more through a replacement transaction. David A. Harding and Peter Todd described the original opt-in replacement policy in BIP 125. A transaction could signal replaceability through nSequence, or the status could be inherited from an unconfirmed ancestor: a preceding transaction whose output the payment spends. The policy therefore looked beyond a payment in isolation. Offering a higher fee can help, but does not guarantee immediate confirmation. [3]

Mempool replacement changes what a node holds as a candidate for confirmation. It does not rewrite confirmed history. BIP 125 also describes a historical opt-in policy, not an immutable rule for every program and release. Later Bitcoin Core releases made replacement without that signal standard behavior, while still imposing acceptance conditions. For recipients, the practical lesson is that the absence of a replacement signal does not prove payment finality. A wallet saying “sent” is likewise different from the transaction appearing in a confirmed block. [3] [6]

Return to the contract. OpenTimestamps produces verifiable evidence that particular data existed before an attested time boundary. It uses a hash, a short digital fingerprint of the contents, and a proof anchored in Bitcoin. Changing the document produces a different fingerprint when checked. The timestamp establishes neither authorship, truth of claims nor the exact creation instant. Someone could have timestamped a false account in time, too. The proof limits how late those data could have come into existence; it does not tell us how long they existed beforehand. [1] [4]

The OpenTimestamps client does not send the document itself to calendar servers. It processes its fingerprint with a random value so that the server cannot infer the contents from what it receives. A calendar here is a service that gathers requests and helps anchor them in Bitcoin. Content privacy is not complete anonymity: timing and proofs produced together can reveal links between requests. The resulting .ots file is not a document backup. Keep it alongside the exact original; a fingerprint cannot restore lost text, and an edited copy represents different data. [5]

A newly created timestamp may not yet be anchored in a confirmed Bitcoin block. Merely having a .ots file does not establish that it is already verifiable against Bitcoin. The OpenTimestamps client distinguishes a pending proof from one containing the complete path to a block. The command ots upgrade can fetch and save that completion when available; it cannot force a block to be mined. The proof then needs verification against the original data and the Bitcoin chain. As with a waiting payment, the actual status matters more than a file or notification appearing. [5]