Is this how reorganization and fork maintenance work in Bitcoin?
I’m trying to understand how these related reconfigurations and forks work in Bitcoin. I went through all the questions (about 80/90) related to: chain-reorganization I think the tags have given me some insight into how everything works, but there are still some uncertainties. This will be explained below. Let’s start by asking questions, starting with how we understand reorganization and fork.
The answer that most helped me understand how it all works (Thank you to these great people!):
Merch:
Peter Wille:
Ava Chow:
First, we would like to thank everyone for their understanding and help, and we sincerely apologize for the excessive text content. Any help would be greatly appreciated.
I’m considering a situation where it syncs, isn’t offline, and then reconnects.
A fork occurs when two miners produce the next blocks (Block A and Block B) at approximately the same time. In this situation, block A is approved by one part of the network and block B is approved by another part of the network. Depending on which block the node first receives (via header or cmpct message), the node will first validate that block (let’s say A) and if everything is ok, it will declare that branch as the default/canonical branch and leave it alone. Block A is then propagated to all peers. For the second block (Block B), cmpct only performs verification to ensure that it has a valid PoW and a known parent block, regardless of whether it received only the header or the entire block (all other details are irrelevant). correct or not). Additionally, since block A is part of the main chain, we only forward it to all peers, while block B only stays locally as one of the chain tips. At this point we have two chains (main and “side”), and we are waiting to see which of these two chains will be expanded next (block C). Once the chain with block A is extended, everything is fine. We perform regular verification. That’s it. However, if the chain containing Block B is expanded, reorganization is necessary. In this case, all transactions in block A are returned to the mempool, and all consumed UTXOs are returned as a UTXO set. After that, a full verification is performed on the other fields in the header and the transactions in block B (if there is only the header, a getdata request for the entire block or a getblocktxn request for the remaining missing transactions must also be sent). If everything is ok, block C is verified. If C is okay, it will be passed to all peers and that branch will become the new canonical/main branch.
My questions are:
- Is everything written above correct?
- I know that node only accepts blocks whose parents it knows (if it doesn’t know, it’s an orphan block). But must that parent be one of the branch tips, or one of the blocks on a random branch (either main or fork)? For example, if the main chain has 100,000 blocks and there are two forks on the side: the first splits the main chain with 20,000 blocks and has an additional 5 blocks, and the second splits it with 60,000 blocks and has an additional 30 blocks. There is this. Is a block only acceptable if its 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 are blocks whose parents are not branch tips also allowed (e.g. block 86,004 of the main chain, block 20,002 of the first fork, etc.)? When I say accepted, I mean verifying the PoW and making sure it becomes the new main chain. Once this becomes the main chain, other validations will follow.
- What happens to the blocks remaining in the old fork during a rebuild? Will it stay the same or will the transaction be deleted and only the header remain?
- When the chain with block B is expanded with block C, it becomes the main chain, so in this case it forwards block C to all its peers. However, since it was previously the chain with block A, it did not propagate block B to its peers, so block C is discarded as an orphan block. What if those colleagues have never heard of Block B? They will never accept this…
- Everything I’ve written is identical to how Bitcoin Core implements blockchain and fork management (maintenance), where there is no part of consensus other than keeping track of which chain is doing the most work. Or is it not even part of the agreement? Is it only important to follow the chain that has done the most work and how to implement it is irrelevant?
