Those are intentionally crafted by my eligius_sendonly branch. The non-standard output is in fact the transaction fee, but encoded such that only Eligius can benefit from it. This was at the request of some miners who apparently see it as a way of contributing to the pool. They should be confirmed every 4 hours on average, given Eligius's current pool size.

Mainly because this forum software makes no effort to notify me that I have messages. Apparently there's 9 since the last time I manually went to check...

Addresses aren't stored in the block chain, except as outputs to transactions. Since every transaction generally has a unique address for its output (except for donations), all addresses are usually "young". When it becomes possible for merchants to use a single address for all transactions (ie, when clients can easily send an address-signed email with a transaction id), this might become viable.
Miners can't "send back" anything at all...

qurashee also built my branches (use at your own risk!): http://eligius.st/~qurashee/

But they don't payout immediately as part of the same block you worked on
The estimate isn't per 24 hours, it's per-block; right now, Europe should find a block on average every 21 hours, which works out to 0.41 BTC every 24. You should see your estimate creep up (possibly slowly) toward the point where it reaches the full .56 BTC per 24 hours (which would be .49 BTC per 21).

I'm not sure why everyone assumes this is easy, or even possible... The main difficulty is finding a way to handle network issues when they can't talk.

What address?

FYI, if you would like to take advantage of Eligius's lower transaction fees, you can clone/merge my eligius_sendfee branch:
I was also asked to write a branch that sends transactions only accepted by Eligius. Replace "sendfee" with "sendonly" to get that. It works by paying fees directly to a "magic" Eligius address rather than normal fees, and making that output non-standard to discourage other miners from including it.

There are many possible errors. Yours is the first I've seen with a null username. Checking for errors adds overhead to every single getwork, and either changes the C code or requires a very carefully crafted MySQL query (which I am aiming to remove for efficiency anyway). I also have other things to work on before I declare Eligius to have formally left the "experimental" stage. So I have to say, if address checking for mining is to be implemented, it won't be very soon... sorry.

git fetch git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git eligius_sendfee && git merge FETCH_HEAD

There's definitely something seriously wrong with Phoenix. Perhaps someone should ask the author to figure out what? :p

Hasn't it always been forced? It seems the correct solution is to include a "Optional fee" in the send dialog, and if it's too small, display a confirmation ("... Do you want to send it this way anyway? Yes/No") if it's "too low". But nobody's submitted a patch for that afaik.

Don't assume it will necessarily get accepted ever...

I will, of course, gradually drop the minimum as the value comes up. The main point is to save you the transaction fees when you go to spend them.

Why Flash? My understanding is that phones can read QR-Codes without it. I hope you plan to make it a HTTPS-only function (with a proper cert)...

Like I said, I'm not putting a fee. And there's no easy way to figure out the overall pool costs. Hence, it's ok if people just donate what they consider a fair amount every once in a while.

FYI, after a week of testing on Europe, I have calculated that a patch I wrote decreases duplicate work by 0.7%. Given the current pool size of 60 GH/s, that means we now (once I apply it to the USA pool) accomplish a whole 420 MH/s extra than an unpatched bitcoind, or almost 1 BTC per day at the current difficulty. Even half of that, 0.50 BTC per day, would take only until the end of the current difficulty to cover the expense of the time I spent writing the patch.

In my mind, this would justify adding a long-term 0.7% "fee" to the pools, but I'm not going to do that. Instead, I'm going to just publish the information and ask everyone to keep this fact in mind when considering donating to the pool.

If anyone would like to double-check my math, let me know and I'll setup an account for MySQL access. I started calculation from UNIX timestamp 1306000000 (about a week ago), but it should be safe to start as early as May 11th. During this time, Europe had the patches, but USA did not.

Thanks. I also appreciate donations, as the pool's fee structure doesn't really cover expenses (it mainly exists to create numbers for testing).

I have shutdown the Europe pool temporarily and redirected its DNS to USA due to discovering a major bug (which accidentally never made it to the USA pool). I could use some help debugging it in #Eligius if anyone wants to volunteer some brainpower.

Edit: False alarm. Europe is and has been working properly. Pool brought back online.

FWIW:

Luke-Jr - Luke Dashjr, core developer (of Spesmilo), Eligius pool admin, and owner of Lightfoot Hosting

Sorry, but my patch probably doesn't help your case. Some corrections:

• It's not really that hacky, I just never bothered to make it work with SSL.
• It doesn't help failover in any way.
• It requires each RPC command to enable threading-- currently I have only enabled it for getwork.
• Eligius only needs/uses it for calling RPC command from inside the coinbaser (which blocks getwork).