Does taproot make OP_RETURN obsolete? How much information can I stuff into an output? A tapscript leaf? Is there a max depth to the tapscript tree?

2 Answers 2


I think your question is confusing two things:

  • Commitments to data: using the blockchain as proof that some data existed before some point in time
  • Publishing data: making everyone actually see the data.

There are fundamentally different goals, and what you need depends on the purpose:

  • In case you want to timestamp something, a commitment is sufficient. A commitment can be achieved using a transaction with an OP_RETURN that contains a hash of the data, but there are many other, and more private, approaches. For example, it is possible to create a completely ordinary ECDSA signature on-chain, for a normal transaction that actually moves money, to an address that wasn't in any way specially designed for this purpose, which in fact "mixes in" some additional data. The signature cannot be distinguished from a normal signature, but together with an external proof, is evidence that this signature could not have been made without using said data. This approach is called sign-to-contract.
  • Commitments are not sufficient if you want to use a transaction to convey information to the recipient, like a message. This is a bad idea for several reasons, but ignoring that: if you'd use a commitment like sign-to-contract here, the recipient wouldn't know a message existed. You'd need to give them the message and the proof the transaction commits to it out of band, and if you need to communicate with them out of band, you could just give them the message directly there.
  • Commitments also do not prevent you for example from committing to two "conflicting" pieces of information. For example keybase.io periodically publishes a hash of their entire database on the Bitcoin blockchain. Even though it is only a hash, a commitment would not suffice, as the entire point is making allowing users to verify that keybase.io is providing the same database for everyone. With just a commitment, they could maintain two distinct trees, and reveal one to some users, and the other to other users.

Mechanisms for publishing include OP_RETURN outputs in transactions, or stuffing things in the keys raw multisig outputs, or stuffing data in witnesses (by using a script with an OP_DROP for example). Mechanisms for commitments include storing a hash using a publishing mechanism, but also the aforementioned sign-to-contract (which commits to data in signatures) or pay-to-contract (which commits to data in public keys).

Now back to your question: taproot does not help in either case. Yes, the taproot script Merkle tree means you can commit to lots of pieces of data, but you can already do that: just compute a Merkle root yourself of these pieces of data, and then commit/store that root. It also doesn't help with publishing, because the leaves are not published on output (only the tweaked public key is). You could reveal data when spending a P2TR output (by having the data in a leaf, and then spending through that leaf), but that doesn't let you do anything that isn't already possible with P2WSH.

Lastly, the script tree in taproot is limited to max 128 levels, but this doesn't affect the rest of what you're asking about.


I don't see how P2TR would benefit OP_RETURN applications at all. The scripts in the leaf are only published on spending which doesn't happen for NULLDATA outputs at all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.