Why is the value field 8 bytes in transaction output when it can be achieved with 7 bytes?

Bitcoin uses a 8 bytes value field in the transaction output. However, the total supply of bitcoin is capped at 21M. Theoretically, even if all the 21M bitcoins are transferred to a single address, the output, after converting to satoshis, can be effectively represented with 7 bytes of data. This means, we are adding at least 2 bytes of redundant data (one for the spend address and other for change address) for every transaction stored in the blockchain. Is there a particular reason why a size of 8 bytes was chosen or was this a design flaw that was overlooked by Satoshi? Is it possible to bring a change to this via a soft-fork or does changing this require a hard-fork?

Ugam Kamat

Posted 2019-04-16T12:03:36.207

Reputation: 5 180

Answers

Is there a particular reason why a size of 8 bytes was chosen

Probably not.

In the original Bitcoin source code, many of the primitives used in data structures were simply the in-memory representations of those primitives. For integers, this is a 32 bit (4 byte) little endian integer. However 32 bits is not enough to represent all of the satoshis that exist in Bitcoin. The next primitive that can be used is a long, aka a 64 bit integer. Since this was just serialized as it is represented in memory, the amounts end up being 64 bit little endian values.

Is it possible to bring a change to this via a soft-fork or does changing this require a hard-fork?

The serialiation format used for computing the weight and hashes can only be changed via a hard fork.

However you can transmit a transaction using whatever serialization you want so long as that format contains all of the necessary information to construct the serialization necessary for computing weight and hash. This would not require any fork because it is not a consensus change.

Andrew Chow

Posted 2019-04-16T12:03:36.207

Reputation: 40 910

-1

Yes, transaction format has unused bytes. One other example is encoding utxo index in four bytes. Nobody cares. We can not change the format without hard-fork. And we do not want to do it. Live with it.

amaclin

Posted 2019-04-16T12:03:36.207

Reputation: 5 763

I disagree on UTXO. 1MB block limit was sneaked in later by Satoshi in July 2010. So before that you could have had number of outputs. So the number of outputs that could have been possible would be capped by the 4 bytes of vout index. – Ugam Kamat – 2019-04-16T16:10:35.850

1I disagree that we don't care, or can't change it without a hard fork. It's trivial to design more efficient ways to store and communicate transactions and blocks; only the data fed to hash functions for txids and other commitments needs to remain consistent without forking. – Pieter Wuille – 2019-04-16T17:03:20.567

@PieterWuille If you change the output value size to 7 bytes, won't the nodes that are running an older version of Bitcoin Core consider those transactions as invalid, resulting in a fork? – Ugam Kamat – 2019-04-16T17:48:16.310

1@UgamKamat You'd just negotiate a newer protocol version in which the 8th byte is gone. This protocol would only be used between two peers which support it. It's important to realize that while transactions and blocks are often thought of a bytes, they're really just abstract structures, and you can encode them anyway you like - as long as all participants in the communication can still compute the correct hashes (which are defined in terms of one particular serialization). – Pieter Wuille – 2019-04-16T18:14:04.787

@PieterWuille That was a good explanation as to how we can reduce it to 7 bytes. Is reducing redundant sizes on the roster in future releases? We can reduce a good percentage of the blockchain size going forward. – Ugam Kamat – 2019-04-16T18:39:42.603

3@UgamKamat There are many more redundancies in the protocol (sizes, DER encoding for sigs, predictable locktimes and sequence numbers, standard script templates, redundant scripts in P2SH-wrapper segwit spends, ...), which could be avoided using a specialized compression scheme. I have done some work on this, but it's not very high priority. Also, it's mostly a bandwidth savings; if the blockchain size is an issue, just run a pruning node. – Pieter Wuille – 2019-04-16T18:47:38.940