Indeed the witness envelope is more costly and less easy to use (or read/track)
But let's take a standard P2PKH or P2WPKH output, what prevents me from adding in the beginning of scriptSig or witness while spending it: OP_PUSH <data> OP_DROP ? Non standard ? This one makes one transaction only There are probably plenty of ways to store data, another one would be to use a dummy 1 of N multisig where only 1 corresponds to a pubkey and the rest is data, but again several transactions... I think the right way so people don't invent deviant things is to increase the size of OP_RETURN, I don't get this number of 80B, you can hardly store a signature (of what?) in there and not the "what" if the "what" is a hash for example Le 02/02/2023 à 14:25, Rijndael via bitcoin-dev a écrit : > 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 -- Sophia-Antipolis, France CV: https://www.peersm.com/CVAV.pdf LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26 GitHub : https://www.github.com/Ayms A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7 A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com Peersm : http://www.peersm.com _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
