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
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
