Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 504EDC002B for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion , Andrew Poelstra References: <764E460B-C0C6-47B8-A97E-F7CBC81FD645@petertodd.org> From: Aymeric Vitte 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 OpDrop? >>> >> This is a technical nit, but the reason is that 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 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

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--