<blockquote>
  <p>All nodes will delete the shortest block-tip before they even hear about the other broadcast.</p>
</blockquote>

<p>This assumption is incorrect.</p>

<p>For Bitcoin Core (and since all full nodes are either Bitcoin Core, modeled off of Bitcoin Core, or forked from it, this applies to basically all nodes), all blocks which have a valid Proof of Work and a few other things are written to disk and added to the block index and chainstate. At the very least the headers are recorded as headers are received before the blocks are. So if I am using Chain+A and I receive block B, I will store block B and mark it as not in my main chain but still fully valid. When block C, I will update my main chain with block C (advance the current tip to block C). When I receive block D, I store block D to disk and mark it as not in my main chain but still fully valid.</p>

<p>If I had received block D (or its header) without having received block B (or its block header), then I will discard it as invalid. However this is unlikely to happen because I will almost always know the best headers chain of all of my peers because I asked for it when they connected and I will receive headers from each of them for every valid block they receive.</p>

<p>Such a fork will resolve when one chain has more work than the other chain. This will typically happen when one becomes longer than the other. When that happens, because all nodes know of the other chain having either its block headers or the blocks themselves, all nodes following the shorter chain will automatically switch over to using the longer chain.</p>

<p>If the split should persist indefinitely, then this will not happen, but that is extremely unlikely given that it becomes more and more improbable for every single block on each chain to be found, broadcast, and received by all nodes simultaneously.</p>

CC BY-SA 3.0
2017-10-22T16:56:28.477Z
2017-10-22T16:56:28.477Z
Ava Chow
<p>So the issue you describe is that half of nodes consider chain+A valid and half consider chain+B valid. </p>

<p>The situation gets resolved when the first subsequent block is mined, let's say it happens to be the one from the miners on the chain+A. Now we have the situation: chain+A+1 vs chain+B. At this point all the nodes switch to longer chain: chain+A+1.</p>

<p>EDIT: Regarding the circumstances of how switch occurs I'm not sure but <strong>an idea</strong> is the following:</p>

<ul>
<li><p>When new block is mined and broadcasted, if it does not fit on recipients tip of chain, communication is held between the broadcaster and recipient to find where the branches diverged.</p></li>
<li><p>If recipient finds the broadcaster's branch is longer it switches to it.</p></li>
</ul>

<p>In real life Internet the contention situation is highly unlikely to exist for longer than 1 block duration. Eventually it gets resolved even if divergence continues for longer.</p>

<p>Someone more experienced can correct me.</p>

CC BY-SA 3.0
2017-10-22T11:38:08.307Z
The chain+B nodes already invalidated A, then how would they know about A in the first place.

Also, what if the process keeps happening, chain+A+C+... and chain+B+D+...
tushar
CC BY-SA 3.0
2017-10-22T11:41:14.290Z
Good question. I have the similar one posted :). Wanted to edit my answer that if this is your question I don't know the answer :D.
croraf
CC BY-SA 3.0
2017-10-22T11:47:30.417Z
I updated with  my idea of how this switch could technically happen.
croraf
CC BY-SA 3.0
2017-10-22T11:32:14.000Z
2017-10-22T14:57:28.943Z
2017-10-22T14:57:28.943Z
croraf
<p>Let's say that 2 miners were able to add a block around the same time. However, when they broadcast their respective blocks to the network, other nodes receive these blocks in arbitrary order. The block that arrives later will be considered invalid because the hash of the previous block will not match up.</p>

<p>How does blockchain ensure that the newly block added is the same one for all the nodes?</p>

<p>EDIT:</p>

<p>Even if everyone is connected to the network this can happen:</p>

<p>Blocks A and B are added at the same time. Then next round C happens on top of A, and D happens on top of B. All nodes will delete the shortest block-tip before they even hear about the other broadcast.</p>

<pre><code>node 1:
chain +A  +C
chain +B  +D

node 2:
chain +B  +D
chain +A  +C
</code></pre>

<p>And if this keeps happening, all the nodes will maintain different versions of the blockchain which, in their view is the correct version</p>

<pre><code>node 1:
chain+A+C+...

node 2:
chain+B+D+...
</code></pre>

CC BY-SA 3.0
2017-10-22T12:16:41.293Z
i think i've answered a similiar question: https://bitcoin.stackexchange.com/questions/61106/does-full-node-store-all-valid-forks-and-alternative-blocks-from-blockchain-hi. I hope this is helpful.
rny
CC BY-SA 3.0
2017-10-22T12:32:56.377Z
:) yes, this is the question I refer to in my comment below
croraf
CC BY-SA 3.0
2017-10-22T12:32:58.847Z
because I cannot add a comment on the other question...

