<p>Both blocks are indexed and stored. The extending block which was received first is represented as an array element with links/pointers to the headers of the strong chain: Chains are represented as arrays with links pointing to headers in the store.</p>

<p>The second block is now considered part of a “candidate chain”, of which there can be many with different heights. The tip of each branch emanating from the strong chain is the tip of a candidate chain. A candidate chain can be potentially extended to form the strong chain if it accumulates the most POW. At this point, the strong chain array elements are popped to the forking height, and the new candidate chain headers/blocks are pushed on the strong chain array/stack. The popped elements of the strong chain are pushed to a candidate chain array in respective order.</p>

<p>Since the number of candidate chains is unbounded, it may not make sense to organize them individually to store, but keep a them as a separate data structure (tree). Furthermore, given the cost of auch branches at current chain heights, they tend to be short. The risk of reorg is most likely with the “2nd” highest chain, so keeping this in persistent store can optimize for faster reorgs if the node is restarted (other indexed candidate chains in memory are lost and need to be rebuilt, but less likely to overtake strong chain). Of course, an implementation can persistently index an arbitrary bounded number of candidate chains depending on design objective.</p>

CC BY-SA 4.0
2018-12-26T17:09:55.803Z
2018-12-26T17:16:24.753Z
2018-12-26T17:16:24.753Z
James C.
<p>I came across these lines from the Bitcoin whitepaper:</p>

<blockquote>
  <p>If two nodes broadcast different versions of the next block
  simultaneously, some nodes may receive one or the other first. In that
  case, they work on the first one they received, but save the other
  branch in case it becomes longer.</p>
</blockquote>

<p>Does that mean two chains are maintained in parallel in each node? If yes, how do the nodes actually maintain it in implementation level of the Bitcoin network?</p>

<bitcoin-core><nodes>
How does the Bitcoin network maintain the chains created when two nodes generate different versions of the same block?
Abrar
# How does the Bitcoin network maintain the chains created when two nodes generate different versions of the same block?

(Asked by: username_0 on 2018-12-26)

I came across these lines from the Bitcoin whitepaper:

> If two nodes broadcast different versions of the next block
> simultaneously, some nodes may receive one or the other first. In that
> case, they work on the first one they received, but save the other
> branch in case it becomes longer.

Does that mean two chains are maintained in parallel in each node? If yes, how do the nodes actually maintain it in implementation level of the Bitcoin network?

**Tags:** bitcoin-core, nodes


---

## 1 answers

### Answer by username_1 on 2018-12-26. Score: 1

Both blocks are indexed and stored. The extending block which was received first is represented as an array element with links/pointers to the headers of the strong chain: Chains are represented as arrays with links pointing to headers in the store.

The second block is now considered part of a “candidate chain”, of which there can be many with different heights. The tip of each branch emanating from the strong chain is the tip of a candidate chain. A candidate chain can be potentially extended to form the strong chain if it accumulates the most POW. At this point, the strong chain array elements are popped to the forking height, and the new candidate chain headers/blocks are pushed on the strong chain array/stack. The popped elements of the strong chain are pushed to a candidate chain array in respective order.

Since the number of candidate chains is unbounded, it may not make sense to organize them individually to store, but keep a them as a separate data structure (tree). Furthermore, given the cost of auch branches at current chain heights, they tend to be short. The risk of reorg is most likely with the “2nd” highest chain, so keeping this in persistent store can optimize for faster reorgs if the node is restarted (other indexed candidate chains in memory are lost and need to be rebuilt, but less likely to overtake strong chain). Of course, an implementation can persistently index an arbitrary bounded number of candidate chains depending on design objective.


---

