They should lie down before they hurt themselves. Designing reward systems requires a clue, which they have none. Not to mention their arrogant, obnoxious attitude when discussing these matters.

Are you talking mid-round or between rounds? Between rounds, that's what I tried to suggest here. The real quantity controlling the tradeoff between variance and hoppability is c*hashrate, so to maintain the same tradeoff c should be chosen inversely to the hashrate. I was told that in BTCMine, "of course decay adjusted to lover[sic] value, when pool hashrate grow.", but they didn't specify if this was done automatically.

If c is dynamically changed during the round, this reduces to just doing the right thing and basing decay on number of shares rather than amount of time.

How do they define "participate"? Assuming that, as written here, they take the time between first and last shares, this is completely idiotic. You can stay all the way to 43%, and just submit a share once in a while to maintain >50% span. If you've mined for an hour, you need to submit a single share one hour later, then 2 hours, then 4, until the round ends. (You always submit a share a few minutes before twice the time of your last share).

There's nothing to worry about. It's safe to mine in MMC. But I do not have complete knowledge of MMC's implementation so the people involved in it should discuss the specifics if they so wish.

Exactly. Basically when c=0 each share is infinitely more valuable than the last, so only the winning share is rewarded, which is essentially solo.

I hope this ugly, unfair patching won't become popular. I might write about it at some point. How do they determine who is a hopper?

Most of the analysis assumes constant block reward, but the method doesn't require it. When you calculate the score for a share, you use the block reward in this share (viewed as a potential block). This guarantees fair expected return, but adds some variance to the operator.

It needs to be the potential income when the share was submitted, not the received income when a block is found.

I don't know much about the technicalities of this, but from an algorithmic standpoint, having shares go slightly out of sync only causes a negligible error in the payouts.

Of course. But as I've said elsewhere, I find hopping permissible since it could expedite the destruction of proportional pools, and the same applies here.

PPLNS, if implemented correctly, is hopping-proof, you can't gain anything from hopping it.
SMPPS is not hopping-proof but you can only decrease your variance by using it to hop, not increase your expectation. But I agree, I expect that when proportional dies, SMPPS will be the new proportional.
You may try lie-in-wait until oblivious shares are implemented.

To "hopping-prevention techniques", probably. To hopping-proof reward systems, no.

Well, the tl;dr version is "For every share you submit, you will get on average exactly your fair reward, with lower variance than other methods."

Secret sharing might be relevant.

Sure, but get ready for disappointment. It is a hybrid between PPLNS and the geometric method, and I recommended to Inaba to set it to be close to PPLNS, to reduce the variance. I still don't get the problem with PPLNS. But this is exponential PPLNS rather than 0-1 PPLNS, so your objections may not apply.

Well. If there's a need, I can design a method that really does encourage people to stay. But, not being a magician, I cannot design a method that encourages people to stay and gives people a reason to start mining in the first place. And, I think any method which is not 100% hopping-proof (expected payout etc. per share always the same) is ignoble, and that the problem you describe is negligible.

I don't follow this logic at all. You are paid once per share in PPS. In PPLNS, you can be paid for every share 0,1,2 or any number of times.

They could have started mining in the giant, low-variance pool in the first place. If they started mining for you and then leave, you can't force them to stay.

You may be interested to know that unlike PPLNS but like the geometric method, double geometric can reduce pool-based variance (the variance caused by the pool being too small). This is at the cost of increased operator risk, though, and I don't know how risk-loving Inaba is.

I don't see that realistically happening.

This falls under the scope of "something happens to the pool". Doesn't have to be a bad thing! I recommend he uses a hopping-proof method.

Actually, I was thinking about hopping without using the pool's published stats at all. When a block is found on the network which is not by any of the transparent pools, assign a certain probability to it in being from each of the delaying pools based on their hashrate. Calculate expected efficiency for such pools based on these probabilities. When efficiency is higher than other pools mine there (this will usually be when several hidden blocks are found in a relatively short time).

And that's without using technical methods to figure out block origin, of which I know very little (something to do with network traffic, long polling, etc.)

Probably because handing out CC data is horrible in theory, but not so much in practice. People go through their entire lives without CC data being stolen by a vendor, and in case it is they can dispute charges and cancel the card. So the kind of people who would appreciate this argument are already convinced.

Can you explain to the uninitiated how does #5 work? I don't know a lot about merged mining, but in normal mining this is impossible since a pool's getwork gives all rewards to the pool.

But if this attack is possible and no other solution is found, pools will have to lobby that much harder for oblivious shares.

I doubt that, hoppers are just too lazy to hop it properly.

Patience, it will collapse eventually (unless something happens to the pool due to unrelated matters first).

Due to real or perceived demand, I've written a complementary paper Summary of mining pool reward systems.

Ok, I misinterpreted the scope to which your comments applied.

Well, I didn't ponder much how difficult issuance is, because I don't think it is ultimately consequential, at least for a currency like Bitcoin. Once every coin passed hands hundreds of times, facilitating trade each time, will it really matter to whom it was originally issued?

I'm going a bit off-topic, but as long as we're here... Can you briefly describe where in this taxonomy fall proof of stake ideas of myself et al (eg this comment)? The general idea is to make sure that those with the ability to game the system are those with the least incentive to do so. The motivation is to enable high transaction security for those willing to wait long enough, with only a small amount of wasteful proof-of-work.

Grandma doesn't need to know she is using OpenPGP, anymore than she needs to know PayPal is using a Verisign extended validation SSL certificate. All she needs is the mail client to tell her "this message is legitimate" and the browser to tell her "this website is legitimate".

There's no Certified Advanced User of Technology (CAUT) training. People can be "advanced" and yet have gaps in knowledge in some areas, such as security. Also, even CAUTs with the necessary knowledge make mistakes.

Also, if people who are not advanced users of technology are using Bitcoin, that's a good thing.