<p>It would not break the algorithm. </p>

<p>As the <a href="https://en.bitcoin.it/wiki/Protocol_documentation#Inventory_Vectors" rel="noreferrer">inventory vector</a> of the described new block would be a duplicate of an already known block, no other node would request this block. It would just be ignored, as if never discovered in the first place. Everybody else would still be hashing away happily, obsoleting the block eventually.</p>

<p>Tough luck for the miner, he'd not get the reward, because everybody would be convinced that no new block has been found at that height yet.</p>

<p>Of course, chances of that happening are negligible, because the block hash is a random 256 bit output (smaller than the current target), which allows for an immense number of possible hash outputs of a similar magnitude as the <a href="https://bitcoin.stackexchange.com/a/12740/5406">address space</a>.</p>

<p>Actually, @NickODell made me aware that it can cause a problem, when nodes see the newer block before the older block that was already part of the longest chain. In that case the node would be unable to synchronize, as it would not be able to build the complete chain.</p>

CC BY-SA 3.0
2015-07-03T10:58:45.870Z
little bit less than 2^256 :)) because hashes have several leading zeros :))
amaclin
CC BY-SA 3.0
2015-07-03T12:01:12.370Z
Oh, of course yes. I totally forgot about that also being the metric being compared to the target.
Murch
CC BY-SA 3.0
2015-07-03T13:33:41.863Z
Worth noting that you don't have to request an inventory item to receive it, you can push items directly to nodes and they will happily download and process it. Violation of the protocol and a waste of bandwidth, but it is valid behavior.
Claris
CC BY-SA 3.0
2015-07-03T18:22:21.230Z
@Bitcoin: So, essentially, those that had it would remain on the fork until a longer chain orphaned it? Or those that hadn't gotten it and couldn't request it, would not be able to join the chain?
Murch
CC BY-SA 3.0
2015-07-03T18:30:28.887Z
I'd have to read some of the code to find out for sure. I suspect the client would just implode when trying to import a duplicate block hash though, making the question especially moot.
Claris
CC BY-SA 3.0
2017-11-02T18:15:41.683Z
Doesn't this limit the usability of bitcoin ? At some point the amount of transactions that can ever be made will be used up. Would the hashspace just be made larger at that point ?
HopefullyHelpful
CC BY-SA 3.0
2017-11-02T18:33:16.320Z
There are 2^256 = 1.1579209e+77 possible transactions. For the block hashes slightly fewer due to the constraints from difficulty. Either way, I think we're good for a few millenia. ;)
Murch
CC BY-SA 3.0
2015-07-03T09:00:25.187Z
2015-07-16T13:25:47.110Z
2017-04-13T12:47:32.940Z
Murch
<p>A Bitcoin client has to download the whole blockchain from the P2P network in order to become a full node.</p>

<p>A full node is able to determine, if a transaction in the network is valid or not.</p>

<p>To download the blockchain, the client queries other peers in the network for more blocks by providing them with the hash of the last block it has currently in its downloaded blockchain.</p>

<p>The other nodes search in their currently best blockchain for the specified hash and return a list of hashes of further blocks the client can download.</p>

<p>After the client determines that the further block hashes are indeed in the longest block chain by crossvalidating other nodes, it requests those blocks from its peers by giving them the hashes of those new blocks.</p>

<p>After the download, it checks for itself that the blocks follow the rules of the bitcoin network and inserts them in its current blockchain.</p>

<hr>

<p>This algorithm assumes that any valid block in the blockchain has a unique hash that identifies it.
What happens, if by chance a block is inserted in the blockchain that has the same hash as a previous block and that complies with all rules of the bitcoin network?</p>

<p>Wouldn't that break the algorithm?</p>

<blockchain><bitcoind><block-header>
How does the bitcoin network recover in case of a hash collision in the block hash?
user1861174
# How does the bitcoin network recover in case of a hash collision in the block hash?

(Asked by: username_0 on 2015-07-03)

A Bitcoin client has to download the whole blockchain from the P2P network in order to become a full node.

A full node is able to determine, if a transaction in the network is valid or not.

To download the blockchain, the client queries other peers in the network for more blocks by providing them with the hash of the last block it has currently in its downloaded blockchain.

The other nodes search in their currently best blockchain for the specified hash and return a list of hashes of further blocks the client can download.

After the client determines that the further block hashes are indeed in the longest block chain by crossvalidating other nodes, it requests those blocks from its peers by giving them the hashes of those new blocks.

After the download, it checks for itself that the blocks follow the rules of the bitcoin network and inserts them in its current blockchain.

---

This algorithm assumes that any valid block in the blockchain has a unique hash that identifies it.
What happens, if by chance a block is inserted in the blockchain that has the same hash as a previous block and that complies with all rules of the bitcoin network?

Wouldn't that break the algorithm?

**Tags:** blockchain, bitcoind, block-header


---

## 1 answers

### Answer by username_1 on 2015-07-03. Score: 9 | Accepted answer

It would not break the algorithm.

As the [inventory vector](https://en.bitcoin.it/wiki/Protocol_documentation#Inventory_Vectors) of the described new block would be a duplicate of an already known block, no other node would request this block. It would just be ignored, as if never discovered in the first place. Everybody else would still be hashing away happily, obsoleting the block eventually.

Tough luck for the miner, he'd not get the reward, because everybody would be convinced that no new block has been found at that height yet.

Of course, chances of that happening are negligible, because the block hash is a random 256 bit output (smaller than the current target), which allows for an immense number of possible hash outputs of a similar magnitude as the [address space](https://bitcoin.stackexchange.com/a/12740/5406).

Actually, @NickODell made me aware that it can cause a problem, when nodes see the newer block before the older block that was already part of the longest chain. In that case the node would be unable to synchronize, as it would not be able to build the complete chain.

> **Comments:**
> **username_2**: little bit less than 2^256 :)) because hashes have several leading zeros :))  
> **username_1**: Oh, of course yes. I totally forgot about that also being the metric being compared to the target.  
> **username_3**: Worth noting that you don't have to request an inventory item to receive it, you can push items directly to nodes and they will happily download and process it. Violation of the protocol and a waste of bandwidth, but it is valid behavior.  
> **username_1**: @Bitcoin: So, essentially, those that had it would remain on the fork until a longer chain orphaned it? Or those that hadn't gotten it and couldn't request it, would not be able to join the chain?  
> **username_3**: I'd have to read some of the code to find out for sure. I suspect the client would just implode when trying to import a duplicate block hash though, making the question especially moot.  
> **username_4**: Doesn't this limit the usability of bitcoin ? At some point the amount of transactions that can ever be made will be used up. Would the hashspace just be made larger at that point ?  
> **username_1**: There are 2^256 = 1.1579209e+77 possible transactions. For the block hashes slightly fewer due to the constraints from difficulty. Either way, I think we're good for a few millenia. ;)  

---

