flatfly (OP)
Legendary
Offline
Activity: 1064
Merit: 1011
|
|
May 01, 2013, 06:07:15 PM |
|
Just curious, what is the longest time that a block has stayed unsolved? For instance, 234078 took 1 hour and 2 minutes to solve.
|
My main address: 1337sfeChyyzZLzdHLewXzcaAaJSNTM893.
|
|
|
|
|
|
|
|
The grue lurks in the darkest places of the earth. Its favorite diet is adventurers, but its insatiable appetite is tempered by its fear of light. No grue has ever been seen by the light of day, and few have survived its fearsome jaws to tell the tale.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
Come-from-Beyond
Legendary
Offline
Activity: 2142
Merit: 1009
Newbie
|
|
May 01, 2013, 11:25:27 PM |
|
Just curious, what is the longest time that a block has stayed unsolved? For instance, 234078 took 1 hour and 2 minutes to solve.
I recall being waiting for 97 minutes.
|
|
|
|
|
dooglus
Legendary
Offline
Activity: 2940
Merit: 1327
|
|
May 02, 2013, 06:33:18 AM |
|
As global hashrate increases, difficulty is increased to keep the mean time between blocks at 10 minutes.
But what happens to the variance of the time between blocks as the difficulty increases? From the above stats it would appear that it decreases.
|
Just-Dice | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | Play or Invest | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | 1% House Edge |
|
|
|
jackjack
Legendary
Offline
Activity: 1176
Merit: 1233
May Bitcoin be touched by his Noodly Appendage
|
|
May 02, 2013, 06:58:40 AM |
|
Yeah it decreases
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
FreeMoney
Legendary
Offline
Activity: 1246
Merit: 1014
Strength in numbers
|
|
May 02, 2013, 06:31:20 PM |
|
Can someone explain how that works? The variance decreasing?
|
Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
|
|
|
Zeilap
|
|
May 02, 2013, 08:08:21 PM |
|
My stats are a little rusty, but as far as I see, it doesn't, it goes up. Hashing is Bernoulli trial, either you beat the target or you don't. That gives mining a geometric distribution, and so the variance (in number of hashes required) is (1-p)/p 2. The re-targeting algorithm tries to keep the hashrate directly proportional to 1/p, so the variance in time quadratically increases with the hashrate. Right? I guess the phenomenon above was a much higher variance in hashrate because of people turning their computers off at night, whereas now the variance is greatly reduced due to increased numbers and because miners tend to keep the gear running 24/7.
|
|
|
|
flatfly (OP)
Legendary
Offline
Activity: 1064
Merit: 1011
|
|
May 02, 2013, 08:52:28 PM |
|
nice list, deepceleron, thanks
|
My main address: 1337sfeChyyzZLzdHLewXzcaAaJSNTM893.
|
|
|
deepceleron
Legendary
Offline
Activity: 1512
Merit: 1025
|
|
May 02, 2013, 09:39:25 PM |
|
My stats are a little rusty, but as far as I see, it doesn't, it goes up. Hashing is Bernoulli trial, either you beat the target or you don't. That gives mining a geometric distribution, and so the variance (in number of hashes required) is (1-p)/p 2. The re-targeting algorithm tries to keep the hashrate directly proportional to 1/p, so the variance in time quadratically increases with the hashrate. Right? I guess the phenomenon above was a much higher variance in hashrate because of people turning their computers off at night, whereas now the variance is greatly reduced due to increased numbers and because miners tend to keep the gear running 24/7. Only 'technically', on a very small scale, is the variance different. In reality it is unobservable at different difficulties. Hashing is typically modeled as an exponential distribution, a continuous series, however it is actually a geometric distribution. The probability is so low though, that the R statistics package fails to compute due to overflow errors with statistics on much more than difficulty 1. The variance is given for a geometric distribution as: You can see that for extremely small p (probability of one hash finding a block), the top numerator approaches 1, becoming insignificant compared to the p 2. The high block times around 20000-30000 has something to do with the satoshi miner and others not making much hashes during that time, there was much less than difficulty 1 worth of mining being done. I could eliminate the first year of Bitcoin to get a better list of long blocks, long due to variance rather than low hashrate.
|
|
|
|
Zeilap
|
|
May 02, 2013, 10:40:03 PM |
|
Only 'technically', on a very small scale, is the variance different. In reality it is unobservable at different difficulties.
I was hoping you'd explain why the difference is unobservable. Anyway, if anyone has the time to do it, it might be interesting to see a chart of the cumulative distributions of the solution times during e.g. January and April, superimposed to see if the bell shape has noticeably widened with the increase in hashing power.
|
|
|
|
deepceleron
Legendary
Offline
Activity: 1512
Merit: 1025
|
|
May 03, 2013, 02:20:43 AM Last edit: May 03, 2013, 02:40:38 AM by deepceleron |
|
It's not a bell curve, the probability density function of an exponential distribution looks like this: Note that the average block time is 10 minutes (1/λ), but 50% of the blocks are less than 6.93 minutes (the median ln(2)/λ). The reason that it makes no difference is: whether the geometric distribution (which counts individual hashes) is calculated for difficulty 1 or difficulty 10000000, the probability of a quantile (such as calculating the probability of a block taking 100 minutes) is the same within several decimal points. In fact it is already identical to the exponential (continuous) function with three digits by difficulty 1, higher difficulty just makes the density function of geometric converge to exponential with even more digits of identity. http://math.stackexchange.com/questions/93098/how-does-a-geometric-distribution-converge-to-an-exponential-distributionHere's a monte carlo simulation of a geometric distribution density, the red line is exponential: See how much like the exponential it is? This example shows a 0.1 probability; Bitcoin's current probability is 0.0000000000000000231. With a lower probability,the steps disappear and the distribution converges to exponential. So the answer is: the probability of a block taking 62 minutes (given a constant hashrate equivalent to difficulty) is 0.2029%, whether the difficulty is 1 or a billion.
|
|
|
|
Zeilap
|
|
May 03, 2013, 04:00:08 PM |
|
Deepceleron, thanks for taking the time to explain, though the convergence of the geometric to exponential distribution wasn't the issue I had. However, dealing with the exponential distribution made finding my error much simpler. My issue was the conversion from dealing with number of hashes to dealing with time. The re-targeting algorithm tries to keep the hashrate directly proportional to 1/p, so the variance in time quadratically increases with the hashrate. Right? My incorrect reasoning was that 1/p is the mean number of hashes, which we choose to be 10 minutes worth of hashes at the current hashrate, R, so 1/p = 600R, then 1/p 2 is 600 2R 2 and concluding that this is the variance in time, which therefore goes up with the square of the hashrate . Anyway, I worked out the error: Transforming the exponential CDF for the number of hashes required into the CDF of time required using 1/p = 600R gives an exponential distribution with a mean of 10 minutes, in particular the hashrate cancels itself out, and so the variance is constant, no matter the hashrate.
|
|
|
|
|