Well, in the discussion, you could have seen confirmation that people who bought the paper didn't feel cheated. The reson I'm asking money first is that I don't believe people would donate, especially people who want to abuse pools. However, it's been some time since anyone downloaded the paper, so here it is, for free:
http://www.bitcoinservice.co.uk/files/111

If anyone wants to donate (and that would incite me to write more about bitcoin), here's an address:
1ESWeHDPSEErzr6tcm3aToVGXKUe8kA9D8

Not that much and only for low-hash rate miners that have a lot of variance anyway because even now there are short rounds and for CPU-miners, there is not a matter of reducing variance but increasing probability of any payout and your pool will still work in this respect.  The most variance in your pool comes from different level of "pool daily luck" anyway and this scheme will not change it.


No, it won't. The whole idea of the pool abuse is that you get paid in two places at the same time. With jgarzik's scheme, it's either or. Either you get paid from the pool, or individually. You never get paid twice. If you start mining on every bitcoin block and stop after some time, you either get paid from the pool (pool found a block) or from yourself (you found a block). Finding a block individually guarantees pool shares reset and all you accumulated shares loss. And finding a block by the pool guarantees that you did't find this block by yourself since the switch time. 


It's your pool and your rules but I'd recommend you reconsider it because your strategy below is much more messy.


Actually, the only thing that the cheater needs is the time when the round started so he can join the pool. Since the I(lambda) function is positive, he can switch out anytime provided he joins when the round starts. You will not only need to hide the number of shares but the round starting time and the number of shares one accumulated in the given round (otherwise the cheater can connect one of its miners and see when the counter starts from zero). This way you can effectively turn off all the statistics and publish only "pool mining digest from yesterday". It will also be unfair to anybody who wants to join the pool (and not cheat) because joining midround is unfair. In my opinion, it will impact the usability of the pool much more than the jgarzik's counting method.

And although I'm not sure because I'm not fluent in the bitcoin protocol, I believe a bad guy can test the bitcoin protocol traffic  to learn that it was the pool that found a block (and hence a new round started) by connecting to your 8333 port and getting your "new block found" broadcast before getting this message from other nodes.  Even if you block your port and connect only to some trusted nodes, by listening to other nodes traffic, he may estimate the probability that you found the block and not a guy in, say, Japan which will have a different node propagation signature. He does not need to be right 100% of the time, being right more than not will be enough. Remember, joining and switching off from the pool at complete random intervals is payoff neutral (apart from startup inefficiencies) so it will be enough  to join more frequently at the start of the round than not. And by looking at the delayed statistics he can check if the strategy worked.

Furthermore, the difference between an acceptable optimization strategy (whether or not it gains you anything at all) and cheating, is IMHO the fact that if everyone used this 43%-strategy on the current system, it would break down (rounds wouldn't ever get finished), while in a only-shares-for-a-block system, the resulting gains would still be perfectly proportional to invested computation power (as share count would be reset after a block is found, even if everybody stopped pool mining, and people would join again).

You don't lose on quick blocks. You lose on slow blocks. People who "cheat" simply lose less than you on slow blocks.

If you want to check whether people are "cheating", don't look at quick blocks. Chart computing power against time, and if people cheat, you'll notice a drop as blocks grow longer.

In quick rounds is much bigger variance. Many people asked me why they have low reward from some short rounds. Basically it is because they was unlucky in those 3 minutes or so. Mining isn't steady at all, even on diff1 and strong machines, of course.


Which one?


Afaik this is default bitcoin behaviour.

I have no opinion about you, good or bad. My interest is what can be done, not what is actually done.


As the pool was before, with full statistics, users could check whether their revenue was really ((50/total_shares) * nb_shares). They could also, by talking with each other, evaluate if the pool reported a plausible number of total shares. While there were ways for the pool to cheat, the statistics allowed users to check it didn't cheat too much.

My understanding of the way your pools works now is: miners find shares, they receive bitcoins, but they can't know how much the pools pays each share. As long as you release data on how much a share is worth, "cheating" becomes possible. I was wondering if you had found a way to preserve both openness and fairness.

I believe having the value of contributed shares decrease over time would also fix the cheating problem, ensuring that the expected gain of joining is the same at all times. And you'd still be able to display the statistics like before.

I must admit I didn't go through every line of the paper, so I just wanted to double check if I understood the problem correctly, in simple terms.

Is the problem this, as an example: assume there are 10 miners in a pool, and they each calculate 1000 hashes before the winning block is found. Then among those 1000 hashes, each of them has created the same expected amount of shares (let's say they have 2 shares on average). That would be the fair case.

The problem is that usually the shares won't be the last hashes to be found. So miner X might already have generated 2 shares among his first 500 hashes. If he stops exactly then, he'll have the same number of hashes as the other minors, for only half the work (on average). Of course had he continued to do 500 more hashes, he likely would have created more shares, too, so the calculation is not THAT simple.

Or in other words: if you stop right after receiving a share, you will have done less work for your shares than the fair miners, on average.

Not sure if all the maths in the paper adds up, as I said, I didn't check thoroughly. For example it might be incorrect to talk about n hashes, because if the winning block is found before n hashes, there wouldn't even be n attempts at hashing (I assume once a block is found, all calculations reset to the start :-) Correct me if I am wrong, but isn't the expected number of winning hashes after n attempts simply n*p? 1-(1-p)^n is not the probability to find one block after n hashes, it is the probability to find at least one block after n hashes (and, as I said, in a typical scenario there would not be n hashes, as hashing stops after the first block has been found). (I tend to get these probability calculations wrong all the time, though - my apologies in case I am just spouting nonsense).

Yes, the average is n*p but what we need is the probability of finding indeed at least one block and by reverse not finding any. This is what drives the strategy. If the block is found early, keep mining for the pool. If not, start individual mining and return after the pool finds a block.

Below is a script for calculating cheater's income in a pool that keeps only some number of most recent shares. It makes the switching from the pool much less profitable.


The above code calculates payoff for a pool that keeps 5% of the difficulty number of shares and the cheater exits from the pool after 7% of the difficulty (this value has to be much lower, lower than original 43%). The calculated value is about 2% which should be low enough to discourage this behavior as switching miners has some overhead (and the pool also has some latency overhead compared to solo mining). Keeping 10% difficulty, results in about 4% gain.  

With a little effort by the bad guy, slush will have to have an investigative team to find the problem. Switching users, switching IPs, being honest for some time or cheating with only a part of ones hashrate, all it make harder for the pool operator to detect. There is a lot of normal variance and it masks quite a bit. And it will be even harder, if there are many pools. Sure, if you cheat with, say, 25% of the pool hashrate, you are exposing yourself but with up to 5%, not that much.