The LLN per se doesn't really say anything meaningful about a finite number of blocks, but fortunately, the CLT does. Over a time period where the pool should find on average 1000 blocks, the distribution of number of blocks found is Poisson with mean 1000, which is to a very good approximation normal with mean 1000 and standard deviation 31.62. This means that with probability ~50%, the actual number of blocks will be between 979 and 1021. So for a PPLNS pool, the payout will be w.p. 50% between 97.9% to 102.1% of the average. For an SMPPS pool, the buffer will be w.p. 50% between -1050 to 1050 BTC, w.p. 25% above 1050 and w.p. 25% below -1050.

It doesn't drift to negative in either case. The only thing affecting long-term behavior is the expectation and variance of the change per round. The bad luck is theoretically unbounded but highly negative values have rapidly diminishing probabilities so they don't have much effect on the overall distribution.

If the expectation is 0, the overall trend is to fluctuate according to Brownian motion, with a rate depending on the variance of the change per round. This means that any level - whether highly positive or highly negative - will be reached eventually. However, here Gambler's ruin comes into play - as long as it's positive you continue playing, but when it's sufficiently negative you quit, so you will eventually reach the point of ruin.

ESMPPS is more complicated, but not very different from this regard, so I'll focus the discussion on SMPPS. The relevance of the difference does not diminish, because what determines the attractiveness of mining now (which is relevant for current miners considering quitting, and others considering joining) is the current difference, not the relative difference compared to the pool's lifetime earnings.

The mentioned "real-world experiences" are about as relevant as me tossing a coin and stating "real-world experience shows that coins land on tails". It's random. The statistical properties of the process are understood. Whatever you try to deduce from the experience has no bearing on what we expect from the process, it only means that your sample is too small. The expected magnitude of the difference does grow without bound as time passes, that's a fact. We can discuss the specifics of this growth if you'd like.


Actually, this has nothing to do with it. You'd have the same problems if both good and bad luck were bounded, or if bad luck was bounded and good luck was unbounded. Even a "reverse pool" which pays for found blocks and is paid for every share, will have the exact same long-term risk as a normal pool. The central limit theorem guarantees that whatever the payout distribution for a single round looks like (as long as its variance is finite), the process will over the long run be equivalent to Brownian motion.

You beat me to posting. This is a fallacious interpretation of the law of large numbers known as the gambler's fallacy. The ratio between the pool's lifetime rewards and lifetime expected rewards will tend to 1, but their difference (which is the buffer) will not tend to 0 and will grow unboundedly in average magnitude. This can be easily verified by simulation.

Oh, we can calculate that, don't worry. You'll find (for pure Brownian motion) that the probability to reach a buffer of -m*B, starting from 0, at any time over a period of n rounds, is roughly 1-(m/sqrt(n))*sqrt(2/Pi). As n goes to infinity this goes to 1, so with probability 1 the buffer will reach that level eventually. However, it is interesting to note that the expected time to reach any level is infinite. Brownian motion is crazy.

It's not too bad if it stays negative as long as it's mild - it just means the maturity time will be about 5 blocks. But what some people may be missing is that there's no magic force pulling the balance towards 0 - that would be the gambler's fallacy. From -200 BTC it's as likely to go to -100 BTC as to -300 BTC.

The fact that pools get shut down due to lack of sufficient interest by the operator is another illustration of the problem with buffer methods. SMPPS is being marketed as "you will get 100% payout eventually". But if someone mines when the buffer is highly negative, and the pool gets shut down while he's waiting to receive payments, he will lose a significant portion of what he deserves. And this brings us back to the collapse scenario once the buffer becomes so low people realize it's better to go elsewhere.

The only thing open to interpretation here is whether using a method which is by design doomed to collapse is wrong. I say it is, but people are welcome to disagree on this.

Arguing with you is futile, but I'll try. Obviously the paper is neither wrong nor biased.

You saying it doesn't make it true. Is there a factual error in what was written about MPPS?

They do, it increases their expected payout and reduces its variance. I wasn't talking about block withholding.

The drift is caused by external factors such as invalid blocks and withholding. In other methods these cause a decrease in profitability but not an expediting of a collapse.

Look up "randomness". Just because Eligius' buffer had a certain manifested trajectory is very little evidence of anything.

This kind of hopping does benefit the hopper and harm the non-hopper. Currently hoppers are busy with the proportional pools, they'll be happy to take advantage of SMPPS once those are gone. By your own admission the pool has only dipped in negative buffer area, so there was no observation of what happens when it is seriously negative.

I don't know what kano meant since Eligius uses SMPPS, just like arsbitcoin. If you want to know what's wrong with SMPPS you can have a look at section "Shared maximum pay-per-share (SMPPS)" (currently 4.2) of Analysis of Bitcoin Pooled Mining Reward Systems.

In other news, people who bought shares during Google's IPO don't deserve to profit from it, because they didn't participate in making Google's products.

