Add evaluation of alternative proposals

[monsterbitar]

There has been other proposals for how to get OP_RETURN interoperability / multiple op_returns. The evaluation section of the multiple op_return chip should be expanded with an evaluation of these proposals and short explanation of their shortcomings / reason for why their respective solution is not more desirable than this chip:

• https://bitco.in/forum/threads/buip149-delimited-op_returns.26362/
• https://bitco.in/forum/threads/buip139-multiple-op_return-with-less-rules.24951/
• https://bitco.in/forum/threads/buip140-multiple-op_return-with-shared-size-limit.24952/

[scherrey]

Have updated the CHIP with references and analysis of these 3 proposals. Let me know if you would like to revise/extend.

[monsterbitar]

I think you have misread/misunderstood 140.

140 states:

replace the standardness rule that enforces a maximum of one OP_RETURN output per transaction

with

a rule that instead enforces a total OP_RETURN size across all OP_RETURN outputs in a transaction

I thought 140 is what your chip was actually based on, but it seems you haven't read my proposals before I linked them to you here?

[monsterbitar]

Based on discussion elsewhere, I think one reason why BUIP139 should be considered inferior is because it makes it more difficult to change the op_return max bytes in the future, as it would magnify the impact, for example:

If BUIP139 took place, and was set to 4 op_returns / transaction, then if we want to change the bytesize it now has to be an even number of 4. If we naively increase by 10 bytes, then a total of 40 more bytes can be used, rather than the 10 byte intended.

[scherrey]

Thanks - good catch on 140 - I did mis-read that. Have corrected that and updated the critique of 139 in the CHIP.