doc: update OP_RETURN size notes #23
Conversation
✅ Deploy Preview for timely-chimera-eba3bb ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Hi, thanks for taking a look and contributing! As written, I'm not sure I understand your sentence well. Moreover, when I look it up I find that the maximum size of the data is not (even by consensus rules as far as I can tell) upper-bounded by the block weight limit.
What do you think of the following: - By default, relay policy limits OP_RETURN data to 80 bytes (this means that under standardness rules`OP_RETURN` can be at most 83 bytes: 1 byte for the opcode, 1-2 bytes for the data push, and 80 bytes of data).
- Ignoring policy (for example if a miner includes the transaction directly), consensus limits still apply: each pushed element must be ≤ 520 bytes, and the entire `OP_RETURN` script (scriptPubKey) must be ≤ 10,000 bytes.I also propose we wait for v30 to come out and can adjust the docs with the correct verbiage then before merging. |
|
Maybe the sentence is not really well written :) "By default" is a complicated affirmation because it's only the default on Bitcoin Core < v30.0. It's not the default for other implementations (Like Knots who has 43bytes limit, I think). I guess using the "default" word will depend if you want the page to be implementation agnostic. On the other side, I'm not sure on how this 10k bytes limit on ScripPubKeys is applied. See this tx with an OP_RETURN with 79,870 bytes. (Will replay to sipa and ask clarification about that :) ) Update: I found an answer. The ScriptPubKey limit only affects to spendable outputs, so it doesn't to OP_RETURN. The max consensus limit is the block size. See |
The maximum size notes were a bit "wrong" or not well defined as it was limited by policy rules and op_return > 80bytes data were valid even with the standarness rule...
This PR updates the limits to consensus rules and defines the policy rules that affects OP_RETURN after core v30.