<p>I see two problems here:<br>
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.  </p>

<p>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 <code>cb7f35:index</code>, 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 <code>cb7f357d7034f93b89a227c2109182740f1798f5a006e9cd0930a380c06aca7e</code> 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.<br>
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 "<a href="https://bitcoin.stackexchange.com/a/37497/87716">pruning</a>" it.</p>

CC BY-SA 4.0
2019-12-10T08:38:11.447Z
2019-12-10T08:38:11.447Z
Coding Enthusiast
<p>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 <code>tx_id:output_index</code>. <code>tx_id</code> is 32 bytes.</p>

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

<p>Prefix sizes could be adjustable.</p>

<p>If there were more than one unspent transactions with the same <code>tx_id</code> 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.</p>

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

<p>This could be implemented either:</p>

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

<p>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?</p>

<blockchain><storage-footprint>
What if the blockchain saved space by trimming input txs on each transaction?
fiatjaf
# What if the blockchain saved space by trimming input txs on each transaction?

(Asked by: username_0 on 2019-12-09)

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?

**Tags:** blockchain, storage-footprint


---

## 1 answers

### Answer by username_1 on 2019-12-10. Score: 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](https://bitcoin.stackexchange.com/a/37497/87716)" it.


---

