<p>By compressing the txids to a shorter fingerprint, you're reducing the unique identifiability. For example, there are three transactions that match the prefix <code>eb36eca</code>: <a href="https://www.smartbit.com.au/tx/eb36eca8deea32c8109825bd3d2e0870fc0aee9288657becbf00c00ea603aca8" rel="nofollow noreferrer">tx1</a>, <a href="https://www.smartbit.com.au/tx/eb36eca8deea32c8109825bd3d2e0870fc0aee9288657becbf00c00ea603aca8" rel="nofollow noreferrer">tx2</a>, <a href="https://www.smartbit.com.au/tx/eb36eca9a06fbe68278ad3e7d16d10ed02e22ad891ed59ef2b84ed4a49e8a6d2" rel="nofollow noreferrer">tx3</a>.</p>

<p>So, essentially, this is creating a combinatorics puzzle, especially considering that the txid is only part of the outpoint, you also have to add the output, otherwise you could be referring e.g. to any of the 51 outputs of the above tx3.</p>

<p>It seems to me that this would make it more complicated to operate thin clients safely, which don't have the complete UTXO Set at their disposal. For relay, similar compressions are already used, but while a such a system might be possible to implement for blockchain data, I'm not sure if the overall effect would be desirable.</p>

CC BY-SA 3.0
2018-04-21T00:17:04.997Z
2018-04-21T00:17:04.997Z
Murch
<p>Murch's "combinatorics puzzle" is a good point.  Indeed, it seems to me that it leads to a pretty disastrous denial-of-service attack.</p>

<p>I can certainly create a transaction whose 7-nibble prefix is whatever I desire, just by brute force: for instance, put some random data in an OP_RETURN output and tweak it until I get a prefix I like.  It needs 2^28 tries on average, about 256 million.  So let me make 200 transactions, all with prefix 1234567.  That needs about 40 billion operations - the work of a couple hours for a decent GPU.  If I put a nice little fee in each one, at current rates, it might cost about US$2000 to get them all confirmed.</p>

<p>Now I choose 100 of them at random and create a transaction spending all of them as inputs.   In order to check if my transaction is valid, you are going to need to start trying every possible combination of 100 out of the 200 possibilities, until you find the right ones.  <code>C(200,100)</code> is about 10^59.  Good luck getting through that before the sun goes out.</p>

<p>So I can, relatively cheaply, bring the entire Bitcoin network to its knees, as every node works on the impossible problem of figuring out which 100 transactions I spent.</p>

<p>You're going to have to put in some safeguard to say that if a matching set of transactions can't be found relatively fast, the transaction is just rejected.  But your rule has to be deterministic; if some nodes find a match and others don't, they'll disagree on the validity of the transaction -> hard fork.  It's not so clear what that would look like.  And it also raises the possibility that I could intentionally create collisions with an existing transaction belonging to my enemy, and render it unspendable.</p>

<p>In short, this would not be an easy thing to do safely, and risks disaster for the currency if you don't get it exactly right.  Seems much safer to keep it simple, even at the cost of efficiency.</p>

CC BY-SA 3.0
2018-04-21T15:14:57.627Z
after this question I started wondering what would be the problems of simply pointing to a block id + transaction index in that block. Seems like some coins do that. I don't see any problem. Why it is the way it is in bitcoin?
PPP
CC BY-SA 3.0
2018-04-21T15:37:55.917Z
In that case, how do you spend a transaction which is not yet confirmed?  You don't know what block it will go in.  Anyway, this wouldn't help with your idea, because a block ID is the same length as a transaction ID (they are both 256-bit hashes).
Nate Eldredge
CC BY-SA 3.0
2018-04-21T15:59:22.987Z
I don't need to specify the block ID, just its index in the blockchain, that's what I meant.
PPP
CC BY-SA 3.0
2018-04-21T20:30:03.183Z
Transactions are only part of the blockchain as soon as they are part of a block.
Murch
CC BY-SA 3.0
2018-04-21T03:12:09.830Z
2018-04-21T03:12:09.830Z
Nate Eldredge
<p>Suppose I want to spend from 3 unspent outputs. I must reference the txid of these unspent outputs. Suppose they are:</p>

