Bitcoin Forum

Bitcoin => Bitcoin Technical Support => Topic started by: Wayne1337 on June 02, 2018, 08:22:30 AM



Title: Theoretical question about fork merges
Post by: Wayne1337 on June 02, 2018, 08:22:30 AM
Hello,

some days ago the following scenario came to my mind. Let's imagine, bitcoin is run by two miners A and B. At some point, they disagree with each other and build two forks that grow independently of each other but both forks strictly stick to the rules. Therefore, both forks are valid bitcoin block chains. Now, let's say one year later, A decides to share his fork with B because he knows that he has a longer chain. In my understanding, if B doesn't decide to break rules, B has to accept the chain of A. Is that correct?

In diffrerent words: What happens, if at some point a node of the mining system presents to the world a completly valid  but perhaps different block chain that is longer than the one the world is working on? Does theoretically the world accept that new chain or not?

Thanks in advance for your help!

Wayne


Title: Re: Theoretical question about fork merges
Post by: ranochigo on June 02, 2018, 08:35:25 AM
some days ago the following scenario came to my mind. Let's imagine, bitcoin is run by two miners A and B. At some point, they disagree with each other and build two forks that grow independently of each other but both forks strictly stick to the rules. Therefore, both forks are valid bitcoin block chains. Now, let's say one year later, A and B decide to work together again. They would like to merge their two forks.
You cannot merge any forks. Once the forks has blocks that has different rules or blocks that are different, the entire blockchain after that point in time will be different completely.
A has the longer fork. In my understanding, the rules now state that the fork of A dominates that one of B and becomes the only valid chain. Is that correct?
Both are valid. If both chains do not contain blocks or transactions that violates the protocol rules, they won't be invalid. The nodes would see two different chains with differing proof of work. The network will see the different chain and only accept the one with the longest proof of work, discarding the others.
In diffrerent words: What happens, if at some point a node of the mining system presents to the world a completly valid block chain that is longer than the one the world is working on? Does theoretically the world accept that new chain or not?
Yes. If its longer difficulty-wise, nodes will take that chain and build on it.


Title: Re: Theoretical question about fork merges
Post by: Wayne1337 on June 02, 2018, 08:39:24 AM
@ranochigo: Thanks for your reply. Could you please clarify what you mean with "difficulty-wise"? As far as I know, the longest valid chain is dominating, not necessarily that one with the highest difficulty. Is that wrong?


Title: Re: Theoretical question about fork merges
Post by: ranochigo on June 02, 2018, 08:47:22 AM
@ranochigo: Thanks for your reply. Could you please clarify what you mean with "difficulty-wise"? As far as I know, the longest valid chain is dominating, not necessarily that one with the highest difficulty. Is that wrong?
Difficulty-wise as in the chain with the longest proof of work. The longest chain with the highest accumulated difficulty requires more effort to make than another chain but with a much lower accumulated difficulty.

It doesn't have to be the longest chain but it has to be the one with the highest total proof of work. It wouldn't make sense to consider the chain length since its easy to produce blocks with a difficulty of 1.


Title: Re: Theoretical question about fork merges
Post by: Wayne1337 on June 02, 2018, 08:58:25 AM
@ranochigo: That's a good point. However, if you stay at difficulty 1, you probabliy won't be able to catch up with the original chain since your rate of calculating blocks is lower. Do you know what exactly is the formula to determine the dominating chain? Is it the longest chain with the highest difficulty? Or how do you calculate the actual work that was done to calculate a chain?


Title: Re: Theoretical question about fork merges
Post by: buwaytress on June 02, 2018, 09:02:34 AM
@ranochigo: Thanks for your reply. Could you please clarify what you mean with "difficulty-wise"? As far as I know, the longest valid chain is dominating, not necessarily that one with the highest difficulty. Is that wrong?
Difficulty-wise as in the chain with the longest proof of work. The longest chain with the highest accumulated difficulty requires more effort to make than another chain but with a much lower accumulated difficulty.

It doesn't have to be the longest chain but it has to be the one with the highest total proof of work. It wouldn't make sense to consider the chain length since its easy to produce blocks with a difficulty of 1.

Thanks for that... I had no idea that you could work on a competing chain on a different difficulty. Always understood that longest proof of work was assumed to be on the same difficulty as the current network sets, otherwise you wouldn't be following the rules. And always thought that this simply meant longest chain...

Otherwise, wouldn't it also then be possible to introduce a shorter chain with a much higher total proof of work? And have that one be the one nodes accept as valid chain?


Title: Re: Theoretical question about fork merges
Post by: ranochigo on June 02, 2018, 02:27:22 PM
However, if you stay at difficulty 1, you probabliy won't be able to catch up with the original chain since your rate of calculating blocks is lower.
Difficulty of 1 is the easiest. Lengthwise, and barring any difficulty increase, maybe?
Do you know what exactly is the formula to determine the dominating chain? Is it the longest chain with the highest difficulty? Or how do you calculate the actual work that was done to calculate a chain?
Unfortunately, no. I briefly scoured over the code and I couldn't find the relevant code (was a quick one since I'm on my phone right now). Generally, the blocks in the same target/nBits (difficulty) are considered to have the same amount of proof of work. I believe this would be the only logical explanation and its the only one I know.

Maybe achow101, HCP, Loyce and bob123 can help to point out the relevant codes; pretty curious too.


Title: Re: Theoretical question about fork merges
Post by: Wayne1337 on June 03, 2018, 06:48:18 AM
Maybe achow101, HCP, Loyce and bob123 can help to point out the relevant codes; pretty curious too.
achow101 answered the following: The work of one block is 2^256/(nBits+1) and the work of a chain is the sum of all blocks.


Title: Re: Theoretical question about fork merges
Post by: Wayne1337 on June 03, 2018, 07:55:57 AM
Since I have somehow exceeded the maximum of personal messages per day (which is 2), I am not able to ask achow101 another question. Who is into the meaning of nBits? If I understood this formula correctly, it means the following. Let's say to mine one block we need to draw tickets with the numbers 1 to 100. If we draw a ticket with the number 10 or less, we successfully mined the block. If we put that into the formula, we get 100/10=10, which is equal to the estimated times I need to draw tickets until I succeed. Does that make sense?

Or does it mean this: Again we need to draw tickets from 1 to 100 until we get a number 10 or less. We are lucky and draw a 5. Is the work in this case 100/5=20?

Thanks again for your help!


Title: Re: Theoretical question about fork merges
Post by: HCP on June 03, 2018, 09:45:36 AM
nBits is the "Target nBits". Basically, it is an "encoded" form of the target threshold (ie. the target number below which your block header hash must be to be considered valid)

Refer here: https://bitcoin.org/en/developer-reference#target-nbits

Basically, it's just your 256 bit unsigned integer, encoded such that it will fit into the 32 bit space available in the block header.


Title: Re: Theoretical question about fork merges
Post by: Wayne1337 on June 03, 2018, 10:35:31 AM
Basically, it's just your 256 bit unsigned integer, encoded such that it will fit into the 32 bit space available in the block header.
Thank you for the answer!
Otherwise, wouldn't it also then be possible to introduce a shorter chain with a much higher total proof of work? And have that one be the one nodes accept as valid chain?
If I got the concept now, the answer is yes.