I know I'm going to regret subscribing to this thread.

But late February 2011, it was mentioned on LW that SIAI accepts Bitcoin donations.

At first I thought, "hm, Bitcoin, is that a new payment processor?". Nothing has prepared me to what I was about to find out .

Ouch, you've done this wrong. In my specification I meant that the scores for existing shares will remain the same, while the variable s that specifies what will be the score for new shares decreases (multiplied by p2/p1). Equivalently, since it's all relative, you could fix s and multiply all scores by p1/p2. But what you've done has two problems:
1. You've multiplied existing scores by p2/p1 instead of p1/p2.
2. Since you don't keep s as a separate variable but rather read it from the shares table, you have scaled both the existing shares and the new shares, so the difficulty fix will actually have no effect whatsoever.
Basically what you want is that the score for the first share submitted after the difficulty change will be multiplied by p2/p1. Then proceed as normal, each share will reference the last one and it will be ok. I don't know what's the DB-friendly way to do that.

Once you show me your solution, I'll adapt it to log scale.

It's quite simple. Note that the value chosen for max is not important, it just needs to be comparable to the highest lscore value and be used consistently.

Keep a value ltotalscore which will represent the logarithm of the total score. Initialize it to los. When a new share is submitted, let ltotalscore += log (1+exp(lscore-ltotalscore)).

Now, if at any point you want to find the balance of a worker, you do

select (1-rd.f)*rd.b*sum(exp(lscore-ltotalscore))
from share where round_id = rd.id
and lscore is not null
and worker = worker_id;

I assume you want to find the balance mid-round? The above will give you what would be the reward if the round ended now. I think it will be more useful to know what is the expected reward. This requires a small tweak, let me know if you are interested in it.

Thanks! This was obviated by slush's gracious hosting.

Thanks! Saved to disk this time.

I don't know if it would be better to discuss this here or on the wiki. I'll discuss it mostly here for more visibility.

1. If most people mine normally and some do pool-hopping according to Raulo's suggested strategy, those that hop will earn more in proportion to their hashrate, and those that don't will earn less. It's just basic sense and I can go over the math if you'd like.
2. If everyone pool-hops, any proportional pool that is in a round that reached 43.5% difficulty shares will freeze, because everyone will hop away from it and no new shares will be submitted. Rounds of greater length are typical, so this will happen very quickly.

We can, if you'd like, discuss the practicalities of pool-hopping without being detected and countermeasures against it.

That's false. Your expected the payout per share is exactly the same no matter when you submitted it (this is true for my method, for slush's early-comers still do have a slight advantage).
Round length follows an exponential distribution, which is memoryless. If the round is young, you're just as likely to be the lucky one who submitted a share close to the end of the round, as when the round is old.

No, it's not. Shares already submitted will depreciate the same way whether you stay or disconnect. And future shares will have the same expected payout whatever the scoring method.
For full disclosure, I should point out that with slush's method (which depreciates based on time), if you are a large miner, you can gain a tiny insignificant advantage if you do stick with slush's pool. This is a quirk of slush's imperfect implementation (much like it is still subject to some hopping), it's not a feature of score-based and it doesn't happen with my method.

That could have made some sense if it was possible for everyone to do it and it would even out. But as I said, that's impossible - if everybody did it, proportional pools would just freeze.

It looks like the paper is unavailable from http://bitcoin.atspace.com/poolcheating.pdf . Where can I get it now?

And this was of course mentioned in my description of the method, and earlier in this thread.

Apparently, it was naive of me to expect that the wiki won't be abused. I have requested the page to be deleted, and recreated the FAQ as a forum post.

How does mining in a pool improve my payouts?
Pooled mining will not have a significant effect on the expectation of your payouts (it can decrease a bit due to fees), but it can dramatically decrease their variance.

What reward systems are there?
All reward systems use the concept of "share", a hash which is easier than the real difficulty and proves you have worked on finding a valid block. Your reward when the pool finds a valid block depends on the shares you submitted.

The main reward systems used are:

• Pay per share: Every share submitted receives a fixed BTC reward known in advance. This has virtually 0 variance and is thus good for beginners. However, the operator is subject to enormous variance, and will thus take a large fee to cover his risk. This means the expectation for participants is low, so it's not an attractive long-term solution.
  It is also vulnerable to sabotage where the miner simply withholds all block-finding shares, causing a loss to the pool operator.
• Proportional ("Share-based"): Every time a block is found, its reward is split between participants according to the number of shares they submitted. This method is vulnerable to a form of cheating known as "pool-hopping". In the theoretical limit, this can reduce the payout for honest participants by up to 30% (in practice the decrease would be much less, but can still be significant).
• Score-based: Each share submitted receives a score based on its age, and the block reward is split between participants according to their score. The method used by slush's pool and BTCmine are resistant to pool-hopping, while the one used by Continuum pool ("geometric method") is completely immune.
  The variance of this method is slightly higher than proportional.
  There is a myth that score-based is disadvantageous if you only mine several hours a day or disconnect in the middle of the round. In fact the expectation (which is the more important part) is exactly the same, and only the variance can slightly increase. The shares already submitted will depreciate the same way whether you disconnect or not, and the newer shares will have the same expectation for any reward method.

What will be my expected payout per share?
Every share will give you, on average, the block reward (minus any pool fees) divided by the difficulty. For example, with a block reward of 50 BTC, 2% fee and difficulty of 240000, each share submitted will give on average 0.000204 BTC (204 μBTC).

How many hashes does it take to find a share?
On average, one share will be found for every 2^32, or 4.295 billion, hashes calculated. So at 1 MHash/s, you will find a share on average every 72 minutes.

