A question about miners choosing fork.

[DannyHamilton]

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,

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.

[1715437936]

1715437936

[vjudeu]

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".

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.

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.

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.

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.

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.

[o_e_l_e_o]

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

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.

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".

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.

[DaveF]

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.

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

[DannyHamilton]

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.

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.

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.

Not really, because you don't have to put the correct timestamp in your blocks.

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.

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.

There is no need to wait. You can mine blocks with future timestamps here and now

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

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.

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.

[o_e_l_e_o]

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

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.

[DannyHamilton]

. . . block timestamps are governed by a lower bound of the median timestamp of the last 11 blocks plus one second . . .

(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 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.

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.

[o_e_l_e_o]

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

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.

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.

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.

[zeuner]

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.

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.

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?

[o_e_l_e_o]

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.

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

Or are you talking about a timestamp manipulation attack?

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

[zeuner]

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.

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?

[o_e_l_e_o]

That last block is expected to violate the Future Block Time Rule (2 hours).

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.

[Synchronice]

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.

[gmaxwell]

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.

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)...