More compact transactions layout

[castarco]

Currently, the way individual transactions are encoded is quite similar to what's done in Bitcoin ( https://en.bitcoin.it/wiki/Protocol_documentation#tx ), but we have the possibility to save some bytes per transaction. The impact wouldn't be very big since a big chunk of the transactions' size correspond to the script, but it's still worth to consider it.

Smaller OutPoint indexes

In the case of the tx_in "fields", we could save between 3 and 2 bytes per OutPoint, using a varint instead of using a 4-bytes integer to denote the prevout index (which will be usually small).

Shortened transaction's input hashes

There's also a more aggressive optimization that could be performed on the tx_in "fields": shortening the hash component of the OutPoint (we could discuss about how much to shorten it), relying on the fact that the hash will refer with high probability to some tx in the UTXO set.

To protect against conflicts between transactions sharing the same prefix, a small cryptographic checksum could be appended to the tx layout (of course, shorter than what we removed from the former hash), so it would be possible to easily resolve the conflict.

In case of multiple inputs, only one checksum would be needed for the whole transaction, decreasing its impact on the tx's size.

An extra potential benefit of having a per-transaction checksum is increasing overall resilience towards sporadic network failures causing data corruption.

[castarco]

There's another possibility: referring to a tuple: (block_height, tx_index, output_idx) , we could check what's more compact. I'm not sure about the security implications though, just posted it to avoid forgetting about.

A reference to where I saw the idea: https://medium.com/@g.andrew.stone/transaction-input-size-optimization-152cdad1b76f