Don't forget that the hoppers aren't the problem. They just aren't willing to work for the pool when it's paying less than market value for the shares. The problem is that the pool is rewarding predictably uneven (including above and below the market value).

Let's not forget that Eligius-De (aka EU) had two week-long rounds with a comparable hashrate/difficulty ratio as we have now. These things can and do happen, and we want to be prepared for it.

While SMPPS does have some real flaws if it were to get too far into "extra credit mode", be assured that myself and others have been brainstorming a solution should we ever get to that point. However, I disagree that probability of catastrophic failure is 100% given an indefinite amount of time. It seems to me that it is a coin-flip between 100% failure or 100% straight-PPS-success.

To qualify for a payout, your balance must be at least 0.33554432 BTC. When the pool is calculating payouts (currently just 50 BTC at a time, due to limitations of generated transactions), it prioritizes addresses which have had unpaid coins for the longest first.

This is being given as an explanation of how payouts currently work, and is not a guarantee that the minimum payout or sorting algorithm will remain the same in the future.

Because you start over every second. You don't need to ask for a new piece, the same one is still valid for up to (on Eligius) 2 minutes. The miner just changes the ntime header (+1 every second), and then it scans its nonce range until the next second.

It's important semantics. If people think it's debt, they will demand to be paid it. Since it's not debt, per system design, it's important that miners understand it so they're not surprised when/if they never get it.

All reward systems suffer from block withholding in different ways. With SMPPS, it affects all the miners more or less equally.

Tracking every single share is basically absurd.

Correct.
I don't think there is any way to avoid this potential problem. Surely you don't want to suggest miners do stale work? A fixed percentage/duration would not adapt well to the many different network links/distances that can affect latency.

Due to network latency, I recommend the following design for miners:
1. getwork, record <duration of getwork request> and <time+getwork expire> , and begin mining on it
2. every second, update ntime and reset nonce to <first nonce>
3. when a share is found, submit it. record the duration of the submit request.
4. if a share submission fails due to a network error, save the share and retry it a second later the same as step 3; also immediately (regardless of how long the current work has been active) begin trying to get new work (which is treated the same as step 5+6 when done)
5. when current time is past <time@1+getwork expire> minus <duration of longest getwork/submit since we started this work> times 4, begin a request for new work
6. when new work arrives, discard old work and begin using the new work.

It could be. The problem as I understand it, is that your miners are sending relative-to-an-unknown-value timestamps in the packets, and tcp_tw_recycle ignores ones with timestamps going backward in time (or something like that). So minerA and minerB have different relative-timestamps, but the earlier of the two gets ignored because of the later's packets...

It remembers the difference, but it isn't a debt as nothing is considered due or owed.

Then you don't know. You can do up to 2^32 nonces per second (with X-Roll-Ntime), which is 4 GH/s. You only need to get new work when longpoll returns it, or the pool sets a time limit on the work it gives you (2 minutes with pushpool).

Each nonce gives a hash/second. You can start over the nonce range every second with new hashes. So your 3 MH/s only covers less than 0.1% of the nonce range before it can start over from the beginning.

Each work can sustain up to 4.294967295 GH/s before you need more. Your suggestion was on July 11th, whereas I originally suggested this June 29th. :p

No number of threads on a single cost-effective machine (CPU or GPU) will ever max out 4 GH/s. Putting this in the protocol (though it could be done in the miner additionally) allows the work to be split among multiple unrelated miners. Anyhow, I don't see your "suggestion" anywhere, much less before I wrote up mine. "Ripoff" doesn't apply to independent research.

If a miner only has 10 MH/s, I don't want to waste 4 GH/s worth of work (a full nonce range) on them. Using noncerange allows me to chop that up into pieces and share a single work among 256 different 10 MH/s miners. I don't know how it would affect the CPU mining algorithms, but IIRC having to "finish off" a nonce range on a GPU caused some slowdown, so the poclbm branch with support rolls ntime aggressively to avoid it.

Feature request: Support for X-Roll-Ntime (with expire extension and noncerange

This can allow clusters of many CPUs/GPUs to process the same work up to ~4 GH/s.

While it doesn't carry debt (because it never rewards more than it has), it does remember the difference, and try to make it up in the future.

Turns out this is a known issue when net.ipv4.tcp_tw_recycle and NAT are combined. I have disabled it on the pool server, so it should be resolved now. Much thanks to mobiusl and everyone else who helped troubleshoot!

Also, I shutdown Eligius-Ti (formerly 3) last night, and its final payout went out this morning as a sendmany.

MagicalTux has confirmed that the new MtGox wallet addresses do correctly support generated transactions, so it should work with Eligius.

MtGox doesn't have wallet addresses, it has one-time deposit addresses that are good for a single transaction within 24 hours. Assuming it works correctly with generated coins at all, you would have to time your address changes very carefully and even then you'd be losing some fraction of payouts... Any standard real wallet should work. So long as you have access to the private keys, you can rest pretty safe. I don't know of any web-wallet service that works correctly with generated coins yet.

Edit: I didn't notice, but MtGox changed the strikedout part with their upgrade.