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

Yep - enough - I looked at the current block (182454) and it also has no 0 Fee txn's - so I thought you still hadn't changed that.
http://blockchain.info/block-index/231606/0000000000000256e46d46b389de5690e5033c1ebb94561fdc261bcb831d9c1b

Looks like you have improved your 'algorithm' ...
Good

P.S. I'll delete these posts soon - you already have a copy here in your post if you need it - I just don't want "Show new replies to your posts." to show up here

Firstly, I know this used to be correct - so I'll ask here to see if that has changed:
Can anyone deny this?
The way to deny it would simply be to identify any 0 fee non-coinbase transaction in a recent Eligius BTC block ...
(before block 182456)

I don't mind being wrong, in fact I'd be happy to be wrong about this particular issue, but I do want the facts, not here-say.

Why are you personally liable for those over payments?  Do you just mean it can make the pool look bad?  Technically, those people are being overpaid either way, just one way you are tracking it in the system.  And I would guess that for 99% of these cases, people will already be positive, or go positive within a day or two.

I understand negative balances could cause the pool to lose it's buffer over time.  To avoid the appearance of this, perhaps only count those parts of the payout once those accounts have gone back positive.  So if a payout was 50 btc and someone was paid out 5 when they were only owed 1, then take them to 0, and say the block reward was only 46.  Track those would be negative accounts and as they earn payments, deduct the payouts until the block reward is back to 50.  Perhaps this is what was meant by option #4, but with tracking.  It's probably the most complicated to implement, but seems to me to be the most fair.

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.

reward = reward * (availableFunds / totalEarned)

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.

The Payout Queue prioritizes qualifying payouts based on their age.

The age of payout is counted since last payout or first contribution.

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

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.

...

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.

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.

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.

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?

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.