{"type":"rich","version":"1.0","author_name":"npub1k4rlc2efxduexgkt7dd9fjva0wrayv88mwewftnzmurleznnx9ssssfa2f","author_url":"https://nostr.ae/npub1k4rlc2efxduexgkt7dd9fjva0wrayv88mwewftnzmurleznnx9ssssfa2f","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-11-16\n📝 Original message:Hi,\n\nThe data that can be embedded as part of an OP_RETURN output is currently\nlimited to 40 bytes. It was initially supposed to be 80 bytes, but got\nreduced to 40 before the 0.9 release to err on the side of caution.\n\nAfter 9 months, it seems OP_RETURN did not lead to a blockchain\ncatastrophe, so I think it might be time to discuss increasing the limit.\n\nThere are a number of proposals:\n\n   1. Allow two OP_RETURN outputs per transaction (PR\n   \u003chttps://github.com/bitcoin/bitcoin/pull/5075\u003e)\n   2. Increase the default maximum payload size from 40 bytes to 80 bytes (\n   PR \u003chttps://github.com/bitcoin/bitcoin/pull/5286\u003e)\n   Note that the maximum can be configured already through the\n   'datacarriersize' option - this is just changing the default.\n   3. Make the maximum OP_RETURN payload size proportional to the number of\n   outputs of the transaction\n   4. A combination of the above\n\n3 sounds the most interesting, and 2 would be the second best.\n\n1 is also good to have as long as the \"space budget\" is shared between the\ntwo outputs.\n\nCan we discuss this and agree on a plan?\n\nThanks,\nFlavien\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141116/91741296/attachment.html\u003e"}