<p>I guess it depends on what you want to do with it. If for example you're using those 20 bytes as keys in a lookup table, then you should be fine as long as you remember you might get an occasional false positive so you always double check if it really is the transaction you were looking for. For that purpose less than 20 bytes is probably already enough.</p>

<p>If 20 bytes is everything that you store while throwing away everything else, and you make important decisions based only on those 20 bytes, then you might run into problems at some point.</p>

<p>Remember that it's not mere chance. If your application plays an important role and an attacker knows about your 20 bytes limitation, they might try to forge 2 conflicting transactions IDs to and crash your system or scam you out of some money.</p>

CC BY-SA 3.0
2015-12-21T19:15:43.343Z
Is it really possible that there is an occasional false positive? Could the attacker really forge a transaction with a sha256 with 20 customized bytes?
Nathan Parker
CC BY-SA 3.0
2015-12-21T19:25:55.083Z
I didn't do the math, but yeah seems pretty unlikely. I'd trust StephenM347's answer on that. I typed my answer before his showed up. I was just saying that it might depend on what you're trying to do (you might go lower than 20 bytes) and to keep in mind that active attackers might cause problems if you do go too low.
Jannes
CC BY-SA 3.0
2015-12-21T19:01:31.097Z
2015-12-21T19:01:31.097Z
Jannes
<blockquote>
  <p>Is it computationally feasible to find two transaction IDs with the same first 20 bytes?</p>
</blockquote>

<p>20 bytes is still 160 bits of security, which is considered very secure. If you are sure that you only need the IDs to check for existence, 20 bytes of the hashes should be fine. </p>

<p>Hard drive space is pretty cheap, though, and you might need the full TXID someday just for interoperability between other systems. So make sure 20 bytes really does satisfy your use cases. A 20 byte hash is sufficiently secure, though.</p>

CC BY-SA 3.0
2015-12-21T16:40:47.813Z
2015-12-21T16:40:47.813Z
morsecoder
<p>Transaction hashes uses sha256, so they are 32 bytes long. If I have to store a very large database of transaction hashes, only for the purpose of checking existence later on, is it really necessary to store all 32 bytes? If i store only 20 last bytes and I compare transactions using only those last 20 bytes, would the crypto guys get mad?</p>

<transactions><security><hash><sha256>
Is it computationally feasible to find two transaction IDs with the same first 20 bytes?
Nathan Parker
# Is it computationally feasible to find two transaction IDs with the same first 20 bytes?

(Asked by: username_0 on 2015-12-21)

Transaction hashes uses sha256, so they are 32 bytes long. If I have to store a very large database of transaction hashes, only for the purpose of checking existence later on, is it really necessary to store all 32 bytes? If i store only 20 last bytes and I compare transactions using only those last 20 bytes, would the crypto guys get mad?

**Tags:** transactions, security, hash, sha256


---

## 2 answers

### Answer by username_2 on 2015-12-21. Score: 4 | Accepted answer

> Is it computationally feasible to find two transaction IDs with the same first 20 bytes?

20 bytes is still 160 bits of security, which is considered very secure. If you are sure that you only need the IDs to check for existence, 20 bytes of the hashes should be fine.

Hard drive space is pretty cheap, though, and you might need the full TXID someday just for interoperability between other systems. So make sure 20 bytes really does satisfy your use cases. A 20 byte hash is sufficiently secure, though.


---

### Answer by username_1 on 2015-12-21. Score: 0

I guess it depends on what you want to do with it. If for example you're using those 20 bytes as keys in a lookup table, then you should be fine as long as you remember you might get an occasional false positive so you always double check if it really is the transaction you were looking for. For that purpose less than 20 bytes is probably already enough.

If 20 bytes is everything that you store while throwing away everything else, and you make important decisions based only on those 20 bytes, then you might run into problems at some point.

Remember that it's not mere chance. If your application plays an important role and an attacker knows about your 20 bytes limitation, they might try to forge 2 conflicting transactions IDs to and crash your system or scam you out of some money.

> **Comments:**
> **username_0**: Is it really possible that there is an occasional false positive? Could the attacker really forge a transaction with a sha256 with 20 customized bytes?  
> **username_1**: I didn't do the math, but yeah seems pretty unlikely. I'd trust StephenM347's answer on that. I typed my answer before his showed up. I was just saying that it might depend on what you're trying to do (you might go lower than 20 bytes) and to keep in mind that active attackers might cause problems if you do go too low.  

---

