In the status bar of the Bitcoin application, you can see the number of blocks you have. It should be at least 142949, otherwise you need to wait until the block chain is downloaded.

If this doesn't help, run Bitcoin with the -rescan command line switch.

Double-spending means:
1. Buyer (attacker) sends money to seller.
2. Seller gives goods to buyer.
3. Buyer creates a new branch in which the coins are sent back to himself.

The proof-of-stake is only relevant for people willing to wait for it. If stakeholders have several candidate branches, each should choose one randomly or according to some rule. One of the branches will come out ahead as the most signed. For every transaction that was agreed upon, there are two possibilities - either it is included in the signed branch, in which case it is secure forever and the seller can send the goods; or it was replaced by another transaction, in which case the seller doesn't send the goods. So, if you wait for proof-of-stake, you'll never have a payment reversed after you've sent the goods.

If I understand your suggestion correctly, it requires that 10% of the coins are owned by the miners. This means that miners possess 10% of the wealth of the world (at least, the part of it that is in the form of bitcoins). This means mining is a huge enterprise, instead of a lean service provider. What if I told you that for the internet to work, 10% of the global wealth needs to be at the hands of ISPs?

PPLNS, or "Pay per last N shares", is a reward system that has been known for a while, but I don't think there's a definitive thread discussing it, including how to implement it in a way that is hopping-proof even considering difficulty changes.

The basic method is this: Whenever a block is found, payment is given to shares in a window, starting with the last share submitted and going backwards up to some number N of shares. Shares older than the window are not paid. This is essentially a 0-1 cutoff decay function. There is no concept of rounds - shares can be paid even if they were found before the previous block. This means that a given share can be paid more than once - however, the payouts are chosen so that the expected reward is equal to solo expected reward. Because the payment for a share depends only on blocks found in the future and not on shares and blocks found in the past, there is no way to hop based on the current status of the pool. However, if implemented incorrectly, it is possible to hop based on imminent difficulty changes.

The most naive implementation is to have a fixed N and simply pay the last N shares equally. However, this makes it more profitable to mine before difficulty decreases, and less profitable before difficulty increases - the number of blocks that are expected to be found in your window depends on the future difficulty, while the payout you can receive elsewhere depends on the current difficulty.

It doesn't help if N is chosen to be a given multiple of the difficulty at the time a block is found. If the difficulty is about to increase, it is more profitable to mine a short while before. For example, if N is set equal to the difficulty D, a share submitted D shares before the increase will be paid the full expectation in the D-window, and then when difficulty increased it will once again go inside the window and have more expected reward. And, like the previous case, shares submitted just before the difficulty change will be rewarded similarly to shares submitted after it.

Another incorrect implementation is to pay all shares in a window given in units of time (sometimes called PPLNM or PPLNH). In addition to the problems above, it has a problem common to all reward systems that use time as a factor, which is that it is more profitable to mine when the current hashrate is higher than the average.

The correct method is as follows.
1. Choose a parameter X, which represents multiples of D to include in the window when difficulty is static. X=2 is a good choice.
2. When a share is submitted, assign to it a score of 1/D, where D is the difficulty at the time the share is submitted.
3. When a block is found, pay (sB)/X for the last share (the one before the winning share), where s is the share's score and B is the block reward. Continue backwards, paying each share based on its score, until you reach a share which brings the total score of the shares counted above X. Pay that share the amount (sB)/(tX) * min (r,t), where r is the score required to bring the total to exactly X and t is the score of the winning share. Don't pay any older shares.
4. If the pool has just started, and a block is found before there are shares totaling a score of X, there will be leftover rewards and it should be decided what to do with them. It doesn't matter much, but I recommend that the operator keeps them (in a macroscopic view, if the pool ever changes, this is compensation for the funds needed to cash participants out). Other options include donating to charity, or distributing among the miners.

The expected payout for a share with score s, so that the total score of it and all younger shares is Y, is sB * Max (0, 1-Y/X). It follows that the expected payout per share when it is submitted is always B/D.

The variance in the payout per share is (pB)^2/X. The average number of shares it takes to receive payment, in multiples of the difficulty, is X/2. Thus X can be chosen to have the desired tradeoff between variance and maturity time, with the invariant being that their product is (1/2)*(pB)^2. Note that for a miner who constitutes a significant portion of the pool, the shares are correlated - if the portion is q, the total steady-state variance can't be lower than q times solo variance.

