Christopher Allen [ARCHIVE] on Nostr: π Original date posted:2023-01-31 ποΈ Summary of this message: Which is better ...
π
Original date posted:2023-01-31
ποΈ Summary of this message: Which is better for placing 64 bytes into the Bitcoin blockchain: traditional OP_RETURN or spent taproot transaction? Debate on safety and uncensorability.
π Original message: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
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.
-- Christopher Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230131/cac8f8b3/attachment.html>
ποΈ Summary of this message: Which is better for placing 64 bytes into the Bitcoin blockchain: traditional OP_RETURN or spent taproot transaction? Debate on safety and uncensorability.
π Original message: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
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.
-- Christopher Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230131/cac8f8b3/attachment.html>