I don't get very well where all the current (other threats) discussions are going, storing on-chain is absurd
It's absurd also to flood bitcoin with several useless transactions to store in witness or others, looks like ethereum messy stuff What is not absurd is to store the proofs that can be checked using a notorious third party/sidechain but you need more than 80B What is the official bitcoin channel to request the OP_RETURN size change? (press often mentions that ethereum is good to manage changes and bitcoin a complete zero) As a very bad solution, I think I would be willing to store data in addresses, with one single transaction, as people did in the past, then burning bitcoins but still not expensive, or less than several txs, because schemes involving several transactions do not work very well In any case, we see the problem, then people will invent something and most likely it will not comply at all with bitcoin good practices Le 04/02/2023 à 15:11, Kostas Karasavvas via bitcoin-dev a écrit : > > > On Fri, Feb 3, 2023 at 10:17 PM Christopher Allen via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > 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 > > > Updating the size of OP_RETURN to support a hash (or two), a > signature, and maybe a few more bytes for metadata, would be very > helpful in a number of scenarios. It is still a limit but a > reasonable one. Otherwise, I think we'll have a lot more > inscription-style scenarios. > > > I wouldn't be against an increase in OP_RETURN but I don't think it > will make any difference in how often inscription-style use cases will > be used. They will be used primarily for much larger datasets than, > say 120 bytes, and they also have the segwit discount. > > > _______________________________________________ > 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
