Hello Christopher, I think if the protocol that you were designing always had <80 bytes, I'd prefer the OP_RETURN. I think the "witness envelope" has two major disadvantages compared to the OP_RETURN method:
1. You need to first spend to he address that commits to the script that encodes your data payload. So you have a two step process of first spending to a "commitment" address and then a second spend to "reveal" your payload. You can CPFP to get them both into the same block, but its still two transactions, so more cost, etc. 2. Because of the two step process in (1), if for some reason you were unable to get the "reveal" transaction into a block (for example there's widespread censorship of transactions that match the format of the "reveal" script), then you might have money that's stuck in the "commit" stage of the protocol. The way out of this would be to get your money out via the keypath or another tapleaf, but then you need to spend money to cancel a step in your protocol. Of course there could be widespread censorship of your OP_RETURNs too, but you don't have to spend funds on the cancellation spends. I think (2) is actually a pretty weak argument because as we saw in the full-rbf discussion, as long as there's some threshold number of nodes in the network that relay transactions to miners, you can probably find a path to a miner (IIRC the number was on the order of 15% of the network?). So I think the big reason to pick OP_RETURN over the witness embedding is that you save a transaction and possibly some failure-recovery/cancellation logic. Obviously if your data is larger than 80 bytes, then you probably want to do the witness-embedding method. If your data smaller, then a pay-to-contract tweak probably the best thing from a space and fingerprinting perspective. - rijndael On 1/31/23 7:46 PM, Christopher Allen via bitcoin-dev 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 > > 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 > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
