Neighbourhood Pool Watch

[organofcorti]

Neighbourhood Pool Watch 18.1 Who owns 1HTM4TYSXF5yZKLpco6MTUUNfSBCiiwGsU ?

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).

[abracadabra]

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.

[organofcorti]

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.

No, I have no idea who owns the addresses - but if you have some addresses you think they might be I can try to find out the shortest distance between them.

[kano]

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

FTFY

[organofcorti]

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

FTFY

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 never get a return on my investment, and purchase a batch of ten"

[kano]

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

FTFY

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

Edit: https://bitcointalk.org/index.php?topic=456691.msg5281847#msg5281847

[organofcorti]

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

FTFY

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"

I may have FTFY

Edit: https://bitcointalk.org/index.php?topic=456691.msg5281847#msg5281847

FTFY

[organofcorti]

Neighbourhood Pool Watch 16.7 Satoshi's hashrate

This post is an investigation into Satoshis' hashrate and asks the question - did he have a hashrate plan? Some excerpts:

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.

[organofcorti]

Neighbourhood Pool Watch 16.9 Another short post on mapping the historical hashrate distribution


Follows on from previous work referenced in the post.

]


1. Some important points
It should be noted that some of the pre-2012 attributions will have errors. Some of these are:

    * Slush's pool blocks are missing from late 2010 to early 2012.
    * Some BTC Guild blocks are missing in late 2011.
    * Attributions for some of the very early miners may be incomplete.
    * The methods used attribute blocks to Satoshi Nakamoto are outlined in Satoshi's hashrate and A little more on Satoshi's blocks.

[btcash]

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!

[organofcorti]

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!

Interesting - that could be a good way to get a basic idea of the hashrate distribution but the averaging time would be variable. Full marks for coming up with the plan though!

[organofcorti]

http://organofcorti.blogspot.com.au/2014/12/measures-of-network-hashrate.html is a new post that I thought you all might find interesting:

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.

[organofcorti]

So, if you have questions about luck in bitcoin mining, you might find this post helpful:

FAQ: Bitcoin mining and the luck statistic

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.

[organofcorti]

New post!

Early detection of unintentional block withholding

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.

[rav3n_pl]

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

[organofcorti]

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

The block withholding check is applicable to any bitcoin version, or any altcoin too.

[kano]

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 ...

[organofcorti]

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 ...

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.

[kano]

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 ...

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.

Yes both of course (sdiff is the share's difficulty, not the pool requested difficulty)

Might be a few days yet

[Cryptonomist]

Hello,

@organofcorti: I'm currently writing a thesis on the performance of p2pool compared to other centralized mining pools (bitcoin mining). One part of it is the collection of data on the performance of the p2pool network. I've read your blog posts '5.1 p2pool - Bad luck or flawed?' and '5.2 p2pool: Achieving expectation'. I found them very informative and helpfull. However, I wonder whether you can give me some advice on how to collect the data? I'm fairly new to p2pool. I've been running a small-scale bitcoin mining operation for the last couple of months. I've found the logs that produce information about the hash rate, stale rate, etc... for my local node and the network. I just wonder were I can find all the data necessary to construct a dataset like you did, but now for the period 2017-2018.

Thank you.