So with datacarrier we can store data in taproot annex with one tx which will be data and/or extension of the script validation via PUSH_ANNEX
I looked at your links and plenty of others, but had some hard time to find the proposal (https://github.com/bitcoin/bips/blob/9dc3f74b384f143b7f1bdad30dc0fe2529c8e63f/bip-annex.mediawiki I suppose), when do you think datacarrier can happen for real on the network? Now I think the OP_RETURN debate remains relevant, it's a quite trivial modification to do, from my standpoint it is certainly not intended to store big things (but 80B, what do you want to do with this?), but if people want to store big things and pay for it... what is the real issue? (I saw your argument of "partial" block validation and others like skipping witness data, at the end nodes must validate the whole thing) Le 17/02/2023 à 13:49, Anthony Towns a écrit : > On Sat, Feb 04, 2023 at 07:11:35PM -0500, Russell O'Connor via bitcoin-dev > wrote: >> Since bytes in the witness are cheaper than bytes in the script pubkey, >> there is a crossover point in data size where it will simply be cheaper to >> use witness data. > Given today's standardness constraints, that's true (because you first > need to construct a p2wsh/tapscript output that commits to the data, > then you have to spend it), but it needn't stay that way. Allowing a data > carrier entry in the annex (as contemplated for eltoo [0]) would allow > you to publish the data with a single transaction, with malleability > prevented because the annex content is committed to by the signature. > > [0] https://github.com/bitcoin-inquisition/bitcoin/pull/22 > > I think the cost for publishing data via the witness today is roughly: > > 115 vb - for the commitment tx > 115 vb + datalen/4 - for the publication tx > > versus > > 125 vb + datalen - for a tx with an OP_RETURN output > > so the crossover point is at a datalen of about 140 bytes. Perhaps > slightly more or less depending on how much you can combine these > inputs/outputs with other txs you would have made anyway. > > With a datacarrier in the annex that has similar or higher limits than > OP_RETURN, I don't think OP_RETURN would ever be cheaper. > > The other advantage to using the witness for random data compared to > OP_RETURN is that the txid commits to OP_RETURN output, so you must > download all OP_RETURN data to validate a block's merkle tree, whereas > you can partially validate a block (in particular, you can validate the > spendable utxo set) without downloading witness data [1]. > > [1] https://github.com/bitcoin/bitcoin/pull/27050 > > Cheers, > aj -- 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
