Welcome, miners.
Changelog:
- Nil.
Errors:
- Discus Fish still seem to update their data irregularly. Until they update more regularly, their data in the second table , and for figure 4, 5 and 7 will only be based on that subset.
Notifications:
- Nil.
0. Block propagation latency and sand size.
I don't have anything interesting to write about pools or the network this week. For the last couple of weeks I've been spending all my free time investigating block propagation times provided by coinometrics.com using their network monitoring tools.
I've found that block propagation latency (time since a block was first reported by a peer to a monitor until reported by some other arbitrary peer) is distributed in much the same way as the size of grains of sand, which is fascinating. It implies that block propagation latency distribution is a mixture of many differently distributed (heterogeneous) normal random variables.
The tricky part has been describing the relationship between block propagation latency and block size. There is a clear relationship between the block latency distribution and block size, but there are four parameters that describe the block latency probability distribution, and three of them change as block size changes - attempted to describe the relationship is what has taken so much of my time for the last two weeks.
I think I'm almost done now and I hope to post something soon so I can get out of this rabbit hole and start answering all your emails.
Explanation of the tables and charts
Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are either from primary sources such as those claimed by a particular pool website, or secondary sources such as coinbase signatures, or known generation addresses. When dependent on secondary sources only, data may be inaccurate and miss some blocks if a particular block-solver has gone to some trouble to hide solved blocks. This will result in an underestimate of the block-solver hashrate.
Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table.
"Unknown" is not an entity but the group of blocks to which I cannot give attribution using the methods given above. "BitAffNet" is Bitcoin Affiliate Network.
Table 2: Pool reported block history statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round.
The table below includes unknown addresses that have been reused ever.
Figure 1: Pie chart of the percentage of network blocks by pool A visual representation of the "Percentage of network" data aggregated in table 1.
Figure 2: 51% attack chart Historical hashrates of the bitcoin network, the largest mining pool, the three largest mining pools combined, and a line representing 50% of the network hashrate. Handy if you're worried about 51% attacks. Hashrates are all estimated from blocks solved, and the history goes back to the earliest date the data contains three known pools. Some pool data may be missing from the earliest data points. The upper and lower 95% confidence interval bounds for the network hashrate are in between the shaded areas.
Figure 3: Percentage of blocks solved each week for the current top ten contributors
Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data.
Figure 4: Average hashrate per solved block (valid + invalid)
Hashrates are calculated from the pool reported difficulty 1 equivalent shares per round and the pool reported block solve times for all solved blocks, both valid and invalid. Note that BTC Guild is not included since the difficulty 1 equivalent shares per round data is not reported; instead use BTC Guild's hashrate chart which has matched my past estimates quite well and which I regard as accurate.
Figure 5: Pool "luck" (valid + invalid solved blocks)
The orange dots are the usual accepted shares / expected shares (equivalently, shares per round / network Difficulty). The background colours are accepted shares / expected shares confidence intervals for the number of blocks solved for the week. The greater the number of blocks solved (the higher the percentage of the network) the narrower the bounds.
The "luck" data points should be outside the upper or lower boundaries only rarely. Many data points outside this range indicate unusual and unlikely "luck".
Data only goes back for the last twelve months at most - any more data points than this becomes hard to read, and recent data is most important.
Note that all solved blocks are used, otherwise the data would no longer be Erlang distributed and a CDF could not be calculated.
Figure 6: Pool user hashrate and combined user hashrate densities
The top facet of this chart shows the proportion of user accounts with a given hashrate - the thicker the "violin" the greater the density of user accounts with a particular hashrate.
The bottom facet is the same data, weighted by hashrate. In effect, it shows what proportion of the pool's hashrate is supplied by particular hashrates. The area of the "violins" is proportional to their total hashrate.
Note that for some pools the hashrate is averaged over twenty four hours, some pools are averaged over an hour or more and some for only fifteen minutes, so expect some variance in the results.
Figure 7: Density of orphaned blocks
This chart shows the density of orphaned blocks per pool, as a function of blocks solved by that pool. The fringe indicates the actual occurrences of the orphaned blocks, and the colour of the line and fringe indicate the approximate date.
Some orphan data may be missing from Polmine. The rest seem to be correct.
Organofcorti lives!
organofcorti.blogspot.com is a reader supported blog:
1QC2KE4GZ4SZ8AnpwVT483D2E97SLHTGCG
Thank you to blockchain.info and coinometrics.com for use of their transaction and address data, and coincadence.com for their p2pool miner data.
Find a typo or spelling error? Email me with the details at organofcorti@organofcorti.org and if you're the first to email me I'll pay you 0.01 btc per ten errors.
Please refer to the most recent blog post for current rates or rule changes.
I'm terrible at proofreading, so some of these posts may be worth quite a bit to the keen reader.
Exceptions:
<weeklypoolstatistics>
Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are either from primary sources such as those claimed by a particular pool website, or secondary sources such as coinbase signatures, or known generation addresses. When dependent on secondary sources only, data may be inaccurate and miss some blocks if a particular block-solver has gone to some trouble to hide solved blocks. This will result in an underestimate of the block-solver hashrate.
Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table.
"Unknown" is not an entity but the group of blocks to which I cannot give attribution using the methods given above. "BitAffNet" is Bitcoin Affiliate Network.
- A much more accurate estimate of the hashrate, confidence intervals are unnecessary.
- Orphan races lost, and percentage of solved blocks that were not added to the blockchain.
- "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty, or (equivalently) accepted shares / expected shares.
- CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks.
- Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one billion Difficulty 1 shares (or one thousand difficulty megashares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block.
Table 3: Reused but unknown generation addresses
Unknown generation addresses that are not reused are probably solominers or private mining concerns that don't have share-holders wanting to follow transactions. However, reused addresses are probably from hash contributors that do not wish to remain anonymous. These need to be identified so they can be removed from the "Unknown" group. I'm not interested in identifying those who wish to remain completely anonymous, so I'm not trying to trace originating IP addresses (as Blockchain.info does).The table below includes unknown addresses that have been reused ever.
| Unknown recurring generation address | Blocks solved this week | Percentage of network | Percentage of unknown | Estimate of hashrate | Blocks solved ever |
|---|---|---|---|---|---|
| 1GcF7j3YH8Qs8hvNEe7zbrQZftMU6sRLfu | 24 | 2.29 % | 24.00 % | 6042 Thps | 261 |
| 1BwZeHJo7b7M2op7VDfYnsmcpXsUYEcVHm | 11 | 1.05 % | 11.00 % | 2762 Thps | 61 |
| 177taU6NzMBYYhG7uS5REm4jVvU2s3fA7H | 9 | 0.86 % | 9.00 % | 2237 Thps | 9 |
| 19KUt1gUviELCs6drdBLiC1mEhkiM2WqKx | 9 | 0.86 % | 9.00 % | 2237 Thps | 9 |
| 1GBoT76cCQL1SemkPW1gVV3Ap9fpbTHKMn | 8 | 0.76 % | 8.00 % | 1989 Thps | 8 |
| 17DKmhXH9pnTWVuYDeEwqx79M7be9q1fG2 | 7 | 0.67 % | 7.00 % | 1740 Thps | 14 |
| 1EHKMBp1TGS67mbjU5TA7ooqMcj4CFsS3q | 7 | 0.67 % | 7.00 % | 1789 Thps | 7 |
| 1H7i9A6F8CHN1Wte9PuFpUowZHextmvwy3 | 5 | 0.48 % | 5.00 % | 1278 Thps | 7 |
| 1JTaqGNCUMLWbPynubMBWhEZZJjspB6B6W | 5 | 0.48 % | 5.00 % | 1243 Thps | 5 |
| 152f1muMCNa7goXYhYAQC61hxEgGacmncB | 4 | 0.38 % | 4.00 % | 1001 Thps | 4 |
| 16G4BpYpbQxDpPNKErkzwP88kqXhSZbRpo | 3 | 0.29 % | 3.00 % | 760 Thps | 3 |
| 1DuDLba6FEJwRq2Heeswrp6xAQdCj2DFEG | 2 | 0.19 % | 2.00 % | 497 Thps | 3 |
Figure 1: Pie chart of the percentage of network blocks by pool A visual representation of the "Percentage of network" data aggregated in table 1.
Figure 2: 51% attack chart Historical hashrates of the bitcoin network, the largest mining pool, the three largest mining pools combined, and a line representing 50% of the network hashrate. Handy if you're worried about 51% attacks. Hashrates are all estimated from blocks solved, and the history goes back to the earliest date the data contains three known pools. Some pool data may be missing from the earliest data points. The upper and lower 95% confidence interval bounds for the network hashrate are in between the shaded areas.
Figure 3: Percentage of blocks solved each week for the current top ten contributors
Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data.
Figure 4: Average hashrate per solved block (valid + invalid)
Hashrates are calculated from the pool reported difficulty 1 equivalent shares per round and the pool reported block solve times for all solved blocks, both valid and invalid. Note that BTC Guild is not included since the difficulty 1 equivalent shares per round data is not reported; instead use BTC Guild's hashrate chart which has matched my past estimates quite well and which I regard as accurate.
Figure 5: Pool "luck" (valid + invalid solved blocks)
The orange dots are the usual accepted shares / expected shares (equivalently, shares per round / network Difficulty). The background colours are accepted shares / expected shares confidence intervals for the number of blocks solved for the week. The greater the number of blocks solved (the higher the percentage of the network) the narrower the bounds.
The "luck" data points should be outside the upper or lower boundaries only rarely. Many data points outside this range indicate unusual and unlikely "luck".
Data only goes back for the last twelve months at most - any more data points than this becomes hard to read, and recent data is most important.
Note that all solved blocks are used, otherwise the data would no longer be Erlang distributed and a CDF could not be calculated.
Figure 6: Pool user hashrate and combined user hashrate densities
The top facet of this chart shows the proportion of user accounts with a given hashrate - the thicker the "violin" the greater the density of user accounts with a particular hashrate.
The bottom facet is the same data, weighted by hashrate. In effect, it shows what proportion of the pool's hashrate is supplied by particular hashrates. The area of the "violins" is proportional to their total hashrate.
Note that for some pools the hashrate is averaged over twenty four hours, some pools are averaged over an hour or more and some for only fifteen minutes, so expect some variance in the results.
Figure 7: Density of orphaned blocks
This chart shows the density of orphaned blocks per pool, as a function of blocks solved by that pool. The fringe indicates the actual occurrences of the orphaned blocks, and the colour of the line and fringe indicate the approximate date.
Some orphan data may be missing from Polmine. The rest seem to be correct.
Organofcorti lives!
organofcorti.blogspot.com is a reader supported blog:
1QC2KE4GZ4SZ8AnpwVT483D2E97SLHTGCG
Thank you to blockchain.info and coinometrics.com for use of their transaction and address data, and coincadence.com for their p2pool miner data.
Find a typo or spelling error? Email me with the details at organofcorti@organofcorti.org and if you're the first to email me I'll pay you 0.01 btc per ten errors.
Please refer to the most recent blog post for current rates or rule changes.
I'm terrible at proofreading, so some of these posts may be worth quite a bit to the keen reader.
Exceptions:
- Errors in text repeated across multiple posts: I will only pay for the most recent errors rather every single occurrence.
- Errors in chart texts: Since I can't fix the chart texts (since I don't keep the data that generated them) I can't pay for them. Still, they would be nice to know about!
<weeklypoolstatistics>
No comments:
Post a Comment
Comments are switched off until the current spam storm ends.