Is OpenTimestamps incompatible with or threatened by the Bitcoin Knots fork of Bitcoin Core and/or the OCEAN mining pool?

I’m told this question has come up a few times from investors and potential users of OpenTimestamps, so I thought it would be worth answering in a blog post. This post isn’t going to get into the politics of Bitcoin Knot’s transaction relaying policy, or OCEAN’s transaction mining policies. We’re going to stick to the facts of how OpenTimestamps uses the Bitcoin blockchain, what policies Knots and OCEAN currently have, and finally, hypothetical changes to those policies.

tl;dr: there is no incompatibility between OpenTimestamps and Knots/OCEAN. Nor is there any way that Bitcoin node operators or miners could prevent OpenTimestamps from functioning, short of extreme levels of censorship. Users of OpenTimestamps have nothing to worry about.

How OpenTimestamps Currently Uses The Bitcoin Blockchain

OpenTimestamps is an efficient, scalable, timestamping protocol. I’ve explained how OpenTimestamps works in detail before on this blog. But in short, it uses merkle trees and commitment operations to timestamp an unlimited amount of data with a single Bitcoin transaction. To succeed in this goal, an OpenTimestamps calendar needs to create a Bitcoin transaction that either contains or cryptographically commits to a single 32-byte hash digest.

The OpenTimestamps Calendar Servers currently embed these digests directly in an OP_Return output:

Since an infinite number of timestamp requests can be aggregated into a single transaction, the absolute maximum number of transactions a single calendar would ever produce is one per block, 144txs/day. In practice they produce significantly less than that due to funding limitations, and the fact that it’s dubious to trust the time fields in block headers to ~10 minute resolution anyway.

Since a single Bitcoin block could potentially contain over six thousand timestamp transactions¹, and there are just four public calendars, OpenTimestamps uses an extremely small percentage of the total Bitcoin blockchain capacity.

The (Mistaken) Controversy

By default, Bitcoin Knots nodes do not relay transactions containing OP_Return outputs with more than 40 bytes of data. Since OCEAN uses Bitcoin Knots, most blocks created by OCEAN² are similarly limited.

40 bytes of OP_Return data is more than enough for OpenTimestamps!

At the moment, there simply is no issue: both Knots and OCEAN will relay and mine the transactions produced by the OpenTimestamps calendars with no issue.

Most of this controversy is simply mistaken, caused by a misunderstanding of what Knots/OCEAN actually does. But, it is hypothetically possible that a future version of Knots will further tighten relay policy in such a way as to not relay these transactions. What then?

Hypothetical: Knots No Longer Relays OP_Return Transactions

Suppose that a future version of Bitcoin Knots makes the choice to no longer relay transactions containing OP_Return outputs at all. We’ll also assume that OCEAN no longer mines those transactions. And, for sake of argument, we’ll assume that nearly 100% of nodes choose to run Knots.

Does this affect OpenTimestamps? No.

At the moment, no released version of Bitcoin Core or any known fork of Bitcoin Core (Knots and Libre Relay) propagates transactions paying a fee-rate less than 1 sat/vB. Yet, at the moment, both of my Alice and Bob calendars are producing transactions with sub-1-sat/vB fee-rates. Even though something like 99% of Bitcoin nodes reject these transactions, they get to miners just fine.

As Satoshi said in the initial announcement, “[Bitcoin] takes advantage of the nature of information being easy to spread but hard to stifle”.

Since it only takes a single path to get a transaction — information — to a miner willing to mine it, for an actively maintained operation like the OpenTimestamps calendars, it is exceptionally difficult to prevent transactions from getting to miners by simply running nodes that reject those transactions.

Hypothetical: A Group Actively Attacks Nodes That Relay OP_Return Transactions

Suppose that a group was trying to attack nodes that relayed OP_Return transactions, e.g. by detecting them somehow³ and launching DoS attacks against them to flood their internet connections with enough data that the nodes are forced offline. Again, against an actively maintained project like the OpenTimestamps calendars this attack will fail because we can easily mitigate the attack by doing things like submitting timestamp transactions to miners directly, as well as running undetectable, non-public nodes.

Hypothetical: Miners Stop Mining OP_Return Transactions

What if you just can’t get an OP_Return containing transaction mined?

The OpenTimestamps proof format is designed to be flexible. It doesn’t make any assumptions about how exactly a timestamp proof is created; there is no concept of transactions in OpenTimestamps proofs. Rather, a proof is a series of mathematical operations that lead to a Bitcoin block header.

That means that the OpenTimestamps calendars can easily switch to other ways of embedding data in Bitcoin transactions. For example, in the past, prior to the creation of the OP_Return mechanism, very early versions of the OpenTimestamps calendar software used bare multisig outputs. Even though the transaction format is totally different, those ancient timestamps can be verified by modern versions of the OpenTimestamps software with no issues⁴.

In this hypothetical circumstance, one of many ways that the OpenTimestamps calendars could create timestamp transactions would be to use the Pay-2-Witness-Script-Hash (P2WSH) address format. Specifically, each timestamp transaction would create a new P2WSH output whose address committed to a multisig script of the form:

1 <real pubkey> <fake pubkey> 2 CheckMultiSig

The “fake” pubkey is just a 32-byte digest computed by hashing a byte and the actual 32-byte digest that needs to be timestamped, plus the even/odd byte. Being a 1-of-2 multisig, we can still spend the funds later with the real pubkey. An arbitrary 32-byte string has an approximately 50% chance of being a valid secp256k1 pubkey. So with a single extra byte we can just keep trying until we find a valid one. The probability of failing is on the order of \(\frac{1}{2^{256}}\) — much less likely than finding a SHA256 hash collision by accident.

Miners can’t block transactions committing to data in this form without making it impossible for many Bitcoin users to spend their funds without prior permission.

Hypothetical: Whitelisting

Suppose that all Bitcoin miners go a step further and refuse to mine transactions without prior approval, AKA whitelisting. Can OpenTimestamps survive?

Of course, this scenario is getting quite ridiculous: Bitcoin as we know it would simply not exist anymore, as we are discussing a permissioned system that ultimately is no different than conventional banking, or most Central Bank Digital Currency (CBDC) proposals.

But yes, even in this scenario OpenTimestamps has a chance: via fancy Elliptic Curve Cryptography tricks, any pubkey or signature can secretly commit to a digest. That means that any transaction could in fact be a timestamp transaction! Anyone approved to create Bitcoin transactions could volunteer to timestamp data for the public calendars, and miners could have absolutely no way of detecting this in advance.

While the OpenTimestamps protocol does not currently support this type of commitment operation, a pull-req by Andrew Poelstra implementing this has been available since 2017 and could easily be added to the protocol if necessary. The actual reason this might be merged would be to save on fees; actually needing this level of censorship resistance is I hope very unlikely.

Hypothetical: Whitelisting and Blacklisting

What if in addition to all Bitcoin usage being limited to approved, whitelisted, entities miners also revoke (blacklist) the licenses and coins of anyone who is detected making timestamps. Since the public calendar infrastructure is, well, public, it would be hypothetically possible for the organization in charge of approving the use of the Bitcoin blockchain to actively detect and punish all timestamping activity.

While I’m sure there is a cryptographic solution to even this scenario — maybe involving zero-knowledge-proofs⁵ or something — at this point I gotta ask, what kind of absurd world are you living in? Why have you allowed authorities to be so draconian as to prevent timestamping, a technology that merely proves things are true?

Summary

As long as people continue to maintain OpenTimestamps and the OpenTimestamps public calendar infrastructure, OpenTimestamps is unstoppable.

Footnotes