Do you aggregate payouts from the same IP? I have 6 poclbm instances running on two machines, each with a different address, and it seems I got to one of the addresses the rewards for all.

Raulo discusses the case of one proportional pool, when the choice is to switch from it to solo/score-based.

You all need to remember there isn't a magical tooth fairy that comes and gives you monies when you do the act of switching pools. It's all a matter of finding the expected payout right now for every pool and going with the one for which it is highest. For proportional pools the payout is determined strictly as a decreasing function of the current round age. For >43.5% it becomes less than solo/score.

Those beautiful days you could mine solo at 1GH/s will never return.
At the current difficulty, I'd say you need at least 5GH/s to think about it.
In other words, you should probably stop thinking about it.

Good. To convert to log scale:
1. Instead of storing r and lastscore, store lr = log(r) and lastlscore = the lscore of the last submitted share.
2. On difficulty change, update round set lastlscore=lastlscore+log(p2/p1).

In fact it's arguably even simpler. For this you don't need to keep ltotalscore. To find the expected payout of a worker for the current round, do

select (1-rd.f)*(1-rd.c)*p*rd.b*sum(exp(lscore-lastlscore))

p should be calculated based on the current difficulty.

That's basically what signature addresses are for, though they work on the user level and not post level.

That too, but I don't think that's what dikidera talked about. The fact that you link to a transaction in BE doesn't prove you made it (you can just go over a block and pick a random transaction). The correct counterargument to the possibility you might be scamming is that if you were not the sender, you would have no way of knowing that the receiver will be surprised by the transaction.

Yes, you can delete everything as long as you have a copy of wallet.dat somewhere.

I think that GPUs aren't very good for chess and that the popular chess software do not use them.
A search brought up this blog about developing a GPU chess software.

In the simplest model, you always want to mine for the pool with the least shares in the current round.
So if your current pool has 30% and some other pool has 0% or 10%, you hop.
The next step is to take into account the time wasted reconnecting to a new pool. If the difference is very small it is generally better to stay.
It will probably be beneficial to have several miners pointed at different pools with similar age.
Thus goes the theory, anon will have to discuss how he implemented this.

Perhaps I should mention that I had suggested a protocol change that would make this attack impossible?

Point taken, but I'm not sure participants necessarily have to know the details of the scoring method, any more than they need to know what hashing is or how the block chain works. I think also with some charts and graphs we can make it easier to understand.


@slush - The geometric method has two advantages:
1. Score fee - Using this, the pool is at a steady state where the past is always the same. In your pool you do not use a score fee, so very early in the round shares submitted compete with less existing shares, increasing payout. After a while it converges to a steady state. Shortening the time constant speeds up convergence and thus improves hopping-resilience, but adds variance to miners. By the way, the time constant should be proportional to the average time of finding blocks to maintain a specific tradeoff.
2. Share-base decay - Your pool uses time-based decay, which creates several quirks and attack vectors. For example, if the hashrate of the pool fluctuates and is currently more than average, the expected time to round completion (and hence, the expected depreciation of shares submitted now) decreases and it's more profitable to join.
PS. You promised a while back that you would look at my suggested method.

