Neighbourhood Pool Watch

[organofcorti]

And to wake up the thread before it gets old ...
So ... if someone was to get some BFL MiniRigs ... or some time in the far distant future ... a bunch of ASIC ...
Wouldn't it be best for them to mine on a PPS pool and withhold blocks ... so they don't increase the difficulty and thus get more BTC ...

Sorry I missed this Kano. It's an interesting point. The block witholding attack has been mentioned before, but not in the context of someone with a large hashrate not wanting to affect difficulty. The miner would have to have a large proportion of the network hashrate to affect difficulty by himself, plus he'd have to hide the fact by using multiple miners on multiple pools.

I think in this circumstance you everyone but the network would notice a problem. Say the attacker has 5% of the network hashrate and doesn't want to affect difficulty. He has to spread the hashrate over several workers (or one worker would look suspiciously unlucky) and at several pools (or one pool would look suspiciously unlucky). Then all the PPS pools will start looking slightly unlucky.

If you found that round lengths were larger than normal on average but the luck index (calculated as log(Percentage of network blocks solved / Percentage of network hashrate) )  was averaging at zero, you'd start to suspect this could be happening.

Luckily I have some charts somewhere that might help

[1713566523]

1713566523

[1713566523]

1713566523

[organofcorti]

4.2 Slush's score method and miner earnings part 1 is posted. This will be a three part series explaining the effects of the exponentially scored method on fulltime miner earnings.

5. Conclusions

• Expected share values decrease with increasing total shares submitted until reaching a steady state.
• The current steady state expected share value is about 0.957 and is reached shortly after the "hop point"
• Increasing difficulty or decreasing 'c' or pool hashrate reduces the hop point and thus the pool hoppers potential profits; the converse is also true.
• The theoretical maximum expected earnings loss is much lower than for a standard proportional pool; currently about 4.1% for Slush's pool as opposed to 43.4% for a standard proportional pool.

[organofcorti]

6.1 Bitlc.net - Pool hopping and unfulfilled promise reports on a pool that started well, stagnated and then become one of the last few prop pools. What went wrong. And more to the point, who still mines there?

7. Conclusions

* Bitlc.net began with a good service and great ideas. Unfortunately the pool has stagnated with few recent updates and an unfair reward method.
* Bitlc.net could be a much more successful pool if the reward method was changed and if monetised in such a way that Jine was able to spend more time on the pool or delegate someone to manage it.
* Fulltime miners at Bitlc.net currently lose approximately 30% of their expected earnings to pool hoppers. By comparison, at Deepbit.net the current percentage loss of earnings for fulltime proportionally rewarded miners to pool hoppers is 1.9%.
* Mining at a 5% fee PPS pool would earning the fulltime miners at Bitlc.net 35% more than they earn at Bitlc.net currently.

[Shadow383]

Very much in agreement regarding bitlc. That's been one of the pools my proxy has hopped for quite a long time now - the unfortunate fact of the matter is that whilst it's profitable to do we'll keep doing it.

However, how did you come to your conclusion that only 6.7% of deepbit's hashrate pre-hop is pool hoppers? I was under the impression that ~500Ghash was hopping that pool, just like with Slush.

[organofcorti]

Very much in agreement regarding bitlc. That's been one of the pools my proxy has hopped for quite a long time now - the unfortunate fact of the matter is that whilst it's profitable to do we'll keep doing it.

However, how did you come to your conclusion that only 6.7% of deepbit's hashrate pre-hop is pool hoppers? I was under the impression that ~500Ghash was hopping that pool, just like with Slush.

It's an estimate, using the median average hashrate per round after 2*D as the fulltime miner hashrate, and  the median average hashrate per round after 2*D as (Fulltime + hopper) hashrate. It's close to results I've obtained in the past using more accurate estimations. I've noticed that the hop hashrate at Deepbit has been much less than when I posted NPW2.2.

[Shadow383]

Very much in agreement regarding bitlc. That's been one of the pools my proxy has hopped for quite a long time now - the unfortunate fact of the matter is that whilst it's profitable to do we'll keep doing it.

However, how did you come to your conclusion that only 6.7% of deepbit's hashrate pre-hop is pool hoppers? I was under the impression that ~500Ghash was hopping that pool, just like with Slush.

It's an estimate, using the median average hashrate per round after 2*D as the fulltime miner hashrate, and  the median average hashrate per round after 2*D as (Fulltime + hopper) hashrate. It's close to results I've obtained in the past using more accurate estimations. I've noticed that the hop hashrate at Deepbit has been much less than when I posted NPW2.2.

Interesting... There has been a bit of a ban wave on there lately, but mostly for larger hopping accounts (>5Gh/s or so). They don't seem to be IP banning yet.

[organofcorti]

I've noticed the hop rate dropped since mid April, so whatever is being done has been done since then.

Edit: Thank you to my most recent anonymous donor.

[ShadesOfMarble]

I don't know if this pool is of interest because of its small hash rate: https://miner.ecki.net:444/

But there seems to be serious evidence that the OP is cheating.
After I found this post
https://bitcointalk.org/index.php?topic=78391.msg874690#msg874690

