I am trying to understand how reorganization and forks related to them work in Bitcoin. I have reviewed all the questions (around 80/90 of them) related to the chain-reorganization tag, and I think I have gained some insight into how everything works, but I still have some uncertainties, which I will outline below. First, I will start with how I understand reorganization and forks, and then I will pose the questions.
Answers that have helped me the most in understanding how everything works (Big Thanks to this great people!):
Murch:
Pieter Wuille:
Ava Chow:
Thank you all in advance for your understanding and assistance and truly apologize for the excessive text. Any help would be appreciated
I am considering a situation where we are synchronized, haven’t been offline and then reconnect.
Forks occur when two miners create the next block (block A and block B) at approximately the same time. In this situation, block A is accepted by one part of the network, while block B is accepted by another part of the network. Depending on which block a node first receives (via header or cmpct message), the node will first validate that block (let’s say A), and if everything is fine, declare its branch as the main/canonical branch, leaving it in place. Block A is then propagated to all its peers. As for the second block (block B), regardless of whether it only received the header or the entire block due to cmpct, it will only perform validation to check if it has a valid PoW and a known parent (all other details are irrelevant; whether the transactions are correct or not). Also, we will only forward block A to all our peers since it is part of our main chain, while we keep B only locally as one of the chain tips. At this point, we have two chains (main and “side”), waiting to see which of these two will be extended next (block C). If the chain with block A is extended, everything is fine; we perform regular validation, and that’s it. However, if the chain with block B is extended, a reorganization is necessary. In this case, all transactions from block A are returned to the mempool, and all spent UTXOs are returned to the UTXO set. After that, a complete validation is performed on the other fields of the header and transactions of block B (if we only had the header, it is necessary to also send a getdata request for the entire block or a getblocktxn request for the remaining missing transactions). If everything is fine, block C is validated. If C is also fine, it is forwarded to all peers, and that branch becomes the new canonical/main branch.
My questions are:
- Is everything written above correct?
- I know that a node only accepts blocks for which it knows the parent (if it doesn’t know, they are orphan blocks). However, does that parent have to be exclusively one of the branch tips, or does it just need to be one of the blocks from any of the branches (either main or one of the forks)? For example, if the main chain has 100,000 blocks and there are two forks on the side: the first split at 20,000 blocks with the main and has an additional 5 blocks, and the second split at 60,000 blocks with an additional 30 blocks. Will a block be accepted only if a block comes whose parent is the 100,000th block of the main chain, the 20,005th block of the first fork, or the 60,030th block of the second fork? Or will blocks whose parents are not branch tips also be accepted (for example, the 86,004th block of the main chain, the 20,002nd block of the first fork, etc.)? When I say accepted, I mean validation of PoW and checking if it might have become the new main chain. If it does become the main chain, then other validation checks follow.
- What happens to the blocks that remain in that stale fork during reorganization? Do they stay as they are, or are transactions discarded, leaving only the header?
- If the chain with the B block is extended with the C block, for me, that becomes the main chain, so in this case, I forward block C to all my peers. However, since it was previously the chain with block A, I didn’t propagate block B to my peers, so block C will be discarded as an orphan block. What happens if such peers have never heard of block B? They will never accept this branch…
- Is all that I have written just the way Bitcoin Core implements blockchain management, and nothing here is part of the consensus except for tracking the chain with the most work, or is that not even part of the consensus? Is it only important to follow the chain with the most work, and how we implement it is irrelevant?
