OUCH! I was just about to make a similar offer, except it isn't worth it for me to cover the fees so I wouldn't be able to compete with you. I guess I'll have to find another solution.

Low-fee transactions will be much more numerous than high-fee, and I wouldn't be surprised if their total fee will be higher.

Suppose there's a pool that includes all transactions. It will be much more profitable per hash than pools that play hard-ball, and thus will enjoy lots of participants.

You're misusing "irrational". Accepting low-fee transactions is very rational for the one who accepts them, because the profits are all his own, while the free rider problem is everyone's. This is assuming the agent is selfish. The problem is that if everyone acts selfishly everyone will suffer, which is the studied-to-death "prisoner's dilemma" or "tragedy of the commons".

You may ask how to stop players from acting selfishly. If there are few players they can collude to fix prices, and they might even do it without any spoken agreement out of fear of a snowball effect. But this doesn't work when there are thousands of players and the barrier of entry is low. Someone who doesn't currently mine can rent some hardware, swipe all the low fees and exit. With these dynamics, the only transactions that will be excluded are those whose fees are less than the cost of inclusion. If a block size limit is placed, the cost of a transaction is the opportunity cost of not including a higher-fee transaction.

Some sort of regulation is another way to ensure non-selfish play, but I doubt that's the direction we want.

Sorry, I should have clarified that the formula (1-f)*B*S*(r-1)/r^I (which is basically using the summation formula for geometric progressions to evaluate the total score) is valid only for the vanilla method as in the original post. Any changes (adjusting for difficulty changes, rescaling to prevent overflow) require rewriting the formula, and to avoid this complication it's best to not use a formula and just go over the scores of operator and all participants and sum them manually. Then split the (1-f)*B reward between everyone in proportion to their score divided by the total score.

Don't forget that rescaling should be done for the operator's score as well.

I could explain more about logarithmic scale, but if it's not intuitive to you it's best to use periodic rescaling instead. Maybe we'll revisit it when there's a real need (say, the rescaling becomes too resource-demanding).

Yes, there are at least two ways:
1. Periodical rescaling - once in a while (say, 100000 shares) go over all participants and divide their score by s, and reset s to 1. If you are able to do this after every share, you'll also get a more visually pleasant representation of the score. I assume that underflow simply results in 0.
2. Working on a logarithmic scale: Instead of keeping s and the score of each participant, keep their logs. Of course you'll need to adapt all calculations to the new scale, in particular you should use a robust method for addition:

By the way, since it is only capability to work with large numbers that you need and not precision, you can safely use double (or single) precision with these modifications.

I think the market for hosting for BTC is saturated, there are quite a few such services. It is to be expected that your BTC customer volume will be low now, it's a chicken and egg problem (people will join Bitcoin slowly if they're not accepted, shops won't accept them if few people use it). I hope your overhead for accepting Bitcoin is low enough that you can wait patiently until the egg hatches.

I agree with you, I'm not convinced by mike's model and I believe it will ultimately boil down to a community decision about the block size limit with an obvious trade-off:
Tight limit = high transaction fees, high network security
Relaxed limit = low transaction fees, low network security

I don't think you should worry too much. I think there are quite a few people here with the training required to model the dynamics, and big changes like this should only be made with community acceptance. You can stir dialogue about this, as you have in this post, to make sure we are ready ahead of time. There's still plenty of time, though. As mike says, the drop to 25BTC/block will be an important observational study.

