Finally burstdev's opencl kernels find use. Thank you so much for this luxe! I have tweeted about it already.
Offhand note, are you reading this bensam
this is great news for burst!
i just developed a new query for my mysql blockchain copy to show which miner found how many blocks and when they found their last block.
the news in this is that it seems there join many new miners who found only a couple of blocks so far.
over 100 "fresh" accounts found a block during the last week and have mined less than 10 blocks in total.
the whole list with all 343 days can be accessed here:
http://pastebin.com/wFFXRSA4it is sorted by the last mined block in days.
if you analyse top 10 miners, what is the distribution of when they find blocks?
for ex. are blocks found throughout a 24 hr period with random distribution, or for some miners are found blocks concentrated into a specific timeframe?
this depends on how you define timeframe. even for the top 10 miner a 24h analysis range is small since several miner mined the same amount of blocks.
the average time in minutes between mined blocks in the last 24h for the top 10 blockfinder are these:
25
96
120
130
180
288
288
288
360
360
sure these are averages but since we mine deadline based there are always some "lucky" blocks which phase out good deadlines which would get a block within 4 minutes otherwise.
i already posted earlier that the 24 blocks in the basetarget formula should be at least increased to smooth the basetarget.
if you look at the block times the diff cannot go much higher than it currently is simply because the network is limited to a certain amount of plotted nonces for each account and if there is no lucky one in the diff goes down much faster than up.
i did a analysis some time back and realized to drive up the diff 8 "fast" blocks can be phased out by one slow block.
we should really think of how the formula can get adjusted or deadlines be cut after a maximum time like 16 minutes or less have passed.
if you look on the last 25 basetargets it looks like 25% of the network switches on and off (even more if you interpret the target in a linear way which it not is --> 2^64 nonces --> 2^22 is 1TB plots --> 2^32 nonces is 1 pb plots and most people mine with less for a single address):
mysql> select height, target, blocktime from blocks order by height desc limit 25;
+--------+---------+-----------+
| height | target | blocktime |
+--------+---------+-----------+
| 123129 | 1926858 | - |
| 123128 | 2015697 | 46 |
| 123127 | 1773816 | 797 |
| 123126 | 1877106 | 122 |
| 123125 | 1824186 | 301 |
| 123124 | 1791419 | 120 |
| 123123 | 1670390 | 444 |
| 123122 | 1668904 | 156 |
| 123121 | 1668280 | 77 |
| 123120 | 1727230 | 422 |
| 123119 | 1698327 | 209 |
| 123118 | 1723225 | 114 |
| 123117 | 1701750 | 344 |
| 123116 | 2127188 | 41 |
| 123115 | 2231141 | 238 |
| 123114 | 2395002 | 76 |
| 123113 | 2288660 | 220 |
| 123112 | 2218216 | 108 |
| 123111 | 2178155 | 218 |
| 123110 | 2188851 | 88 |
| 123109 | 2124294 | 173 |
| 123108 | 2049925 | 167 |
| 123107 | 1925893 | 396 |
| 123106 | 1910637 | 42 |
| 123105 | 1748422 | 797 |
+--------+---------+-----------+
25 rows in set (0,00 sec)
to get rid of this we need a pool mining with a single address for all miner.
