Neighbourhood Pool Watch - page 5. | Bitcointalksearch.org

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

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.

Quote

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.

emcg

newbie

Activity: 12

Merit: 0

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

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

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.

Quote

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.

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

Quote from: kano on September 05, 2012, 06:24:33 PM

Quote from: organofcorti on September 05, 2012, 06:15:46 PM

Quote from: ShadesOfMarble on September 05, 2012, 11:00:03 AM

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

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: organofcorti on September 05, 2012, 06:15:46 PM

Quote from: ShadesOfMarble on September 05, 2012, 11:00:03 AM

@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

donator

Activity: 2058

Merit: 1007

Poor impulse control.

Quote from: ShadesOfMarble on September 05, 2012, 11:00:03 AM

@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?

Graet

vip

Activity: 980

Merit: 1001

Quote from: ShadesOfMarble on September 05, 2012, 11:00:03 AM

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

good news

ShadesOfMarble

donator

Activity: 543

Merit: 500

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

Graet

vip

Activity: 980

Merit: 1001

Quote from: ShadesOfMarble on September 05, 2012, 10:00:24 AM

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)

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

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.

ShadesOfMarble

donator

Activity: 543

Merit: 500

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

Graet

vip

Activity: 980

Merit: 1001

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 [email protected] in the coinbase
easily seen here http://blockchain.info/tx/cc8e9de906601a9f1537d83d0c86f48f76853cdae835d18141e1ca3186d9e62b/cc8e9de906601a9f1537d83d0c86f48f76853cdae835d18141e1ca3186d9e62b for example

ShadesOfMarble

donator

Activity: 543

Merit: 500

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://bitcointalksearch.org/topic/m.874690

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.

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

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.

Shadow383

sr. member

Activity: 336

Merit: 250

Quote from: organofcorti on August 28, 2012, 06:21:04 AM

Quote from: Shadow383 on August 28, 2012, 06:06:35 AM

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

donator

Activity: 2058

Merit: 1007

Poor impulse control.

Quote from: Shadow383 on August 28, 2012, 06:06:35 AM

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

sr. member

Activity: 336

Merit: 250

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

donator

Activity: 2058

Merit: 1007

Poor impulse control.

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?

Quote

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.

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

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.

Quote

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

donator

Activity: 2058

Merit: 1007

Poor impulse control.

Quote from: kano on August 01, 2012, 10:33:22 PM

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 Wink

Topic: Neighbourhood Pool Watch - page 5. (Read 49907 times)