Bitcoin Forum

When miner encountering a fork, one fork has less difficulty but longer in length, while the other fork is more difficult but short. Which fork should miners choose :)?

I assume you talk about accidental hard fork when two miners find the same block simultaneously. When this happens, later block decides which chain becomes the longer one. In this case, miner should choose the longest chain because if they mine the short one, that means they are mining a fork, which is not supported, won't be supported and has no idea to mine.

Miners should generally choose the fork with the longest length.
In blockchain terminology, the length refers to the number of blocks on a particular fork. Choosing the longer fork ensures that the miner is contributing to the majority of the network's computing power, which enhances the security and stability of the blockchain.

Visualization of a blockchain fork event: the network reconverges on a new longest chain:
http://talkimg.com/images/2023/05/14/msbt_0806443ad2e86c891195.png

This is wrong.

Nodes will follow the chain which has the most accumulated work. This is not necessarily the chain with the longest length.

Usually when we reorganize one or two blocks, then the blocks will obviously have the same difficulty and therefore represent the same amount of work, so the longest chain will be the chain with the most work. However, if a fork lasted long enough to significantly stretch beyond a difficulty retargeting and in to a new difficulty epoch, then blocks on each chain would represent a different amount of work and so the longest chain may not necessarily be the chain with the most work. Nodes will switch to a shorter chain if that chain has more accumulated work.

This is also wrong, let me explain why I was not wrong.

While a shorter and more difficult fork may offer higher rewards in the short term, it is important for miners to consider the long-term implications. The longer fork represents the consensus of the network, as it has accumulated more computational work and has a greater number of participants supporting it. By choosing the longer fork, miners align themselves with the majority, reducing the risk of their blocks being orphaned or invalidated in the future.
It's worth noting that miners typically rely on consensus rules implemented by the network's protocol and the consensus of the majority of miners and nodes. Following these rules and aligning with the majority helps maintain the integrity and stability of the blockchain.

Being the longer chain does not mean a fork has accumulated more computational work. Proof of work is determined by the difficulty in solving the puzzles which influences the amount of computational energy that is spent. A longer chain can have significantly less computational work if it has a low difficulty level.

In the proof of work model, consensus should be determined by the greater work done.

- Jay -

This is not correct.

As I explained above, the longest chain does not necessarily contain the most accumulated work. I could fork bitcoin right now, drop the difficulty to 1, and then churn out 10,000 blocks in a few minutes. My new chain would be far longer than the main chain, but have much less accumulated work because the number of hashes required to generate all 10,000 of my blocks would only be tiny fraction of the number of hashes to generate a single block on the main chain. The main chain, although shorter, would have the higher amount of work, and so everyone else would stay on that chain and not switch to my longer chain.

No, they do this by aligning themselves with the chain with most work, which again, is not the same as the longest chain.

That's a greate explanation and a pretty crucial point. So a difficulty comparison is done every time by just checking the zeros in front of the latest blockhash?

Reading about the accidental-fork-by-miners issue, I remember there was one instance, maybe already 10 years ago, when this happened 6 or seven times in a row. It then became apparent that there was a bug causing this. Need to look up what happened there exactly.

Not quite. The amount of work is based on the current difficulty, and not the individual hashes of each block. Every block in the same difficulty epoch will add the same amount of chain work, regardless of the actual hashes or the number of leading zeroes in each hash.

The difficulty of mining is determined by the network protocol and is adjusted periodically based on the target set by the protocol.

In most blockchain systems, including Bitcoin, the difficulty adjustment algorithm takes into account the average time it took to mine a certain number of blocks in the past. If the blocks were mined too quickly, indicating that the network's total computational power exceeds the intended rate, the difficulty is increased. Conversely, if blocks were mined too slowly, the difficulty is decreased.
This is designed to ensure that the average time to mine a block remains relatively constant over time.

Considering that both chains are supposed to exist at the same time, and having forked apart from a common block, how would the longer chain have a lower difficulty level if both chains adhered the difficulty retargeting protocol?

I've answered this above:


Usually, the longest chain does indeed have the most work, since as you say, when the chains fork each block on each chain adds the exact same amount of work. If the fork continues past a retargeting, then the chains will have different difficulty adjustments since they will not have found all the blocks between the fork and the retargeting in the exact same amount of time. From that point on, the blocks added to each chain do not add the same amount of work, and so the longer chain will not necessarily be the chain with the most work.

Bitcoin difficulty adjustment does not take a random period of time in the past, it only accounts for the last 2,016 of confirmed blocks and uses the time taken to mine a block averagely to adjust the difficulty.

As mentioned it depends on if the chains last into the next retargetting, which will result in different amounts of work in the different chains.

- Jay -

A fork will occur when on the initial chain, there is split to two or three different chains. Miners and mining pools have to choose what chain they will continue to mine with and obey those consensus on that chain.

