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

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org