Thanks, then this limitation should be rethought I think (see the email I just sent replying to the coloured thread)
Because it forces people to store in witness (less easy to track/show I believe) or adopt some deviant behavior (like storing in addresses where the utxo will remain unspendable forever) Le 02/02/2023 à 12:49, Peter Todd a écrit : > On Thu, Feb 02, 2023 at 12:45:42PM +0100, Aymeric Vitte wrote: >> As far as I can read nobody replied to the initial question: what is >> considered as good/best practice to store in Bitcoin? > Your answer is beyond not putting unspendable data in the UTXO set, the exact > details don't really matter. Do what makes sense for your specific > application. > >> Reiterating my question: what are the current rules for OP_RETURN, max >> size and number of OP_RETURN per tx > Max 80 bytes, one OpReturn output per tx. > > This of course is the standardness rule. With a miner willing to mine non-std > transactions anything goes. > -- 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
