Topic: [OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 # - page 149. (Read 458255 times)

Looking at blockchain.info, after the block you dsicussed, I see two other blocks today that appear to be Eligius blocks, which are not showing up on the eligius.st under found blocks:

http://blockchain.info/block-height/181845
http://blockchain.info/block-height/181839

They both payout to the address normally included on Eligius payouts (   18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B ) so I don't think they are just relayed blocks, that blockchain is incorrectly tagging against Eligius.

In fact they have payed out the full 50 BTC to that address.

Has that dodgy block confused the code somehow?

Edit: In fact, looking at that address a bit more, it has picked up a couple of other 50 BTC payments over teh last few days whilst we have been running with a long payout queue:

http://blockchain.info/address/18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B

Absolutely not suggesting anything improper - just hoping that there is a code error contributing to our poor luck over the last few days.

I vote 1.

OK, so we've hit an interesting dilemma, and I'd like input on how to handle it. Until this is resolved, all balances and payouts are frozen (but will be retroactively corrected/paid when we come to a conclusion).

Block 000000000000081a00eb707e9a9d816708933b50887afd895a38ac3c425e56de was found by an Eligius miner. However, the miner who found it didn't obey the 2 minute rule on jobs, and it was expired (this means a very slow internet connection and/or buggy mining software). It was therefore rejected as a share, but still submitted to the Bitcoin network as a valid block. One of the safeguards in Eligius's SMPPS implementation checks that all blocks crediting the pool are also valid shares - if it didn't, someone could submit shares that were invalid because they paid the wrong people, for example. Especially in "extra credit" mode, accepting shares over 2 minutes long could very well result in overpayment as well.

So as I see it, there are 4 options available:

• (1) Ignore this block and any like it, as if it was completely unrelated to the pool. Everyone paid in the block gets a little bonus compliments of the miner who didn't follow the rules.
• (2) Accept blocks that don't actually try to overpay someone, even if the pool doesn't recognize it as valid participation. This could be fairly difficult to implement, as it means refactoring the code such that it can "back out" of a block it has already begun to process.
• (3) Partially accept these blocks: recognize the payouts as valid and deduct it from the relevant balances, but don't add the 50 BTC to the "pool blocks found" balance. The net effect of this means that the block value more or less gets redirected to me.
• (4) Partially accept the blocks, but add the actual deductions (that don't take balances negative) to the "pool blocks found" balance. This is basically the same as accepting the whole block (1) when it doesn't take balances negative, but with a "half way" state. It's also the most complicated option to implement.

Any other ideas for how to handle it? I'll try to put up a poll when I'm satisfied there's no more nominations - hopefully by the end of today.

Edit: Please note that in any case, the miner who found the invalid share will not be credited for it. The share validity rules are there for a reason.

Edit: Also, I was wrong about why the share was invalid: it wasn't expired work, the time header was too old. Miners may move the time header forward or backward, but only 5 minutes backward! Since jobs expire after 2 minutes, a share with over 5 minute old time header means the mining software is doing something pretty stupid. In this particular case, it probably means the miner's system clock is wrong. (This also puts the block at risk of being rejected by Bitcoin itself.)

Edit: To clarify, having your system clock wrong can make invalid shares if your miner uses it to modify the time header. In this case, the miner in question is using Eligius's distributed mining via getmemorypool, probably with gmp-proxy which does supplant the proxy's system time in the header (or else it'd drift too fast). Most (all?) getwork miners seem to be reasonable with how they modify the time header. In any case, unless your shares are showing rejected as time-too-old, you don't need to worry about it.

Well, since I'm mining here (Feb) only very recently this has started happening. But if it's just a temporary occurrence I will just shrug it off.

It's also the right place to mine, ain't it. 

The first block after your balance hasn't increased for a week. In "extra credit" mode, balances might keep increasing even after you stop mining for a while, though.

Not that exceptional. We've had huge buffers before, and the equivalent in extra credit is just as likely. So long as we keep mining, it should even out eventually, so I'm personally not going to stop.

Still, this would mean we have hit very exceptional "hard times", is this the case? should I turn off this shit or not?

By the way, how long do you need to be idle before what's remaining on your address (including the namecoins) are paid out? I've taken some of my rigs offline lately due to the heat here and the balance around ~0.21 coins including 5.2~ NMC are still sitting there for almost a week.

Eligius is SMPPS: so long as it consistently has income to cover full PPS, it does so. When it runs out, it's similar to proportional (but still not vulnerable to hopping), but keeps track of work done (the pink "maximum reward") so it can overpay later when it catches up on blocks.

Eh well, definitely not a matter of chance. The whole graph has changed completely. It was steady for months, now it's not.

This particular machine I moved it to Eligius in February:

(tested different configurations, ramped up with 2 card)


Same machine in March (a couple reboots there):


And this is now (stopped it last night to see if it made any difference - didn't):

You're not finding any blocks <.<

My production has gone to shit lately while my hashing rates are the same. What's going on?

Payouts from the buffer are processed manually (for security, the funds are not "online"), but in the same way as generated payouts.

Are you sure?  Best I can tell, that is automatic and the quote I pulled from the FAQ specifically says manually.  Moreover, (also best I can tell), all numbers based on ~twmz are for generate transactions and I am operating on the assumption that buffer funds are previously generated and must be payed out (as opposed to being generated in the new Eligius blocks) even if the behavior were automatic.  It is certainly possible that I missed something glaringly obvious, but I don't think ~twmz has anything to do with the buffer, and the quote from Luke-Jr doesn't appear to indicate otherwise (assuming payout queue = automatic / generate queue).

The buffer is available at http://eligius.st/~twmz/ as described above. Atm it's 164 btc in the red.

Regardless of your already answered question, the FAQ also states this:So methinks we don't really know if the pools buffer is used up or not.

Right, nevermind, think I got it.

My question was coming mostly because looking at the stats pages even between several users I saw that each block had that given per-share value, so I was wondering how that could compensate users properly. Decided to actually compare other values and finally realized that the shown per-share value isn't the actual per-share value, so of course all sorts out.

Thanks all the same.

From http://eligius.st/wiki/index.php/Shared_Maximum_PPS :


Pay-Per-Share means any share is worth the same as any other. If the pool has enough credit to pay you at the end of a round, it does. If it doesn't have enough to pay PPS for all shares, the pool makes best effort to ensure all miners are eventually paid the same (PPS) amount per share submitted.

To my knowledge, every SMPPS share submitted to Eligius has been paid exactly PPS (with the exception of those on the waitlist which I'd expect to be paid PPS eventually, God-of-the-block willing).

Sorry, but don't quite follow your reasoning since in Eligius the share value clearly fluctuates and that's why you're credited .10 BTC for a long block as you may get .15 BTC for a quick block depending on the fact if the pool ran out of funds or not.

The 'per share value' is always B/D (reward / difficulty). The variable is the time it takes to get paid, not how much you get.

Given this recent bad luck streak, and thus looking at the graph and seeing the "Maximum reward" filled area, I can't help but to ask one question concerning this pool:

So, if the pool has no buffer funds it means that in case a given block takes a long time to solve then the value per share will drop in order to keep the total volume of shares multiplied by value to be more or less 50 BTC. Consequentially if the following block would be solved in little time then each share would have a greater value to make up for the reduced payment on the last block.

My question is though, does the pool track the individual effort of each user so that it rewards a particular user more until the value of his work is compensated?

i.e: Suppose there's a very long block which substantially brings down the per share value, then several quick blocks. The large block took about 20 hours to find, and a given user (Let's say he has 1500MH/s available, generates 1200 shares/hour or something) was mining for about 19 hours and 40 minutes of this block but then stopped - Let's say there was a power outage for the next few hours. He will of course receive the reduced share value multiplied by all of his work done so far, but what about afterwards? Given that the next few blocks are quick, everyone that keeps mining will receive much more value/share until the value of the shares of the long block is made up for, but what about the user that was made unable to mine during that period? Will he just lose the right to that compensation or the system adjusts the share value for him in the future?