I made some investigations, i.e. clicked thru the "found blocks" page on the pool webpage and entered the block numbers on blockchain.info

What I found is this:

BTC 187,500 Distribution marrog 2012-07-04 20:43:02 537,341
http://blockchain.info/block-index/242747/00000000000000461dcf498b2ba02f19dde9a98bb126de9d8e313b0bcdba5bfb
=> P2Pool


BTC 188,332 Distribution glordglord 2012-07-10 04:10:01 966,959
http://blockchain.info/block-index/244059/000000000000094b944cc807129a2e270753a565a3a8b37f609dc1e80a631e4c
=> P2Pool


BTC 188,936 Distribution Mycom 2012-07-14 05:23:02 1,715,598
http://blockchain.info/block-index/245155/00000000000001e4cee1f8f939b18d5248f367397ec5ec7ff8cf240cfb669ef8
=> OzCoin


BTC 195,994 Distribution marrog 2012-08-28 05:32:05 7,313,184
http://blockchain.info/block-index/269508/00000000000000e03ed033296e37cd676536ecbfdc600059dba12b25e2ca2fe3
=> BTC Guild


So it's not the classic "faking round lengths" but the whole blocks are "faked".

My question is: How reliable are the markers P2Pool, OzCoin and BTC Guild use? Is this strong enough evidence?

I'm asking because I think you have way more experience in exposing cheating pool OPs.

[Graet]

not long after Ozcoin started I had a furious person join our IRC blaming us for "stealing" another pools block
our software reported the wrong block number, we had the previous one.....

since January all Ozcoin blocks have eco@ozco.in in the coinbase
easily seen here http://blockchain.info/tx/cc8e9de906601a9f1537d83d0c86f48f76853cdae835d18141e1ca3186d9e62b/cc8e9de906601a9f1537d83d0c86f48f76853cdae835d18141e1ca3186d9e62b for example

[ShadesOfMarble]

So it could also be a bug in the pool software?

[organofcorti]

Interesting, but how would claiming blocks not theirs benefit the pool op? It's a PPLNS pool so he would have to pay extra to his miners. I can't quite see where the gain for the pool op is.

I don't know how reliable the block claim markers are, and I'm not sure how accurate blockchain.info is.

[Graet]

So it could also be a bug in the pool software?

would be my 1st guess
I do see what you mean though, checked a couple of their blocks (including the Ozcoin one)

[ShadesOfMarble]

@Graet you were right. Block numbers are off. Blocknumber+1 is the correct one. So just a bug in the pool software

[Graet]

@Graet you were right. Block numbers are off. Blocknumber+1 is the correct one. So just a bug in the pool software

good news

[organofcorti]

@Graet you were right. Block numbers are off. Blocknumber+1 is the correct one. So just a bug in the pool software

Which ones are out by one - ecki.net - or the other pools?

[kano]

@Graet you were right. Block numbers are off. Blocknumber+1 is the correct one. So just a bug in the pool software

Which ones are out by one - ecki.net - or the other pools?

ecki.net or course ...
As mentioned above you simply look at the coin base to identify a lot of pools.
In fact around 50% of blocks can be identified directly by looking at the coinbase transaction - either they say the pool name or they are e.g. like p2pool you can identify it by the number of payouts and some of the addresses in there.

[organofcorti]

@Graet you were right. Block numbers are off. Blocknumber+1 is the correct one. So just a bug in the pool software

Which ones are out by one - ecki.net - or the other pools?

ecki.net or course ...
As mentioned above you simply look at the coin base to identify a lot of pools.
In fact around 50% of blocks can be identified directly by looking at the coinbase transaction - either they say the pool name or they are e.g. like p2pool you can identify it by the number of payouts and some of the addresses in there.

When I'm at work I have to deal with a locked down computer and internet - it's just easier to get other people to confirm things for me.

[organofcorti]

New post : Neighbourhood Pool Watch 4.3 Slush's score method and miner earnings part 2

In this post I derive the actual current loss of earnings for fulltime miners at Slush's pool.

6. Conclusions

• Slush's constant has changed to ~ 210. This has reduced the "hoppability" of the pool significantly. Currently, changing 'c' from 300 to 210 has reduced by half the maximum possible percent loss of earnings for fulltime miners.
• The current loss experienced by fulltime miners is (as a proportion of the expected fee free PPS reward, B/D) for current D, pool hopper hashrate, full time miner hashrate and c is ~ 98.5% of PPS, where a standard proportional reward method would result in fulltime miners only earning ~ 82.8% of PPS.
• Reducing Slush's constant 'c' makes pool hopping less profitable, but increases miner variance.

[emcg]

Thanks for the most recent topic as it was one I was waiting to read about.

[organofcorti]

In this post I explain how to select either a particular number of submitted shares per minute or a particular pool difficulty to result in an acceptable variation in average hashrate.

4. Conclusions

• Increasing average submitted shares per period only increases the standard deviation in submitted shares per period by the square root of the average submitted shares per period.
• When difficulty varies constantly so shares per minute remains constant, the variation in average hashrate is not dependant on the miner's hashrate, but only on the number of shares per minute.
• When difficulty is selected by the miner,  the variation in average hashrate is very much dependant on the miner's hashrate and the selected difficulty.