From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id CD670C002B for ; Sun, 12 Feb 2023 16:24:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 9AAEC60B9A for ; Sun, 12 Feb 2023 16:24:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9AAEC60B9A 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrNVNGfOW2nG for ; Sun, 12 Feb 2023 16:24:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org BDFB960A69 Received: from smtpout3.mo529.mail-out.ovh.net (smtpout3.mo529.mail-out.ovh.net [46.105.54.81]) by smtp3.osuosl.org (Postfix) with ESMTPS id BDFB960A69 for ; Sun, 12 Feb 2023 16:24:03 +0000 (UTC) Received: from mxplan6.mail.ovh.net (unknown [10.108.20.235]) by mo529.mail-out.ovh.net (Postfix) with ESMTPS id DCF69209D5; Sun, 12 Feb 2023 16:24:00 +0000 (UTC) Received: from peersm.com (37.59.142.102) 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; Sun, 12 Feb 2023 17:24:00 +0100 Authentication-Results: garm.ovh; auth=pass (GARM-102R0043b340e09-e490-431f-a883-dd441d1a0d61, B4C7D7AD1F5A4529B5943D5837896D0BF92101CE) smtp.auth=aymeric@peersm.com X-OVh-ClientIp: 92.184.102.200 To: Russell O'Connor , Bitcoin Protocol Discussion , Peter Todd , Andrew Poelstra , Christopher Allen References: <57f780b1-f262-9394-036c-70084320e9cf@peersm.com> <3d00aacb-585d-f875-784d-34352860d725@peersm.com> <230265ee-c3f8-dff3-9192-f0c8dc4d913c@peersm.com> <76718304-A8E3-46E6-B2F7-DE86831F15DF@petertodd.org> From: Aymeric Vitte Message-ID: Date: Sun, 12 Feb 2023 17:23:59 +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="------------9AF7A061FABC2FC78A967B1D" X-Originating-IP: [37.59.142.102] X-ClientProxiedBy: DAG5EX1.mxp6.local (172.16.2.41) To DAG6EX2.mxp6.local (172.16.2.52) X-Ovh-Tracer-GUID: 4eac7d6e-93a3-4812-84b7-967629ea97ee X-Ovh-Tracer-Id: 1342072691644785571 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrudehledgkeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtihesrgdtreertdefheenucfhrhhomhepteihmhgvrhhitgcugghithhtvgcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnhepteehfedvvdehffdthfejvddtjeejieetudevleeikeduvedvtdelveevfeetgfefnecuffhomhgrihhnpehgihhthhhusgdrtghomhdplhhinhhugihfohhunhgurghtihhonhdrohhrghdpphgvvghrshhmrdgtohhmpdhlihhnkhgvughinhdrtghomhenucfkphepuddvjedrtddrtddruddpfeejrdehledrudegvddruddtvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqpdhnsggprhgtphhtthhopedupdhrtghpthhtohepvehhrhhishhtohhphhgvrhetsehlihhfvgifihhthhgrlhgrtghrihhthidrtghomhdprghpohgvlhhsthhrrgesfihpshhofhhtfigrrhgvrdhnvghtpdhpvghtvgesphgvthgvrhhtohguugdrohhrghdpsghithgtohhinhdquggvvheslhhishhtshdrlhhinhhugihfohhunhgurghtihhonh drohhrghdprhhotghonhhnohhrsegslhhotghkshhtrhgvrghmrdgtohhmpdfovfetjfhoshhtpehmohehvdelpdhmohguvgepshhmthhpohhuth X-Mailman-Approved-At: Sun, 12 Feb 2023 16:49:12 +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: Sun, 12 Feb 2023 16:24:05 -0000 --------------9AF7A061FABC2FC78A967B1D Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1427069403 "What is the process to have someone do the PR for this? Or I do it and most likely it will be a very shxtty one since I am not a C/C++ expert, then wasting the time of everybody It's urgently required, I did consider OP_RETURN as a dart in the past but changed my mind, it's adapted to the current evolutions, not flooding bitcoin with 2 txs while only 1 is needed If not the best 1 tx solution is super simple: store in addresses, and super bad at the end because burning bitcoins, while still not expensive if you don't need to store big things" Le 05/02/2023 =E0 19:12, Russell O'Connor via bitcoin-dev a =E9crit : > > > On Sat., Feb. 4, 2023, 21:01 Peter Todd, > wrote: > > > > On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via > bitcoin-dev > wrote: > >Since bytes in the witness are cheaper than bytes in the script > pubkey, > >there is a crossover point in data size where it will simply be > cheaper to > >use witness data. Where that crossover point is depends on the fi= ner > >details of the overhead of the two methods, but you could make som= e > >reasonable assumptions. Such a calculation could form the basis o= f a > >reasonable OP_RETURN proposal. I don't know if it would be > persuasive, but > >it would at least be coherent. > > I don't think it's worth the technical complexity trying to > carefully argue a specific limit. Let users decide for themselves > how they want to use OpReturn. > > > Even better. > > > > _______________________________________________ > 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 --------------9AF7A061FABC2FC78A967B1D Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit

https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1427069403

"What is the process to have someone do the PR for this? Or I do it and most likely it will be a very shxtty one since I am not a C/C++ expert, then wasting the time of everybody

It's urgently required, I did consider OP_RETURN as a dart in the past but changed my mind, it's adapted to the current evolutions, not flooding bitcoin with 2 txs while only 1 is needed

If not the best 1 tx solution is super simple: store in addresses, and super bad at the end because burning bitcoins, while still not expensive if you don't need to store big things"


Le 05/02/2023 à 19:12, Russell O'Connor via bitcoin-dev a écrit :


On Sat., Feb. 4, 2023, 21:01 Peter Todd, <pete@petertodd.org> wrote:


On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>Since bytes in the witness are cheaper than bytes in the script pubkey,
>there is a crossover point in data size where it will simply be cheaper to
>use witness data.  Where that crossover point is depends on the finer
>details of the overhead of the two methods, but you could make some
>reasonable assumptions.  Such a calculation could form the basis of a
>reasonable OP_RETURN proposal.  I don't know if it would be persuasive, but
>it would at least be coherent.

I don't think it's worth the technical complexity trying to carefully argue a specific limit. Let users decide for themselves how they want to use OpReturn.

Even better.


_______________________________________________
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
--------------9AF7A061FABC2FC78A967B1D--