Topic: How to resolve forks while reading .dat files? (Read 575 times)
Great answers, thank you!
Yes, but it's a sort of a race condition between forks,
Correct. This is how the network reaches consensus and agrees on the contents of the blockchain.
at which point you measure which one is longer,
At the point where it becomes longer. Note that there is a possibility that one fork can become longer for a brief time, and then the other fork can catch up and become longer. This is why BOTH forks are stored by the node. The longer fork is the "valid" fork only so long as it remains longer. If the other fork ever extends longer, then the entire fork that used to be longer is abandoned (orphaned) and the new longer fork becomes the "valid" fork. This rarely happens more than 1 block deep, and extremely rarely happens more than a few blocks deep, but it is ALWAYS a possibility.
after the second block arrives in one of the forks?
Correct. Once a fork is longer, it is the valid chain so long as it remains longer.
How long ( or by how many blocks longer) one fork needs to be to win?
It simply needs to remain longer. So long as it is longer, it is the current "valid" chain. If it ever stops being longer, then it is abandoned and orphaned.
Note: All references to "longer" in terms of bitcoin blockchain actually mean "most total work" as determined by the difficulty. Under normal circumstances the chain with more blocks will be the one with "most total work", since any blocks at the same height should all have the same difficulty. However, there are attacks that can alter the difficulty, and if difficulty isn't taken into consideration properly, then it could be possible for an attacker to trick you into following a chain with many blocks at very low difficulty when the rest of the network is following a chain that has less blocks at a much higher difficulty.
You need to take into account future blocks to detect orphans. The longer path is the main chain.
Yes, but it's a sort of a race condition between forks, at which point you measure which one is longer, after the second block arrives in one of the forks?
How long ( or by how many blocks longer) one fork needs to be to win?
With that in mind, someone can create their own chain from block 1000 to 1005 and when the network has mined till 1004, that person releases all the blocks from 1000 to 1005 and the original 1000 to 1004 will be orphaned.
You need to take into account future blocks to detect orphans. The longer path is the main chain.
Yes, but it's a sort of a race condition between forks, at which point you measure which one is longer, after the second block arrives in one of the forks?
How long ( or by how many blocks longer) one fork needs to be to win?
You need to take into account future blocks to detect orphans. The longer path is the main chain.
I'm writing my own block finder that reads .dat files made and verified by bitcoind, starting from blk00000.dat forwards. As soon as a new block is read I append it to it's parent, thus creating the blockchain. Blocks ofc are not read in the right order so you need to shuffle them on the fly.
Sometimes a block is read that claims a parent that already has a child, so this is a fork (at least in my terms) and one of them has to become an orphan.
How can I resolve this and figure out which one to keep?
Is it a decision based on future block codes or is it an external decision?
For example, I stumbled on a block 000000000000000000E0BBFCB8C89D8A1A68247E9A379E64BF4F6309A2282383 that you won't find on blockchain.info but can see thru bitcoin-cli API, it claims 0000000000000000005f2a78bcf67d01b57c72b3a1c354fad15c18550657b631 as a parent but it was never added to the blockchain.
Sometimes a block is read that claims a parent that already has a child, so this is a fork (at least in my terms) and one of them has to become an orphan.
How can I resolve this and figure out which one to keep?
Is it a decision based on future block codes or is it an external decision?
For example, I stumbled on a block 000000000000000000E0BBFCB8C89D8A1A68247E9A379E64BF4F6309A2282383 that you won't find on blockchain.info but can see thru bitcoin-cli API, it claims 0000000000000000005f2a78bcf67d01b57c72b3a1c354fad15c18550657b631 as a parent but it was never added to the blockchain.
Jump to: