Changelog:
- Added Mintsy using their stats page to find their generation address (you'll need an account to see it).
- Added 21.co - if everyone turns out to be incorrect, I'll retcon it.
Errorlog:
- Nil.
Notifications:
- Nil.
0. No "Unknowns" this week
Not just a small percentage, but exactly 0% - if the 21.co address is correct. That's the first time ever that has happened.
1. AntPool leading Discus Fish (F2Pool) and Bitfury close
AntPool solved about thirty more blocks than Discus Fish this week. This can't be due entirely to the short lived SPV fork yesterday, so I'd say Discus Fish is starting to lose some miner, or at least not gain them as fast as AntPool and Bitfury.
Not just a small percentage, but exactly 0% - if the 21.co address is correct. That's the first time ever that has happened.
1. AntPool leading Discus Fish (F2Pool) and Bitfury close
AntPool solved about thirty more blocks than Discus Fish this week. This can't be due entirely to the short lived SPV fork yesterday, so I'd say Discus Fish is starting to lose some miner, or at least not gain them as fast as AntPool and Bitfury.
Solved block statistics table. 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.
"BitAffNet" is Bitcoin Affiliate Network
"Dot pool" and "Day pool" are block makers that are unknown, but that have enduring coinbase signatures, address clustering, or generation address reuse similarities. However, since they are unknown and unclaimed we can't be sure if these block makers are actually part of another known block maker.
"Unknown" is not an entity but the group of blocks to which I cannot give attribution using the methods given above.
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).
| Unknown recurring generation address | Blocks solved this week | Percentage of network | Percentage of unknown | Estimate of hashrate | Blocks solved ever |
|---|---|---|---|---|---|
None
| 0 | 0 % | 0 % | 0 Thps | 0 |
Timeless hashrate distribution: Stacked histogram percentage of network blocks over the past week.
Rather than a simple "pie chart" of blocks solved over the past week, this plot represents an estimate of the hashrate intensity function at any given time. This means that variance is reduced, so if you want to see intra-week changes in network ownership this chart is much more than a simple 24 hour or four day pie chart. If there are very sudden changes in hashrate - for example a 50% or greater change over several hours - the smoothing method will not be able to distinguish this from variance.
Hashrate distribution: Actual and cumulative percentage of network blocks
Another visualisation of the data in the table. The unshaded section indicates block makers with the largest hashrates that control 50% of the network between them.
Hashrate distribution: Heatmap of historical percentage of network blocks attributable to block makers.
The data in the above hashrate distribution histogram is a subset of the weekly data data below.
Hashrate distribution: Daily proportion of network for current block makers.
The next three plots group hashrate distribution into three tiers: The block makers with the largest proportion of the network, block makers with an average proportion of the network, and block makers with the smallest proportion of the network.
Because the data is a daily summary, the kernel smoothing shows quite clearly the variance in hashrate distribution that occurs in block making. It will also show the intra-week hashrate movements which were previously unavailable.
Comparison of transaction fee per block
Block makers that consistently perform better than average are attempting to earn as much from each block as possible, which probably means more transactions per block and a better functioning network.
Block makers that consistently earn less than average transactions per block are either including too many low priority (no fee) transactions or are trying to reduce their orphan rate by reducing the size of their blocks.
Historical centralisation of bitcoin network block creation
This chart shows the changes in the amount of the network controlled by the largest block maker, second largest, and so on up to the twentieth largest (should that number of block makers exist during the week the estimate was made).
organofcorti.blogspot.com is a reader supported blog:
1QC2KE4GZ4SZ8AnpwVT483D2E97SLHTGCG
Created using R and various packages, especially dplyr, data.table, ggplot2 and forecast.
Recommended reading:
- For help on ggplot2.
Thank you to blocktrail.com for use of their 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!
I write in British English.
No comments:
Post a Comment
Comments are switched off until the current spam storm ends.