<pre><code>eb36eca9a06fbe68278ad3e7d16d10ed02e22ad891ed59ef2b84ed4a49e8a6d2

e912d1d29c2daa30cee47a89329426d254aa1ca59927b2d2ae0a2c561a30c4ad

aec43a6a925e55a4f5aa3fdfa2df308912ae06636a7c92b2e19ba55e7d7fc689
</code></pre>

<p>Instead of pointing to the entire txids, couldn't I point to just like the first 7 digits of each, so it'd be <code>eb36eca</code>, <code>e912d1d</code>, <code>aec43a6</code>?</p>

<p>Of course, it's easy to generate a txid that matches just the 7 first digits of each of the used txids. But <strong>what if</strong> we also included the information that, once you find these 3 txids in the database that start with <code>eb36eca</code>, <code>e912d1d</code> and <code>aec43a6</code>, the hash of these 3 entire txids must be equal     <code>hash(eb36eca9a06fbe68278ad3e7d16d10ed02e22ad891ed59ef2b84ed4a49e8a6d2 + e912d1d29c2daa30cee47a89329426d254aa1ca59927b2d2ae0a2c561a30c4ad + aec43a6a925e55a4f5aa3fdfa2df308912ae06636a7c92b2e19ba55e7d7fc689)</code> (where + here is concatenation). </p>

<p>So instead of including all 3 txids, we just include the first <strong>n</strong> digits of each <strong>and</strong> the hash of these 3 txids concatenated. </p>

<p>Wouldn't it free a lot of space? It's just one hash + <code>n*k</code>, being <code>n</code> the number of first digits, and <code>k</code> the number of inputs.</p>

<p>Also, wouldn't Schnorr signatures make it possible to sign all these outputs with just 1 signature? Wouldn't it make all transactions have almost the same size? Today, each new output adds to the transaction size at least: it txid and signature, which are the biggest parts.  </p>

CC BY-SA 3.0
2017-12-25T06:01:19.910Z
Related to schnorr suggestion: https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
meshcollider
CC BY-SA 3.0
2017-12-25T22:12:41.707Z
Signatures are per input, not per output.
Pieter Wuille
<transactions><hash><script>
Why we must reference the entire txid for each output we want to spend?
PPP
# Why we must reference the entire txid for each output we want to spend?

(Asked by: username_0 on 2017-12-25)

Suppose I want to spend from 3 unspent outputs. I must reference the txid of these unspent outputs. Suppose they are:

```
eb36eca9a06fbe68278ad3e7d16d10ed02e22ad891ed59ef2b84ed4a49e8a6d2

e912d1d29c2daa30cee47a89329426d254aa1ca59927b2d2ae0a2c561a30c4ad

aec43a6a925e55a4f5aa3fdfa2df308912ae06636a7c92b2e19ba55e7d7fc689

```

Instead of pointing to the entire txids, couldn't I point to just like the first 7 digits of each, so it'd be `eb36eca`, `e912d1d`, `aec43a6`?

Of course, it's easy to generate a txid that matches just the 7 first digits of each of the used txids. But **what if** we also included the information that, once you find these 3 txids in the database that start with `eb36eca`, `e912d1d` and `aec43a6`, the hash of these 3 entire txids must be equal `hash(eb36eca9a06fbe68278ad3e7d16d10ed02e22ad891ed59ef2b84ed4a49e8a6d2 + e912d1d29c2daa30cee47a89329426d254aa1ca59927b2d2ae0a2c561a30c4ad + aec43a6a925e55a4f5aa3fdfa2df308912ae06636a7c92b2e19ba55e7d7fc689)` (where + here is concatenation).

So instead of including all 3 txids, we just include the first **n** digits of each **and** the hash of these 3 txids concatenated.

