actorforth / auction-protocol Goto Github PK

It has come to my attention that there are wallets that are or want to use OP_RETURN based protocols and that there might be issues or difficulties to understand in relation to their implementations.

We should reach out to the known wallets and ask them what their feedback is.

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/

It has come to my attention, that merge-mining miners are one stakeholder to consider.

We should look into what merged miners exist, and reach out to them.

https://github.com/ActorForth/Auction-Protocol/blob/main/CHIP-2021-03-12_Multiple_OP_RETURN_for_Bitcoin_Cash.md#specification

You can use other push opcodes, e.g. OP_PUSH_X with 0x01 - 0x75

Example:

OP_RETURN OP_PUSH_32 <data>
6a 20 <data>

so you save a byte of overhead and can store a max. of 221 bytes.

Without the change to counting the op_return bytes in aggregate, a change in the maximum bytes allowed in an op_return output would remain the same as long as there is only a single op_return in a transaction.

If the restriction of a single op_return would be dropped from standardness but the size limit would remain, then a user could create a transaction with a large number of op_returns, effectively rendering the byte limitation ineffecient.

If multiple opreturns were to be allowed but in a limited number, then the byte limitation would become a multiple of that allowed number of opreturns, which would make entangle the byte limitation with the opreturn count limitation. In such a case, changing the byte limit would inadvertently get amplified.

Take for example, a change that would set the allowed number of opreturns to 64. Not an entirely unreasonable number, but after that change any increases or decreases to the opreturn byte limitation would be amplified to the point where selecting an intended targer number for total storage bytes, might no difficult. For example, the current size of 224b is not evenly divisible by 64 and would not be a candidate.

In short, assuming that Bitcoin Cash does allow multiple op_returns, the following outcomes can be observed: