CHIP 2021-01 Ranged Script Numbers

After the June 1 BCH network discussion, we decided to extract the Ranged Script Numbers component of the PMv3 CHIP into a separate CHIP to make it a bit easier to both review and reference externally. Just posting this thread for focused discussion on this “sub-CHIP”:

Feedback and reviews are appreciated, both here on BCR and on GitHub issues. Thanks!

3 Likes

Arguments laid out here hold for RSNs too: they would break the TX format.

Since main motivation is to make it easier to poke around raw TX data when it is used as proof, to extract some contract’s parent numerical state, again we have the same problem: implementation costs would spread to the whole ecosystem, while only those building something with unforgeable covenant contracts would reap the benefits.

@cculianu I will quote some of our chat from #dev-general :smiley:

hmm that feels so hacky though… like there must be a better way (with new sophisticated deeper introspection-like-opcodes). and seriously adding RSN would cause so much breakage unnecessarily for everybody – all to bring some value to a specialized case that is not of general interest to all.

seriously we’ll give you all the op-codes you need. OP_HAX_7 whatever…

Instead, we can contain the costs to node software by introducing 2 opcodes to unwrap VarInts, like OP_VAR2NUM that’d pop 1 element from the stack, interpret it as VarInt, and push the matching script number. OP_NUM2VAR would do the opposite. At least start from there and see how to address the problem @bitjson has identified with that:

Because VarInt is variable-width, a simple OP_VARINT2NUM and OP_NUM2VARINT solution wouldn’t fully address the issue either: many contracts need to be able to safely parse a number from within a longer item on the stack.

If that is the problem, then couldn’t the OP_VAR2NUM be made to work like this: pop 2 items from the stack. The first one will be interpreted as the 1st byte of a VarInt, and read the bytes from the 2nd item. Push the number and 2nd stack item’s “change” bytes if there were extra bytes after the number.