If the parameter X ever needs to be changed (for example, to harness increases in the pool's size to decrease variance without changing maturity in units of time), the scores of all recent shares should be changed so that their new expected remaining payout will be equal to the old one, starting from the youngest share and moving backwards. If X is increased, scores should be decreased. This creates a situation similar to the start of the pool where there could be leftover rewards. If X is decreased, scores should be increased. For some of the older shares, it will be impossible to increase the score to maintain the expected value. In this case they should be "cashed out", with the operator paying from his own funds their expected reward.

A variant of this is, instead of using a 0-1 cutoff, use an exponential decay function. This is equivalent to the double geometric method with o=1. If shares decay by a factor of e every (XD/2) shares, the variance is (pB)^2/X and the maturity time is X/2, just like with 0-1. The advantage is that the due payment of a miner can be encoded with a single number, his score - there's no need to keep or handle a history of shares. The disadvantages are that it takes longer to receive the reward in full, and that the implementation requires either a logarithmic scale or periodic rescaling.

Another variant is to use a linear decay function. This achieves a better variance-maturity tradeoff invariant, (4/9)*(pB)^2. However, it is probably harder to implement and understand.

A substantially different variant is to pay for every share at most once. If, when going backwards in the list of shares, we encounter some that were already paid, we skip them and move on to older shares. X needs to be less than 1 to make sure that eventually we will have enough unpaid shares to draw on. I'm not sure what's the correct way to handle difficulty changes with this variant.

Edit: Fixed an error in the description of the block payment.

By this, do you mean simply the variance of the reward? In this case you need parameters that are realistic with respect to the risk operators are willing to take, but for an operator who is already seriously considering offering PPS, I think these parameters are entirely viable (perhaps with a slightly higher f if he wants to gain on average).

The existence of hoppers changes the % of time the pool spends in young rounds - hoppers make the pool grow old faster. This does decrease the total benefit that can be achieved. However, if a hopper does find a pool with a young round, this does not change the amplification factor for shares he submits. The payout per share will be B/N, where N is the total number of shares which will be found in this round, which is distributed geometrically conditioned on I shares having already been found. Time plays no role with this part.

In the limit where everyone hops, all proportional pools will be stuck at 43.5%, and thus no more hopping can be done.

It doesn't work this way. If you condition on the total number of shares in the round of course you'll find there's no benefit. You need to condition on the number of shares already found.

If you say they hop at 50% of the total shares in the round (and it doesn't matter if it's 50% or some other number, if they know it or not, or whatever), you're leaving open the possibility that they will mine until 1.5D shares were found in a round whose total is 3D, which is something they will not do, since they leave at 0.435D.

The longer the round is, the less % of the total shares the hopper will have in this round. It is in this way that the hopper biases his share distribution towards shorter rounds, thus getting more reward per share.

If everyone hops, the result is known - all proportional pool will end as no one will mine past 43.5%. The situation I analyze is the situation in practice, that hoppers are a minority. The hopper's rewards don't decay over time as the pool's reward system has no consideration of time. The amplification factor as a function of round age doesn't change. What does change is how young the rounds are expected to be. If the hopper does find a pool with a young round he should choose it over fallback mining (in all cases it is assumed that the hopper has a solo / fair pool option available for which he mines if there are no milkable proportional pools).

Use f = -1, c = 0.5, o = 0.5. With these parameters this method is the most different from other methods, so if there are any problems they should show up there. Also, with this the average fee is 0, so efficiency will be exactly 1.

Remember that to simulate/implement this, you need to use either logarithmic scale, or periodic rescaling (once in a while (which could be every share if you're only keeping track of a few workers), divide all scores by s and set s to 1).

This is because the calculation is relative to the fair reward, which itself is tied to time with the miner's hashrate.

It is assumed that are enough continuous miners so that a block is eventually found.

That's a pretty strong presumption. Everything about pool-hopping relies on the random nature of block finding, ignoring this results in nonsense.


You may want to have a look at the paper I'm working on which I believe, if I may say so myself, does a better job discussing pool-hopping than Raulo's paper.

This is of course all off-topic for this thread, which is about ethics.

It doesn't. For now I recommend (for all reward systems) that the operator keeps transaction fees, and take this into account in his business plan when he decides what pool fees to take. I'll investigate this more thoroughly as it becomes a bigger problem.

EDIT: As discussed below, this turns out not to be a serious problem. Though variability in block rewards does increase operator risk.

You should look not at the time until all the reward is obtained, but rather at the average time it is received. So if your reward is 2 BTC, and you receive 1 BTC a million shares from now and 1 BTC two million shares from now, I count it as a maturity time of 1.5M shares. If you consider time to be fully repaid important for reasons of making a clean break from the pool, I have a different suggestion to address this which I will post about later.

When o=1, you can choose r to have whatever tradeoff you want between maturity time and variance. It turns out you get the same tradeoff as with 0-1 cutoff. A good choice is r=1+p, resulting in decay by a factor of e every D (difficulty) shares, with maturity time of 1 (expressed in multiples of D) and variance of (pB)^2/2. This is the same as with PPLNS when N = 2D. Then you can decrease o (and change r accordingly), keeping maturity time constant while decreasing variance of participants (at the cost of increased operator variance).

The decay rate, and the accuracy of the estimates (which is basically the inverse variance), are tunable, and as discussed above, start as good as PPLNS and can then be improved.

The operator can only lose if f is negative, and in this case, can lose up to (-f)B per block found. Compare with PPS, which is equivalent to f -> -Inf and the operator's loss per round is unbounded.

I'll think about it.

Then it's more profitable to mine at the beginning of an interval.
Actually it will create interesting dynamics depending on the number of hoppers. But it's still more profitable to mine early in the round.

It's more profitable to mine in the beginning of the 3-round batch, or after 1 or 2 blocks were found if there are relatively few shares.


Anyway, this is off-topic, hopping-proof methods have been known for months, no need to reinvent the square wheel. This post is about a breakthrough in low-variance reward systems.

I haven't made much progress with this lately, partly because I was too busy inventing a new reward system. But I hope to be able to resume work soon.

This is a new reward system for mining pools, a hybrid between PPLNS and the geometric method which combines advantages of both. It starts with PPLNS-like low share-based variance without operator risk, and then allows the operator to absorb some variance to decrease pool-based variance (which the geometric method can do, but not PPLNS). It is of course hopping-proof - the expected payout per share is always the same no matter when it was submitted. The variance and the maturity time (the time it takes to receive the reward) are independent of the pool's history and almost completely independent of future difficulty changes.

The method is purely score-based, which means that all the information required to calculate payouts can be encoded with a single score value per participant. There is no fundamental need to keep a history of shares. However, because the scores grow exponentially, it is advised to use a logarithmic scale to store their values and do the calculations.

We will denote by B the block reward (assumed constant) and p = 1/Difficulty. In addition there are 3 parameters which can be adjusted to balance average fee, operator variance, share- and pool-based participant variance, and maturity time:
f - Fixed fee.
c - Average variable fee. The average total fee will be (c+f-cf)B per block. Increasing c reduces participants' variance but increases operator's variance.
o - Cross-round leakage. Increasing o reduces participants' share-based variance but increases maturity time. When o=0 this becomes the geometric method. When o->1 this becomes a variant of PPLNS, with exponential decay instead of 0-1 cutoff (note that "exponential" does not mean "rapid", the decay can be chosen to be slow). For o=1, c must be 0 and r (defined below) can be chosen freely instead of being given by a formula.

The method is as follows:
1. When the pool first starts running, initialize s=1. Initialize the scores of all workers to 0.
2. Set r = 1 + p(1-c)(1-o)/c. If at any point the difficulty changes, p and then r should be recalculated.
3. When a share is found, increase by p*s*B the score of the participant who found it. Set s=s*r.
4. If the share found happens to be a valid block, then after doing #3, also do the following for each participant: Letting S be his score, give him a payout of (S(r-1)(1-f))/(ps). Set S=S*o. The remaining reward is given to the operator. Or, if the total is higher than the block reward (only possible if f<0), the operator pays the difference out of his own funds.

The inutition is this: Instead of keeping the score unchanged when a block is found (as in PPLNS) or setting all scores to 0 and effectively transferring them to the operator (as in the geometric method), a part of the score is transferred to the operator. When rounds are long, participants get to keep most of their score between rounds and this is similar to PPLNS. However, if several blocks are found in rapid succession, the operator will collect a large portion of the score and thus be the primary beneficiary of the good fortune. The fees collected this way allow letting f be negative, sweetening the rewards of long rounds. Overall, this decreases the dependence of participants' rewards on the pool's luck, thus reducing the variance caused by it.

The variance of the payout for a single submitted share is

(1-c)^4(1-o)(1-p)p^2(1-f)^2B^2
------------------------------
   (2-c+co)c+(1-c)^2(1-o)p

Notably, the factor of (1-o) allows this to be much smaller than the variance of the geometric method, if o is chosen close to 1. This value is of relevance, though, only to small miners, and the potential advantage of this system is for large miners (which suffer from pool-based variance but not so much from share-based variance). It would be of interest to evaluate the total variance for a participant constituting a given portion of the pool, and the variance of the operator. So far I was unable to derive symbolic expressions for these, but they can be evaluated in simulation. For c = 0.5, o = 1-c = 0.5, f = (-c)/(1-c) = -1 I got that a miner constituting the entirety of the pool has about 30% of solo variance (instead of 100% as in PPLNS), and the operator's variance is about 25% of PPS variance.

The geometric method was so called because shares decay in a geometric sequence, and its analysis crucially depends on summation of geometric series and the fact that round length follows the geometric distribution. Because in this new method shares decay geometrically along two directions, both for every share found and for every block found, I call it the double geometric method.

The variables used in the calculations grow rapidly, so if the method is implemented naively, they will overflow the data types used. Thus the implementation should use one of the following:

a. Periodic rescaling: The only thing that matters is the values of the scores relative to the variable s. Thus, if the values grow to large, all that is needed is to rescale them. This means dividing the scores of all participants by s, and then setting s=1. This should be done once in a while, the exact times do not matter (it can even be done for every share).

b. Logarithmic scale: Instead of maintaining the variables themselves, their logarithms are stored and updated. The following is the method expressed in logarithmic scale, denoting by log the natural logarithm function and by exp the natural exponentiation function:
1. When the pool first starts running, initialize ls=0. For every worker define a variable lS and initialize it to negative infinity (or a negative number of very large magnitude, say -1000000), and do this also for every worker which later joins.
2. Set r = 1 + p(1-c)(1-o)/c, lr = log(r). If at any point the difficulty changes, p, r and lr should be recalculated.
3. When a share is found, let lS = ls + log(exp(lS-ls) + pB) for the participant who found it. Set ls = ls + lr.
4. If the share found happens to be a valid block, then after doing #3, also do the following for each participant: Give him a payout of (exp(lS-ls)*(r-1)*(1-f))/p. Set lS = lS + log(o).

For display purposes, the quantity that should be shown as the score of a worker is S/s (or exp(lS-ls) in logarithmic scale). This represents the expected payout the worker should receive in addition to any confirmed rewards (before fees). To display the expected payout after deducting fees, use (1-f)*(1-c)*S/s, or (1-f)*(1-c)*exp(lS-ls).

Not really that surprising. The expected gain per share decreases with the age of the round. If you stick through the whole round (and there are no other hoppers) the efficiency will be 1. So if you leave early, even if this "early" is pretty late, you'll always get more than 1.

That's not really a good example because if the pool is larger, the probability to win is also larger, so the expectation is the same.

Blocks like this are one in 130. Not really that rare if you think about it.

We had an Eternal Block From Hell on Continuum once. And it was a 10 GH/s pool. It wasn't pretty.

If memory serves, Pattaya is first (April maybe?). Bruce said details will be posted on bitcoinconference.com.

The variance can be calculated, but it depends on so many factors (and even with very simplified assumptions, the resulting expressions are messy) that for this purpose, you're probably better off with empirical observations like organofcorti's.

Raulo's paper only does 1 prop + backup. My paper (work in progress) deals with multiple pools.

That was probably http://www.bitcoindeals.com/ .

I might have to reword this sentence in a way which is less dramatic but also less ambiguous.

What I meant is that, if a future event is random and independent of the past, you can't predict it better than the prior probability.

But if the event is not independent of the past, you certainly can improve upon the prior.

"Number of shares remaining until round end" is independent on the past. "Eventual total number of shares at the end of current round" is certainly dependent on the past. At round start, "probability that the round will have >3D shares" is 5%. If 2D shares have already been found, this probability is 37%. If 2.9D have been found it's 90%, and if 3D or more have been found it's 100%.

And, pertinently, the eventual total number of shares at the end of current round (denoted N) is what matters, since your payout for every share you submit is B/N. If E[B/N] is less than what you could get per share elsewhere (which is B/D), you should mine elsewhere.

And I'll repeat the simple example - if 2D shares have already been found, then necessarily N>2D so E[B/N] < B/(2D), so you want to mine elsewhere.

So, if I say something which is true, and which was already said before many times, and I'm properly citing an influential paper about it, redoing the calculations myself and adding calculations and results which were never published before, then I'm "copying"?

You'll have 5% of the shares. You'll have more than 5% of the reward because you will have more shares in short rounds than in long rounds.

I think the only way is to convince Theymos to switch to a forum software which has this feature. I'll support a switch for the same feature.

Mining exists for a reason, you know. By increasing your hashrate you are making the Bitcoin network more secure, and rewarded for it.