Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-01 🗒️ Summary of this message: A debate on ...
📅 Original date posted:2023-02-01
🗒️ Summary of this message: A debate on whether a traditional OP_RETURN or a spent taproot transaction is better for placing 64 bytes into the Bitcoin blockchain.
📝 Original message:On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <bitcoin-dev at 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_FALSE
>OP_IF
>OP_PUSH my64bytes
>OP_ENDIF
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.
🗒️ Summary of this message: A debate on whether a traditional OP_RETURN or a spent taproot transaction is better for placing 64 bytes into the Bitcoin blockchain.
📝 Original message:On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <bitcoin-dev at 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_FALSE
>OP_IF
>OP_PUSH my64bytes
>OP_ENDIF
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.