Note, PMv3 was withdrawn in favor of CashTokens (v2) in February 2022.
CHIP: Ranged Script Numbers
The Ranged Script Number (RSN) format is derived from the existing Script Number format used within the BCH VM, but it includes a prefix which allows RSN values to be safely parsed from serialized transaction messages.
After the June 1 BCH Network Discussion, the participants decided a component of the PMv3 CHIP, the Ranged Script Number (RSN) Format – should be extracted into its own specification for easier review and external referencing.
CHIP: Ranged Script Number Format is now available. The technical specification remains unchanged from its original publication (January 15, 2021), but the CHIP now includes additional supporting information and documentation of design decisions. In particular, a set of interactive examples comparing parsing of RSN and VarInt formatted numbers have been added.
(Excerpt below.)
Summary
This proposal describes the Ranged Script Number (RSN) format. The RSN format is derived from the existing Script Number format used within the BCH VM, but it includes a prefix which allows RSN values to be safely parsed from serialized transaction messages.
Deployment
This proposal is designed for deployment with CHIP: Version 3 Transaction Format (PMv3).
Motivation
Many advanced BCH contracts inspect and validate the contents of transactions, and even if native introspection operations are introduced, contracts which inspect the contents of parent transactions will still need the ability to safely parse serialized transactions.
Bitcoin Cash transactions use 4 different formats for representing integers – Uint32, Uint64, VarInt, and Script Number (used within Unlocking Bytecode and Locking Bytecode). The OP_BIN2NUM and OP_NUM2BIN operations allow conversion between VM integers (Script Numbers) and unsigned integers, but the VarInt format remains unaddressed. 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.
Additionally, existing transaction integer formats are inefficient: the specified Ranged Script Number format saves ~12 bytes for small transactions and ~3 additional bytes per input/output.
Benefits
By offering compatibility with the existing BCH VM Script Number format, the Ranged Script Number format simplifies contracts, reduces transaction sizes, and enables future upgrades.
Simplifies In-Contract Parsing
Because RSN is directly compatible with Script Numbers for values below 128, many use cases with fixed or capped integer requirements will require no parsing at all. Input counts, output counts, outpoint indexes, and bytecode lengths below 128 can be treated as standard Script Numbers.
For variable number ranges, all parsing can safely be accomplished using a single 11-byte macro, rather than the minimum 29-byte macro required of VarInt in most cases. (Note, the safe, fully-equivalent VarInt macro is 53-bytes.) This simplification is notable enough to enable use cases which would otherwise be inhibited by parsing constructions causing contracts to exceed VM limits.
Allows for Future Expansion
RSN is a positive integer format which is compatible with a signed integer format (Script Numbers), so it can make use of a range of unused values (the negative range of Script Numbers). This unused range is valuable both for implementing non-disruptive future upgrades (like fractional satoshis) and for off-chain signing and proof-of-ownership applications.
Reduces Transaction Sizes
By eliminating waste from fixed-size encoding formats, the RSN format could save ~3.6% of blockchain space.
The RSN format is derived from the existing Script Number format used within the BCH VM, but it includes a prefix which allows RSN values to be safely parsed from serialized transaction messages.