If that was not a big enough hint: There are more ways to participate in an economy than to provide labor. People who buy bitcoins increase the total worth of all bitcoins, thus the incentive of merchants to accept Bitcoin, thus help grow the Bitcoin economy. If this growth results in the success of Bitcoin and a corresponding price appreciation, those who took a risk by investing in bitcoins have every right to profit from it.

In this post I will discuss what I call a "mixing transaction", which allows you to move bitcoins from one of your addresses A1 to another address of yours A2, without a clear trace linking the two addresses. This is similar to the ideas presented in this comment, and this one. Such transactions can act as a primitive to help improve anonymity, though how exactly to incorporate them in a complete anonymity solution is beyond the scope of this post.

Mixing transactions can be done completely p2p without a centralized service which risks fraud, leaking information, being shut down and so on.

Step 1: 2-party mixing transaction

User A who wants to perform a mixing transaction finds user B who also wants to make such a transaction (peer finding for this will probably be done on a dedicated p2p network). A wants to send X bitcoins from address A1 to A2, and B wants to send X bitcoins from B1 to B2. They exchange information about A1, A2, B1, B2 and construct a transaction with 2 inputs and 2 outputs. One input is X BTC from A1, the other is X BTC from B1 (we can assume A1 and B1 have a redeemable output with exactly X BTC, since such an output can be prepared in advance from a larger output); one output is X BTC to A2, the other is X BTC to B2. The inputs and outputs appear in random order. A and B sign the transaction with the private keys corresponding to A1 and B1, respectively, and broadcast the signed transaction to the network.

A will have X BTC deducted from A1 and X added to A2, as desired; likewise for B. Of course, no party can run away with the money because the funds are exchanged in a single atomic transaction. An outside observer cannot deduce from this transaction that A1 and A2 are related; they have equal chance to belong to the same person or to two unrelated people. If A routes his funds through 10 mixing transactions, the address where the funds end up is related as strongly to A's original address as to 1023 other addresses, each of which could belong to a different person. This indeed makes tracing difficult. Of course, this will require that a large number of people participate in this anonymization method.

The weakness of a 2-party transaction is that B knows certainly that A1 and A2 belong to the same person and could leak this information. This may not be devastating if enough mixing transactions are made, but we want a more robust system where privacy is maintained with as few transactions as possible.

Step 2: 3-party mixing transaction

User A finds peers B and C. A wants to send X BTC from A1 to A2, and so on. They exchange information about A1, B1 and C1; however, they do not openly share the addresses A2, B2 and C2. We want each participant to know all addresses A2, B2 and C2, but not know which belongs to whom. That is, A shouldn't know whether B2 belongs to B and C2 belongs to C or vice versa.

To achieve this, the following protocol can be used:
1. A creates two keypairs, (priv_B, pub_B) and (priv_C, pub_C), for a one-way, commutative encryption technique.
2. A sends pub_B to B and pub_C to C.
3. B encrypts B2 with pub_B to obtain E_B(B2), and sends E_B(B2) to C. C encrypts C2 with pub_C to obtain E_C(C2), and sends E_C(C2) to B.
4. B encrypts E_C(C2) with pub_B to obtain E_BC(C2). C encrypts E_B(B2) with pub_C to obtain E_BC(B2), and sends E_BC(B2) to B.
5. B sends E_BC(C2) and E_BC(B2) to A in a random order.
6. The cryptosystem is commutative, so A can't deduce which of E_BC(C2), E_BC(B2) was encrypted with pub_B first and then pub_C. But she can use priv_B and priv_C to decrypt both messages and obtain B2 and C2.
7. A sends A2, B2 and C2, in a random order, to B and C.

A only receives encrypted versions of B2 and C2 in a random order so can't deduce which belongs to whom. B knows that E_C(C2) is C's encrypted address, but he doesn't know pub_C so he cannot verify which of A2, C2 belongs to C.

Now that A, B and C know A2, B2 and C2, they can construct a transaction with 3 inputs and 3 outputs and sign it. For an outside observer, A2 is mixed with 3 addresses A1, B1 and C1. Even if B is compromised, all that is revealed is that A2 corresponds to either A1 or C1 (branching factor 2), rather than that it definitely corresponds to A1.

However, if B and C collude or are both compromised, the relation between A2 and A1 does leak. This seems unlikely, but it still means we may be interested in transactions with more mixing power.

Step 3: n-party mixing transaction

For an n-party mixing transaction, n peers need to exchange destination address information without any other knowledge given about which address belongs to whom. I don't know of an efficient cryptographic protocol to achieve this, though it can be done with generic secure multi-party computation. Alternatively, an external anonymization network could be used for each user to broadcast his address without revealing the source.

For an n-party transaction where each user has an input of X BTC and an output of X BTC, compromising m participants only means that each of the n-m uncompromised destination addresses is known to be associated with one of the n-m uncompromised source addresses (branching factor n-m).

