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

Question

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?

Answer 1

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 2

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.