No. But I don't think I can ever convince you of the difference between finding history vs the odds of it repeating itself.


If every block was being marked as invalid, would that be a sign of "bad luck" or of a software problem. If, after the pool operator applied a patch and blocks were now being found successfully, would you expect the future runs to revert to every block as invalid? Or would you treat that as a discontinuous function instead of a continuous one?


They don't change the yield, but understanding the events that were causal is much more logical than just assuming you understand the distribution perfectly. Congratulations, you found a pool that were you to possess a time machine you would be able to warn people from the past not to use it.


Well, I suppose I should just let you cherry pick your results and pass them off as statistics.


You don't understand how a DDoS from a botnet could affect performance? Or a patch that prevented submitted shares from being aggregated correctly might skew results? I think I see now why your view on this subject is so narrow.

It does not make the payments random. If I combine the shares for two consecutive blocks and combine the rewards for the blocks and then only distribute the reward (and the information about the second round starting) after both blocks have been found, hoppers should not be able to take advantage of the start of the round for the second block. The total rewards to each miner will be identical, the information is hidden until it cannot be acted upon.


So, someone breaks into my server and instead of just transferring the thousands of bitcoins sitting in the wallet, they take my random number seed? Also, obscuring data until it is no longer actionable is not "faux security", The data will eventually be available to all, this is the nature of bitcoin. Delaying the dissemination until it is useless to hoppers removes the piece of data they require in order to function, namely the point in time a new round starts. Again, the payout function is not random, the reporting and aggregation period for payouts is.


PPLNS where N varies is almost exactly what I proposed. Except N varies according to the number of shares in some number of solved blocks.

The payout in absolute terms does not decay. The rate of return decays. In my opinion, time should always be a component when evaluating human behavior in an economic context.


It was just a counter-example to discount a claim that a function was always continuous and positive. It was not meant to disprove the existence of rewards for pool hopping. They do exist, but I believe they have been quantified in a way that is misleading. Vladimir brings up an excellent point with mtred where it's hashrate changed from 100Gh/s to 400Gh/s to 100Gh/s. There are only a few pools available and the longer that mtred spends in the unfavorable share of a block, the longer it cannot be hopped into. This is a corner case where the number of pools is small and the length of rounds is potentially very large because of increased difficulty and dramatically lower hash rate.


Yes. But it was supposed to be a single counter-example in the form of "what if this occurred once when the stars are aligned, the result will be zero". It was not meant as a template for behavior in mining.


Hoppers are a minority in the overall population, at least I think they are (/checks under bed and in closet). However, in a small pool they can easily form a temporary majority. The reason why I bring up this "corner case" is that I believe we are actually living it right now.

As for solutions, I think smoothing the rewards over a varying number of blocks found would make it impossible to know the dimensions and boundaries of a "round". That would make it very hard to hop effectively unless the hoppers knew the algorithm and inputs to the smoothing function. The issue is that the reward for the block is arbitrary with respect to the work completed.

The odds of finding outcome in a dataset is different than that outcome occurring in a single monte carlo run. You need to calculate what the odds were of finding a pool with luck that bad, not what the odds were that a specific pool would experience that luck in the future. One is more likely than the other, and misrepresenting the data in this fashion doesn't do anyone any favors.


If one were to go back to June 1st and then decide a pool to mine in, you would be absolutely correct. Going forward, what sort of prediction would you make about the performance of BTCguild? I went and asked the pool operator about events that had an outsized effect on performance that were unlikely to recur. There were 3 and they were very visible in the data set. (DDos July 4th-7th, DDoS Aug 12th, a bad pushpoold patch from June 29th - July 2nd). Also, you didn't treat the invalid blocks correctly in your data set, but that is another conversation.


The historical performance is definitely subpar. However, after dropping those 3 periods the picture changes quite a bit. I do mine with them currently, although I didn't point any significant hashing power at them until August, after the dust had settled from the DDoS and patch issue.


You are going to throw out 20 days worth of data that demonstrates a clear trend in 4 pools (including the one your are discussing now)? When I come back in 10 days with 30 days worth of data, will you dismiss that as well? You were not even curious as to why 4 pools were clearly below trend and the other 2 were flat?


First point:: I believe you calculated the odds incorrectly regarding finding a set of bad luck in the search space of pools

Second point: I believe you treated the invalid blocks found incorrectly in your data set

Third point: I believe you represented past data that contained extreme and discontinuous events as historical norms. If you going looking for a problem in the past and show how the performance deviated from expected as a result of those problems, that is fine. You shouldn't represent that search as the result of a true Monte Carlo run to be expected in future performance.

Fourth point: I believe you are dismissing data that disagrees with you because it is not "as significant". Your response should have been: "Oh, that is interesting, I wonder why that is." I wonder why those pools are under-performing and I believe that someone who claims to be providing a defense course for pool-shopping should wonder as well.

You are very right about one thing, with hindsight we should have absolutely avoided BTCGuild on 7 out of the last 60 days. I am trying to keep this discussion collegial and courteous, I am not trying to pick gnat scat out of pepper to just to troll you 