It could might as well be that different nodes end up adding a block to a different block-tip and if that's the case how can consensus ever be reached
tushar
CC BY-SA 3.0
2017-10-22T12:46:43.043Z
It can be, but highly unlikely if they are connected to the network. One of the branches will get ahead and broadcast its length and branch. Then everybody will switch to this longer branch.
croraf
CC BY-SA 3.0
2017-10-22T12:58:53.270Z
I edited the question otherwise it would be too big for a comment.
tushar
CC BY-SA 3.0
2017-10-22T13:28:40.090Z
As per how I understand, as soon as C comes, node 2 will switch to chain+A+C, and they will be consistent again. Or if D comes first, both will switch to chain+B+D. It is extremely unlikely this can continue for more than 1 block.
croraf
CC BY-SA 3.0
2017-10-22T13:29:42.527Z
but I'm saying that node 2 never hears about C, but hears about D which happens on top of B
tushar
CC BY-SA 3.0
2017-10-22T13:30:02.517Z
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/67464/discussion-between-croraf-and-tushar).
croraf
<blockchain><broadcast>
Consistency when multiple blocks are added
tushar
# Consistency when multiple blocks are added

(Asked by: username_0 on 2017-10-22)

Let's say that 2 miners were able to add a block around the same time. However, when they broadcast their respective blocks to the network, other nodes receive these blocks in arbitrary order. The block that arrives later will be considered invalid because the hash of the previous block will not match up.

How does blockchain ensure that the newly block added is the same one for all the nodes?

EDIT:

Even if everyone is connected to the network this can happen:

Blocks A and B are added at the same time. Then next round C happens on top of A, and D happens on top of B. All nodes will delete the shortest block-tip before they even hear about the other broadcast.

```
node 1:
chain +A  +C
chain +B  +D

node 2:
chain +B  +D
chain +A  +C

```

And if this keeps happening, all the nodes will maintain different versions of the blockchain which, in their view is the correct version

```
node 1:
chain+A+C+...

node 2:
chain+B+D+...

```

**Tags:** blockchain, broadcast

> **Comments:**
> **username_1**: i think i've answered a similiar question: https://bitcoin.stackexchange.com/questions/61106/does-full-node-store-all-valid-forks-and-alternative-blocks-from-blockchain-hi. I hope this is helpful.  
> **username_2**: :) yes, this is the question I refer to in my comment below  
> **username_0**: because I cannot add a comment on the other question...  It could might as well be that different nodes end up adding a block to a different block-tip and if that's the case how can consensus ever be reached  
> **username_2**: It can be, but highly unlikely if they are connected to the network. One of the branches will get ahead and broadcast its length and branch. Then everybody will switch to this longer branch.  
> **username_0**: I edited the question otherwise it would be too big for a comment.  
> **username_2**: As per how I understand, as soon as C comes, node 2 will switch to chain+A+C, and they will be consistent again. Or if D comes first, both will switch to chain+B+D. It is extremely unlikely this can continue for more than 1 block.  
> **username_0**: but I'm saying that node 2 never hears about C, but hears about D which happens on top of B  
> **username_2**: Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/67464/discussion-between-username_2-and-username_0).  

---

## 2 answers

### Answer by username_3 on 2017-10-22. Score: 2

> All nodes will delete the shortest block-tip before they even hear about the other broadcast.

This assumption is incorrect.

For Bitcoin Core (and since all full nodes are either Bitcoin Core, modeled off of Bitcoin Core, or forked from it, this applies to basically all nodes), all blocks which have a valid Proof of Work and a few other things are written to disk and added to the block index and chainstate. At the very least the headers are recorded as headers are received before the blocks are. So if I am using Chain+A and I receive block B, I will store block B and mark it as not in my main chain but still fully valid. When block C, I will update my main chain with block C (advance the current tip to block C). When I receive block D, I store block D to disk and mark it as not in my main chain but still fully valid.

If I had received block D (or its header) without having received block B (or its block header), then I will discard it as invalid. However this is unlikely to happen because I will almost always know the best headers chain of all of my peers because I asked for it when they connected and I will receive headers from each of them for every valid block they receive.

Such a fork will resolve when one chain has more work than the other chain. This will typically happen when one becomes longer than the other. When that happens, because all nodes know of the other chain having either its block headers or the blocks themselves, all nodes following the shorter chain will automatically switch over to using the longer chain.

If the split should persist indefinitely, then this will not happen, but that is extremely unlikely given that it becomes more and more improbable for every single block on each chain to be found, broadcast, and received by all nodes simultaneously.


---

### Answer by username_2 on 2017-10-22. Score: 1

So the issue you describe is that half of nodes consider chain+A valid and half consider chain+B valid.

The situation gets resolved when the first subsequent block is mined, let's say it happens to be the one from the miners on the chain+A. Now we have the situation: chain+A+1 vs chain+B. At this point all the nodes switch to longer chain: chain+A+1.

EDIT: Regarding the circumstances of how switch occurs I'm not sure but **an idea** is the following:

* When new block is mined and broadcasted, if it does not fit on recipients tip of chain, communication is held between the broadcaster and recipient to find where the branches diverged.
* If recipient finds the broadcaster's branch is longer it switches to it.

In real life Internet the contention situation is highly unlikely to exist for longer than 1 block duration. Eventually it gets resolved even if divergence continues for longer.

Someone more experienced can correct me.

> **Comments:**
> **username_0**: The chain+B nodes already invalidated A, then how would they know about A in the first place.  Also, what if the process keeps happening, chain+A+C+... and chain+B+D+...  
> **username_2**: Good question. I have the similar one posted :). Wanted to edit my answer that if this is your question I don't know the answer :D.  
> **username_2**: I updated with  my idea of how this switch could technically happen.  

---

