If I could find a collision...

[Nobody Really]

Assuming, I can find one anytime I want, with any output I want, how in the name of cheese would I use it for anything?

(I can't but...) If I could find an unlimited number of hashes with any value I wanted (I know, I can't. Shut up. ) and I found a collision with 19 zeros or whatever, what possible use is it? How would I even push it to the block chain? It's not as if I could email it to MoneyPlz@bitcoins.com ...

Any thoughts?

[achow101]

Being able to find a collision of any hash function used in Bitcoin can completely mess with Bitcoin. It would result in, at best, lost funds. Or we will have a consensus failure.

Let's suppose you found a collision in the hash160 algorithm (RIPEMD160 of the SHA256 of data) used for P2PKH, P2SH, and P2WPKH outputs. Say you are able to find a collision of a hash in a P2WPKH or P2PKH output. That means that you have found a piece of data that has the same hash of a public key owned by someone else. If this piece of data also happens to be a valid public key and you know it's private key, you can spend an output that isn't really yours. Thus you can steal funds from someone.

Now suppose that you can find a collision for a hash in a P2SH output. That means that you have found a piece of data that has the same hash as the redeemScript for that output. If this piece of data is also a script and is a script which does nothing or involves public keys for which you know the private keys for, then you can spend that P2SH output even though it isn't really yours.

Let's now suppose you found a collision in SHA256. SHA256 by itself is only used for P2WSH outputs. But if you had a SHA256 collision algorithm, you could do the exact same things with P2WSH outputs as you could with P2SH outputs, i.e. spend an output that is not yours.

Let's suppose you found a collision in SHA256 Double (SHA256 of SHA256 of data) which is used in block hashing and transaction hashing. With this, you can cause a consensus failure. If you find a valid block whose hash collides with another block's, you would be able to force nodes to have different views of the blockchain from each other. This is because one node would have one block that has one set of transactions in it, and another node would have a different block (but with the same hash) that has a different set of transactions in it. If transactions in one block are not in the other, but they are referenced in a later transaction, then the transaction would fail to validate. In general, this would be very bad for the network as it would be possible for nodes to have a different view of the blockchain and thus not be in consensus. This would not really be detectable automatically as both blocks would have the same hash.

With a SHA256d collision, you can also collide transactions. If you can create two transactions that spend different inputs or create different outputs and have the same txid, then you can also cause a consensus failure in the same way that colliding blocks would. You can have some nodes believe a chain of transactions is invalid because their values or output scripts don't match.


In conclusion, hash collisions are bad for Bitcoin and can cause lost money or consensus failures. If any of the hash functions in use in Bitcoin every have a practical collision attack, then we should move to different hash functions ASAP.

[Nobody Really]

Well then...if I figure it out, I will keep it to Myself

Thanks for that.

On a related note, I have always wanted to know ...

If there's only 16^64 possible outputs, wouldn't the hash of every possible sha256 output result in a collision, even if you don't know what it's colliding with?

[achow101]

If there's only 16^64 possible outputs, wouldn't the hash of every possible sha256 output result in a collision, even if you don't know what it's colliding with?

16^64 is 2^256 which is the number of possible SHA256 hashes. With P2PKH and P2WPKH, the number of possible hashes in those types of outputs is 2^160. This means that yes, in theory there are multiple public keys which have the same hash160 but different SHA256 hashes. However, we cannot say if all hash160's have collisions, nor can we say how many collisions there might be. This is because SHA256 may not actually produce all possible 256 bit values. It is possible that there are some values that do not have any data that hash to them, but we do not and cannot know this for sure with today's technology (or likely any technology for that matter).

However, even though the probability of a collision is high when you consider the sets of all possible values, the probability of finding a collision is still extremely low as the set of all possible values is extremely large.

[Foxpup]

only 16^64

It is improper to use the word "only" in connection with a 78 digit number. It is impossible for the human mind to fully conceive just how large this number really is, but to help put it in perspective, it is "only" a billion times greater than the number of atoms in the entire Milky Way galaxy.

[Nobody Really]

I suppose you're right, but I'm not concerned about the practical applications, what with the number being larger than I could possibly imagine.  More of a theoretical question.

I hadn't thought about there being an output that no possible input could produce.  That's a really neat concept.

Thanks for taking the time to answer.

[Nobody Really]

only 16^64

It is improper to use the word "only" in connection with a 78 digit number. It is impossible for the human mind to fully conceive just how large this number really is, but to help put it in perspective, it is "only" a billion times greater than the number of atoms in the entire Milky Way galaxy.

It's even bigger than that, but it's not nearly as much as sha512

Life's short, man. Do you really want to spend yours being critical of the way a complete stranger talks on the internet?

I've made no factual error.
I've made no grammatical error.

I was slightly cheeky with an incomprehensibly large number. There's no reason to be an insufferable douchebag.  Calm down. You'll be fine, cupcake.