The calculations ignore that the hoppers change the rate the reward is realized by their movement from one pool to the next. They also accelerate the rate at which the reward for the pool they hopped too is realized, including the part that was calculated before they arrived.

Eventually, but leaving the pool degrades the reward to be obtained from that pool. The paper ignores the time component and treats the reward as constant.


It doesn't matter whether they actually hit 50% or not, it works for any percentage whether they are correct or not. The half way point just makes the math easy, and it is contained within the continuum which is supposed to be non-zero. It doesn't matter where the miners think they are, the point is that a single counter example exists for which the continuum is zero. A miner could leave randomly, land on 37.82734% and it just makes the addition annoying. All I was doing was providing a counter example in a continuum which was claimed to be non-zero for all values of x.


I shall look at that paper. Until we quantify under what circumstances hoppers can obtain benefits, we cannot understand the ethics of the behavior.
(time elapses)
I have looked at the paper. It is indeed a better explanation, however you still have the assumption that hopper hash rate will be magically replaced after it has left the pool. Why would anyone hop into a pool that has over 43.5% shares already submitted when they have a choice of a better pool? Nobody has yet discussed the decay rate of hopper's rewards over time in the pool they leave as compared to the expected rewards in a new block in a new pool for which there is suddenly more competition.

One of my contentions is that after some percentage of the pool hops, it becomes counter productive. Moreover, the supply of pools is quite small and I could see scenarios of hopper congestion given a large enough population of hoppers.

Yep, you are right. one roll of 6 dice is will show a 1 66.51% of the time. /sadface
My point was the probabilities were different. I assure you, my point was not to belabor the fact that I am a moron. 

Two things I noticed about Raulo's paper on pool hopping:

First there is no component of time in any of the reward calculations. This is curious because humans usually consider a reward as a rate of return over time.

Second, the paper claims that (assuming a contributed mode pool):


 the cheater payment share is
                                        λ
                             S(λ, x) =                               (5)
                                       λ+x
and is non-zero for all x and λ > 0 which shows that in this continuous
model in contributed mode cheating always pays.


Well, the first and most obvious counter example to this is that if all participants of pool A hop out and nobody hops in. Since pool A now has an effective hash rate of 0 Mh/s the cheater payment share will never be realized because the next block will never be found by that pool. That implies a total rate of return for all the hoppers of zero.

Let us now modify this scenario slightly, all participants of pool A hop out at 50% of the shares needed to find the next block. The cheater payment for the next block will be 25BTC (to be divided amongst the hoppers according to their individual shares) when the block is found. 1 intrepid soul hops in and grinds away for however long it takes to find the next block. Nobody else hops in. When the next block is found, that intrepid soul contributed half of the shares and receives 25BTC reward for his efforts. Now I realize that one cannot know for certain when this 50% of shares required to find the block has been reached. That point does however fall within the continuum of the cheater payment share equation and appears to be a zero gain under these circumstances. Let us presume that these hoppers have network of magic 8 balls that will notify them of the exact half-way point in the block search.

One could further presume that the intrepid soul has immense hashing power at his/her command and this power is in fact equal to the combined rate of all those who hopped out of the pool. If this person hops in after everyone has hopped out, it appears there is no cheater payment to be had. Since the hash rates of the hoppers and the soul are equal, the rate of return over time is unchanged.

A further counter example is if the intrepid soul (let us call him Ralph) has been there from the start of the current block search. Ralph will acquire 25% of the shares at the point which the hoppers consult their magic 8 balls and leave (@ 50% of the shares required to find the next block). Ralph will then continue the search by his lonesome and the total search will consume 150% of the time it would have taken had none of the hoppers left. Ralph will acquire 75% of the shares for the block and earn 37.5 BTC. The cheaters payment needs be part of the 25% of the shares acquired by the hoppers before they left. This rate of return of hopping has been degraded by the additional time it has taken for Ralph to search for it on his own.

Maybe I need more coffee, but I am having trouble reconciling these scenarios with what was predicted on page 3 of the paper.

What if they flipped a coin made by a "friend" who claims that he made the coin right. It is the first time he has ever made a coin, but he did his best to make sure it was flat and looked good. We should first test the performance of this coin against the universe of coins made by friends, not against the theoretical 50/50. If we need to choose a coin to flip, we should compare then to each other and then choose one.

Also, the point is not that all pools are having bad luck. The point is that the universe of pools was examined and a single unlucky one was chosen. A better analog than coins might be dice. Imagine throwing six dice. One die comes up with 1 and we calculate the odds of that die landing on 1 correctly as 1 in 6. But that is not what we saw, we saw 6 dice land and the odds of any one of those dice showing a 1 is 1 in 1. Now let us suppose that these dice were not bought from the store, but were each made by a different individual. Now we are no longer sure what the correct distribution of die faces is for any of the dice.

