I've put together a chart with the status of listening nodes. |
|
|
|
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. 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. If it's accepted into the system, then not only are the payouts deducted from miners' balances, but there's also 50 BTC the pool was "supposed" to have received for distribution. If the 50 BTC doesn't go to pay off the pool's debts (because someone gets overpaid), I'm liable out-of-pocket for that difference. 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, that seems the most ideal, but probably almost impossible to implement with the current setup. Maybe one day I'll rewrite the coinbaser in a sane way (perhaps upgrading to ESMPPS at the same time?), but until then, I'm inclined to just accept "no overpayment" blocks as they come up and ignore ones that are clearly trying to harm the pool if we encounter them. |
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
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/181845http://blockchain.info/block-height/181839They 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/18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2BAbsolutely 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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
My production has gone to shit lately while my hashing rates are the same. What's going on?
You're not finding any blocks <.< |
|
|
|
Background:Currently, before a new release of Bitcoin-Qt is published to SourceForge, it must be compiled by 3 different people who verify that they have produced the same exact binaries. This is done to protect against a variety of attack vectors: a single builder could include a trojan or backdoor into their binaries. No matter how much this person is trusted, their ability puts them at risk of being forced (eg, by gunpoint or legal action) to do so, or potential to do so accidentally (eg, if their build system is infected itself). Additionally, there is one person to impersonate or man-in-the-middle-attack, and the chance (5-10% in a person's lifetime, according to a quick Google) the person may begin to go insane. It also leaves open a question to the masses should that person die, of whether his successor is just as trustworthy. However, right now, these thrice-verified builds are only possible for Linux and Windows using the Gitian framework. So far, Gavin has been personally responsible for the Mac OS X binaries, and he (and the community) incurs all the risks above as a result. My proposal:I have succeeded in building bitcoind (the JSON-RPC server) for Mac OS X under Gitian, and verified that this build is deterministic (able to be compared with others' builds). In addition to the cross-compiler and dependencies of bitcoind, I have also succeeded in building the dependencies required for Bitcoin-Qt under Gitian - except for Nokia Qt itself. To build Qt, I need to go back to the cross-compiler and figure out how to get the Objective-C compiler working. Then I will need to configure Qt for cross-compiling using it, and ensure the output is deterministic enough to produce a deterministic Bitcoin-Qt build based on it. This is going to be a lot more work, especially since nobody seems to have ever cross-compiled Qt for Mac OS X before. Therefore, I am asking for donations to help fund completing this effort: 1D8jkYpkcJUQ6BJzjAATAEBjHdgVhvisAVP.S. My work thus far on this specific project is all published in these Gitorious repositories.
|
|
|
|
|
Payouts from the buffer are processed manually (for security, the funds are not "online"), but in the same way as generated payouts.
|
|
|
|
are there any plans to add the option to cpu mine with windows?
I don't want to make it too easy for botnets to abuse BFGMiner. Is there a legitimate need for CPU mining for people who don't know how to compile themselves? yes, my friend says he gets 30mh/s with his cpu. every little extra bit helps imo. The electricity to mine 30 MH/s with a CPU costs more than you'll get. |
|
|
|
are there any plans to add the option to cpu mine with windows?
I don't want to make it too easy for botnets to abuse BFGMiner. Is there a legitimate need for CPU mining for people who don't know how to compile themselves? |
|
|
|
|
If someone wants to implement it for Eligius, feel free to email me for webserver access...
|
|
|
|
A newbe question (but I have looked through Eligius FAQ): my unpaid reward went down by a lot, like by 90% of the amount due. I was about to hit payout treshold and now it reports 2mBTC. This could not be a result of orphaned block, rather an orphaned branch of all 10 blocks mined in last two days by Eligius. Some of these blocks are reported already as confirmed (over 120 blocks have been mined after them, but this count includes blocks mined by everyone). The graph still shows that I have an unpaid reward of ~0.66 BTC. But I know that graphs have significant lag. Could someone point me toward source of enlightment? (What the **** is going here?  ) Probably you were paid. If it doesn't show, restart your client (there's a known rare bug where it doesn't show some transactions until restart). In doubt, check your address in Block Explorer or BlockChain.info. Thanks for explanation, you are verry correct. I was under impression that the payout queue is like 7 blocks long. Hence, I thought that I should wait for at least 7 blocks to be mined by Eligius before I get to the front of the payout queue. I did not expect payout to be so quick after hitting the treshold. Thanks again. PS. Before posting I checked payout queue and I had not been listed there. The payout queue is ordered by how long people have been waiting, so if it took you a while to get to the threshold, you'll enter the queue on top. |
|
|
|
A newbe question (but I have looked through Eligius FAQ): my unpaid reward went down by a lot, like by 90% of the amount due. I was about to hit payout treshold and now it reports 2mBTC. This could not be a result of orphaned block, rather an orphaned branch of all 10 blocks mined in last two days by Eligius. Some of these blocks are reported already as confirmed (over 120 blocks have been mined after them, but this count includes blocks mined by everyone). The graph still shows that I have an unpaid reward of ~0.66 BTC. But I know that graphs have significant lag. Could someone point me toward source of enlightment? (What the **** is going here? ) Probably you were paid. If it doesn't show, restart your client (there's a known rare bug where it doesn't show some transactions until restart). In doubt, check your address in Block Explorer or BlockChain.info. |
|
|
|
|
Show Posts
