<p>I think your question is confusing two things:</p>
<ul>
<li><em>Commitments</em> to data: using the blockchain as proof that some data existed before some point in time</li>
<li><em>Publishing</em> data: making everyone actually see the data.</li>
</ul>
<p>There are fundamentally different goals, and what you need depends on the purpose:</p>
<ul>
<li>In case you want to timestamp something, a commitment is sufficient. A commitment can be achieved using a transaction with an <code>OP_RETURN</code> 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 &quot;mixes in&quot; 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 <a href="https://blog.eternitywall.com/2018/04/13/sign-to-contract/" rel="nofollow noreferrer">sign-to-contract</a>.</li>
<li>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.</li>
<li>Commitments also do not prevent you for example from committing to two &quot;conflicting&quot; 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.</li>
</ul>
<p>Mechanisms for publishing include <code>OP_RETURN</code> outputs in transactions, or stuffing things in the keys raw multisig outputs, or stuffing data in witnesses (by using a script with an <code>OP_DROP</code> 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).</p>
<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2021-10-27T16:50:07.370Z
2021-10-27T16:50:07.370Z
Pieter Wuille
<p>I don't see how P2TR would benefit <code>OP_RETURN</code> applications at all. The scripts in the leaf are only published on spending which doesn't happen for <code>NULLDATA</code> outputs at all.</p>

CC BY-SA 4.0
2021-10-27T16:03:36.213Z
2021-10-27T16:03:36.213Z
Murch
<p>Does taproot make <code>OP_RETURN</code> obsolete? How much information can I stuff into an output? A tapscript leaf? Is there a max depth to the tapscript tree?</p>

<taproot><op-return>
How much information can a single taproot output hold?
arshbot
# How much information can a single taproot output hold?

(Asked by: username_0 on 2021-10-27)

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?

**Tags:** taproot, op-return


---

## 2 answers

### Answer by username_1 on 2021-10-27. Score: 1

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](https://blog.eternitywall.com/2018/04/13/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.


---

### Answer by username_2 on 2021-10-27. Score: 0

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.


---

