2

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+...
  • i think i've answered a similiar question: bitcoin.stackexchange.com/questions/61106/…. I hope this is helpful. – renlord Oct 22 '17 at 12:16
  • :) yes, this is the question I refer to in my comment below – croraf Oct 22 '17 at 12:32
  • 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 Oct 22 '17 at 12:32
  • 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 Oct 22 '17 at 12:46
  • I edited the question otherwise it would be too big for a comment. – tushar Oct 22 '17 at 12:58
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.

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.

  • 1
    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 Oct 22 '17 at 11:38
  • 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 Oct 22 '17 at 11:41
  • I updated with my idea of how this switch could technically happen. – croraf Oct 22 '17 at 11:47
0

Still, there is a small thing that is not completely clear for me.

In all of the blockchain samples e.g. adilmoujahid, Savjee as I checked, they added previous Hash by creating a block.

Suppose that, L is the current last block in a chain. Block A and B are created at the same time. So they set their previous hash with the same hash e.g. Hash of L.

What happens by mining when both of them are mined successfully, but B was mined faster.

Therefore normally previous hash of B is correct, but previous hash of A should be changed to the hash of B.

What I want to reach, I think assigning previous hash by creating a block is not necessary, but by mining. Am I right?

New contributor
masoud2011 is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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