<blockquote>
  <p>What was the rational for using such a large integer?</p>
</blockquote>

<p>Because Satoshi did not care about it. Bitcoin transaction serialization is not optimized for size. </p>

<blockquote>
  <p>Could this be reduced with a new block version?</p>
</blockquote>

<p>No</p>

<blockquote>
  <p>Could this be done without a hard fork?</p>
</blockquote>

<p>No. But you can implement new way to serialize data on disk and on network and encode/decode transaction contents on-the-fly. In fact nobody cares about these bytes.</p>

CC BY-SA 3.0
2017-08-14T11:11:37.007Z
2017-08-14T11:11:37.007Z
amaclin
<p>The transaction version field is a unsigned 32 bit integer. <a href="https://github.com/bitcoin/bitcoin/blob/master/src/primitives/transaction.h#L268" rel="nofollow noreferrer">[Source Code]</a> <a href="https://bitcoin.org/en/developer-guide#transactions" rel="nofollow noreferrer">[Docs]</a></p>

<p>This will allow for 0 through 4,294,967,295 (2^32 − 1) versions. So far, only versions 0, 1, 2 have been used. It seems that the amount of storage for this field is wasteful. Surely unsigned 8 bit integer would be more than enough. What was the rational for using such a large integer?</p>

<p>Could this be reduced with a new block version? Could this be done without a hard fork?</p>

<block><raw-transaction>
Why is such a large int (uint32) used for the transaction version field
Gary van der Merwe
# Why is such a large int (uint32) used for the transaction version field

(Asked by: username_0 on 2017-08-14)

The transaction version field is a unsigned 32 bit integer. [[Source Code]](https://github.com/bitcoin/bitcoin/blob/master/src/primitives/transaction.h#L268) [[Docs]](https://bitcoin.org/en/developer-guide#transactions)

This will allow for 0 through 4,294,967,295 (2^32 − 1) versions. So far, only versions 0, 1, 2 have been used. It seems that the amount of storage for this field is wasteful. Surely unsigned 8 bit integer would be more than enough. What was the rational for using such a large integer?

Could this be reduced with a new block version? Could this be done without a hard fork?

**Tags:** block, raw-transaction


---

## 1 answers

### Answer by username_1 on 2017-08-14. Score: 2

> What was the rational for using such a large integer?

Because Satoshi did not care about it. Bitcoin transaction serialization is not optimized for size.

> Could this be reduced with a new block version?

No

> Could this be done without a hard fork?

No. But you can implement new way to serialize data on disk and on network and encode/decode transaction contents on-the-fly. In fact nobody cares about these bytes.


---

