📅 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.
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 23:18:54
in reply to nevent1q…83ve
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 23:18:54Event JSON
{
"id": "f1cb46c4aba0a6c214062937b76bb40645d5f437566886778857223f2d636620",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686179934,
"kind": 1,
"tags": [
[
"e",
"db7e30240de322a59459e6f6d735c7f019f73c8194514d70467812fbd7606451",
"",
"root"
],
[
"e",
"38db739c56c6894572a30fdcaa34fe5cfa3549378e6fb74cf4fff2e6885fb781",
"",
"reply"
],
[
"p",
"2a2be7532ec03e16fa6ff38360d30cc714893870cbd9fafbefeb1df2df858c4d"
]
],
"content": "📅 Original date posted:2023-02-01\n🗒️ 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.\n📝 Original message:On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003eAll other things being equal, which is better if you need to place a\n\u003e64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent\n\u003etaproot transaction such as:\n\u003e\n\u003eOP_FALSE\n\u003eOP_IF\n\u003eOP_PUSH my64bytes\n\u003eOP_ENDIF\n\nWhat's wrong with OpPush \u003cdata\u003e OpDrop?\n\n\u003eI know that the anti-OP_RETURN folk would say “neither.” But if there was\n\u003eno other choice for a particular protocol, such as a timestamp or a\n\u003ecommitment, which is better? Or is there a safer place to put 64 bytes that\n\u003eis more uncensorable but also does not clog UTXO space, only spent\n\u003etransaction `-txindex` space?\n\u003e\n\u003eMy best guess was that the taproot method is better, but I suspect there\n\u003emight be some who disagree. I'd love to hear all sides.\n\nAn 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.\n\nAlso, 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.\n\nFinally, _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.",
"sig": "1220ac4f0556123f5613972c225f1bf2a1cc05fbf3e056ea96cb5142f46950150ea920082fb51d08a41e9b0f4c5243b0ef54f12e57722448dbf4db4bc8f664cf"
}