📅 Original date posted:2023-02-02
🗒️ Summary of this message: No one has answered the question of what is considered good practice for storing in Bitcoin, specifically regarding OP_RETURN rules, max size, and number of OP_RETURN per transaction.
📝 Original message: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 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);
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/13100de1/attachment.html>;
Aymeric Vitte [ARCHIVE] /
npub15f…g5grz
2023-06-07 23:18:56
in reply to nevent1q…zx5g
Author Public Key
npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grzPublished at
2023-06-07 23:18:56Event JSON
{
"id": "6919a8ddba5a9f860019e949e4fb2ad701cf11b96d5b7382dd8ef251edf3d531",
"pubkey": "a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df",
"created_at": 1686179936,
"kind": 1,
"tags": [
[
"e",
"db7e30240de322a59459e6f6d735c7f019f73c8194514d70467812fbd7606451",
"",
"root"
],
[
"e",
"9b2c16de6c5b86cfbe3342db3f67e258df9ecf5428b71f0c5aef86e23d809343",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2023-02-02\n🗒️ Summary of this message: No one has answered the question of what is considered good practice for storing in Bitcoin, specifically regarding OP_RETURN rules, max size, and number of OP_RETURN per transaction.\n📝 Original message:As far as I can read nobody replied to the initial question: what is\nconsidered as good/best practice to store in Bitcoin?\n\nReiterating my question: what are the current rules for OP_RETURN, max\nsize and number of OP_RETURN per tx\n\n\nLe 02/02/2023 à 12:22, Peter Todd via bitcoin-dev a écrit :\n\u003e On Wed, Feb 01, 2023 at 02:02:41PM +0000, Andrew Poelstra wrote:\n\u003e\u003e On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote:\n\u003e\u003e\u003e\n\u003e\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\u003e\u003e All other things being equal, which is better if you need to place a\n\u003e\u003e\u003e\u003e 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent\n\u003e\u003e\u003e\u003e taproot transaction such as:\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e OP_FALSE\n\u003e\u003e\u003e\u003e OP_IF\n\u003e\u003e\u003e\u003e OP_PUSH my64bytes\n\u003e\u003e\u003e\u003e OP_ENDIF\n\u003e\u003e\u003e What's wrong with OpPush \u003cdata\u003e OpDrop?\n\u003e\u003e\u003e\n\u003e\u003e This is a technical nit, but the reason is that \u003cdata\u003e is limited to 520\n\u003e\u003e bytes (and I believe, 80 bytes by standardness in Taproot), so if you\n\u003e\u003e are pushing a ton of data and need multiple pushes, it's more efficient\n\u003e\u003e to use FALSE IF ... ENDIF since you avoid the repeated DROPs.\n\u003e Yes, for more than 520 bytes you need to wrap the push in an IF/ENDIF so it's\n\u003e not executed. But in this example we're just talking about 64 bytes, so that\n\u003e limit isn't relevant and OpPush \u003cdata\u003e OpDrop should be sufficient.\n\u003e\n\u003e Specifically for more than 520 bytes you run into the the\n\u003e MAX_SCRIPT_ELEMENT_SIZE check in script/interpreter.cpp, which applies to all\n\u003e scripts regardless of standardness at script execution:\n\u003e\n\u003e //\n\u003e // Read instruction\n\u003e //\n\u003e if (!script.GetOp(pc, opcode, vchPushValue))\n\u003e return set_error(serror, SCRIPT_ERR_BAD_OPCODE);\n\u003e if (vchPushValue.size() \u003e MAX_SCRIPT_ELEMENT_SIZE)\n\u003e return set_error(serror, SCRIPT_ERR_PUSH_SIZE);\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-- \nSophia-Antipolis, France\nCV: https://www.peersm.com/CVAV.pdf\nLinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26\nGitHub : https://www.github.com/Ayms\nA Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7\nA bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7\nMove your coins by yourself (browser version): https://peersm.com/wallet\nBitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions\ntorrent-live: https://github.com/Ayms/torrent-live\nnode-Tor : https://www.github.com/Ayms/node-Tor\nAnti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com\nPeersm : http://www.peersm.com\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/13100de1/attachment.html\u003e",
"sig": "4a3ebae72145c2aef17b4375c29fee62aeae37b740d6fe16b6423cb665a80cfd2329b4c2e6399cb9407e4f3b03fd732ad6f87acc595e968389ddb227a00648dc"
}