<blockquote>
  <p>Is there a particular reason why a size of 8 bytes was chosen</p>
</blockquote>

<p>Probably not.</p>

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

<blockquote>
  <p>Is it possible to bring a change to this via a soft-fork or does changing this require a hard-fork?</p>
</blockquote>

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

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

CC BY-SA 4.0
2019-04-16T18:44:34.267Z
2019-04-16T18:44:34.267Z
Ava Chow
<p>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.</p>

CC BY-SA 4.0
2019-04-16T16:10:35.850Z
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
CC BY-SA 4.0
2019-04-16T17:03:20.567Z
I 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
CC BY-SA 4.0
2019-04-16T17:48:16.310Z
@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
CC BY-SA 4.0
2019-04-16T18:14:04.787Z
@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
CC BY-SA 4.0
2019-04-16T18:39:42.603Z
@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
CC BY-SA 4.0
2019-04-16T18:47:38.940Z
@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
CC BY-SA 4.0
2019-04-16T14:37:53.447Z
2019-04-16T14:37:53.447Z
amaclin
<p>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?</p>

<transactions><blockchain><output>
Why is the value field 8 bytes in transaction output when it can be achieved with 7 bytes?
Ugam Kamat
# Why is the value field 8 bytes in transaction output when it can be achieved with 7 bytes?

(Asked by: username_0 on 2019-04-16)

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?

**Tags:** transactions, blockchain, output


---

## 2 answers

### Answer by username_1 on 2019-04-16. Score: 3 | Accepted answer

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


---

### Answer by username_2 on 2019-04-16. Score: -2

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.

> **Comments:**
> **username_0**: 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.  
> **username_3**: I 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.  
> **username_0**: @username_3 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?  
> **username_3**: @username_0 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).  
> **username_0**: @username_3 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.  
> **username_3**: @username_0 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.  

---

