Can Taproot be used to commit arbitrary data to chain without any additional footprint?

Question

A common way of committing some data to the chain is through an OP_RETURN with some hash. Doing this marks an output unspendable, but the output still requires some footprint (and cost) on the chain as it contributes to the TX hash.

So I'm wondering if it is possible to embed some data in an OP_RETURN in a script of a TapLeaf which is never intended to be part of a spend. If we assume that the Taproot output is spent using the key path, and it has already confirmed, it should be possible to later reveal the paths and scripts containing the OP_RETURNs, and it could be proven that the TapTweak hash did indeed commit to these hashes via the TapBranch hashes.

A single transaction could commit to a large number of OP_RETURNs which have no on-chain outputs, but whose hashes are indirectly committed to the chain. These could be revealed individually to whatever parties they concern. The paths and scripts would have no presence on the blockchain.

Maybe this doesn't even require the OP_RETURN as you could just use the TapBranch/TapLeaf hash itself as the data you wish to commit.

Would this not significantly reduce the cost of services like colored coins, timestamping services, etc, which commit their data directly onto the chain?

Answer 1

Yes, you can commit to data this way, but there is nothing special about Taproot here.

The Pay-to-Contract construction used to tweak the root key in Taproot is generally usable, and has in fact been used for exactly this purpose. In fact, it is one of the mechanisms used in OpenTimestamps to commit to timestamped data (including a variant sign-to-contract which makes a signature commit to data rather than a public key). It is also used in Blockstream's Liquid pegin mechanism, where transfers from Bitcoin to Liquid pay to an address derived using a tweaked key of the federation, which commits to the transfer information.

In fact, using an additional leaf in Taproot for this is overkill, and would inevitably increase the depth in the Merkle tree for at least one other leaf - resulting in increased spending cost. Just using pay-to-contract or sign-to-contract directly on one of the public keys involved can be done with zero cost to on-chain spending policies.

Would this not significantly reduce the cost of services like colored coins, timestamping services, etc, which commit their data directly onto the chain?

Decent timestamping services already use better techniques.

For colored coins it depends whether they just need timestamping or actual publication of data. My understanding is that it's generally the latter (as otherwise, they need another censorship-resistant channel to transfer the actual data, which could then probably be used directly).