CHIP 2021-01 Ranged Script Numbers

[bitjson]

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”:

bitjson/pmv3/blob/master/ranged-script-numbers.md

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

[bitcoincashautist]

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

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.

[bitjson]

Note, this CHIP (part of PMv3) was withdrawn in favor of CashTokens:

CHIP 2021-01 PMv3: Version 3 Transaction Format

Hi everyone, Over the past year, I’ve been working on a full covenant design for a long-running, prediction market sidechain on Bitcoin Cash – including an on-chain initial token sale (with continuous public buyouts), a practically-unlimited class of arbitrators (people who hold the token and are paid fees from the market), a sealed-voting, sidechain-bridging strategy, and multithreaded covenants to avoid spend-races. I’m now convinced that the problem space is well-defined enough to identify …