2

So I understand that difficulty increases by some algorithm calculated every 2016 blocks. But my understanding is that this algorithm attempts to set a difficulty such that the average time it takes to mine a block is about 10 minutes. My understanding of verifiable time is that the only way to measure a time in minutes is by using trusted timestamping, which I assume bitcoin doesn't do (since it's not supposed to trust anyone).

So my question is, how does the bitcoin protocol measure time in seconds or minutes in order to determine what the difficulty should be?

I'm reading here that "every Bitcoin client compares the actual time it took to generate these blocks with the two week goal and modifies the target by the percentage difference". How does every bitcoin client affect the difficulty set by the network? Is this a scenario where there's minimum and maximum bounds on difficulty and any difficulty within those bounds is accepted by nodes in the network? Or is the calculation of difficulty something discrete and precise?

2

Yes, bitcoin should not trust anyone, but it trusts itself, i.e. its own blockchain. So, when the time comes to update the difficulty (as you said, every 2016 blocks), code grabs the timestamp of this last block, and the first block in this difficulty period (block with the index of: last index - 2016).

Comparing timestamps of those 2 blocks gives us the timespan between 2016 blocks, and allows for difficulty calculation.

You can check the code for it here: https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L55

actual_timespan = last_block->get_timestamp() - first_block->get_timestamp()

More information on what block timestamps are considered valid can be found here http://en.bitcoin.it/wiki/Block_timestamp

  • Ah so it's trusting that the miners of the first and last block in the set of 2016 wrote a correct timestamp. Couldn't malicious miners that want the difficulty to be lower or higher spoof different timestamps if they end up mining one of those critical blocks? – B T May 25 '17 at 21:25
  • Is there something in the protocol that puts verifiable or statistical bounds on the correctness of the block timestamps? – B T May 25 '17 at 21:29
  • @BT I'd have to look through the code for any possible checks on the timestamp, but there should not be any. Miners can put whatever timestamp they want, and if they have more than 50% hash power, they can force blockchain to act however they want to, since most of the blocks are theirs, and they control it. But with less hashing power, this is not possible because other people mine and find blocks, and see there is something fishy going on - same for the timestamp spoofing. – epson121 May 27 '17 at 16:12
  • 1
    edit: looks like I was way off on this last comment. See this for more info en.bitcoin.it/wiki/Block_timestamp – epson121 May 27 '17 at 17:11
  • Ah very interesting. Add this to your answer and I'll accept it! It would seem to me that this would allow time as measured by the bitcoin network to drift with respect to real time if there is some pressure to manipulate timestamps, but places some statistical constraints on how fast it can drift according to what percentage of the network has incentives to manipulate those timestamps. This could be pretty interesting as a way to validate timestamps in the future! – B T May 28 '17 at 22:34
0

According to http://en.bitcoin.it/wiki/Block_timestamp, bitcoin nodes only accept blocks with timestamps greater than the median of the previous 11 blocks and less than network-time + 2 hours. Network-time is the median time reported by all the peers a node is connected to. This gives statistical bounds on how much the time can drift given a mostly honest network.

For lots more information on how timestamps work, the incentives involved, and how they could be manipulated in an attack situation see:

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.