6

From what I understand, the difficulty required by the proof-of-work in bitcoin is a function of block history, specifically the average time between last ~2000 blocks, with the intention that its hovers around the 10 minute mark.

The function relies on the timestamp of when the block was created. It occurs to me that when nodes are calculating blocks, they have an incentive to overstate the timestamp (because the difficulty would then be recalculated to allow for quicker mining of new blocks, which would lead to a higher rate at which that node receives rewarded bitcoins).

The protocol states nodes should reject blocks that have timestamps that look invalid (e.g. too far into the future), but again it relies on nodes being honest.

In short, what is the incentive for miners to not overstate timestamps? Am I right in thinking that if a majority of miners/nodes colluded in overstating + not rejecting invalid timestamps, then the entire bitcoin network would start generating bitcoins faster?

Note: It occurs to me that as the total pool of bitcoins increases + rate of reward halves every 4 years, this 'speeding up' of the bitcoin block generation has less and less impact.

3

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.

Whenever a node connects to another node, it gets a UTC timestamp from it, and stores its offset from node-local UTC. The network-adjusted time is then the node-local UTC plus the median offset from all connected nodes. Network time is never adjusted more than 70 minutes from local system time, however.

So, if you want your block accepted by other nodes, you won't mess with anything close to deviating from the current time by two hours.

But the protocol doesn't care how many blocks are being mined, it only will use those durations of the past 2,016 blocks to adjust difficulty when that periodic event occurs.

  • How does the network know that a new block is "new"? If a new user is downloading the entire blockchain, why aren't all of those old block rejected? Thank you so much in advance! – user5107 Jan 5 '14 at 2:59
  • 1
    @user5107, downloaded blocks follow the same validation rules, but the greater than the median time stamp of the past 11 blocks is relative. So when validating block 100, you look at time stamps of blocks 89-99 to check the median. – morsecoder Dec 19 '14 at 12:19
3

The major factor for pools is that if they do that, their blocks might get rejected by the network and the honest nodes. That would mean not only loss of profits for the pool and the miners, but also a loss of confidence. Both of those factors might result in the pool losing its miners and hashpower.

  • Yep that sounds right. Interestingly, I think non-mining nodes could start accepting blocks with invalid timestamps, and not been penalized while +51% of miners are honest (the longest blockchain will consist of valid blocks). Then when some threshold of non-mining-nodes-accepting-invalid-timestamps is reached, +51% miners could start generating invalid timestamps. Far fetched I know, but interesting to think about. At the end of the day, I guess such an attack would undermine confidence in bitcoin, and thus the benefit of such an attack. – BitPiggy Oct 17 '12 at 7:32
  • 1
    51% or more of miners might collude to change timestamps, but my client still won't accept their blocks. So no, that isn't something the miners have control over. – Stephen Gornick Oct 17 '12 at 9:32
  • 2
    Miners collectively have a vested interest in keeping Bitcoins worth as much as possible. So the idea that miners would conspire to reduce the value of Bitcoins doesn't seem very likely to me. – David Schwartz Oct 17 '12 at 18:15
  • What basis are they rejected, specifically? Do you have a code sample? Thank you so much in advance! – user5107 Jan 5 '14 at 2:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.