<oembed><type>rich</type><version>1.0</version><author_name>npub1k4rlc2efxduexgkt7dd9fjva0wrayv88mwewftnzmurleznnx9ssssfa2f</author_name><author_url>https://nostr.ae/npub1k4rlc2efxduexgkt7dd9fjva0wrayv88mwewftnzmurleznnx9ssssfa2f</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2014-11-16&#xA;📝 Original message:Hi,&#xA;&#xA;The data that can be embedded as part of an OP_RETURN output is currently&#xA;limited to 40 bytes. It was initially supposed to be 80 bytes, but got&#xA;reduced to 40 before the 0.9 release to err on the side of caution.&#xA;&#xA;After 9 months, it seems OP_RETURN did not lead to a blockchain&#xA;catastrophe, so I think it might be time to discuss increasing the limit.&#xA;&#xA;There are a number of proposals:&#xA;&#xA;   1. Allow two OP_RETURN outputs per transaction (PR&#xA;   &lt;https://github.com/bitcoin/bitcoin/pull/5075&gt;)&#xA;   2. Increase the default maximum payload size from 40 bytes to 80 bytes (&#xA;   PR &lt;https://github.com/bitcoin/bitcoin/pull/5286&gt;)&#xA;   Note that the maximum can be configured already through the&#xA;   &#39;datacarriersize&#39; option - this is just changing the default.&#xA;   3. Make the maximum OP_RETURN payload size proportional to the number of&#xA;   outputs of the transaction&#xA;   4. A combination of the above&#xA;&#xA;3 sounds the most interesting, and 2 would be the second best.&#xA;&#xA;1 is also good to have as long as the &#34;space budget&#34; is shared between the&#xA;two outputs.&#xA;&#xA;Can we discuss this and agree on a plan?&#xA;&#xA;Thanks,&#xA;Flavien&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141116/91741296/attachment.html&gt;</html></oembed>