Wouldn't it free a lot of space? It's just one hash + `n*k`, being `n` the number of first digits, and `k` the number of inputs.

Also, wouldn't Schnorr signatures make it possible to sign all these outputs with just 1 signature? Wouldn't it make all transactions have almost the same size? Today, each new output adds to the transaction size at least: it txid and signature, which are the biggest parts.

**Tags:** transactions, hash, script

> **Comments:**
> **username_1**: Related to schnorr suggestion: https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/  
> **username_2**: Signatures are per input, not per output.  

---

## 2 answers

### Answer by username_3 on 2018-04-21. Score: 1 | Accepted answer

By compressing the txids to a shorter fingerprint, you're reducing the unique identifiability. For example, there are three transactions that match the prefix `eb36eca`: [tx1](https://www.smartbit.com.au/tx/eb36eca8deea32c8109825bd3d2e0870fc0aee9288657becbf00c00ea603aca8), [tx2](https://www.smartbit.com.au/tx/eb36eca8deea32c8109825bd3d2e0870fc0aee9288657becbf00c00ea603aca8), [tx3](https://www.smartbit.com.au/tx/eb36eca9a06fbe68278ad3e7d16d10ed02e22ad891ed59ef2b84ed4a49e8a6d2).

So, essentially, this is creating a combinatorics puzzle, especially considering that the txid is only part of the outpoint, you also have to add the output, otherwise you could be referring e.g. to any of the 51 outputs of the above tx3.

It seems to me that this would make it more complicated to operate thin clients safely, which don't have the complete UTXO Set at their disposal. For relay, similar compressions are already used, but while a such a system might be possible to implement for blockchain data, I'm not sure if the overall effect would be desirable.


---

### Answer by username_4 on 2018-04-21. Score: 1

username_3's "combinatorics puzzle" is a good point. Indeed, it seems to me that it leads to a pretty disastrous denial-of-service attack.

I can certainly create a transaction whose 7-nibble prefix is whatever I desire, just by brute force: for instance, put some random data in an OP\_RETURN output and tweak it until I get a prefix I like. It needs 2^28 tries on average, about 256 million. So let me make 200 transactions, all with prefix 1234567. That needs about 40 billion operations - the work of a couple hours for a decent GPU. If I put a nice little fee in each one, at current rates, it might cost about US$2000 to get them all confirmed.

Now I choose 100 of them at random and create a transaction spending all of them as inputs. In order to check if my transaction is valid, you are going to need to start trying every possible combination of 100 out of the 200 possibilities, until you find the right ones. `C(200,100)` is about 10^59. Good luck getting through that before the sun goes out.

So I can, relatively cheaply, bring the entire Bitcoin network to its knees, as every node works on the impossible problem of figuring out which 100 transactions I spent.

You're going to have to put in some safeguard to say that if a matching set of transactions can't be found relatively fast, the transaction is just rejected. But your rule has to be deterministic; if some nodes find a match and others don't, they'll disagree on the validity of the transaction -> hard fork. It's not so clear what that would look like. And it also raises the possibility that I could intentionally create collisions with an existing transaction belonging to my enemy, and render it unspendable.

In short, this would not be an easy thing to do safely, and risks disaster for the currency if you don't get it exactly right. Seems much safer to keep it simple, even at the cost of efficiency.

> **Comments:**
> **username_0**: after this question I started wondering what would be the problems of simply pointing to a block id + transaction index in that block. Seems like some coins do that. I don't see any problem. Why it is the way it is in bitcoin?  
> **username_4**: In that case, how do you spend a transaction which is not yet confirmed?  You don't know what block it will go in.  Anyway, this wouldn't help with your idea, because a block ID is the same length as a transaction ID (they are both 256-bit hashes).  
> **username_0**: I don't need to specify the block ID, just its index in the blockchain, that's what I meant.  
> **username_3**: Transactions are only part of the blockchain as soon as they are part of a block.  

---

