Changelog:
- AntPool block statistics added. No reply from AntPool management about getting user hashrate distribution data.
Errorlog:
- Nil.
Notifications:
- Nil.
0. I'm in coinbase graffiti.
I was reading through the recent coinbase transactions looking for secret messages (of which there have been very few lately any) and found the message "Mined by AntPool usa1 organofcorti.blogspot.com". I looked here and found out the AntPool is doing something interesting - allowing it's miners to immortalise a message in the coinbase of a block. Someone did that without telling me, which was nice of them.
While I was poking around their site I decided to break my rule about not including pools that didn't have a dedicated API, and include them in the weekly pool statistics post. They use nicely configured HTML tables, so it wasn't hard.
I also emailed them asking for user hashrate distribution data, so far with no response (other than an automated message saying they'd respond at some point).
Now if I can just get those user hashrate stats, and block and user hashrate stats from Discus Fish, I'll be happy.
1. GHash.IO profitability above 100% again.
This is nice, and I'm hoping signals a return to normal mining for the pool. Whatever was causing their poor profitability - either the previously mentioned vulnerability or something else - seems to have ceased.
User account hashrate distributions still needed
Now that you can see more of the interesting analyses I can perform if I have this data, you might be even more keen to encourage your pool to provide a "Hall of Fame" feed. To reiterate, I need user account hashrates in order to estimate a number of different network statistics, and to do that I need user account hashrates averaged over at least an hour, preferably several hours or more. The data can be anonymised - it's just the user hashrates I need.
a = reward estimate (tx-free bitcoin rewards) per valid block including orphaned blocks
Now that you can see more of the interesting analyses I can perform if I have this data, you might be even more keen to encourage your pool to provide a "Hall of Fame" feed. To reiterate, I need user account hashrates in order to estimate a number of different network statistics, and to do that I need user account hashrates averaged over at least an hour, preferably several hours or more. The data can be anonymised - it's just the user hashrates I need.
Explanation of the tables and charts
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.
- 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.
- Pool profitability uses compares variables such as total number of shares in a week and total reward (including transactions) in a week with the expected reward per share as follows (pool fee not included):
a = reward estimate (tx-free bitcoin rewards) per valid block including orphaned blocks
b = estimated difficulty 1 shares for valid blocks
c = actual rewards for valid blocks
d = submitted difficulty 1 shares for all blocks including orphaned blocks
Actual reward per share = c / d
Theoretical reward per share = a / b
Profitability = Actual reward per share / Theoretical reward per share
Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck cannot be calculated but orphaned blocks can be enumerated. Pools that don't have a public pool interface cannot be included.
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.
Pool profitability
This simple pool profitability uses compares variables such as total number of shares in a week and total reward (including transactions) in a week with the expected reward per share. Pool fee is not included, but this is a good basis on which to compare pools, as long as you're aware of pool fees, whether transaction fees are paid to you, and whether or not the pool is paying for orphaned blocks. Details of the profitability calculation are given in the block history table.
Obviously this chart is only relevant to miner income if the reward method is not PPS; however the charts can also be interpreted as the profitability of the pool, so it might give you some insight into the financial health of a PPS pool.
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.
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.
Gini coefficient for miner hashrates
The Gini coefficient measures inequality, as is further discussed here. In the plot below, it is measuring inequality within public mining pools. The lower the coefficient, the less inequality in the pool.These indices are much higher than most things for which the Gini coefficient is calculated. For example in countries notoriously unequal incomes it is rarely above 65% (Seychelles, 2007), and educational inequality in the poorest countries comes close, at 92% (Mali, 1990). There are a large number of bitcoin miners with near (or less than) zero income, and a small few who actually make a living.
"All combined" is the Gini coefficient for miners at all pools that can be monitored, combined. It is more affected by larger pools and less affected by smaller pools.
Thank you to blocktrail.com for use of their address data, and coincadence.com for their p2pool miner data.
organofcorti.blogspot.com is a reader supported blog:
1QC2KE4GZ4SZ8AnpwVT483D2E97SLHTGCG
Created using R and various packages, especially dplyr, data.table, ggplot2 and forecast.
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.
`
this site:www.f2pool.com/bitcoin-blocks contains lots of data not analyzed for Discus Fish. chinese pools always hide somethings for their reasons.
ReplyDeleteyou can also get some user's hashrate distribution data from AntPool's coinbase.
mined by Antpool usa indicate the block was mined by the miner in usa roughly.
sc,sichuan province in china.bj is beijing.nmg,Nei Monggol procince
> this site:www.f2pool.com/bitcoin-blocks contains lots of data not analyzed for Discus Fish
DeleteWhat do you mean by that? Is there some other statistic I could extract from the data?
> you can also get some user's hashrate distribution data from AntPool's coinbase.
Sorry, you've misunderstood what I meant - "what hashrates are distributed amongst user accounts?" rather than "what is the geographical distribution of hashrates?".
I think that's what they were getting at, though? I.e. analyze the users from that list. If User X appears 30% of the time, then you could make the assumption that User X has 30% of the pool's hash rate. One major problem is that 'User X' doesn't really mean much.
DeleteThe coinbase won't have this sort of data, but you can do something similar if you can identify all the miner addresses and monitor all the f2pool txs. This is a lot of work for what ends up being data that still ends up being too inaccurate to use over short time scales, but more useful than just the miner account responsible for solving a block.
DeleteAntpool's hashrate is about 60000 Thps at their site.
ReplyDeleteYes, looks like some of the block data is missing. Thanks for pointing it out, I'll fix that now.
Delete