<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2021-06-29T18:35:58.950Z
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
CC BY-SA 4.0
2021-06-29T18:21:05.757Z
2021-06-29T18:28:37.640Z
2021-06-29T18:28:37.640Z
Pieter Wuille
<p>&quot;What you're really asking about is the collision resistance of SHA-256. A collision has never been found ...&quot;
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.</p>

CC BY-SA 4.0
2021-09-22T16:39:19.367Z
How are 640 bits less than 256 bits?
Murch
CC BY-SA 4.0
2021-09-23T11:39:52.727Z
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
CC BY-SA 4.0
2021-09-23T13:01:33.957Z
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
CC BY-SA 4.0
2021-09-23T13:02:49.053Z
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
CC BY-SA 4.0
2021-09-22T02:32:14.153Z
2021-09-22T02:32:14.153Z
mjuliov
<p>You don't need to assume block hashes will be unique for a given blocks chain.</p>
<p>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.</p>
<p>That's going to fix your problem, which is to correctly model blocks and block chains, in your application's data layer.</p>
<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2021-09-22T10:46:13.237Z
2021-09-22T10:46:13.237Z
Mercedes
<p>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.</p>
<p>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?</p>

CC BY-SA 4.0
2021-06-29T23:41:36.293Z
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.
Vojtěch Strnad
CC BY-SA 4.0
2021-06-30T02:28:16.607Z
@VojtěchStrnad you are right that this is really about collision of the hashing algorithm. Thank you for the info :)
septerr
<alternatives><sha256>
Can a blockchain have duplicate block hashes?
septerr
# Can a blockchain have duplicate block hashes?

(Asked by: username_0 on 2021-06-29)

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?

**Tags:** alternatives, sha256

> **Comments:**
> **username_1**: 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.  
> **username_0**: @username_1 you are right that this is really about collision of the hashing algorithm. Thank you for the info :)  

---

## 3 answers

### Answer by username_2 on 2021-06-29. Score: 3 | Accepted answer

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.

> **Comments:**
> **username_0**: 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.  

---

### Answer by username_3 on 2021-09-22. Score: 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.

> **Comments:**
> **username_4**: How are 640 bits less than 256 bits?  
> **username_3**: Sorry, 256 is less than 640. I meant the hash is smaller than the header, therefore there are aproximately 2 hashes for every header  
> **username_4**: 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.  
> **username_4**: 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.  

---

### Answer by username_5 on 2021-09-22. Score: 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.


---

