š
Original date posted:2023-02-02
šļø Summary of this message: Discussion on the most efficient way to place 64 bytes into the Bitcoin blockchain, with suggestions including OP_RETURN and spent taproot transactions.
š Original message: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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/aa281e02/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 23:18:55
in reply to nevent1qā¦39w2
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 23:18:55Event JSON
{
"id": "9b2c16de6c5b86cfbe3342db3f67e258df9ecf5428b71f0c5aef86e23d809343",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686179935,
"kind": 1,
"tags": [
[
"e",
"db7e30240de322a59459e6f6d735c7f019f73c8194514d70467812fbd7606451",
"",
"root"
],
[
"e",
"a75fc2545583dddab36da0258eac442c12bc6f8abf050a092d21ce802f88587c",
"",
"reply"
],
[
"p",
"ee55eb03423bd4db01d5c92ad434d52c602d9da1de37ed37cc5bf7d2a13a4cab"
]
],
"content": "š
Original date posted:2023-02-02\nšļø Summary of this message: Discussion on the most efficient way to place 64 bytes into the Bitcoin blockchain, with suggestions including OP_RETURN and spent taproot transactions.\nš Original message:On Wed, Feb 01, 2023 at 02:02:41PM +0000, Andrew Poelstra wrote:\n\u003e On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote:\n\u003e \u003e \n\u003e \u003e \n\u003e \u003e On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e \u003eAll other things being equal, which is better if you need to place a\n\u003e \u003e \u003e64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent\n\u003e \u003e \u003etaproot transaction such as:\n\u003e \u003e \u003e\n\u003e \u003e \u003eOP_FALSE\n\u003e \u003e \u003eOP_IF\n\u003e \u003e \u003eOP_PUSH my64bytes\n\u003e \u003e \u003eOP_ENDIF\n\u003e \u003e \n\u003e \u003e What's wrong with OpPush \u003cdata\u003e OpDrop?\n\u003e \u003e\n\u003e \n\u003e This is a technical nit, but the reason is that \u003cdata\u003e is limited to 520\n\u003e bytes (and I believe, 80 bytes by standardness in Taproot), so if you\n\u003e are pushing a ton of data and need multiple pushes, it's more efficient\n\u003e to use FALSE IF ... ENDIF since you avoid the repeated DROPs.\n\nYes, for more than 520 bytes you need to wrap the push in an IF/ENDIF so it's\nnot executed. But in this example we're just talking about 64 bytes, so that\nlimit isn't relevant and OpPush \u003cdata\u003e OpDrop should be sufficient.\n\nSpecifically for more than 520 bytes you run into the the\nMAX_SCRIPT_ELEMENT_SIZE check in script/interpreter.cpp, which applies to all\nscripts regardless of standardness at script execution:\n\n //\n // Read instruction\n //\n if (!script.GetOp(pc, opcode, vchPushValue))\n return set_error(serror, SCRIPT_ERR_BAD_OPCODE);\n if (vchPushValue.size() \u003e MAX_SCRIPT_ELEMENT_SIZE)\n return set_error(serror, SCRIPT_ERR_PUSH_SIZE);\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/aa281e02/attachment.sig\u003e",
"sig": "bf09ee44b43a99977a4624a84c3d71a5d771e05e5b1e4290ecb67591bd0e585a8be21849a40fd6cf2c3be843860d87ee99184b2f0ecda733f59503ee10d4c030"
}