Having a mixing transaction with many parties also allows to be more flexible with the input/output amounts. The inputs could be chosen to be any value among some standard values (e.g. powers of 2), and each user can have several inputs with 1 output. Since there are multiple inputs of each size, it should be impossible to deduce the relations between inputs and outputs. If the input amounts are generic, it will be possible, information-theoretically, to match inputs to outputs by finding which inputs sum to a given output amount; however, depending on the specifics, it might be intractable computationally (this is related to the subset sum problem).

One weakness with large mixing transactions is availability. Since all parties need to collaborate to complete the transaction, unavailability of either one of them will create extra work for reorganizing the transaction. This is especially true if one of the supposedly interested parties is in fact a DoS attacker planning to quit and blow up the deal. If he makes sure to be part of every large mixing transaction, he can make it hard to have any such transaction go through.

Ars isn't PPS, it's SMPPS. Don't dilute the term PPS by conflating it with other methods.

Do you seriously think they're not completely aware how many customers they would get if they could pull it off? PayPal has already frozen an account used by mtgox once, and mndrix's, and any other Bitcoin-PayPal exchange service.

It's interesting that they let Inaba off the hook, probably because he's not doing currency exchange but only paying for doing computational work.


If the pool's hashrate is low, and the reward method does not reduce pool-based variance, then miners will have high variance. If the pool uses PPS then the pool's hashrate is irrelevant for miners.

ABCpool sets the donation to 4% by default. I'm not sure how other pools do it but it seems a bit underhanded. Pools need fees, to compensate for work, hosting and (especially in PPS) risk, and pools get shut down every Monday and Thursday because their revenues do not justify these costs. We understand that. But please, be forthcoming about this, figure out what fees you need and openly publish them, don't play games.

Great! Sure, we'll have one in March, too.

This isn't a problem with generating a public key from adding two other public keys, but rather with some specific applications. I for one thought we were talking about making casascius coins - if they're not manufactured according to spec all bets are off, which is why they need to be sampled anyway, which would detect attacks like the one described.

(I don't disagree with your main point though.)

For me they always take about 3.3% currency conversion fee.

This is on the list of Bitcoin's advantages.

Maybe you should explain more clearly in the tooltip what the cashout feature is, especially that it is a special feature not used ordinarily.

Note that in most places in the site the more appropriate term is "Bitcoin", the system, rather than "bitcoins", the unit.

A sad day indeed. This pool seemed poised to become the new star. I completely sympathize with your situation though, I only wish more people would realize running a pool properly is serious business.

No need to give up hope, I know of at least 2 pools which are considering switching. PPLNS is also fine, as is PPS if the fees are kept reasonable. There's a promising new pool in the PPS scene, though it seems it wasn't announced here so I'm not sure I'm at liberty to mention it.

You are doing it wrong (I mean, this can work too, but there's a proper way to do it). From each miner's score you can calculate his expected pending payout. If the pool closes you need to pay this amount to everyone (like cashout, but with no fee since it is you who initiated the shutdown). By so doing you are paying back the stochastic loan you took from miners when you started the pool. The pool was a model for DGM in life, let it be one also in death.

Yes, that is correct. Tony, is there a reason you're using "Bitcoins" everywhere instead of "Bitcoin"?

I don't think that's the proposal. I thought the point with casascius coins is that you can pay with them, with the active ingredient being that the private key is hidden but with Mike's seal that it is valid. If redeeming a coin requires the private key of the customer who originally ordered the coin, he can't pay with it to another party.

My interpretation of the proposal is: Mike generates a key m and has a business partner who generates a key b. The partner creates a "mini-coin" with b hidden and B exposed, so that b can only be found if the minicoin is evidently opened. Mike embeds the minicoin in his own coin with m hidden and M+B exposed. To redeem the coin it needs to be opened completely to expose m and b and thus m+b. This way, the bitcoins can only be stolen if either:

1. Mike and the partner collude, which is assumed to be unlikely, or
2. Mike opens minicoins before embedding them and scrapes b, which can be detected by sampling Mike's coins and verifying that the minicoin is intact.

Note that sampling needs to be done anyway to verify that coins indeed contain the promised private key. Mike will also need to sample the minicoins of his partner before he commits to embedding them in a coin sealed by himself.

This can be extended to multiple partners each submitting their own minicoin, all of them being embedded in a single coin by Mike.

Is there anything I can do to change this?

I put two blank lines to clarify that the hopping comment has nothing to do with the PPS fee comment.

The hopping comment was addressing all the people who were talking as if there is nothing wrong with proportional and looking for a small proportional pool.

It seems trivial to prove that if ECDSA is secure then so is the addition scheme (though of course this has to be vetted by someone who is actually experienced with these things): Suppose that given A and (A+B)*G we can deduce A+B. Now let's say we have some arbitrary public key C*G. Generate a random A. C = A + (C-A) so by assumption we can find C.

There is an established scheme for an application which is not identical to this. There's no reason we shouldn't make use of known primitives to create new applications. Again, I agree that the uninitiated could miss something even when the recombination seems trivial - so we should ask someone about it, but not wait for someone to write a paper about such trivialities.

This is in the works (assuming you meant "compute the combined signature").