Going forward this will be important. Right now I think the explanation part of Bitcoin is so bad that drawing more attention from the general public (who'll generally have a harder time crossing the pons asinorum) might actually be harmful. Let's put some more work in the wiki and in some videos first.

This should be possible, and in the limit it allows the cheater to almost double his earnings. I don't know if it was discussed before, I'll call it the "lie in wait" cheating method.

A possible countermeasure, which I don't know if is now implemented, is to keep track of the times of getwork requests, and ignore shares which were requested later than the winning share (or in the same getwork with a higher nonce).

No. The hashing function used is such that any change in the details of the block will alter the hash in ways we can't imagine, making it for all practical purposes uniformly random. Mining consists in randomly tweaking details of the block until we find a tweak that makes the hash less than some number, which happens once in 2^32*difficulty tries (shares submitted to a pool have difficulty=1). If you find a nonce which satisfies the difficulty-1 requirement and then try to change one of the details, the new hash will once again have one in 2^32 chance of being a valid share, so it's no better than just trying an arbitrary nonce as usual.

Such an attack is possible and has been discussed before, but it has nothing to do with it. The CDF still can't reach 100%.

Right. Changing the receiving address changes the Merkle root of the block, thus changes the block hash, thus it will no longer meet difficulty requirement.

No, the private key is unrelated to this. Even the operator can't change the receiving address after a winning share is found.

Common myth. Bitcoins aren't backed by CPU time, they are backed by merchants willing to trade goods and services for them.

The short answer is that the computations are used to secure the Bitcoin network from attack.

Another myth is that Bitcoin is about getting bitcoins by mining. Mining is a niche activity. You are supposed to use bitcoins as a medium of exchange just like any other currency.

Parabon, but they only work with institutions.

That's great, but it looks like they don't have a PageRank and this is thus ineligible for a bounty.

Sorry for the late reply, I didn't notice your post. Here is the exact procedure which also deals with difficulty changes:

1. At the beginning of the round, calculate p = 1/difficulty and r = 1-p+p/c.
2. Assign the operator a score of 1/(r-1).
3. Initialize s=1, this will keep track of the score given for the next share.
4. When a user submits a share: Add s to his score, and let s=s*r.
5. If the difficulty changes to a new value so that 1/difficulty is now p2: Let s=s*p2/p and r=1-p2+p2/c (which is the same formula for r, now with the new p). Continue with step 4 for each submitted share henceforth.
6. When round ends, sum up all scores and divide the reward proportionally (this sum can be evaluated quickly using the formula for a geometric progression, keeping in mind that each difficulty change creates a new progression, but it's simpler to do a brute-force sum).

This way, whenever a participant submits a share, he always sees behind him a score of 1/(r-1) times this share's score, with r based on the current difficulty.

Edit: Fixed an error in the formula. Again.

Not as good as a method which was analyzed and proven to be secure (I did not post the proof yet due to insufficient interest). Also, someone who wants to cheat for profit will be motivated to analyze it anyway.

If the round lasts a long time after the cheater left and the shares lost all their value, he'll gain nothing either way.
But if the round ends shortly after or before cheater decides to hop, then his profit will be much higher if the round is fresh, because there will be less people with shares to split the reward with.
Let's say shares are devalued completely after 30 minutes. Then it doesn't matter if the age of the round is 30 minutes, or 60, or 100 or more, because in all those cases there are 30 minutes worth of shares. But if the age is 0 minutes, or 10 or 20, or anything less than 30, there will be less than 30 minutes worth of outstanding shares, thus profit will be greater.
Taking this into account, expected payout will be greater when participating early. Expectation = long term average value.
My method takes care of this by always having "30 minutes worth of shares", so to speak, where the operator has them if they do not yet belong to participants.
Of course I'm just handwaving here, but this can be rigorously analyzed.
The correct question to ask is always, "If I submit a share now, what is my expected payout from it?".

Probably after 30 minutes or so.
Another problem with time-exponential is that it is much harder to analyze than score-exponential. It can be analyzed if we assume the pool's hash rate is constant.
If we make this assumption, and we know the pool's hashrate and slush's decay factor, I'll be able to calculate when is the best time to hop and what can be gained by it. But I don't think calculating the exact numbers is as important as simply knowing that hopping is profitable.
Also, for time-exponential, the decay factor should be proportional to the pool's hashrate. I did not see you or slush mentioning you do that, and if you don't, the decay will become weaker when your hashrate increases.
Time-exponential is also vulnerable to attacks based on fluctuations in the hashrate.

Good luck with those projects. I hope managing CoinPal/CoinCard will include improvements to their automation, robustness, prices and limits.

Have you considered making an automated service for selling MoneyPak for bitcoins? These can't be chargebacked, right? If it's possible, it should really help with maintaining cash for CoinCard while obviating your need to buy MoneyPak on the forum.

I'm confused about the "Order ID" part of linking PGP. Does it need to be the order ID of any one of my orders, the first one, all of them?

You do now.

I do not enjoy repeating myself.
slush's method does not guarantee that cheaters do not get additional profit. By participating only very early in the round, they can increase their profit and of course the profit of honest miners will decrease. The problem is of course not as severe as in proportional but still.
This increase/decrease is in expectation, and thus will maintain itself over long periods of time.
slush's method also needs to rescale at difficulty jumps (which is so simple I can't believe we're arguing this) but this is ignored because it doesn't have any guarantees to begin with.
Rescaling is just a part of the very careful design of my method, just like the value of the score fee was specifically chosen to make the payout distribution time-invariant.
My method is also exponential, so a better way to refer to slush's method might be "fixed-fee time-exponential score method". The main differences of my method is that the exponential depends on shares rather than time, and that a score fee is introduced to make it 100% cheat-proof.
The "special attention" I talked about was in the design, not in the operation. Of course I paid attention to every detail to make it work flawlessly. The pool operator just needs to plug in the formulae, fire and forget.

Each share has score r^I, where I is the number of shares already submitted, and the operator has score 1/(r-1).

Not that I'm aware of. slush said he would examine it when he has time.

slush's method is not immune to pool-hopping, and if cheaters exist it will have a toll even long-term.

Why?

I stated very clearly that it does not have a problem with difficulty change. This only requires a rescaling of the scores which is very simple (just multiply all current scores by p2/p1).

But there's a more fundamental problem with your statement. My method comes with a guarantee of 100% fairness, so maintaining this guarantee under all contingencies may require special attention. slush's method doesn't come with any guarantee so it's easy to ignore such contingencies. In particular, slush's method also stands to gain by rescaling at difficulty jumps, which he doesn't currently do.

I stated very clearly that the expected payout is always the same, and there is never incentive for either shorter rounds or longer rounds.