4 ms·

> The Bitcoin Difficulty adjusts dynamically so that a proper hash is found on average once every ten minutes. So here, the bitcoin network needs to defer to t

by rocqua 9y ago

> The Bitcoin Difficulty adjusts dynamically so that a proper hash is found on average once every ten minutes. So here, the bitcoin network needs to defer to the actual time. The difficulty is adjusted every 2016 blocks. Then, the time it took to create those blocks is determined by looking at actual time stamps of the blocks. That is, time stamps that purport to be the time in UTC when the block was created. I never understood how these time stamps are trusted and reliable. If I recall correctly, a block with a creation time that is 'too far of' is supposed to be rejected by well behaving nodes. Yet, getting accurate time-stamps is the problem bitcoin is trying to solve. I suppose that for almost anyone, it is feasible to get time accurate down to 60s and that might be enough that the difficulty calculations aren't affect as much. Especially due to the averaging over 2016 blocks. edit: I found this link en.bitcoin.it/wiki/Block_timestamp it states that: > 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. So the limits are quite loose. (An interesting footnote from memory) The difficulty calculation contains a bug where it calculates the average block time ignoring either the first or last block. Thus, the block time is slightly wrong. However, changing this would be a hard-fork because 'the running concensus code is the spec'. That is, if you fix this bug everyone has to fix it at the same time.

johnmaguire2013 9y ago
If you choose a time in the future, other nodes could reject you. If you choose a time obscenely short (say, 1 second after the last block), presumably the difficulty is an average of many created blocks, and it would take a lot of malicious actors to make this valid. Plus, if Block A is found at 10:00, and I find Block B at 10:10 but say it was 10:01... and then Block C is found at 10:20, the average of these three is ~10 minutes still.
- tromp 9y ago
  There is no requirement that timestamps be nondecreasing. A block at 10:00 can be followed by one at 9:59. What is required however it that a timestamp be at least the median of the last 11 blocks.
api 9y ago
The recalculation window is substantially larger than the permitted clock drift window, so it would take a large number of consistently malicious actors to affect difficulty. Even then all you'd get is a difficulty adjustment, so it's not a catastrophic attack.
- rocqua 9y ago
  Is there a way to use clock drift to exclude certain miners? That is, change the time-stamp in such a way that honest miners using an actual time-stamp might get their blocks denied?
  - gruez 9y ago
    you can already exclude certain miners by not building ontop of their blocks.
    - jacobush 9y ago
      Yes, but that shut the question down. There may be interesting nuances left to discover. If we do as you suggested, we would actively "attack" certain miners, quite openly. With a time shift, could miners collude to increase the burden on other miners not privy to the collusion? Perhaps ever so slightly?
bigiain 9y ago
> I never understood how these time stamps are trusted and reliable. I guess for difficulty adjustment purposes, that's not a hard requirement, it'd be closer to "plausible and consensus agreed timestamps". It doesn't matter much if a bad actor can try to slightly influence the raising or lowering of difficulty, so long as the long-term once every ten minutes "clock tick" holds and can be used to define transaction ordering.
omarforgotpwd 9y ago
First of all the difficulty doesn't need to be set perfectly. It just can't be way too high or way too low. Even if the algorithm is slightly off the optimal difficulty everything still works fine. Secondly, because other nodes need to validate the submitted blocks for the miners get any reward they are strongly incentivized to fill out all the information in the block as correctly as possible, including the time. Imagine mining a block and getting a 12.5 BTC reward (currently valued at around $100,000) and having it get rejected because you put the wrong timestamps -- ouch. I don't know what logic they use to see if the timestamp is valid, but even if there was a bug in this logic that was used for nefarious purposes other peers would wise up and patch the software if it hurt anyone in any way. So yes, the difficulty calculation may not be perfect and could even be subject to manipulation but it seems good enough for now to me.
ikeboy 9y ago
Bingo. Vitalik Buterin showed how to abuse this to soft fork (!) Bitcoin to have 2 minute blocks https://www.reddit.com/r/btc/comments/428tjl/softforking_the_block_time_to_2_min_my_primarily/ https://www.reddit.com/r/btc/comments/428tjl/softforking_the...

by rocqua 9y ago

johnmaguire2013 9y ago

If you choose a time in the future, other nodes could reject you. If you choose a time obscenely short (say, 1 second after the last block), presumably the difficulty is an average of many created blocks, and it would take a lot of malicious actors to make this valid. Plus, if Block A is found at 10:00, and I find Block B at 10:10 but say it was 10:01... and then Block C is found at 10:20, the average of these three is ~10 minutes still.

tromp 9y ago
There is no requirement that timestamps be nondecreasing. A block at 10:00 can be followed by one at 9:59. What is required however it that a timestamp be at least the median of the last 11 blocks.

api 9y ago

The recalculation window is substantially larger than the permitted clock drift window, so it would take a large number of consistently malicious actors to affect difficulty. Even then all you'd get is a difficulty adjustment, so it's not a catastrophic attack.

rocqua 9y ago
Is there a way to use clock drift to exclude certain miners? That is, change the time-stamp in such a way that honest miners using an actual time-stamp might get their blocks denied?
- gruez 9y ago
  you can already exclude certain miners by not building ontop of their blocks.
  - jacobush 9y ago
    Yes, but that shut the question down. There may be interesting nuances left to discover. If we do as you suggested, we would actively "attack" certain miners, quite openly. With a time shift, could miners collude to increase the burden on other miners not privy to the collusion? Perhaps ever so slightly?

bigiain 9y ago

> I never understood how these time stamps are trusted and reliable. I guess for difficulty adjustment purposes, that's not a hard requirement, it'd be closer to "plausible and consensus agreed timestamps". It doesn't matter much if a bad actor can try to slightly influence the raising or lowering of difficulty, so long as the long-term once every ten minutes "clock tick" holds and can be used to define transaction ordering.

omarforgotpwd 9y ago

First of all the difficulty doesn't need to be set perfectly. It just can't be way too high or way too low. Even if the algorithm is slightly off the optimal difficulty everything still works fine. Secondly, because other nodes need to validate the submitted blocks for the miners get any reward they are strongly incentivized to fill out all the information in the block as correctly as possible, including the time. Imagine mining a block and getting a 12.5 BTC reward (currently valued at around $100,000) and having it get rejected because you put the wrong timestamps -- ouch. I don't know what logic they use to see if the timestamp is valid, but even if there was a bug in this logic that was used for nefarious purposes other peers would wise up and patch the software if it hurt anyone in any way. So yes, the difficulty calculation may not be perfect and could even be subject to manipulation but it seems good enough for now to me.

ikeboy 9y ago

Bingo. Vitalik Buterin showed how to abuse this to soft fork (!) Bitcoin to have 2 minute blocks https://www.reddit.com/r/btc/comments/428tjl/softforking_the_block_time_to_2_min_my_primarily/ https://www.reddit.com/r/btc/comments/428tjl/softforking_the...