Usually mining pools, nodes, and miners will choose a longest chain to continue their work (mining blocks and confirm transactions). They will less likely to choose shorter chains as it contains more risk for them. The second scenario only happens when some mining pools intentionally support a consensus which leads to that shorter chain so they clearly know what they are doing when they choosing that short chain, then become a fork.

Hell no, do you know that most of forks are useless and will die with time?

A comparative analysis of Bitcoin forks (https://coinmetrics.io/a-comparative-analysis-of-bitcoin-forks/).
How many Bitcoin forks are there? (https://forkdrop.io/how-many-bitcoin-forks-are-there)

You know, the miner should choose to mine the longest chain that the network is likely to accept. Because mining a short chain will be pointless, because the network will eventually abandon that chain as well as I know and understand the point you are making.

And accidental hard fork are also relatively rare and resolved quickly as well too.

Source: https://en.wikipedia.org/wiki/Fork_(blockchain)
           https://www.bitstamp.net/learn/crypto-101/what-are-blockchain-forks/

Once again, as I've said multiple times above, nodes and miners choose the chain with the most chain work, which is not synonymous with the longest chain.

In the event of a fork of just one or two blocks where both chains have the same amount of work, then nodes will generally pick the chain which they saw first.

Actually, you are right! I always thought the longest chain was the answer because the whitepaper says:

It's true that originally the block height was a main factor but it was changed later when people saw the danger of height over most work where one can mine blocks locally  with low difficulty, manipulate timestamp and make his chain the longest chain, broadcast it and do the magic. To protect ourselves from this accident, we should follow chain with more accumulated work.

Thank you for this post, you really enlightened me.

Correct, and well noted!

When writing the Whitepaper, Satoshi clearly didn't envisage the issue with a longer chain having less work, as I have described above. The code to change from height (longest chain) to chainwork (chain with the most work) was implemented in 0.3.3 in July 2010, as you can see here: https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420

When a fork occurs, miners have the ability to choose which blockchain branch they will work on. They make this choice using consensus algorithms, which typically rely on computational power (Proof of Work) or other criteria   

1) According Bitcoin Proof-of-Work consensus, Miners follow the valid chain with the most accumulated Proof-of-Work

2) Traditionally this chain is called "the longest chain". However, this name is confusing.

3) Often the heaviest valid chain coincide with the longest valid chain in Bitcoin. However, in general case it might not be true.

4) There are theorems which claim that under certain conditions heaviest chain coincide with the longest chain.

5) In this context, other rules of Bitcoin protocol has an important role too. For example, Bitcoin client doesn't append into the blockchain blocks which have timestamps more than 2 hours into the future.

If this rule is discarded, then a solo miner can mine a longest chain by systematically putting timestamps far into the future. In this scenario, the block difficulty will decrease and this solo miner will be able to mine blocks with a little effort. However, his personal longest chain won't have the most accumulated Proof-of-Work, unless he has more computational power than the rest of the network.

If this solo miner poses more computational power than the rest of the network, he may generate the longest and the heaviest chain in the network. However, his chain might be truncated by peers, who will discard those blocks whose timestamps are far in the future. After this truncation his chain might be not as long and difficult as it was before. In this edge case scenario miners might follow the chain which is neither the longest, nor the heaviest.   

I've read this sentiment in the forum many times in the past, but is it true?

First of all, the current block height is over 790,000 so you'd need a LOT more than 10,000 blocks to "be far longer than the main chain".

Secondly, after you've churned out 2016 blocks, in order to create valid blocks, you'd need to immediately increase your difficulty by a factor of 4, then again after the next 2016 blocks, and again after the next 2,016 blocks. Pretty quickly, you'd encounter a situation where your particular equipment can't mine blocks any faster than an average of one block every 10 minutes.  You could shut your equipment off for a few weeks to get the difficulty to come back down, but you'd burn a lot of time waiting, and then once you've spent a few days mining another 2016 blocks, the difficulty would shoot right back up again.

You can start from the Genesis Block, or from the current block. In both cases, changing the rule from the heaviest chain to the longest chain is a hard-fork change. That means, the starting point is not that important, because it is hard-fork anyway. Also, "drop the difficulty to 1" without going through difficulty adjustments is again a hard-fork. When it comes to this rule, you can even see it in action by looking at testnet3: it is much longer, but it also has much lower chainwork.

Not really, because you don't have to put the correct timestamp in your blocks. Also note that difficulty increase is not absolute, but relative. So, if you count, how long it took to mine all blocks from 2009 to 2023, and you compare it to the time we should get there (for example by looking at halvings), then you won't reach the current difficulty. That means, your log2_work could be for example around 40, and your chain could be longer than the current one.

