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 |
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.