there's a lot of other "wasting room" on the transaction, and the most important one to me is the hash of 256 bits indicating the transaction. This is overkill. There is also the 32-bit number indicating the "output number of the transaction" as if transactions would contain 4 billion outputs. This is wasted space.
You are free to store transactions however you like and negoiate with your peers to send them however you like, there is no need for space to be wasted as a product of serialization. Using a larger hash does take up more resources but the difference is pretty small compared to the rest of the transaction.
Well, the room for a full "transaction cycle" consists the room taken for the output on the transaction that has the UTXO, and the corresponding room for the input in the transaction that spends it. When you look at it, this mainly consists of:
- output amount 8 bytes
- output script, about 25 bytes, of which 20 bytes are the output address (output)
- transaction hash (32 bytes) of the previous output transaction (input)
- output number of this transaction (4 bytes) (input)
- scriptsig, containing the signature (~64 bytes) AND the pubkey (also, old version ~64 bytes, compact version ~32 bytes)
- 4 bytes "sequence number"
Total usage: about 169 bytes (in compact format)
Of these, 32 bytes (the pub key) are redundant, because one can restore the pub key from the signature and the message.
But:
If an address was only used once, then the transaction hash, and the output number are also redundant (one can find them), and we would save still 36 bytes more. As such, in the most compact form, if addresses were used only once, we would save 68 bytes out of 169.
However, the initial argument was that reducing the address from potentially 256 bits to 160 bits "to save space" cannot be correct, because of the wasteful usage of 256 bits of the transaction hash, and 32 bits of the output indication. If bits were considered expensive, this is where one wasted many of them.
There's no fundamental reason to have more indications of transactions than of addresses for instance, and 32 bits for the output are also overkill. 8 bits would be sufficient I'd think. Transactions with more than 256 outputs are not very common.