What if the blockchain saved space by trimming input txs on each transaction?

Question

At each block there is a determined set of unspent transaction outputs. Each new transaction specifies the unspent outputs it's going to spend in the format tx_id:output_index. tx_id is 32 bytes.

If at any point in time an unspent output has tx_id = cb7f357d7034f93b89a227c2109182740f1798f5a006e9cd0930a380c06aca7e and no other unspent output has a tx_id with prefix cb7f35 a new transaction could reference only cb7f35 and everything would still be exactly determined.

Prefix sizes could be adjustable.

If there were more than one unspent transactions with the same tx_id at each point any mempool transaction trying to spend from an ambiguous prefix would become invalid and a new one with a bigger prefix would have to be issued.

This could save up to 5GB of disk space in an year according to my stupid naïve math.

This could be implemented either:

1. In the raw Bitcoin protocol, so the canonical blocks would have only prefixes;
2. As a way to "compact" stored blockchain data without using fancy compression algorithms and without losing the data structure.

So, considering the two potential usages above and not mentioning that this is not doable without a hard-fork (therefore impossible); that is is silly; that disk space is not the biggest bottleneck; and that it isn't worth doing due to practicality and low cost-benefit, why is this a bad idea?

Answer 1

I see two problems here:
First problem is collision, since you chose only 24 bit out of 256 bit. You'll have to use a much bigger short form to mitigate that, so the big space you saved is now a lot smaller.

Second problem is when you have to convert the short form to the long form. Lets say you stored the outpoint of the tx as cb7f35:index, now another node wants the block containing this tx. To reply, you have to construct this outpoint in its long form first. The only way to do that is to go through the entire history and find the long txid cb7f357d7034f93b89a227c2109182740f1798f5a006e9cd0930a380c06aca7e and send that. That process takes a lot of time, you could however index the blockchain based on txids but then you'll need an extra space to store the index that negates the space you saved.
You could not communicate with the network (don't relay blocks) to avoid all that, but why store the blockchain in first place? A better solution would be "pruning" it.