Bitcoin Forum
May 04, 2024, 08:09:22 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How to resolve forks while reading .dat files?  (Read 538 times)
alikim (OP)
Member
**
Offline Offline

Activity: 80
Merit: 11


View Profile
July 05, 2017, 08:58:32 PM
 #1

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.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714853362
Hero Member
*
Offline Offline

Posts: 1714853362

View Profile Personal Message (Offline)

Ignore
1714853362
Reply with quote  #2

1714853362
Report to moderator
1714853362
Hero Member
*
Offline Offline

Posts: 1714853362

View Profile Personal Message (Offline)

Ignore
1714853362
Reply with quote  #2

1714853362
Report to moderator
1714853362
Hero Member
*
Offline Offline

Posts: 1714853362

View Profile Personal Message (Offline)

Ignore
1714853362
Reply with quote  #2

1714853362
Report to moderator
vh
Hero Member
*****
Offline Offline

Activity: 699
Merit: 666


View Profile
July 05, 2017, 09:55:54 PM
 #2

You need to take into account future blocks to detect orphans.   The longer path is the main chain.

alikim (OP)
Member
**
Offline Offline

Activity: 80
Merit: 11


View Profile
July 06, 2017, 08:30:25 AM
 #3

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?
ranochigo
Legendary
*
Offline Offline

Activity: 2954
Merit: 4166


View Profile
July 06, 2017, 11:02:41 AM
 #4

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?
At least one; if any of the chain has a higher weight (difficulty and length factored in), those that see that chain will accept it as valid. That is the behaviour of the reference client.

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.

.
.HUGE.
▄██████████▄▄
▄█████████████████▄
▄█████████████████████▄
▄███████████████████████▄
▄█████████████████████████▄
███████▌██▌▐██▐██▐████▄███
████▐██▐████▌██▌██▌██▌██
█████▀███▀███▀▐██▐██▐█████

▀█████████████████████████▀

▀███████████████████████▀

▀█████████████████████▀

▀█████████████████▀

▀██████████▀▀
█▀▀▀▀











█▄▄▄▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.
CASINSPORTSBOOK
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀▀█











▄▄▄▄█
DannyHamilton
Legendary
*
Offline Offline

Activity: 3388
Merit: 4616



View Profile
July 06, 2017, 01:37:35 PM
 #5

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.
alikim (OP)
Member
**
Offline Offline

Activity: 80
Merit: 11


View Profile
July 06, 2017, 05:04:39 PM
 #6

Great answers, thank you!
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!