How much will the pool decrease my variance?
If you constitute a significant part of the pool (say, above 1%), your variance will be roughly proportional to your portion of the pool. If, for example, you are 20% of the pool, your variance will be 20% of solo mining variance (a decrease factor of 5 times).

If not, your variance will not depend on the size of yourself or the pool, but rather on the scoring method used. For proportional, the decrease factor is roughly difficulty/ln(difficulty). For the geometric method the decrease factor is roughly (1 + 2*difficulty*c), where c is the score fee parameter used.

Increasing the size of the pool will always decrease the variance, but at some point you will have diminishing marginal utility.

Actually, just moments ago I thought about this again and realized your code doesn't contain the part of updating on difficulty change. Is that on purpose? There is a simple way to implement this, and with a simple tweak it will work for logarithmic scale.

No, that's the magic of the -max part. max can't be much smaller than lscore and los, so the exps won't overflow. They can underflow, but I'm assuming in this case they just return 0 which is ok.


Oh, and I missed two places where score should be replaced with lscore, fixed now.

Ok, I think I know just enough SQL to be able to translate this to logarithmic scale, obviating the need for periodic rescaling. I am assuming log and exp return the natural logarithm and exponentiation. You will of course need to check I didn't mess anything up and test it thoroughly. Note that keeping lr in cache will remove the need to calculate it for each share, and that the summation function in round end is somewhat heavier. Note also that the first function now returns the log of the score. Here is the code, I have also renamed os and score to los and lscore, and bolded the lines I changed.

CREATE OR REPLACE FUNCTION share_score() RETURNS trigger AS $$
DECLARE
rd round%rowtype;
d double precision;
p double precision;
lr double precision;
ls double precision;
BEGIN
d := difficulty from difficulty
order by time desc limit 1;
p := 1.0/d;
select * into rd from round
order by id desc limit 1;
if rd is null then
-- First round
insert into round default values;
select * into rd from round
order by id desc limit 1;
lr := log(1.0-p+p/rd.c);
update round set los=log(1/(exp(lr)-1))
where id=rd.id;
ls := 0;
else
lr := log(1.0-p+p/rd.c);
-- Get the last score
ls := lscore+lr from share
where round_id = rd.id and lscore is not null
order by id desc limit 1;
if ls is null then
-- first insert in this round
ls := 0;
end if;
end if;
NEW.round_id := rd.id;
if NEW.our_result = 'f' then
return NEW;
end if;
-- No need for rescaling!
NEW.lscore := ls;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION worker_payments(rnd_id integer)
RETURNS table(
worker text,
cr double precision) AS $$
DECLARE
rd round%rowtype;
totscore double precision;
max double precision;
BEGIN
select * into rd from round where id=rnd_id;
max := lscore from share
where round_id = rd.id and lscore is not null
order by id desc limit 1;
totscore := sum(exp(lscore-max))+exp(rd.los-max) from share
where round_id = rd.id;
RETURN QUERY select share.worker,
(1-rd.f)*rd.b*sum(exp(lscore-max))/totscore
from share where round_id = rd.id
and lscore is not null
group by share.worker;
RETURN;
END;
$$ LANGUAGE plpgsql stable;

1. Some people need the 0.01% services.
2. Some people buy as an investment because they expect the value to rise (due to becoming more ubiquitous and practical).
3. Some people want to be part of this movement out of ideology.

1. They don't have to pay fees for receiving payment.
2. They don't risk being chargebacked.
3. They get extra sales to people who prefer to pay with Bitcoin.
4. They want to be part of this movement out of ideology.

In this system, it is always more profitable to mine early in the round. And once the round is over, the later shares are always more valuable. C controls the balance between hopping-resistance and variance (high C = less variance, less resistance).

If someone has a substantial disagreement with the contents of that page, they should discuss it either here or the talk page. Edit warring isn't helpful.

Well, there's an explanation of my score-based system which I hope is fairly clear. Going forward I'll write about it in the wiki too.

I have started a long overdue Mining pool reward FAQ. Enjoy.

You could say that gold is backed by its industrial uses. But AFAIK the value of gold is much higher than had it not been used as a currency, so indeed the lion share's of gold's value does not come from backing.

In principle, consumer prices, but currently exchange rate with USD is used as a proxy because everyone uses it as a guide for BTC prices.
Why wouldn't BTC be a mainstream currency?

Then enlighten me. What does it mean that "slush's pool penalizes for disconnecting mid-round"? Or maybe it doesn't mean anything and you're just spewing out meaningless FUD?

The slower miners will get their shares in the next round. "Sweet spot" is a myth.

Your earlier shares depreciate even if you stay connected. They don't depreciate because you disconnected. And your newer shares have the same expectation with either scoring method.

And this isn't semantics. If the question is "If I often disconnect from the pool, does this mean I'm better off with deepbit?" then the factual, objective answer is a resounding "no".

A bigger pool has less variance.
Hence, splitting the pool will increase variance, with no effect on expectation.

slush's pool doesn't penalize for disconnects mid-round.

This is getting a bit off-topic, and I know you like things to remain on-topic... But FWIW, I think this kind of threads is extremely important and shares the spot of "most important project development goal" with developing (and documenting) SCI modules for merchants. Though I think they might be a better fit for the wiki than the forums. Personally I've taken the habit of adding questions to the FAQ as I encounter unanswered questions, and referring to it. I really do appreciate the work you're doing in this regard, so I've just sent 1 BTC to your "New to Bitcoin" address. I know you'd much rather have smaller donations from multiple people, but I didn't want to feel like a hypocrite not putting my money where my mouth is.