You need to think it through more.

Yeah, fair enough. Rules are rules, after all.

It works to improve your miner's efficiency. It's not cheating: as with all improvements to efficiency, those who don't do it end up with less. Unlike other efficiency improvements, it doesn't help the network. The end result when everyone uses it could be problematic.

Nothing comes "crashing down", it just evens out like with other efficiency improvements.

BFI_INT helps the network in addition to improving efficiency, but that is unrelated.

Where do you think the extra income from BFI_INT comes from? Other miners, too! And just like with BFI_INT, once everyone does it, it evens out again. It's not stealing to work more efficiently. Nobody is guaranteed any earnings at all.

That's not evidence it's a problem or cheating. It's evidence that it's more efficient. Using BFI_INT is more efficient too.

My understanding of reading this algorithm is that it only works if the pool takes fees... yet you claim no fees. How does that work?
Eligius is a community pool, with (read-only) access to basically anyone. You're welcome to setup SMS etc notifications on the server if you want (contact me for an account), though I'm not sure you'd care to since you have your own pool now.

This is basically wrong. There is no evidence that "pool-hopping" is a problem or cheating; in fact, the score method actually creates a pool-hopping issue because it rewards later-comers unfairly at the expense of earlier miners. Finally, the score method really is disadvantageous to intermittent miners.

In case anyone hasn't noticed yet, we have a growing community at #Eligius (FreeNode) and http://eligius.st (email me for your own webspace)

Some various change-ideas are being discussed on IRC, and I would appreciate participation from everyone/anyone that uses the pool and wishes to have a say on what changes get made.

Just because someone publishes it doesn't mean you can copy it.

I'd like to hear what the coined.com author is looking for.

Right, preferably your local Eligius is the main instance, and the other Eligius can be your backup pool

A stale block occurs when two miners find the same block at basically the same time. Due to the design of Bitcoin, only one of them can be the "real" block. Until the next block is found, they continue to compete by the miners who are looking for the next block; when the next block is found, the one it chose to be based on becomes the real block, and the other one becomes an orphan. At that time, it basically ceases to exist retroactively.

When Eligius has a stale block, it works the same way: it ceases to exist. Payouts in that block (usually rewards for the same block) cease to exist. Your shares are counted toward the next block, just as if the stale one was never found, so they will be paid when the pool finds its next block.

Stale blocks should not be confused with stale shares, which is what your mining program might report. A stale share occurs when the pool has already moved on to the next block, yet your miner is still submitting shares against the last block. Eligius supports long polling, so it can tell miners immediately when it moves on to a new block. Therefore, if your miner continues to submit stale shares, they are rejected as invalid and not counted toward your earnings.

The pools are most certainly up far far more than they are down. I am pretty sure total combined downtime combined has been under 24 hours since I started Eligius.

Total time that both have been down at the same time, I believe, is never (since starting Europe). I personally run two miners, one on each pool, so that when one goes down the other picks up the slack.

Unfortunately, most of the downtime has been from pushpool bugs under high load, which are extremely difficult to debug without a high-load test server. And with only 40-50 GH total, I'm not certain there's enough people yet willing to run on a "guinea-pig" debugging server? If there is, I could probably set one up... As things are, I've just been killing and restarting pushpool when it goes bad in an attempt to get things back online ASAP.

Also, Artefact2's pool statistics seem to be having an issue graphing the pool hashrates; the majority of the missing spots on the graph are not downtime at all.

That's calculating "leftovers" from generation, not fees per block. There's a big difference. Also, you're counting a sendmany as Paid: 0 / Fees: 50, when it should be the exact opposite...Me too.Combining them is extremely difficult due to the way Eligius pays out. It's on the table, but not an overnight project. Any suggestions on how to best deal with netsplits?

At least the original client intentionally forces a proper decimal point regardless of locale settings. I agree that removing the ambiguity is a good thing.

That's a BAD thing. If 0.03 BTC discourages CPU mining, great! It should be discourage.

P.S. note that commas are for deliminating thousands, not a decimal point

Based on the specs at http://en.wikipedia.org/wiki/Xenos_(graphics_chip) , XBox360's GPU can probably manage a measley 7 MH/s.

Actually, the fact is that it is basically impossible to add any more precision. It's possibly if the whole network upgrades, but that's basically creating a new network. It's just as "trivial" as changing the 21 million total into something else.