[OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #

[muyuu]

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

[1713285385]

1713285385

[1713285385]

1713285385

[1713285385]

1713285385

[1713285385]

1713285385

[1713285385]

1713285385

[Luke-Jr]

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

You're not finding any blocks <.<

[muyuu]

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

You're not finding any 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):

[Luke-Jr]

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

You're not finding any blocks <.<

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

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.

[John (John K.)]

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.

[muyuu]

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

You're not finding any blocks <.<

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

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.

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

[Luke-Jr]

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.

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.

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

You're not finding any blocks <.<

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

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.

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

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.

[muyuu]

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.

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. 

[Luke-Jr]

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.

[muyuu]

I vote 1.

[atsoat]

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.

[Luke-Jr]

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.

18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B is the pool's (offline) address, generated to when there's no payouts ready and in "blank" longpoll blocks before the transactions have been recalculated following a network block. Generally, the 50 BTC ones are the latter case. As mentioned in my previous post, payouts are frozen until the issue is resolved, so all blocks mined until then will go entirely to this address. The SMPPS code automatically catches any abnormality and shuts down until a human has had the opportunity to look over the situation and deal with it. Basically, all of this is expected behaviour to ensure the pool is kept secure from attempted exploits.

[lunchb0x]

I vote for 1 because it seems like the simplest solution. Although there will definitely need to be some sort of warning about it on the homepage.

[49er]

I'm not sure I fully understand the problem, but personally I'd prefer the fairest option.

If the invalid share paid the "official" pool address, then that should go to the "pool blocks found" balance. If the invalid share paid pool users' addresses, then the amount paid to them should be subtracted from what those users will earn.  If they go negative then so be it, hopefully (most likely?) it won't be by much.

I guess I don't see the problem with taking users' balances negative.  They get the payout either way, correct?

[Luke-Jr]

If they go negative then so be it, hopefully (most likely?) it won't be by much.

I guess I don't see the problem with taking users' balances negative.  They get the payout either way, correct?

Yes, but if I treat it as a block, I'm personally liable for overpayments. If those negative balances never "pay back" with mining, they're paid, but the pool has that much less funds.

[atsoat]

18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B is the pool's (offline) address, generated to when there's no payouts ready and in "blank" longpoll blocks before the transactions have been recalculated following a network block. Generally, the 50 BTC ones are the latter case. As mentioned in my previous post, payouts are frozen until the issue is resolved, so all blocks mined until then will go entirely to this address. The SMPPS code automatically catches any abnormality and shuts down until a human has had the opportunity to look over the situation and deal with it. Basically, all of this is expected behaviour to ensure the pool is kept secure from attempted exploits.

OK, that makes sense - I missed the bit where you said payments had been suspended.

If I understand correctly, a user producing such blocks can't be altering the payouts (or all their shares would be being rejected) - so they are just submitting late/messing up altering timestamps. So I wouldn't try to write complicated routines for such an abnormal case. In virtually all cases when you get a block like this it is going to be paying out to correct addresses which will not be taken negative by the payout. So I'd aim to accept in these cases.

However, I don't really like solution 1, as that seems exploitable by somebody who wants a chance of get their payout multiple times, by delying their submission should they find a block.

[atsoat]

If they go negative then so be it, hopefully (most likely?) it won't be by much.

I guess I don't see the problem with taking users' balances negative.  They get the payout either way, correct?

Yes, but if I treat it as a block, I'm personally liable for overpayments. If those negative balances never "pay back" with mining, they're paid, but the pool has that much less funds.

How can they go negative? The only way I can see is if one of those blocks occur around the same time as a manual payout is being done.

In any case, if they should go negative then I don't see how the pool is any worse off - as accepting that abnormal block has reduced the pools payout liability.

[drlatino999]

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.

Interesting, I need to get some coffee to help with the thinking.

[coinft]

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.

...

This is the first time this happened? Likely it will not happen soon again. Let's go with 1 as it is least work and simplest to understand, and doesn't change much overall.

-coinft.

[Peter Todd]

I mine on Eligius for fun with some spare equipment, so take this for what it's worth, but I'm all for #1; sounds like a lot less work for you.