1

I am writing an indexer that will work with various blockchains and not just Bitcoin. I am wondering if it is safe to assume that block hashes will be unique for a given blockchain, across reorgs.

Is it possible that the data in two blocks ends up hashing to the same value...such that we now have two blocks with same hash either in the canonical chain or one in canonical and one in a reorged chain?

2
  • What you're really asking about is the collision resistance of SHA-256. A collision has never been found, and unless an attack is found that could reduce the 2^128 complexity, there won't be a collision in many years to come. You will find many answers on this on the Math StackExchange. Commented Jun 29, 2021 at 23:41
  • @VojtěchStrnad you are right that this is really about collision of the hashing algorithm. Thank you for the info :)
    – septerr
    Commented Jun 30, 2021 at 2:28

3 Answers 3

3

Assuming SHA256 isn't broken, this isn't possible in Bitcoin, as the only way to find data that hashes to the same thing is when the data is the same. Since every Bitcoin block contains a hash of its parent, and thus indirectly commits to its entire ancestry, blocks with distinct history will always have distinct contents.

This is probably the case for many similar and not too similar systems as well, but it's hard to answer generically as the term blockchain tends to be very loosely defined only. It's also off topic here.

1
  • Thank you for the response. I could not find a stack exchange for general blockchain questions. So, posted here with the alternatives tag. :) If we ignore the extremely rare chance of collision with sha256, at least in bitcoin, it seems safe to assume block hashes will be unique.
    – septerr
    Commented Jun 29, 2021 at 18:35
0

"What you're really asking about is the collision resistance of SHA-256. A collision has never been found ..." Correct me if I am wrong, but in my opinion although extremely unlikely, collisions must exist because the header is 80 byte = 640 bits, which is less than the hash length of 256 bits.

4
  • How are 640 bits less than 256 bits?
    – Murch
    Commented Sep 22, 2021 at 16:39
  • Sorry, 256 is less than 640. I meant the hash is smaller than the header, therefore there are aproximately 2 hashes for every header
    – mjuliov
    Commented Sep 23, 2021 at 11:39
  • I see, yes, that's right and that argument would actually indicate that there are vastly more than that: 2^640 possible headers are being mapped to 2^256 possible hashes, so there would approximately be 2^384 possible headers per hash if header data could be anything. Header data is restricted in various ways though, so the entropy is not quite that big although it's definitely multitudes of the projection space.
    – Murch
    Commented Sep 23, 2021 at 13:01
  • In case you didn't know, on Stackexchange we often update, improve answers, because the goal is to collect the best answers rather than a discussion with a fixed thread. So, please feel free to edit your answer if you wish.
    – Murch
    Commented Sep 23, 2021 at 13:02
0

You don't need to assume block hashes will be unique for a given blocks chain.

If you are fearful it could cause a collision, then assume block hashes will be unique for a given blocks chain and for a block mining date and time.

That's going to fix your problem, which is to correctly model blocks and block chains, in your application's data layer.

Then, when writing your application, write the back ends considering it is possible (even if it is not possible), though extremely unlikely, such a hash collision would occur. Don't even care writing front ends code until such a hash collision has happened.

This fixes all of your problem and future problems like other crypto assets choosing a different function for hashing blocks and getting shot in their feet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.