Finally, the pools use different infrastructure. There is work to be done by the server when a share is submitted. What if pool A waits until all that work is complete before acknowledging to the client that it has received a submitted share. If clients cannot begin work on a second share until the first is acknowledged, this serializes the share submission with server share collation at the cost of latency. If pool B allows clients to submit their share and then immediately gives them a new one to work on before the collation work is done on the server, the share submission and processing are overlapped. Pool A's method has the effect of a natural governor on the speed that clients can use the server. Pool B's method minimizes latency but relies on the server to never get bogged down. Under maximum sustained load, these two systems will measure the same. But under failure conditions, they will measure differently.


BTCguild did experience a DoS situation in June, I do not have the exact dates. But the scuttlebutt was that it was from a botnet, that it occurred over the course of a couple of days and peace finally "broke out". I am not sure just what the effect this might have on the "efficiency" of a pool, but I suppose it is possible it could skew the data.


Actually, they do. http://www.l0ss.net/index30.php
As you can see, there is very little if any "good" luck to be found in any of these 6 pools over the last 30 days.
Note btccoins.lc, btcmine, and mtred are all well below the expected luck line. What if there is friction that derives from a common component in the make up of these 3 pools? The luck for these 3 pools is demonstrably worse than btcguild, perhaps you should calculate what the "odds" of their bad luck occurring as well. Then we can calculate the conditional probabilities of those 3 pools + btcguild all having this sort of bad luck all at the same time. 

Also, one side question. How did you account for the invalid blocks?

Vladimir: After looking at your spreadsheet, I found a flaw in your analysis. You need to calculate the Poisson for all blocks found by all pools (and expected), not just the ones found by btcguild. You then need to determine what is the likelyhood that out of all the difficulty periods in all the pools, one will exhibit a run of "bad luck" such as the ones you found in BTCguild. You are failing to account for the selection bias effect.

For instance:

I separate people into many groups and have them all flip coins. I then tally each groups expected number of heads and tails. I see that one group has more heads than tails, and I calculate the Poisson distribution of that group as if those were the only coin flips thrown. Of course, this will show that groups efforts as unlikely to have occurred because I have masked out the efforts of the other groups.

Edit:

Also, you are comparing a real world empirical measurement to a perfect world theoretical average. Since there is no magic fairy dust that would result in a computer solving blocks at an average rate consistently faster than this theoretical average, we can ignore positive biases. If there was an operational friction that was not accounted for, it would exert a negative bias to all results. The way to account is to examine the poisson of all blocks found vs expected, btcguild blocks found vs expected, and all blocks without btcguild vs expected. That may produce a baseline would could illuminate any unseen frictions. It might be interesting to do that exercise for each pool, if deepbit had less friction its size may mask higher rates of friction in other pools.

The creepy part is, he did the silkscreen shown in that picture. 

Irony: me quoting misinformation about bitcoin in a thread about how misinformation about bitcoin doesn't matter.

I now proceed to not care! 

No, it is not normal. It is a bug in the Catalyst drivers, you should change driver versions.

Do you have dummy plugs installed on all the cards?

Change your drivers. Try 11.6. Make sure you uninstall the current drivers before you install the next version.

There is a version of Catalyst drivers that do not have the 100% CPU bug. Catalyst version 11.6 works on LInux.
On my windows box, I have driver version 8.861 from 5/24/2011 and it is barely using any CPU at all. I believe that driver is from the 11.6 Catalyst package as well.

Quaecumque.

This was all a carefully crafted ruse to get you to fly off the handle. Happy Birthday! 

That is the odds of it happening again over the next 50 days. Since you went looking for bad luck in the history of pools, you need to account for all the days in all the pools for which you found none. You need to calculate the odds of finding that 5 day period in 4 months of data from 3 pools.

Also keep in mind, the original poster has been examining all the pools for statistical clusters of bad luck (as evidence of malfeasance). When the OP presented the odds of finding the cluster, he failed to mention the other 2 major pools he examined (deepbit and slush) and did not include them in his search space. The OP presented the odds of his finding occurring as if he had only examined 1 pool instead of 3. Had he found bad luck in slush or deepbit, he would be talking about them instead of btcguild in exactly the same way.

It is as if he flipped a coin 1000 times, dropped 700 of the results completely and then chose a run of NINE tails over a 10 flip period. I would absolutely expect him to find a run of "NINE" tails out of 10 under those circumstances.  

I would also expect him to try to convince me of how "unlikely" the existence of that event was.


Both Vladamir and Mad7 are conflating two calculations of odds:
finding this behavior in the next 5 days for btcguild
finding this behavior in any 5 day period for any pool

Vladimir correctly calculated the odds of finding this behavior in the next 5 days of btcguild. However, that is not relevant. We need to calculate the odds of searching every possible 5 day period for every pool (or even just the 3 biggest) and finding this sort of luck. The OP set out to find the luckiest pool to mine in and to find the unluckiest pool to accuse of cheating.

That is the case if you want to prove a negative. We do not have to prove that you have not been cheating. All you need do is point out the fact that no proof has yet been presented and leave it at that. The OP got his odds wrong, as people who are not familiar with math have been doing for decades in Vegas.