Author: Tobias Ruck

Introduction

An important consideration for a new transaction format is the integer encoding.

This article:

1. explains the importance of an integer encoding format,
2. proposes three different integer encoding formats,
3. measures the space required of real-world blocks on eCash,
4. gives a short list of pros/cons for each encoding,
5. and gives an opinionated conclusion.

Importance of an integer encoding format

If you’re new to this, I recommend reading Amaury’s article on this topic.

In that article, he proposes a new integer encoding for Bitcoin, which we could use for a new tx format on eCash.

Choosing the right integer encoding format for a new tx format is important for many reasons:

1. Compactness 🤏/🖐: A compact integer encoding will require less data to be stored on disk and to be transfered when sending txs
2. Simplicity 💡/🤯: A simple integer encoding is easy to implement by others, without getting edge-cases wrong
3. Readability 🤓/😵‍💫: A readable encoding means that the hex encoding has some resemblance with the actual number (in hex), which makes it easier to gloss over txs and debug them
4. Skipability

Point 1 is obviously very important. The more compact we can encode integers, the more txs we can squeeze into our blocks, and the more throughput we can get. We compare the integer encodings to general purpose compression, using the LZ4 compression algorithm, which is very fast and also reasonably compact. ZSTD

Point 2 and especially the last point might seem a bit unnecessary for a tx format, but keep in mind that Bitcoin predominantly is a social project, where getting others to join and work on it is very important.

Writing a tx parser, for example, is a cool simple task a novice could start with, and parsing integers is one of the first things one has to do for this.