Changelog:
- New timewise "pie chart".
Errorlog:
- Nil.
Notifications:
- Nil.
0. Thanks, TheRealSteve.
The last couple of weeks I've been busy IRL, flat out like a lizard drinking. Luckily, the TheRealSteve stepped in and in the course of his explanations ended up writing a primer for determining block attribution - great job, TheRealSteve. If anyone is feeling generous this week, rather than donating to me, send some fiscal thanks his way: 15oME1MHKgz1WK3scxCf8eLZJDfMLTDdZz.
I'll be editing his comments and posting them separately as an FAQ, but in the mean time, read his comments here.
1. New "pie chart"
Although it looks more like a "cake chart", the timeless pie chart shows the relative proportion of the network each of the larger block makers have. I have a couple of posts on the subject of more accurately reflecting the data:
Why 'proportion of network' pie charts are misleading
How to make a more accurate 'proportion of network' pie chart part 1
How to make a more accurate 'proportion of network' pie chart part 2
Soon I'll be including weekly versions of the plots from part 1 so you have an indication of the data range and mean estimate. This should reduce further the "zomg the sky is falling" posts we see from time to time on reddit.
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 |
|---|---|---|---|---|---|
| 1CdJi2xRTXJF6CEJqNHYyQDNEcM3X7fUhD | 45 | 4.48 % | 77.59 % | 15835 Thps | 268 |
| 1NY15MK947MLzmPUa2gL7UgyR8prLh2xfu | 10 | 1.00 % | 17.24 % | 3529 Thps | 97 |
| 1GcF7j3YH8Qs8hvNEe7zbrQZftMU6sRLfu | 2 | 0.20 % | 3.45 % | 706 Thps | 573 |
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.
Thank you, organofcorti!
ReplyDeleteI can confirm that's my address (people can check my BitcoinTalk Forum profile anyway); though if you'd like to donate to organofcorti and feel swayed by his words to donate to me instead, by all means.. donate to organofcorti :)
I'm also very happy to see that that the number of recurring unknowns is down to 3 for this week - and if we're to believe that 1CdJi2xR is 21, Inc. it's down to just two - with barely over 1% of the network hash rate estimated.
But if you know who 1NY15MK9 or 1GcF7j3Y are (or have a solid on 1Cdji2xR being 21, Inc. , drop a comment here, toss it on up on BitcoinTalk, make a post on reddit, or send organofcorti a message directly.
From barely scratching the surface (I, too, find there are too few hours in a day):
1GcF7j3Y is often in transactions with 174Fio4h and 12zGKHDR, typically paying out to 1BE1ttHn. The former two don't immediately lead anywhere except periodical payouts to them. 1BE1ttHn was the first output for 1GcF7j3Y at a whopper of 1648.2 BTC (followed by even bigger transactions). Down the rabbit hole you go :)
1NY15MK9 pays its bulk of mined coin out to 1DNTAeaj . An address that did so in the past was 1CG7Dmgs . If we know who that was - and I think we do(?) - they may be related.
( Need to resolve those short forms to full addresses? Try goochain.net - not affiliated, just another neat service built around the Bitcoin blockchain )
~ TRS
Quick comment: I don't know to whom 1CG7Dmgs belongs. There's nothing interesting in any of the coinbase txs of the eighteen blocks that paid out to that address, except that they all include "nodeStratum" at the end of the transaction - which 1NY15MK9 also does. Unfortunately so do six hundred and fifty one other blocks. These are their attributions:
DeletePool No. of blocks
1: Dot pool 170
2: Unknown 168
3: BW Pool 116
4: Bitfinex pool 100
5: Bitfury 74
6: Day pool 13
7: Poolz 4 You 7
8: BitAffNet 1
9: Halleychina.com 1
10: GIVE-ME-COINS 1
Yeah, I'm guessing that's some default string in some client/server piece of software. Recently-ish there was a whole spate of quote coinbases again as well, hadn't seen those in a while. I'll check if I made some sort of association with 1CG7dmgs somewhere.. I might be mixing it up though as I've got no annotation in my flowchart (abandoned because half of everything started to look like a polmine association - the many addresses making post-mine payout to 1Axse9dq are fun though)
Deleteupdate: nope, couldn't find a thing on 1CG7dmgs . Might dig around some tomorrow, but not expecting to get particularly far :)
Delete> Yeah, I'm guessing that's some default string in some client/server piece of software.
DeleteI think that's the same with a number of coinbase strings. Using a repeating coinbase string isn't a good indicator of attribution of you don't know what it means or why it's there. Which is why "Dot pool" isn't a very useful designation. A number of the attributions bci uses aren't explained anywhere. I think that's a little bit dangerous - anyone can update that without any proof, it seems. Blocktrail provides a link to mentions of a generation address, which is useful.
Agreed - I had started a spreadsheet with block attribution data, pointing out what led to a particular attribution (e.g scriptSig, self-reporting, public claim, etc.). There's a few unverifiables in there, but it's better than nothing. As with the flowchart, though, on halt - though in this case because bc.i's API is giving me trouble (inconsistent results between queries) :)
Delete