This will not help since all old shares are in essence worth zero. Only the winning one is worth 50 BTC. I(λ) function is always positive. No matter how low is your payout after switching out of the pool, you still get "unearned" gains.

It may be possible to make cheating impractical but at the expense of making the pool more like individual mining. Because switching between pool and solo mining costs you some hashes (even if you do it as cleverly as possible), if the payout from cheating is low enough, it may be not worth cheating. I did Monte Carlo simulations  that show that counting only last 10% of difficulty of shares in the pool, reduces the extra cheating income to about 5% but the variance in the pool gets larger. But with multiple pools it get more interesting.

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.

slush and twobitcoins,

You are right. The block-shares resetting still allows for cheating. I was blinded by this nullification stuff and didn't notice it will erase some cheating gains but not all.

Slush "blinding" approach is probably best strategy currently (except awarding 50 BTC to the person who found the block which solves the porblem once and for all ) but I still think by some bitcoin network analysis (due to different network distances between the nodes) one can find at least the continent, where the current block is found. And the strategy would be to join the pool if the last block was found in Europe and leave the pool if not.  This way you will be more likely connected to the pool for fresh rounds and less likely for stale.

Contributed method is very tricky because in fact, all that matters is the winning block and the non-winning shares are all wasted.  

By the way, for those who want to have some practical test of this cheating strategy, instead of special functions, here is the Monte Carlo run which finds the round length (with exp(-x) distribution) and performs swiching to individual mining after some fraction of shares. Here is the awk code.

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.

But what you programmed is actually a perfect pool-abuse countermeasure that I realized after reading about your method:
http://bitcointalk.org/index.php?topic=3165.0

Instead of switching to slush's method, you should keep this one.

I have written a description of the optimal pool abuse strategy (for a single pool) with proofs and calculations. Available here:
http://bitcoin.atspace.com/poolcheating.pdf

If the link does work, use a mirror: http://mining.bitcoin.cz/media/download/poolcheating.pdf