There is no need to wait. You can mine blocks with future timestamps here and now, and release them in the future. Then, someone may even join your network, and try to mine new blocks, but if you will have a lot of blocks prepared in advance, then you can always trigger chain reorganization on those clients.

Technically no, because as vjudeu has pointed out, no one would join my chain anyway since I would have to hard fork to drop the difficulty like this. I was simply using it as an analogy as to why the longest chain is not synonymous with the chain with the most work.

For the longest/most work argument, it doesn't matter. Even one block more would be enough for all nodes to swap to the longer chain if this was the criteria being used.

If we did use the longest chain, then what would be possible would be a miner mining in secret while manipulating the time stamps on their blocks to artificially drop the difficulty. Theoretically a miner can drop the difficulty to 1 by incrementing the timestamp on the first 2,015 blocks of each difficulty period by 1 second, and then setting the final block's timestamp to the current time. If we actually used longer chain rather than most chain work, then a very small minority miner could reorg as much of the blockchain as they liked by using this method.

They will follow the one that their nodes validated 1st. Minor wording but if for whatever oddball reason 1 fork has blocks that take longer for the nodes to come out and finish the work that says yes this is a valid then the other will win. In theory a node should validate in seconds, but if something is funky in a block that for whatever reason takes longer to validate then another one can sneak in behind it.

This is a very very very edge case scenario but it's worth a mention. If you are running a proper mining pool you have nodes distributed all over the wold behind some fairly sophisticated firewalls and security devices. So, there could be some situations where 2 blocks come in within fractions of second and even though one got there 1st it was still processed 2nd and therefor lost. I have said it a few times, this is also important to note about pools that DON'T use real security appliances they can see and process blocks that other pools have not even started to process because their front end security devices are still working on it. Once again we a taking fractions of seconds or a second or 2 at most but we have seen blocks come in back to back that quickly.

-Dave

Hard-fork is a strawman argument.  EVERY time this argument is used, it's used as an example of "If Bitcoin WAS designed that way, then this is what could happen."  My point is no, that couldn't happen. Even if Bitcoin was designed that way.  There absolutely are problems with using longest chain instead of most work, and I would never suggest that we should use longest chain.  I'm just saying that the argument that I see over and over, that "someone could start at block 1 and build a longer chain in minutes (or days, or weeks, or even a few months)" under that scenario is dishonest and misleading.

This is the piece I wasn't thinking about.  I'll have to think about that a bit. You might be right. That might be enough to make it possible.


Yes. This is the part I wasn't thinking about.  You're probably right. I'll think about it a bit.



Maybe.  I'm not 100% convinced yet, but I'm coming around.

It seems like in order to adjust timestamps enough to keep the difficulty low, you'd have to have timestamps that average to at least 10 minutes per block (otherwise at the end of 2016 blocks, the difficulty would increase).  Meanwhile, the current blockchain has an average over it's lifespan that is significantly less than 10 minutes (which is WHY the difficulty almost always increases).  Therefore, if you started your block 1 with a timestamp of January 1, 2009, then it seems like you'd still have less blocks in your blockchain than the current blockchain has by the time you had advanced your timestamps all the way to now.

I'm beginning to suspect that, with some careful planning, it can MAYBE be accomplished, but it certainly isn't as simple as "set difficulty to 1, start at block 1, mine more blocks than the current blockchain in a few minutes."

One way that it definitely COULD be accomplished would be if you used a timestamp in block 1 that was significantly earlier than January 1, 2009.  However, since the genesis block is coded into the software and defines which blockchain you are on, that wouldn't work. None of the existing software would recognize it as a valid longest chain, since it would have the wrong genesis block.

Here's how it would work.

For this, it is important to know that block timestamps are governed by a lower bound of the median timestamp of the last 11 blocks plus one second, and an upper bound of 2 hours in the future.

Let's say I am a miner with a small percentage of the hashrate. I mine my own competing chain in secret. It takes me longer than 10 minutes per block, but that's ok. Let's start at the beginning of the next difficulty epoch for the sake of this example.

I mine a block and give it time x. The next block that I mine, I give time x+1 second. The block after that, x+2 seconds. And so on, for 2,015 blocks, up to x+2,014 seconds. The last block of the difficulty epoch I give a timestamp of the current time.

Let's say it took me 60 days to mine those 2,016 blocks. The difficulty now drops by a factor of 4, the maximum allowable change in one retarget. I keep mining, but now consider the timestamps of the last 11 blocks I just found. The last block I just found has a timestamp of the current time, but the 10 blocks before that all have a timestamp of x plus a few seconds, which is now 60 days ago. If we take the median of those 11 blocks, then we still have a timestamp which is 60 days ago.

