Topic: Neighbourhood Pool Watch (Read 49882 times)

sdiff is the pool difficulty (minimum accepted work difficulty) or the work difficulty? You'll need both of them.

Let me know what you find? That much data is going to be a very good test of the methodology.

Well - yes that's assuming unintentional is only 32-bit related.

Of course there could be other reasons, but yep thanks for this OOC - it seems blatantly obvious once you point it out but yeah never thought of it before.

Fortunately I have full share history of my pool since it started
Time to do 20TB of share searching (sdiff is part of the share log) ... and of course make it permanently record them ...

Are you planning some analysis for block version/Core version?

5. Summary

By examining the numerical values of each block hash returned by a miner, a mining pool operator can detect unintentional block withholding a lower tailed probability of exp(-10) or 0.000045, after only (max difficulty work returned) / (network difficulty) shares have been accepted by the pool.
Early detection of unintentional block withholding can represent a significant saving. At the current network difficulty, a pool that uses early detection to find a miner with equipment unable to return work greater than 2^32 will lose 0.3 of a block reward instead of ten block rewards.

8. Summary

If I have to boil this information down to its important elements:
 # Variance in income reduces as a function of number of blocks solved.
 # Variance in income is not a function of time.
 # Learn how to plan for bad luck, and to check that your pool's luck is not impossibly bad.

I hope I've made this a bit less tricky for you - post in the comments if I haven't been clear or need to add in more information. I expect this post to be a long term work in progress.

0. Introduction
I think we're all aware there is significant concern that if block makers (pools and large solo mining farms) are able to create significant proportions of the network's blocks in an arbitrary time period, then they could cause problems for the network.

For example:
50% of the network or more:  a 51% attack becomes a real possibility. This can be performed by one entity, or a colluding group.
25% of the network or more:  cartel-style selfish mining and double spend attacks are both possible.

...
...
...
...

6. Summary
Available methods of centralisation measurement include:
      * The proportion of the network controlled by the largest or a group of the larger block creating entities;
      * The Gini coefficient and the Theil index;
      * The bitcoin centralisation index.

* Of these, the last three are likely most useful to measure general inequality in the network hashrate distribution.
* The Theil index and the bitcoin centralisation index are the easiest to measure; the Gini coefficient is more widely known.
* None of the measures suggest a long term increase in centralisation over time; the Gini coefficient and Theil index both indicate a decrease in centralisation since the start of the year.

Your latest blog post made me curious about F2Pool hashrate distribution. So I checked the last 1000 blocks for F2Pool signatures.

276 blocks found by 155 different miner.
Top five miner account for ~ 29% of the pools hashing power:
daqi4ant: 21 - 7.61%
f2poolscant: 19 - 6.88%
qq123456: 19 - 6.88%
avhb: 12 - 4.35%
jua005: 9 - 3.26%

I know this is not fully accurate but percentages stay roughly the same if I go back 3000 blocks.

BTW: You are doing a great job!

0. Introduction
There are many reasons I enjoy working at coinometrics.com, and having access to data I wouldn't otherwise have is chief among them. Recently, Jonathan Levin had been discussing whether or not Satoshi's coins had been moved (which was in the news at the time) and Martin Harrigan of QuantaBytes (who had recently started working with us) was able to provide the sort of data that we needed to assign blocks to Satoshi.

With that information I was able to do what I'd wanted to do since I first started mining - estimate Satoshi's hashrate. At the time I didn't realise that I would also be provided with a small window into the great man's thinking - his plan for managing his personal hashrate.

5. Summary
    * Satoshi initially followed a plan of reducing the hashrate by 1.7 Mhps every five months, but a month after the second such drop abandoned this method in favour of a continuously decreasing hashrate.
    * This implies two things: Satoshi had a hashrate plan, and that initially Satoshi had very coarse-grained control of his hashrate, but then was able to achieve a very fine grained control of the hashrate.
    * These insights may help investigators determine the sort of hardware Satoshi used, and how much control he would have had over the early client or his PC / cloud infrastructure.

I may have FTFY

Edit: https://bitcointalksearch.org/topic/m.5281847

You can (only just) mine BTC at a profit with these things, even at 35c per kWh. That should hold true for a few months yet.

I'm not assessing the net profit (after purchase) though, which might be what you're thinking. I did say " I decided to throw caution to the wind, ignore the fact that I may will never get a positive return on my investment, and purchase a batch of ten"

FTFY

If you just bought a Gridseed and were wondering whether or not it might be more profitable to make less loss if you mine bitcoin, then this post is for you.

http://organofcorti.blogspot.com/2014/03/918-gridseed-should-you-mine-bitcoin-or.html

OoC,  have you managed to determine which, if any of these "unknown" addresses, are Bitmain's? They claimed that their products were/are powering 20% of the network.

Monday 17th March, 2014

Essential reading:
Wikipedia entry on "Graph theory"

Other posts covering similar topics: 
16.3 The unknown network hashrate
16.4 Updated unknown network hashrate

Other interesting links:
Bitcoin Transaction Graph Analysis
Quantitative Analysis of the Full Bitcoin Transaction Graph
Do the rich get richer? An empirical analysis of the Bitcoin transaction network
An Analysis of Anonymity in the Bitcoin System
An Analysis of Anonymity in Bitcoin Using P2P Network Traffic

0. Introduction
A while back in posts 16.3 and 16.4 I pointed out some of the generation addresses from sources of unknown bitcoin network hashes. My aim was not to somehow "out" smaller solominers but to attempt to find out if some of the already known hash sources might be trying to hide some of the blocks they solve in an effort to appear less threatening to the network. If some large pool was to hide some of the blocks it solves, then some miners would be losing income, and the pool could approach 50% of the network without anyone knowing.

A pool that was hiding some of its solved blocks would appear to have slightly poor luck over a long period. It is not hard to detect poor luck over a long period, but you wouldn't be looking for it without a reason. And even if you did, all you could say was that public hashrate contributor 'X' had statistically unlikely luck.

I wanted an indicator that was a little more clear than that; and if there was no proof tying the new sources of hashes to a pool, then I hoped to have enough information to identify some of the new hash contributors (as I did for last week for KNC) or set some bounties (as I did in posts  16.3 and 16.4).