Topic: A question about miners choosing fork. (Read 460 times)

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

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.

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.

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?

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://bitcointalksearch.org/topic/m.62269397

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?

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.

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

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.

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.

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

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.

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.

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.

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.   

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   

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

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.

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.

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/