I think logically: - if you want to store something big and can afford several txs in your design, then you use something like witness
- if you want to store small things like signatures, addresses hashes and some metadata and your design does not make several txs easy, then you use OP_RETURN Then how can we move forward with several OP_RETURN and no size limit? I can start posting a bug/enhancement proposal in bitcoin repo but can't write the PR Le 05/02/2023 à 01:04, Peter Todd a écrit : > > On February 5, 2023 12:09:02 AM GMT+01:00, Aymeric Vitte via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: >> I don't know, what number would you advise? When I made the >> bitcoin-transactions nodejs module some years ago the limit (from the >> specs) was 512B > 1) Allowing only one OpReturn output causes problems trying to compose > different uses of OpReturn. We should allow any number of OpReturn outputs. > > 2) There's no reason to put a size limit given all the other ways people can > publish data, including with a 75% discount. Let the fee market deal with it. -- 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
