Changelog:
Errorlog:
- Nil.
0. Back home and still a bit jet-lagged
I've been travelling for the past few weeks and most recently was in San Francisco, meeting a few friends, visiting bitcoin startups and attending the Coinbase office warming party (great space you have there, fellas). I'm still recovering, so I'm keeping this week's comments short and sweet, except for.....
1. Discus Fish, Bitfury and AntPool go head to head
I've been travelling for the past few weeks and most recently was in San Francisco, meeting a few friends, visiting bitcoin startups and attending the Coinbase office warming party (great space you have there, fellas). I'm still recovering, so I'm keeping this week's comments short and sweet, except for.....
1. Discus Fish, Bitfury and AntPool go head to head
Based on the weekly hashrate, there's not much difference between them - since the confidence intervals are around +/- 15%, any of them could have the largest hashrate at the moment. This is why I need to update the weekly estimates using a smoothed mean - the confidence intervals are much smaller and a contest like this easier to call.
Any ideas who is going to win?
Any ideas who is going to win?
- Discus Fish were top dog (fish?) for almost a year could regain the some of their lost miners. PPS is a significant draw card for miners.
- Bitfury has been consistently and regularly increasing the size of their farm, and develop their own hardware.
- AntPool have also lead the list for quite some time and likewise could regain the some of their lost miners. They also have the ability to increase the size of their private farm, which would reduce variance at their pool even further and make the difference between PPS and PPLNS insignificant. This might bring even more miners and increase the pool size even further.
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).
Diachronic 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: Heatmap of historical percentage of network blocks attributable to block makers.
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 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.
| Unknown recurring generation address | Blocks solved this week | Percentage of network | Percentage of unknown | Estimate of hashrate | Blocks solved ever |
|---|---|---|---|---|---|
| 1DXRoTT67mCbhdHHL1it4J1xsSZHHnFxYR | 19 | 1.86 % | 95.00 % | 7111 Thps | 61 |
Diachronic 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.