Return-Path: <aymeric@peersm.com> Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 504EDC002B for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 2 Feb 2023 11:45:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 1E0DF41B6D for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 2 Feb 2023 11:45:49 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1E0DF41B6D X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 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, RCVD_IN_MSPIKE_H2=-0.001, 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 DMKEQhYUP0RC for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 2 Feb 2023 11:45:46 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9649741B61 Received: from 8.mo548.mail-out.ovh.net (8.mo548.mail-out.ovh.net [46.105.45.231]) by smtp4.osuosl.org (Postfix) with ESMTPS id 9649741B61 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 2 Feb 2023 11:45:46 +0000 (UTC) Received: from mxplan6.mail.ovh.net (unknown [10.109.156.48]) by mo548.mail-out.ovh.net (Postfix) with ESMTPS id 0F5FE20B26; Thu, 2 Feb 2023 11:45:43 +0000 (UTC) Received: from peersm.com (37.59.142.101) 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; Thu, 2 Feb 2023 12:45:43 +0100 Authentication-Results: garm.ovh; auth=pass (GARM-101G004d528f3d9-448b-490a-b6f1-ea707c13d5ad, 6AA1D679F834A14CBEAA49266E816969C7C1CEBF) smtp.auth=aymeric@peersm.com X-OVh-ClientIp: 92.184.100.16 To: Peter Todd <pete@petertodd.org>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, Andrew Poelstra <apoelstra@wpsoftware.net> References: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com> <764E460B-C0C6-47B8-A97E-F7CBC81FD645@petertodd.org> <Y9pxAdm3kO1rr2kU@camus> <Y9uc72RSs6LQojG4@petertodd.org> From: Aymeric Vitte <aymeric@peersm.com> Message-ID: <16446c77-c9de-7b11-8e66-7f8e20421cba@peersm.com> Date: Thu, 2 Feb 2023 12:45:42 +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: <Y9uc72RSs6LQojG4@petertodd.org> Content-Type: multipart/alternative; boundary="------------741F1923621C33C05D5E6C54" X-Originating-IP: [37.59.142.101] X-ClientProxiedBy: DAG1EX2.mxp6.local (172.16.2.2) To DAG6EX2.mxp6.local (172.16.2.52) X-Ovh-Tracer-GUID: e7206ec9-679c-4138-9595-6767acc0998c X-Ovh-Tracer-Id: 11702322158756914141 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrudefkedgfedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtihesrgdtreertdefheenucfhrhhomhepteihmhgvrhhitgcugghithhtvgcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnhepveduhefgudefhffghfdvleetfffhiefhkeefvddtgedvhfdvffdvvdetuedtgeegnecuffhomhgrihhnpehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhpvggvrhhsmhdrtghomhdplhhinhhkvgguihhnrdgtohhmpdhgihhthhhusgdrtghomhenucfkphepuddvjedrtddrtddruddpfeejrdehledrudegvddruddtudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqpdhnsggprhgtphhtthhopedupdhrtghpthhtoheprghpohgvlhhsthhrrgesfihpshhofhhtfigrrhgvrdhnvghtpdgsihhttghoihhnqdguvghvsehlihhsthhsrdhlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhpvghtvgesphgvthgvrhhtohguugdrohhrghdpoffvtefjohhsthepmhhoheegkedpmhhouggvpehsmhhtphhouhht X-Mailman-Approved-At: Thu, 02 Feb 2023 12:03:27 +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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Thu, 02 Feb 2023 11:45:49 -0000 --------------741F1923621C33C05D5E6C54 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit As far as I can read nobody replied to the initial question: what is considered as good/best practice to store in Bitcoin? Reiterating my question: what are the current rules for OP_RETURN, max size and number of OP_RETURN per tx Le 02/02/2023 � 12:22, Peter Todd via bitcoin-dev a �crit : > On Wed, Feb 01, 2023 at 02:02:41PM +0000, Andrew Poelstra wrote: >> On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote: >>> >>> On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: >>>> All other things being equal, which is better if you need to place a >>>> 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent >>>> taproot transaction such as: >>>> >>>> OP_FALSE >>>> OP_IF >>>> OP_PUSH my64bytes >>>> OP_ENDIF >>> What's wrong with OpPush <data> OpDrop? >>> >> This is a technical nit, but the reason is that <data> is limited to 520 >> bytes (and I believe, 80 bytes by standardness in Taproot), so if you >> are pushing a ton of data and need multiple pushes, it's more efficient >> to use FALSE IF ... ENDIF since you avoid the repeated DROPs. > Yes, for more than 520 bytes you need to wrap the push in an IF/ENDIF so it's > not executed. But in this example we're just talking about 64 bytes, so that > limit isn't relevant and OpPush <data> OpDrop should be sufficient. > > Specifically for more than 520 bytes you run into the the > MAX_SCRIPT_ELEMENT_SIZE check in script/interpreter.cpp, which applies to all > scripts regardless of standardness at script execution: > > // > // Read instruction > // > if (!script.GetOp(pc, opcode, vchPushValue)) > return set_error(serror, SCRIPT_ERR_BAD_OPCODE); > if (vchPushValue.size() > MAX_SCRIPT_ELEMENT_SIZE) > return set_error(serror, SCRIPT_ERR_PUSH_SIZE); > > > > _______________________________________________ > 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 --------------741F1923621C33C05D5E6C54 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <p>As far as I can read nobody replied to the initial question: what is considered as good/best practice to store in Bitcoin?</p> <p>Reiterating my question: what are the current rules for OP_RETURN, max size and number of OP_RETURN per tx<br> </p> <br> <div class="moz-cite-prefix">Le 02/02/2023 � 12:22, Peter Todd via bitcoin-dev a �crit�:<br> </div> <blockquote cite="mid:Y9uc72RSs6LQojG4@petertodd.org" type="cite"> <pre wrap="">On Wed, Feb 01, 2023 at 02:02:41PM +0000, Andrew Poelstra wrote: </pre> <blockquote type="cite"> <pre wrap="">On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote: </pre> <blockquote type="cite"> <pre wrap=""> On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <a class="moz-txt-link-rfc2396E" href="mailto:bitcoin-dev@lists.linuxfoundation.org"><bitcoin-dev@lists.linuxfoundation.org></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">All other things being equal, which is better if you need to place a 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent taproot transaction such as: OP_FALSE OP_IF OP_PUSH my64bytes OP_ENDIF </pre> </blockquote> <pre wrap=""> What's wrong with OpPush <data> OpDrop? </pre> </blockquote> <pre wrap=""> This is a technical nit, but the reason is that <data> is limited to 520 bytes (and I believe, 80 bytes by standardness in Taproot), so if you are pushing a ton of data and need multiple pushes, it's more efficient to use FALSE IF ... ENDIF since you avoid the repeated DROPs. </pre> </blockquote> <pre wrap=""> Yes, for more than 520 bytes you need to wrap the push in an IF/ENDIF so it's not executed. But in this example we're just talking about 64 bytes, so that limit isn't relevant and OpPush <data> OpDrop should be sufficient. Specifically for more than 520 bytes you run into the the MAX_SCRIPT_ELEMENT_SIZE check in script/interpreter.cpp, which applies to all scripts regardless of standardness at script execution: // // Read instruction // if (!script.GetOp(pc, opcode, vchPushValue)) return set_error(serror, SCRIPT_ERR_BAD_OPCODE); if (vchPushValue.size() > MAX_SCRIPT_ELEMENT_SIZE) return set_error(serror, SCRIPT_ERR_PUSH_SIZE); </pre> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ bitcoin-dev mailing list <a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a> <a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a> </pre> </blockquote> <br> <pre class="moz-signature" cols="72">-- Sophia-Antipolis, France CV: <a class="moz-txt-link-freetext" href="https://www.peersm.com/CVAV.pdf">https://www.peersm.com/CVAV.pdf</a> LinkedIn: <a class="moz-txt-link-freetext" href="https://fr.linkedin.com/in/aymeric-vitte-05855b26">https://fr.linkedin.com/in/aymeric-vitte-05855b26</a> GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a> A Universal Coin Swap system based on Bitcoin: <a class="moz-txt-link-freetext" href="https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7">https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7</a> A bitcoin NFT system: <a class="moz-txt-link-freetext" href="https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7">https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7</a> Move your coins by yourself (browser version): <a class="moz-txt-link-freetext" href="https://peersm.com/wallet">https://peersm.com/wallet</a> Bitcoin transactions made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-transactions">https://github.com/Ayms/bitcoin-transactions</a> torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a> node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a> Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.peersm.com">http://torrent-live.peersm.com</a> Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a></pre> </body> </html> --------------741F1923621C33C05D5E6C54--