Do not split runestone payload into MAX_SCRIPT_ELEMENT_SIZE pushes

[casey]

I believe the MAX_SCRIPT_ELEMENT_SIZE limit is only checked when outputs are spent. Since runestones begin with an OP_RETURN, they can never be spent, so we do not need to chunk the payload.

It's unfortunate that I'm only realizing this now, since if I had known it earlier, we could have required the payload to be a single data push, since without the MAX_SCRIPT_ELEMENT_SIZE limit, there's no reason to accept multiple data pushes in the payload.

This is marked as a draft PR, because although I think it's correct, I want to actually test it against Bitcoin Core to confirm before merging.

[casey]

Confirmed this locally with a split which generated a 4550 byte OP_RETURN. OP_RETURNS are totally uninterpreted and unexecuted. The script does not even need to be valid, and the script element size of 520 byte is unchecked.

[raphjaph]

LGTM

[gmart7t2]

I believe the MAX_SCRIPT_ELEMENT_SIZE limit is only checked when outputs are spent

I can confirm that.

I had to change MAX_OP_RETURN_RELAY to get sendrawtransaction to accept an OP_RETURN longer than 83 bytes but that's the only change I had to make. Then I was able to create a 200 edict runestone with a 874 byte OP_PUSHDATA2:

$ bitcoin-cli -regtest getrawtransaction a6c3de3d9b9fb0f849816e7127987aef4e7245af0a041f1feebde089ea5481dc 1 | jq -r .vout[0].scriptPubKey.hex
6a5d4d6a0300c5090164000000640100006402000064030000640400006405000064060000640700006408000064090000640a0000640b0000640c0000640d0000640e0000640f000064100000641100006412000064130000641400006415000064160000641700006418000064190000641a0000641b0000641c0000641d0000641e0000641f000064200000642100006422000064230000642400006425000064260000642700006428000064290000642a0000642b0000642c0000642d0000642e0000642f000064300000643100006432000064330000643400006435000064360000643700006438000064390000643a0000643b0000643c0000643d0000643e0000643f000064400000644100006442000064430000644400006445000064460000644700006448000064490000644a0000644b0000644c0000644d0000644e0000644f000064500000645100006452000064530000645400006455000064560000645700006458000064590000645a0000645b0000645c0000645d0000645e0000645f000064600000646100006462000064630000646400006465000064660000646700006468000064690000646a0000646b0000646c0000646d0000646e0000646f000064700000647100006472000064730000647400006475000064760000647700006478000064790000647a0000647b0000647c0000647d0000647e0000647f00006480010000648101000064820100006483010000648401000064850100006486010000648701000064880100006489010000648a010000648b010000648c010000648d010000648e010000648f0100006490010000649101000064920100006493010000649401000064950100006496010000649701000064980100006499010000649a010000649b010000649c010000649d010000649e010000649f01000064a001000064a101000064a201000064a301000064a401000064a501000064a601000064a701000064a801000064a901000064aa01000064ab01000064ac01000064ad01000064ae01000064af01000064b001000064b101000064b201000064b301000064b401000064b501000064b601000064b701000064b801000064b901000064ba01000064bb01000064bc01000064bd01000064be01000064bf01000064c001000064c101000064c201000064c301000064c401000064c501000064c601000064c701
$ python
>>> 1748/2
874.0
>>> 0x036a
874

That's 6a (op_return) 5d (op_13) 4d (op_pushdata2) 6a03 (874 bytes) ...

[casey]

Nice, thanks for confirming! I did too, but always nice to double check, since it would be catastrophic if I fucked this one up.