user6610: The transaction version field is a unsigned 32 bit integer. [Source Code] [Docs]
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?

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

6610: <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>
 12983: <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>