@anon4758 - Can you share with us, do you also post on this forum regularly under a different identity? (Obviously I don't expect you to say what that identity is.)

@anon4758 - this is some very useful info, thanks for sharing!

I generally agree, I mentioned elsewhere that I don't have a beef with hoppers, rather with operators of proportional pools.

In the theoretical limit of infinitely many proportional pools and perfect hopping, I think you get log(difficulty) times normal, which currently is X13, or 1200% extra.

I know, slush's has several flaws which is why I devised my method which I named the "geometric method".
Surely you don't get a lot of volume on slush with this profit?

You're probably referring to the geometric method. But hey, it's not complicated at all. Most of the post is just analysis of its various features.

Even if this works (which I'll try to look at at some point) it seems much more complicated.


The huge variance of solo mining is under the scope of the "other cases". But once you cut down, say, 99% of the variance with a score pool, there's not much point in decreasing it further.

Right, but if they want to go for "simple and understood", why not PPS? It has the least variance, it's simplest, and it has higher expectation than worst-case presence of hoppers.

... That's because difficulty increased 4 times in this period. Deepbit doesn't set the payout however they want, they divide the block reward by the difficulty and deduct a constant 10% fee.

No. Over a single miner. His expected payout is equal to his contribution. So if he keeps his intermittent mining over a long period of time, his total reward will be close to his total contribution.

Can you show your calculation why this is so?

I think you're confused about how score-based works. If you join at a time which, in retrospect, is late in the round, you will get more reward. Of course, you don't know beforehand when the round will end, so whenever you join your expectation is the same.
In fact, it is true for proportional pools that if you join late in a round you'll get screwed.

Again, it might happens that he has bad luck, but his expectation is equal to his contribution.

This will depend on greatly on the miner's risk averseness. Because in most cases variance is less important than expectation, and because the variance of score-based is not that high, the best recommendation is to always use score-based.

You always mine at the proportional pool which has the least shares in the current round. Once all such pools have >43.5% difficulty, you move to a score-based pool like Continuum.

Arguing on whether to call it "cheating" or "not cheating" is a red herring.
The facts are:
If one person does it, his payout is greater than his contribution to the pool (or to the Bitcoin network at large), and for others it's less. In this sense he does not do "all the work he has to do".
If everyone does it, all proportional pools freeze and people will mine in score-based / solo anyway.
So why add unfruitful complication by having proportional pools exists in the first place?

Luke-Jr, you need to remind yourself what mining is about. Mining is trying to find blocks, which secures the network. If you find a block, you receive a reward for your help. More generally, you can perform actions that have a chance of producing blocks and being rewarded for it. Your expected payout for your actions should be equal to your expected contribution (up to fees for any services you are using).

In the more parochial view of a specific mining pool, each share you submit has a chance of being a valid block which will boost the pool's total earnings. Once again, your expected payout must equal your expected contribution.

Compare these scenarios:
BFI_INT : Increases your chance to find a block for the pool, increases your reward from the pool = Good.
Pool-hopping : Does not increase your chance to find a block, increases your reward from the pool = Bad.
[Insert any improvement like better hardware, software, connectivity, LP that increase block-finding rate] : Increases your chance to find a block for the pool, increases your reward from the pool = Good.

Now I'll address your comments from the wiki.

This method prevents pool-hopping completely. I have now also posted a proof outline of this.
By pool-hopping I mean: "Using information like a pool's round age or current hashrate, to participate in it only when your expected payout exceeds your expected contribution".

Depending on the parameters, this method needn't be more vulnerable to this attack than any other.
Incidentally, I had also suggested a protocol change that would make this attack impossible.

Because he knows that if he'll be lucky and a block will be found shortly, his reward will be high. The expectation is the same, but the variance is greater. I have already said that score-based has higher variance. Variance is usually less important than expectation. Variance is not a black box, the significance and exact value of variance can be calculated (for proportional and geometric, anyway. slush's method is a bit amorphous) and generally the variance introduced by score-based is not really worrisome.

You are correct, everyone should be free to come and go as they please. Which is why I have never said people shouldn't pool-hop. I said people shouldn't join a proportional pool (because they will earn less than they should if hoppers exist) or operate a proportional pool (because it's promoting a bad option to miners who may not know better).
If people decide that pool-hopping is "not nice" and should be disallowed despite technical feasibility, a good working definition for it is what I gave above.

It's greater risk that doesn't create additional value to anyone, so there's no reason to be rewarded for it.

As above, I'm not very keen on emotional terms like "cheating" or "attacking", and prefer to focus on actual consequences. Score-based pools allow people to easily use their mining capacity to create blocks for the Bitcoin network, and receive a payout in proportion to their contribution.

Nothing is "needed". But adopting BFI_INT adds security to the Bitcoin network (compared to a situation where it exists but ignored by the honest network). Adopting pool-hopping does not add security to the network.

See above. I don't oppose hopping, I oppose enabling hopping.

This bit doesn't work (note that martok only asked if it would work). I will soon supply the correct formula.

It is.

It can have a numerical effect, but only for the worse. It can introduce a small error, and if the exp over/under flows you have a problem.

<sarcasm>
As we all know, Bitcoin can't be used unless you mine, so naturally, Groove will want to give away his $107 worth of bitcoins.
</sarcasm>

Note everyone, someone, probably this person, has already tried to pull this stunt under a different username.

I added ~1.5 Ghash/s 5 hours ago. I put my mining where my math is (hey, that's a really nice-sounding paraphrase!)

Detail: I added my 370MH/s personal computer immediately when I found this. But my mining rigs are harder to access and I was busy so I postponed it. Then my personal MB died and this miner was down until I got a replacement. Then the PSU for one of my mining rigs died, so I did some switching hardware around which left my PC unsuitable for mining. But at the same time I switched my mining rigs from slush, which total about 1.9GH/s.

Edit: Hm, I've just checked at http://www.continuumpool.com/ and it reports my mining rate is ~15% lower than what is reported by poclbm. Any idea why this is? (Sorry if this was discussed before and I didn't notice)

luv2drnkbr, I agree with you. Raulo's formulation of "not having contributed if you leave the pool" is incorrect. I have never raised my dissent because the analysis of pool hopping does not depend on it as a premise. It is still a way to benefit on the expense of others in proportional pools, which is unsustainable if done by everyone.

The correct way to view this is to ignore the past, look at the present and see how it affects the future. If I submit a share now, what is the expected benefit to the pool? What is my expected payout? Are they the same? In my scoring method, the contribution and reward are always equal (up to fees). In a proportional pool, the reward is higher than the contribution in young rounds, and lower in old rounds.

On a proportional pool, suppose the current round already has shares twice the difficulty. If you submit a share, what is your expected contribution? You have a probability p=1/difficulty to find a valid block with reward B, so it's pB. What is your expected payout for this share? No matter what happens, you will get less than (pB/2) reward, so the expectation is less than pB/2. So you're better off mining solo which has pB expectation per share.

What if the round is very fresh, say, no shares at all? Your contribution to the pool is still pB. But now you have a probability of p to get the whole reward B to yourself, this contingency alone adds pB to the expectation; probability p(1-p) of getting half the block - since 1-p is quite small, this already puts you at almost 1.5pB; and with probability p(1-p)^2 you get a third, and so on. So your expected payout is roughly log(1/p)pB, which at current difficulty is 13pB. So shares submitted early on will give you a very large expected payout, much more than your fair share for your contribution to the pool.

I have added a correctness proof outline to the OP.