I have started this work some time ago and it is not finished (I wanted to derive the optimal strategy for multiple pools but it's not ready yet) but with jgarzik's announcement of a new pool code, there is a chance we have multiple pools very soon and with multiple pools, pool abuse gets more profitable, and because I realized there is a perfect countermeasure, I decided to publish it now .

For those who don't want to bother reading it, the optimal strategy is to join the pool at the start of a new round and stop pooled mining after 43.5% fraction of the current difficulty of shares was contributed and start mining solo. This strategy will bring 28% of extra income compared to only pooled or only individual mining.

In this thread, the author finds no evidence of massive use of this strategy
http://bitcointalk.org/index.php?topic=2941.0
(I didn't read the paper since I find it strange to ask for a payment for something that may or may not contain anything interesting; and I didn't find any hard numbers in the discussion)
However, I was testing it in mid January with 3-4% of the pool hashrate. It is indeed very hard (at this level it is quite well buried in the noise) in the global hashspeed, but it is possible to detect by the pool operator by checking the payout. An abuser, will have significantly larger payouts in the short rounds than in longer ones.

Concerning the countermeasures. Apart of administrative ones (i.e. banning) which will be difficult if one starts to be more clever: randomly changing switching threshold, contributing all the time with a fraction of ones hashspeed, etc, there is of course a connected method which is will be very hard in slush's implementation. It is also possible to calculate the payout based only on the very recent shares but it only reduces the cheating payout, not eliminate it. However, after reading the recent jgarzik's pool discussion
http://bitcointalk.org/index.php?topic=3078.0
and his "bug", where he only counted shares contributed to the latest block, I realized that such counting is a perfect countermeasure. Since finding a block ensures that everybody else who worked on solving this block wasted its effort, there is no incentive to switching from the pool. If one switches from the pool and finds a block, the pool resets its counter and all the cheater's "unearned" shares will be lost. Of on the other hand, one switches from the pool and the pool find the block, it guarantees there is no individual income after the switching. I'd advice slush and other pool operators to implement this counting. It slightly increases the variance of ones income but it's fair, it's simple and eliminates cheating which with multiple pools can become widespread.

Edit; It won't work, see the further discussion.  

How does withdrawal of EUR work? There is only an option for an email destination. What then? Will I get instructions for submitting an IBAN number? Any fees?

Optimize first with the standard clock. Use SDK 2.1, it is faster but probably not 10% faster so it will not explain everything. Did you look at all the options? Low -f gives a few percent speedup (but makes desktop usage impossible).

Before I overclocked it, my 5850 got 244 Mhash/s with m0mchil's code so a bit better than this card in the table. I use SDK 2.1. SDK 2.3 was slower but I don't remember by how much. What SDK version do you use?

Probably. But I would try to run it on testnet and see if anything gets accepted. On testnet, you should get a block after several minutes. If it works on testnet, it's just a matter of time (and luck) on "realnet".

I found the same problem on some of my systems. This is likely a bug in glibc.
See my post http://bitcointalk.org/index.php?topic=1925.msg31333#msg31333.

I recommend compiling your own libcurl with --enable-ares (you need to have c-ares libraries). After linking to such libcurl, the problem is gone and my miner is working without a crash for 2+ weeks.

Completely dark pools, like mtGox, ones is not a good idea. I've never seen anything like that in any real market. However, partial hiding of the size of the order is done and should be rather beneficial for both the market and for the large order owners.

Suppose the minimum shown order size is 1000 BTC. If you want to sell, say 100000 BTC, you can mark only 1000 BTC visible (and 99000 hidden). If someone buys 1000 BTC, the order gets filled and another 1000 BTC on the ask side is shown (and the hidden part is now 98000). If someone buys 2000 BTC, 1000 BTC is sold from the ask part, then another 1000 BTC is immediately fulfilled by another part of the hidden pool and another 1000 BTC is shown (and 96000 hidden). If someone buys 100 BTC, 900 is left on the visible order. The hidden pool will be moved to the visible order only after the visible order is gone.

This way, you can hide some of the volume and not "scare" the market and the potential buyers can see that there is some order and can buy it and not act completely in the dark.
  

OK, I understand. All values are net. So essentially I "donate" some percent of the shares, don't I? In other words, you get the donation when the block is found. And If I change the donation percentage, it will not change the rewards for the blocks already found, only the future ones. Correct?

From what value is this donation is calculated? From unconfirmed reward, confirmed reward or reward sent? I've just got a bunch of rewards and nothing was subtracted.

I like the new statistics page. Is there a way to download "your reward" history older than the entries displayed on the stats page?

We have new difficulty and the pool has completed 66 blocks since the last change in difficulty. However, with the total number of shares completed (1167791), it should have resulted in 78.65 blocks on average. This might be due to bad luck (Poisson distribution gives about 8% probability of such an outcome) but before the last difficulty change, there were also less blocks than one should expect (see post #312). Such a bad luck twice in a row is rather suspicious. I am wondering (and worrying) if something is (slightly) wrong with the pool server and if some work is duplicated.

Slush, did you check if all the shares are unique or if there are some stale/invalid shares?

2^32=4294967296. A share is a solved block with "difficulty of at least 1 but less than current difficulty (which will earn the pool a block).

A small chance, yes, but to get paid much more.

I agree that pooled mining is more predictable and less random. But from the mathematical point of view, the average expected payout is exactly the same regardless of assumptions about hashspeed and growth rate.

If you like a constant stream of micropayments, pooled mining is for you. If you prefer the thrill of getting a block by yourself, do it the standalone way.

Standalone is like betting on a roulette. Except there is no casino that takes its cut. All the winning are distributed fairly. The thrill of gambling for just the cost of electricity

Probability distribution changes with pooled mining but the average expected mining income does not. No matter what your mining speed is and what your time frame is. If you have a slow CPU miner from which you can get only a 1 BTC a month from pooled mining (and less when the difficulty increases), you have 2% chance of getting 50 BTC in the same time frame (actually you have an average payment of 1 BTC, you have a slightly less than 2% chance of getting 50 BTC but also some chance of getting 100, 150 BTC, etc. )

The "benefit" depends on what you like. Some people would rather have a 1 BTC than a 2% chance of getting 50 BTC. But others would rather have a chance of winning more than get pennies. Millions of people spend a few dollars to get a tiny chance of winning a million in lotteries (even though the expected payment is negative). 


That's true. But there will be some CPU-miners who will win 50 BTC on their own, an amount they would never get from pooled mining. And the average of winnings of those lucky and unlucky is the same as the average income from pooled mining.

No. In long term, there is no benefit of pooled mining. The only difference is reduced variance in the income stream. Yes, you can get, say, 5 BTC before difficulty gets higher with pooled mining but you have equivalently 10% chance of solving complete 50 BTC block before difficulty gets higher in standalone mining.