Topic: Could BTCGuild be cheating its miners? - page 4. (Read 5833 times)

Also, people in this thread need to show their work when they are calculating probabilities.

Hint: you at least need to know the standard deviation.

I think this is an excellent point. Pretend you are a pool operator out to cheat. Having 5 visibly bad days seems like a bad way to steal. It would be both easier and less visible to skim off a small amount on a constant basis rather than inserting code that robs a large amount on a set schedule.

online poker is rigged!

Just wanted to say I for one don't have much complaints with btcguild *I think ad-funded sites are tacky/1990's though*.  At the very least my "24 Hour Rewards" at btcguild is 99% of the time above the "Reward estimation PPS: X.XX BTC/24h" at deepbit.

I realize the PPS has much higher fee's to negate the risk, but, it makes me happy.

I think the best analysis would be to start by taking the longest period possible. If the odds of performance that low by luck alone over that longest possible interval is not less than 5%, I'd say you can pretty much ignore the possibility of cheating on the part of either miners or the pool. If the pool is stealing from miners, it's not like sometimes they're going to cheat and sometimes they're going to sneak in bonuses.

I think questions should always be asked, so I don't begrudge you for putting forth the notion that BTC might be cheating.

However, people are notoriously poor judges of randomness. The "hot hand" in basketball is a classic example that statisticians use of sports fans attributing skill to what can be explained by a good run of randomness.

As you said, the luck suddenly shot up 70% for a day. Rather than focusing on the five days, it might make more sense to take an entire month, which includes the one good day and all the bad days. Put another way, I'm sure you know that flipping a coin and coming up with five heads proves nothing, even though the probability is 3%, which in the parlance of this post implies a 97% chance of cheating.

As a final note, your calculated probability of 0.6952% (which I have not verified) is well within a 4-sigma event (0.0165%). Four standard deviations is hardly considered extreme.

How many times would the random number generator have to say "NINE" before you believe something is wrong?

I did. Deviation in either the  positive or negative direction is a sign of manipulation.


"That's the problem with randomness, you can never be sure."

NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE NINE


How does Poisson work for this? During that time that we only got 105 blocks 807 blocks went by. With the binomial distribution calculator you put that 807 number in as the number of trials and that is a major factor affecting the probability. In the binomial calculator try dividing p by 10 and multiplying 807 by 10 and seeing how much it affects the outcome.

Here is the binomial calculator: http://stattrek.com/tables/binomial.aspx. Try putting in 0.1648, 105 and 807 in there from top to bottom. If you put in 133 instead of 105 that would be for a 0% luck 5 day period.

Just to clarify. Basically, my math (rounded to integer) shows that when we expect 133 blocks and 105 get solved it means that:

99% chance that here is either malicious activity or technical glitch or both (I have no idea which one it is)
1% chance that it is simply bad luck.

1% chance shall not be discounted since it is something that happens on about every 100th try.

However, no matter whether it is malicious or technical glitch these are equally good reasons to jump the ship unless one wants to play with odds stacked against him.

If someone would like to make his own DD, simply break available data over difficulty periods. You would need number of shares submitted for each difficulty period. Than divide this number of shares by difficulty, it will be your expected number of solved blocks for the period. Sum all the expected blocks for all the periods. Now you have both expected number of blocks and actual one. The longer time period you use the better.

Than read up http://en.wikipedia.org/wiki/Poisson_distribution or if you really lazy (like me) use one of online calculators like http://www.sbrforum.com/betting-tools/poisson-calculator/

Simply enter expected and actual blocks there and see 'at most' number. This will be a chance of pool finding at most so many actual blocks for given number of expected ones.

All you need to know for this calculation is number of shares and difficulty and number of actual blocks found.

Luck is luck.. And el is a very transparent person so not for one second do I believe he would cheat anyone. and yes there has been days where the luck has hit 50%+ and well no one complained then.


All I am gonna say is prove that he's cheating..


I call bullshit..

My silence on this matter has been the result of having 0 control over it.  I made my posts last time these threads started [which went away immediately when a few days later our luck surged the opposite direction for ~34 hours].

BTC Guild uses the following:

  Pushpool 0.5.1 [only modifications are adding in a long-poll disable bit to specific workers, and DB Schema changes].  6 smaller pool servers each running against their own bitcoind/wallet.dat file, so there is never "duplicated" work across the servers.

  Bitcoin 0.3.24 with JoelKatz's patches [upgraded to his 0.99 patch on Saturday]


So unless somebody finds a flaw in one of those two (pushpool or JoelKatz's patch), I can only shrug it off and wait for better days.  To those leaving over it:  I'll see you again after our next positive streak, just like what happened during the +54% day.

Regarding the 11m share round, within 24 hours of that round completing DeepBit reported a 16m round, just for reference regarding extremely long rounds.

I have a lot of respect for El and the other guys at BTCguild, and they claim they're running standard pushpool and there's nothing they can do about the bad luck.

I believe them.

Assuming that is true, what else could be causing such a run of bad luck, both in terms of technical glitches and malicious activity?

EDIT:, I'm an idiot, and I've been looking at the wrong chart and not paying attention to differences in scale bars. Ignore me.

There is not enough data to make conclusions. For 11 million shares (5.7 blocks expected, at most  1 found) probability is about 2% i.e. this is expected to happen every 50*11 = 550 million shares or so.

It is when we are talking about hundreds of blocks the probabilities could get much more damning quickly due to law of large numbers.

I had posted July 30th https://bitcointalksearch.org/topic/are-my-eyes-fooling-me-32933 where they had an 11 million shares round of no block found.

If we assume that you are correct on expectation of 133 while only 105 blocks found (I have not checked it) than probability of finding at most 105 blocks out of expected 133 is 0.6952%. This is rather high certainty i.e. more than 99.3% that something is badly wrong there. I'd suggest anyone to jump the ship ASAP (I would).

Check out http://mining.mainframe.nl my math shows that no cheating going on there.

On longer time period it is very easy to spot cheating. Take as long period as you have data for. Calculate expected number of blocks solved, calculate actual number of blocks solved. It should converge. The law of large numbers is working. A few such bad streaks as described above and certainty that a pool is cheating quickly goes over 99.99%.

Could be botnet miners, they cause high load and generally screw with things.

I left BTCGUILD.com for the same reason. I noticed the beginning string of "bad lucks" back when they implemented the 1 hour delay announcement to avoid pool hoppers. If they can delay announcement, can they "forgot" to announce?

Edit: And now, high stale shares - https://bitcointalksearch.org/topic/a-ton-of-rejectedstale-hashes-on-btc-guild-35507

I left btcguild recently because of this. Could be a technical problem too.

Could be.

By my math, such an attacker would have to have at least 1/7th of the pool's hashing power.

OR someone is trying to kill the pool by withholding shares that meet the network difficulty.