So I can keep mining blocks, and continue giving all the blocks I find a timestamp of x+1 more second, which is 60 days ago. I do this for another 2,015 blocks, and then the last block of the epoch I set to the current time. This time, let's say it took me 15 days to mine those blocks, since the difficulty was lowered by a factor of 4. However, the first block of these 2,016 blocks still has a timestamp of x+some seconds, which is now 75 days ago. So the protocol thinks it took me 75 days to mine these 2,016 blocks, and the difficulty is lowered by another factor of 4. Now consider again the timestamp of the last 11 blocks. The last block has a timestamp of the current time, and the 10 before that have a timestamp of 75 days ago. The median timestamp is 75 days ago.

So I repeat the process again. Every difficulty epoch I mine 2,015 blocks incrementing the time by 1 second only from the initial value of x all those days ago, and then the last block at the current time. This is all within the rules set out above. Each time we hit a retargeting, the protocol thinks it has taken me longer and longer to find the last 2,016 blocks, and the difficulty drops by a factor of 4 each time. And each time, the median timestamp of my last 11 blocks never moves by more than a few seconds.

Very quickly I can drop the difficulty to 1 and keep it there. I can churn out a block a second for as long as I want. If the rule was to follow the longest chain, then I can broadcast this chain I have been mining in secret and successfully take over the entire network indefinitely.

(emphasis added by me)

There it is. This is what I was missing.

For some reason, I thought it was the mean of the last 11 blocks.

With the rule being the median of the last 11 blocks, I can see how this can happen.

If the rule was the mean of the last 11 blocks, then using the "current time" for the last block of the epoch would force the next block of the epoch to be MUCH later and the timestamps would quickly catch up to today.


I think I had this wrong too.  I thought the last block of the previous epoch was the first block of the new epoch.  So, I was thinking that setting the time on the last block of the previous epoch to "current time" and then doing the same again on the current epoch (if the epoch was completed in less than 5040 minutes) would result in the difficulty increasing again by a factor of 4. If the last block of one epoch is not the first of the next, then I can see the opportunity for the epoch duration to be continuously manipulated by always jumping back in time for the first block of the epoch.

As far as I understand, the reason median is used is because it guarantees that the lower bound never goes backwards. With each new block found it either advances, or doesn't change. If the mean was used, then there is the possibility that the minimum timestamp could move backwards.

Thanks to an off-by-one error, not only is the last block of one epoch different to the first block of the next epoch, but actually the time it takes to mine the first block of every epoch is not taken in to account whatsoever when calculating the difficulty.

The chain where the blocks can be computed using less work bought that privilege by reaching the retargeting later, so there is not much to gain. Or are you talking about a timestamp manipulation attack?

Well, whether or not there is much to gain depends on how long the fork lasts for.

Also a possibility, as I've discussed earlier in this thread: https://bitcointalk.org/index.php?topic=5452676.msg62269397#msg62269397

That last block is expected to violate the Future Block Time Rule (2 hours). Won't other nodes reject the block when the secretly mined chain gets published?

Why do you think that? The upper limit as I stated above is two hours in the future based on network adjusted time. If I give it a timestamp of the network adjusted time (NAT), then that is obviously less than NAT + 2 hours.

The timestamps of my previous 2,015 blocks do nothing to change the network adjusted time.

To be honest, this is by far the most interesting and educational article that I have found about which chain should miners follow, the longest or the strongest one.
I suggest everyone to read this article, it's very interesting: The Longest Blockchain is not the Strongest Blockchain (https://cryptoservices.github.io/blockchain/consensus/2019/05/21/bitcoin-length-weight-confusion.html).

That's called a timewarp attack, there is an example I put into the testnet chain back whenever this edition of testnet started. An attack chain can advance time at a rate of about 1 sec per 6 blocks while keeping difficulty going DOWN (or at the minimum).

FWIW the timewarp attack can be prevented with a simple and fairly conservative constraint on the timestamp of one block during the interval-- a constraint that last time I checked had never been violated on mainnet.   Bluematt had a proposal introduce a softfork to fix it, but by the time he started on that the bitcoin ecosystem had started turning too toxic for people to want to pursue proposals --- so even years after it was realized that it could be fixed with a ~1 LOC change and deployed in a softfork this vulnerability remains unfixed and the mining code hasn't been changed to obey the rule to make a fix safer to deploy (there were no violations in the chain last I checked but in theory a miner could innocently violate the rule, so it would be safer to first get miners on code that won't violate the rule).

With no timewarp attack the comparison *still* needs to be on work rather than length, because an attacker could still gain an advantage over the honest chain on a fork that has lower difficulty but it's closer to a boundary effect e.g. relating to the fact that the honest chain may not be as far in he future as it was allowed to be or the honest boundary block wasn't as far in the future as it could have been (keep in mind the last difficulty interval of the attack can advance the clock at the minimum rate-- they don't care that the difficulty will go back up again, they just want to be able to produce more blocks than the honest network in spite having somewhat less hashpower before the difficulty does go back up)...