Aymeric Vitte [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-04 🗒️ Summary of this message: Increasing the ...

📅 Original date posted:2023-02-04
🗒️ Summary of this message: Increasing the size of OP_RETURN to store proofs that can be checked using a third party/sidechain is reasonable, but storing on-chain is absurd.
📝 Original message: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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/5dfda935/attachment.html>;