Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

From: Aymeric Vitte <aymeric@peersm•com>
To: Peter Todd <pete@petertodd•org>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	Andrew Poelstra <apoelstra@wpsoftware•net>
Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
Date: Thu, 2 Feb 2023 12:45:42 +0100	[thread overview]
Message-ID: <16446c77-c9de-7b11-8e66-7f8e20421cba@peersm.com> (raw)
In-Reply-To: <Y9uc72RSs6LQojG4@petertodd.org>

[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4824 bytes --]