Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D2D04C002B for ; Sat, 4 Feb 2023 17:40:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id AD2FF41851 for ; Sat, 4 Feb 2023 17:40:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org AD2FF41851 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kDHy_s-m8yV for ; Sat, 4 Feb 2023 17:40:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 348084184E Received: from 9.mo552.mail-out.ovh.net (9.mo552.mail-out.ovh.net [87.98.180.222]) by smtp4.osuosl.org (Postfix) with ESMTPS id 348084184E for ; Sat, 4 Feb 2023 17:40:31 +0000 (UTC) Received: from mxplan6.mail.ovh.net (unknown [10.108.1.237]) by mo552.mail-out.ovh.net (Postfix) with ESMTPS id 7C4E2297DF; Sat, 4 Feb 2023 17:01:22 +0000 (UTC) Received: from peersm.com (37.59.142.105) by DAG6EX2.mxp6.local (172.16.2.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.17; Sat, 4 Feb 2023 18:01:21 +0100 Authentication-Results: garm.ovh; auth=pass (GARM-105G006d9f72e5d-e61e-4b6f-bfb0-ec72cac74c33, 83B9442A37C74570B8CB15ECCD3A86C2760700E6) smtp.auth=aymeric@peersm.com X-OVh-ClientIp: 92.184.100.83 To: Kostas Karasavvas , Bitcoin Protocol Discussion , Christopher Allen References: <57f780b1-f262-9394-036c-70084320e9cf@peersm.com> From: Aymeric Vitte Message-ID: <3d00aacb-585d-f875-784d-34352860d725@peersm.com> Date: Sat, 4 Feb 2023 18:01:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8C4BD7752612BCCB5F7A2904" X-Originating-IP: [37.59.142.105] X-ClientProxiedBy: DAG3EX2.mxp6.local (172.16.2.22) To DAG6EX2.mxp6.local (172.16.2.52) X-Ovh-Tracer-GUID: ca84e9f6-60c3-4bd9-9d9a-1b34a559ddf6 X-Ovh-Tracer-Id: 10331820495460656093 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrudegvddgleehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtihesrgdtreertdefheenucfhrhhomhepteihmhgvrhhitgcugghithhtvgcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnhepveduhefgudefhffghfdvleetfffhiefhkeefvddtgedvhfdvffdvvdetuedtgeegnecuffhomhgrihhnpehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhpvggvrhhsmhdrtghomhdplhhinhhkvgguihhnrdgtohhmpdhgihhthhhusgdrtghomhenucfkphepuddvjedrtddrtddruddpfeejrdehledrudegvddruddtheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqpdhnsggprhgtphhtthhopedupdhrtghpthhtohepvehhrhhishhtohhphhgvrhetsehlihhfvgifihhthhgrlhgrtghrihhthidrtghomhdpsghithgtohhinhdquggvvheslhhishhtshdrlhhinhhugihfohhunhgurghtihhonhdrohhrghdpkhhkrghrrghsrghvvhgrshesghhmrghilhdrtghomhdpoffvtefjohhsthepmhhoheehvddpmhhoug gvpehsmhhtphhouhht X-Mailman-Approved-At: Sat, 04 Feb 2023 17:56:49 +0000 Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2023 17:40:33 -0000 --------------8C4BD7752612BCCB5F7A2904 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable 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 =E0 15:11, Kostas Karasavvas via bitcoin-dev a =E9crit : > > > On Fri, Feb 3, 2023 at 10:17 PM Christopher Allen via bitcoin-dev > > wrote: > > On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev > > 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 --=20 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/Ay= ms/029125db2583e1cf9c3209769eb2cdd7 A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3b= eed1bfeba7 Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transac= tions 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.p= eersm.com Peersm : http://www.peersm.com --------------8C4BD7752612BCCB5F7A2904 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit

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> wrote:
On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev <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
--------------8C4BD7752612BCCB5F7A2904--