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

OK. I made a tottal newbe out of myself... again. However, I think there is a mistake on page:
http://eligius.st/wiki/index.php/Shared_Maximum_PPS

The pseudo code reads:

It should be:

This is caused by two things.
First, the timeframe for the hashrate calculation is not identical to the time it takes to find a block.
Second, the SMPPS reward system currently has a depleted buffer, causing it to not be able to pay full PPS rewards until pool luck will get high enough. It will attempt to pay that back as soon as it can, but nobody knows if it will ever be able to fully pay it.
This is my main concern against SMPPS: It is more likely for you to be fully paid if you leave the pool now, however if everybody does that nobody will be fully paid at all. This is a very critical situation for the pool, and if it stays like this for a long time, miners will start leaving, and new miners will have no incentive to join, effectively killing the pool. Let's hope for luck to catch up quickly

Regarding the valid block in invalid share dilemma, I think the most fair solution is the most complicated one (which wasn't proposed above), to take these blocks into account, dropping a user's balance negative if necessary, only putting the "collected" funds into the buffer, until the user "pays back" his debt (by mining), which would put the remaining funds in the buffer once this happens. A bit complicated, but should be possible, and should not be attackable any worse than any of the other solutions.
I had an in-depth discussion about the pros and cons of this with Luke-Jr yesterday on IRC, and it seems that we agree that this is the solution with the least negative impact on the pool (or even a positive one).

In FAQ the is:

May I suggest adding:

Current wording implies that age is counted since "payout" became a "qualifying payout".

I went over FAQ again because there is something that bothers me and I could not figure it out. How does current block estimate works? At this moment I contribute tiny 0.17% of the whole pool hash rate. However, estimated reward for the next block is only 0.12% of 50 BTC per block reward. It may seem that 0.05% is not much but it actually makes about 40% diff to my payouts.

Does it means that there are some people who jumped out of the pool and pool still owes them "maximal reward"? I am I correct at guessing that I am offered (my unpaid reward)/(all unpaid rewards)*50BTC. This would depend on historical contributions as long as 30h ago. While hash rate calculations are based on last 3 hours performance only.

Since it's technically in the public share log anyway... 1Q5vfJ2dEFgRcsF9SQSGgvAnpk2Fp2bMCi is the one who found the block in question.

I've accepted this block into the pool since it seems innocent enough (no balances went negative even briefly). What to do with future occurances, if any, we can figure out later.

Woops, my main mining rig was only behind by...a year and a month. ~If there is a God, Please don't let this be my fault~

vote for #1 - seems like the least work.  miners should probably check that the time on their rig is set to something consistent with reality.

Will

+1 for #1 here. Mind publishing the address of the miner who submitted that block? He might come forward and help resolve this.

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.

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.

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

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.

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.

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.

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?

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.

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.

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.