Specification

Integers are encoded big-endian according to the following table:

Range Binary encoding
0 .. 0x7f 0xxxxxxx
0x80 .. 0x3fff 10xxxxxx xxxxxxxx
0x4000 .. 0x1f'ffff 110xxxxx xxxxxxxx xxxxxxxx
0x20'0000 .. 0xfff'ffff 1110xxxx xxxxxxxx xxxxxxxx xxxxxxxx
0x1000'0000 .. 0x7'ffff'ffff 11110xxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
0x8'0000'0000 .. 0x3ff'ffff'ffff 111110xx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
0x400'0000'0000 .. 0x1'ffff'ffff'ffff 1111110x xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
0x2'0000'0000'0000 .. 0xff'ffff'ffff'ffff 11111110 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
0x100'0000'0000'0000 .. 0xffff'ffff'ffff'ffff 11111111 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx

Rationale

To minimize bandwidth requirements of eCash, it is advisable to encode integers in transactions more efficiently.

Also, having one integer encoding for transactions simplifies the system. Currently, Bitcoin transactions use two different types of integers:

Fixed-size integers are the least efficient, as they always require the given number of bytes. VARINT integers are more efficient, but are still not as good as the new encoding here.

An exploration of existing encodings can be found here:

2017-01-08 Variable size integer encoding

A survey on different encodings, especially between the current format, all VARINT, and all MitraInt can be found here:

A video discussing the integer encoding (and other things) can be found here: https://www.youtube.com/watch?v=vWvv_G2AOPA

All in all, space-savings of around 3.7% are achieved with this new encoding for a representative sample, which is significant enough to warrant this change.