On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>All other things being equal, which is better if you need to place a
>64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
>taproot transaction such as:
>OP_PUSH my64bytes

What's wrong with OpPush <data> OpDrop?

>I know that the anti-OP_RETURN folk would say “neither.” But if there was
>no other choice for a particular protocol, such as a timestamp or a
>commitment, which is better? Or is there a safer place to put 64 bytes that
>is more uncensorable but also does not clog UTXO space, only spent
>transaction `-txindex` space?
>My best guess was that the taproot method is better, but I suspect there
>might be some who disagree. I'd love to hear all sides.

An important consideration with using taproot is that you need to have the data 
you are committing too to be able to to spend the txout in the future. OpReturn 
doesn't have that problem, meaning that in a situation like a hard drive 
failure, you can still recover the funds from a wallet seed.

Also, it is incorrect to say that OpReturn outputs "clog UTXO space". The whole 
point of OpReturn is to standardize a way to keep such outputs out of the UTXO 
set. There is the 75% discount to using witness space. But considering the size 
of a transaction as a whole using taproot instead of OpReturn doesn't save much.

Finally, _64_ bytes is more than a mere 32 byte commitment. What specific use 
case do you actually have in mind here? Are you actually publishing data, or 
simply committing to data? If the latter, you can use ECC commitments and have 
no extra space at all.
bitcoin-dev mailing list

Reply via email to