Changelog:
- Nil.
Errorlog:
- Nil.
Notifications:
- Nil.
0. 21.co at 3.9%?
If 21.co do indeed control 1CdJi2xRTXJF6CEJqNHYyQDNEcM3X7fUhD then their pool contributed 3.86% of network blocks over the past week.
1. Bitfury now third largest block maker
George Kikvadse from Bitfury tweeted a while back "@oocBlog @blocktrail stay tuned. @BitFuryGroup on the march...". Bitfury now appears to be the third largest block maker.
2. BW Pool also takes a leap.
BW Pool is very close to Bitfury's share of the network, and the fuzziness of variance means that it's possible BW Pool has a larger share than Bitfury. We'll see who's third largest next week.
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 | 41 | 3.86 % | 61.19 % | 13856 Thps | 223 |
| 1NY15MK947MLzmPUa2gL7UgyR8prLh2xfu | 12 | 1.13 % | 17.91 % | 4055 Thps | 87 |
| 1BwZeHJo7b7M2op7VDfYnsmcpXsUYEcVHm | 5 | 0.47 % | 7.46 % | 1690 Thps | 278 |
| 1Ar2gRkt1u6k4PToeeTKm1KGmtR2GRA1wL | 2 | 0.19 % | 2.99 % | 676 Thps | 30 |
| 1GcF7j3YH8Qs8hvNEe7zbrQZftMU6sRLfu | 2 | 0.19 % | 2.99 % | 676 Thps | 571 |
| 1Fdpys8g2Dsnk2vyLARdDidAebCafrH2Wb | 1 | 0.09 % | 1.49 % | 338 Thps | 3 |
| 1qtKetXKgqa7j1KrB19HbvfRiNUncmakk | 1 | 0.09 % | 1.49 % | 338 Thps | 23 |
Hashrate distribution: Stacked histogram percentage of network blocks
A visual representation of the "Percentage of network" data aggregated in the table.
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.
I'm curious. You don't list 1KTNEBhQd or 17JJ3oZy under recurring unknown. Does that mean they /are/ known, or are they included in Unknown, and just not listed under recurring unknown because reasons? Thanks :)
ReplyDeleteHi Curious, both of those addresses are known. I can't remember who they are (not at home at the moment) but I know I've had them both for maybe a year or so? Maybe a little less.
DeleteAck, dad jokes! I tried to figure it out from past entries, but got nowhere fast. 1KTNEBhQd doesn't seem to be mentioned. August 24th, 2014 is the last mention for 17JJ3oZy, with no mention of resolved addresses or pools added on August 31st.
DeleteI think 1Ar2gRkt and 18UBaMPq may be part of that same group, given the many transactions they share.
1BwZeHJo should be BTC Nuggets: http://104.197.8.250/index.php?page=statistics&action=blocks
I have 1KTNEBhQd and 17JJ3oZy listed as Megabigpower.com, I found them when I was investigating 1HTM4TYSXF (http://organofcorti.blogspot.com.au/2014/03/181-who-owns-1htm4tysxf5yzklpco6mtuunfs.html). From what you write, it might be time to have another look.
Deletehttp://organofcorti.blogspot.com.au/2014/03/181-who-owns-1htm4tysxf5yzklpco6mtuunfs.html
I can confirm both 1Ar2gRkt and 18UBaMPq are Megabigpower, as is 1ESxhbSXJxKY9zKsQHignDsHZ6nk563yPi.
DeleteAhhh, that would explain that. I did spot the 1HTM but didn't check it as that was quite a while ago :) Do you have 18xf3MQv under MegaBigPower as well?
DeleteYes, thats one of the fifty or so MBP addresses.
DeleteOkay, thank you :)
DeleteOh, one more thing that you might be able to squeeze in. I noticed 1Fdpys8g in your 'Unknown' list. Thought that looked familiar - it's in your BCT pool list thread. 1Fdpys8g is solo.ckpool . bc.i has the address tagged as 'ckolivas' as well. The primary output address for some of these, 16fQsshc, is NiceHash (should have two coinbase scriptSig tagged ones).
DeleteEr, that is to say, they're using the solo.ckpool coinbase and etc. That's not solo.ckpool's official fee address (per the site), at least, so maybe they're just donating? Could poke at -ck :)
DeleteHey, how do you know that Bitfury is now third largest block maker. Isn't GHASH.IO related to Bitfury? GHASH.IO only has 2% of total blocks ... where is the information about Bitfury's generating address published? And in general, how do you get all the names for the table "Block maker statistics"? Thanks!
ReplyDeletePlease note: not speaking for organofcorti, just giving some general pointers.
Delete1. It is technically impossible to say who mined a block. There are plenty of ways to spoof or lie about the information that is used to take an educated guess who mined a block.
2. We take educated guesses when determining who mined a block.
There are several ways in which an educated guess can be made.
A. The miner (and this includes pools) officially states what address they mine to (if mining to an address). This is the ideal, as that means we can always point to wherever they stated it as the source.
B. The miner publicly announces the blocks it mined. Many pools do this. See my above pointer to "BTC Nuggets", for example. This pool lists the blocks it mined. By comparing this against other claims to blocks, if there's no overlap, there's a good chance that this type of source is at least not trying to claim blocks that belong to others.
C. Miners can set a small bit of text in the mined block, in the coinbase's scriptSig, 'signing' it with their information. As an example of this, see block 361226 and its coinbase transaction ( https://blockchain.info/tx/d08e5324f9330d4222da1dbade6c9e630037b0abf017ebbfac487a9203496f33 ). You'll see the text "/slush/" in there, and this can be used to say "Slush's Pool mined this block".
D. If all else fails, the Bitcoin mined can be traced through transactions to find a likely miner. For example, if the owner a particular address X almost immediately transacts the bulk of the mined coin to address A, and in the past the only address with transactions to that address A was address Z and address Z is /known/ to belong to SuperMinerYeah, then you could make the assumption that address X also belongs to SuperMinerYeah. This is similar to how 1KTNEBhqD, 17JJ3oZy 1Ar2gRkt and 18UBaMPq are linked, for example; all four (and a few more) addresses have been inputs for a single transaction, together. So whoever has control over any one of those, most likely has control over the others. This doesn't necessarily identify a miner, though; it could also be one seriously trusted custodian that just happens to be a custodian for multiple pools. Occam's Razor.
These options appear in level of confidence order. Organofcorti doesn't have enough confidence yet to link 21, Inc. to the 1CdJi2xRTX address and coins mined to it, for example. (1/3)
In the particular case of BitFury, approach C mostly applies. The coinbase scriptSig cointas the string "/BitFury/". BitFury.org posting their mining address(es) would be preferable, but we make do :)
DeleteYou do seem to have been out of the loop a bit, though. BitFury pulled away from Ghash.io a long time ago when Ghash.io was hovering around 50% of the network hash rate. This was publicly stated by BitFury, a year ago: http://www.coindesk.com/bitfury-pulls-power-ghash-community-uproar/ . Ghash.io has been dwindling ever since. (2/3)
Addendum on some peculiar ones:
Deletei. dotpool, also known as Telco 214 at other sites, is identified via approach C, based on there being a string "/..../" in the scriptSig with the number of periods varying (possibly as an internal identified)
ii. P2Pool can be identified via the pre-last output transaction going to the donation address ( 1Kz5QaUP ), the last output transaction script being an OP_RETURN with apparent nonsensical data, and having "/P2SH/" in the scriptSig. This last one shouldn't be relied upon solely, as there are plenty of other scriptSigs with /P2SH/ - but if this is one of the first things you can check in your parser, then you can at least branch code from there.
Ultimately, you can end up with a pretty simple lookup-table of addresses, partial (regex) strings, and perhaps just a few miner-specific bits of code, and off you go. Blockchain.info publicly posts their address+scriptSig part, for example, at https://github.com/blockchain/Blockchain-Known-Pools , which can be a good place to start from if you wanted to build your own.
I hope this helps, and I'm sure (well, I'd hope that) organofcorti will correct me where I'm hideously, or even just slightly, wrong :) ( 3/3 - I swear it was under 4,096 characters originally )
These are great answers, thanks! And this is definitely something that should be pointed out on this site's FAQ or something similar.
DeleteI'll see about posting something up on the wiki, perhaps.
DeleteI also forgot one more method - but it's a bit controversial and you'll notice that organofcorti explicitly doesn't use it:
E. the IP address of the node relaying the block. There's a few services that report this information, blockchain.info is one of them. The theory is that as long as you're connected to all nodes equally then you should also be connected to the miner's node. The miner's node should, naturally, be the first to relay a block having been mined to you. The problem with that is that 1. you're not connected to all nodes, and 2. the nodes that you're connected to, you're not connected to equally. In practice this means that in the first case the IP address relaying the block to you first might not be the miner, but a node you're connected to, which in turn is connected to the miner - or it might be a node connected to a node connected to the miner - and in the second case, even though you are connected to the miner, the connection between the two of you is spotty and so some other node may simply be able to relay the information to you faster. There is, however, a bit of a silver lining to the second case, and that is that this sort of situation is rare, or that you can resolve it through other means. If it's rare, then you'll still get blocks mostly from the miner first, so the IP address that shows up the most? Probably the miner or at least very well connected to them. Resolving it through other means might be as simple as a DNS lookup. If one IP resolves to a residential connection or a popular VPS provider, while the other resolves to SuperMinerYeah.man , some spidey senses should go off. This technique can also be mixed with the association technique in D.. i.e. if blocks mined to address K and blocks mined to address L share a common IP address, you may still not know who the miner is, but there's a good chance that it's the same one. Just 'a good chance', though.. it's still a weak link and arguably weaker than the shared transaction one.
( I'll await organofcorti's writeup + potential comments before putting anything into the wiki :) )
DeleteThis is an excellent explanation. I'd like to make it an actual post - how would you like me to attribute it. I'm sure you're not new to bitcoin analysis?
ReplyDeleteFeel free to attribute to TheRealSteve (hi) :) Not entirely new, but certainly nowhere near the level of your analysis or Meni's mathematical and statistical contemplations. Looking forward to today's update - wonder who would win if you'd take @BitfuryGeorge up on the bet :)
DeleteP.S. Unrelated to the core of your blog - but I know you make tangential posts once in a while - have you seen the 8MB block size votes (coinbase scriptSig) on blocks from F2Pool/AntPool/BTC China? Doesn't really look like BIP100 or those pools' own agreement are taking off (the whole block size debate is spaghetti anyway), but might be fun to track if they ever do :)