4 ms·

This is nothing, it failed to produce blocks for -days- before There are anomalous blocktimes throughout the entire history. Long times, short times, even nega

by aliqot 4y ago

This is nothing, it failed to produce blocks for -days- before There are anomalous blocktimes throughout the entire history. Long times, short times, even negative times. Press play here for an order tabular list of all anomalous block times outside of a normal deviation: https://blockchainsql.io/wkeno3 https://blockchainsql.io/wkeno3

gojomo 4y ago
Other sources report the only 'days' delay was between block 0 and block 1 – and thus likely an idiosyncratic effect of the launch. Apparently, also, there were a few more >20hr blocks in the 1st half of 2009, when interest was very, very low. So while technically true, without further details, your comment implies something that's not really reflective of the system today. Of course, as a stochastic process, it's possible that the delay reaches any length whatsover. But it becomes vanishingly unlikely, under the rough assumption that hash power stays at the level observed at the last difficulty-adjustment. By the formula Tadge Dryja shared, a 1-day (1440 minute) delay would be expected once every 6.568×10^57 average Gregorian years, or far far far longer than the age of the universe so far: https://www.wolframalpha.com/input?i=%281%2Fe%5E%28-1440%2F10%29%29%2F144+days https://www.wolframalpha.com/input?i=%281%2Fe%5E%28-1440%2F1... (If large amounts of hash power disappear for any reason – war, regulations, sabotage, bugs, massive price drops, etc – then all bets are off.)
- deleted 4y ago
  [deleted]
- sidewndr46 4y ago
  Anyone arguing a delay between block 0 and block 1 is not arguing from a rational standpoint. It is akin to arguing that an airline had days of no flights where they didn't fly any routes at all, because the company was obviously founded and incorporated at least a few weeks before their first commercial service was introduced.
kevincox 4y ago
How can negative times happen? Each block contains a hash of the previous block so in order to mine the next block you would need to know the hash of the previous block which more or less means that you need to know the previous block which means it existed first. Is this some play going on with embedded timestamps or something that are not necessarily monotonic?
- aliqot 4y ago
  timestamps are submitted by the miner solving the block, so a misconfigured clock could be the culprit, but most often these are attacks against a difficulty adjustment algorithm or re-org scheme where a lot of hashrate is used to overwhelm consensus and assert that their tampered chain is the correct chain. This is typically used for forcing a block history in smaller networks where it is easier to dominate the hashrate. Zawy12 is a researcher who has put a considerable amount of work into different rolling window hashrate adjustment algorithms to combat this, like LWMA etc. It's a fun fact that not a lot of people know: These same algorithms are used in heating elements and thermocouples so that the heat level does not 'overshoot' the objective and is able to maintain heat in windy environments or variable temp environments while staying in a certain window. If you've ever used an e-nail or soldering iron, chances are you've used something that employs this same tech.
- nullc 4y ago
  The internal timestamps are not necessarily monotone because if they were forced to be then if the single clown in front of you set the timestamp incorrectly into the future you'd be forced to do so too. If you want monotone stamps from the block header timestamps you can post process them to make them monotone. ... if that kind of error would be superior for your purposes. For this discussion probably the best thing to do is ignore any non-monotone timestamps (and maybe the block before them too). Because the protocol rules don't have any strong incentives for setting the timestamps precisely they're best taken as approximate.

by aliqot 4y ago

gojomo 4y ago

Other sources report the only 'days' delay was between block 0 and block 1 – and thus likely an idiosyncratic effect of the launch. Apparently, also, there were a few more >20hr blocks in the 1st half of 2009, when interest was very, very low. So while technically true, without further details, your comment implies something that's not really reflective of the system today. Of course, as a stochastic process, it's possible that the delay reaches any length whatsover. But it becomes vanishingly unlikely, under the rough assumption that hash power stays at the level observed at the last difficulty-adjustment. By the formula Tadge Dryja shared, a 1-day (1440 minute) delay would be expected once every 6.568×10^57 average Gregorian years, or far far far longer than the age of the universe so far: https://www.wolframalpha.com/input?i=%281%2Fe%5E%28-1440%2F10%29%29%2F144+days https://www.wolframalpha.com/input?i=%281%2Fe%5E%28-1440%2F1... (If large amounts of hash power disappear for any reason – war, regulations, sabotage, bugs, massive price drops, etc – then all bets are off.)

deleted 4y ago
[deleted]
sidewndr46 4y ago
Anyone arguing a delay between block 0 and block 1 is not arguing from a rational standpoint. It is akin to arguing that an airline had days of no flights where they didn't fly any routes at all, because the company was obviously founded and incorporated at least a few weeks before their first commercial service was introduced.

kevincox 4y ago

How can negative times happen? Each block contains a hash of the previous block so in order to mine the next block you would need to know the hash of the previous block which more or less means that you need to know the previous block which means it existed first. Is this some play going on with embedded timestamps or something that are not necessarily monotonic?

aliqot 4y ago
timestamps are submitted by the miner solving the block, so a misconfigured clock could be the culprit, but most often these are attacks against a difficulty adjustment algorithm or re-org scheme where a lot of hashrate is used to overwhelm consensus and assert that their tampered chain is the correct chain. This is typically used for forcing a block history in smaller networks where it is easier to dominate the hashrate. Zawy12 is a researcher who has put a considerable amount of work into different rolling window hashrate adjustment algorithms to combat this, like LWMA etc. It's a fun fact that not a lot of people know: These same algorithms are used in heating elements and thermocouples so that the heat level does not 'overshoot' the objective and is able to maintain heat in windy environments or variable temp environments while staying in a certain window. If you've ever used an e-nail or soldering iron, chances are you've used something that employs this same tech.
nullc 4y ago
The internal timestamps are not necessarily monotone because if they were forced to be then if the single clown in front of you set the timestamp incorrectly into the future you'd be forced to do so too. If you want monotone stamps from the block header timestamps you can post process them to make them monotone. ... if that kind of error would be superior for your purposes. For this discussion probably the best thing to do is ignore any non-monotone timestamps (and maybe the block before them too). Because the protocol rules don't have any strong incentives for setting the timestamps precisely they're best taken as approximate.