1

If a fork happens, miners mine on the block they receive at first. Further, they only forward the block they received first (so the block they will use to mine)!

So it can happen that 10% of the network will mine on the chain A. The other 90% will mine on chain B. So only 10% know about chain A and 90% know about chain B. And some edge node will know about chain A and chain B... Depends on how the overlay structure looks like.

What happens if now the 10% fork (chain A) will mine a block and send it to the network? Why won't the other nodes discard the block from chain A? How do they know that this chain is longer? How do they know that the block is not just some part of DDOS attack?

If someone could give me a detailed describtion how the conflict is solved, I would be very happy.

Ugam Kamat
  • 7,263
  • 2
  • 13
  • 38
user674907
  • 47
  • 4
  • I think this is a good lecture on [blockchain fork](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch10.asciidoc#forks) – vincenzopalazzo Sep 18 '19 at 14:08
  • The Paper "Majority is not Enough: Bitcoin Mining is Vulnerable*" says "The Bitcoin protocol prescribes that when a miner knows of multiple branches of the same length, it mines and propagates only the first branch it received." In your tutorial it is described that every node receives every block? So they all have the same knowledge about all forks? Is the paper wrong? – user674907 Sep 18 '19 at 14:18

1 Answers1

3

What happens if now the 10% fork (chain A) will mine a block and send it to the network?

When a miner building on top of chain A finds a valid block, it will relay the block to the rest of the network. For convention let us assume the fork (chain A and chain B) has happened at block height N. This is how different nodes on the network will react when they receive a block at height N+1 whose parent is on chain A.

  1. Nodes already using chain A: For them, this block N + 1 is a natural progression of the blockchain and as a result they will just add this block to their blockchain.
  2. Nodes using chain B but has chain A block: There might be some nodes who might have received the chain A block at height N after receiving block at height N from chain B. Since these node received block from chain B first, they will use this version of the chain as their primary one. However, block from chain A that is received later is not discarded but is processed and kept on the disk. So, when block at height N + 1 is received from chain A version, these nodes just revert the chain at height N and use the other block that was kept on disk.
  3. Nodes only having chain B: When they receive block at height N+1 from chain A, these nodes will see that they do not have its parent. As a result, these nodes will query the parent block using the previousblockhash and see if it exists. The nodes having this block will then transmit that block to the nodes not having it. When that block is received, these nodes will see that this chain is the longest proof of work chain and as a result they will now operate on chain A. The block at height N from chain B becomes stale but it is not discarded and is still kept on disk.

How do they know that this chain is longer?

Nodes accept the longest proof of work chain (in most cases it is same as the longest chain). Nodes sync headers first and verify the proof of work of the chain before asking the actual blocks from other nodes. When nodes on chain B version of chain receive the header of block N+1 on chain A version, they will see that the chainwork of the block received is more than that of the chain they already have and as a result will use it to query the block associated with it.

How do they know that the block is not just some part of DDoS attack?

When they receive the block header, the proof of work is verified first. So, if the attacker wants to spam the network with invalid blocks, he/she would have to do so with valid proof of work. That means spending immense amount of energy as other miners but not getting the reward (as the block does not have any ancestor, it will be rejected). If the node receives a block header with invalid proof of work, then the node that has sent this block header will be blacklisted after certain attempts of this mischief. This was actually the basis of PoW in 1990s when it was used to prevent spam emails.

Ugam Kamat
  • 7,263
  • 2
  • 13
  • 38
  • Thanks a lot! This is exactly I was looking for. What about combining old blocks with sibling attacks? :P – user674907 Sep 18 '19 at 14:35
  • What do you mean? Can you elaborate on it? – Ugam Kamat Sep 18 '19 at 14:40
  • I'm not sure how bitcoin is blacklisting nodes. If blacklisting is IP-based, spawning infinitely new identities won't work. If it is based on bitcoin addresses, it may work. To circumvent calculating always new PoWs for wrong blocks, I just use old ones there the PoW is correct. Then nodes would have to always findout that this is an old block... So they need efficient lookup data structures. Further, the UTXO check would probably crash. I think this attack would not work... ^^ Just an idea... But if blacklisting is IP-basd I can spoof IP addresses and take down the network?! – user674907 Sep 18 '19 at 14:48
  • @user674907 Bitcoin blacklists nodes from IP. Address is not a node identifier, it is just some mathematical equation to lock bitcoins. I'm unsure as to how the lookup process actually works, but if a node sees some header it has already received then it will not query the block associated with it. I think it would make for a good new question as to how the lookup process works, if it has not been asked on this forum. – Ugam Kamat Sep 18 '19 at 17:26