castarco
commented
5 years ago 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
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 perOutPoint, using avarintinstead 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 theOutPoint(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.