Announcement: Eligius will soon stop sending the X-Roll-Ntime header (and will reject ntime-changed shares from) miners which do not send at least "X-Mining-Extensions: rollntime" in their getwork headers. An exception to the rule will be made for User-Agents matching miners known to roll ntime correctly (currently, this is poclbm and newer cgminer versions), but authors of such miners are encouraged to advertise rollntime support anyway.
What this means for you: If you're using a miner that isn't either known by me to have working rollntime support and has a unique User-Agent header, or advertises having rollntime support explicitly, your miner's efficiency (accepted shares per getwork) will drop. If network latency is bad, you may get more "miner is idle" messages. It is recommended that miners use clients which support rollntime, such as poclbm.
This is one step toward improving our longpoll times and making the pool more efficient in general.
P.S. If you hack your client to advertise rollntime support, but don't really support it, expect to have the miner blacklisted from rollntime. There is no reason to do this.
In other words, you're giving me a reason to remove rollntime completely in DiabloMiner. Good jorb. Or you could make it send X-Mining-Extensions. For now, I've whitelisted "Java" user agent... Until Tycho adds support for X-Mining-Extensions to his Roll NTime spec, I see no reason to support this. Tycho has nothing to do with rollntime. The only spec is what I just wrote up at https://en.bitcoin.it/wiki/Getwork#rollntime |
|
|
|
Here's a new bugfix: http://tinyurl.com/3qo2j3oSynopsis: Don't turn off X-Roll-Ntime just because the work submit doesn't include the header. (it really should associate it to the specific work, but this is good enough) |
|
|
|
Announcement: Eligius will soon stop sending the X-Roll-Ntime header (and will reject ntime-changed shares from) miners which do not send at least "X-Mining-Extensions: rollntime" in their getwork headers. An exception to the rule will be made for User-Agents matching miners known to roll ntime correctly (currently, this is poclbm and newer cgminer versions), but authors of such miners are encouraged to advertise rollntime support anyway.
What this means for you: If you're using a miner that isn't either known by me to have working rollntime support and has a unique User-Agent header, or advertises having rollntime support explicitly, your miner's efficiency (accepted shares per getwork) will drop. If network latency is bad, you may get more "miner is idle" messages. It is recommended that miners use clients which support rollntime, such as poclbm.
This is one step toward improving our longpoll times and making the pool more efficient in general.
P.S. If you hack your client to advertise rollntime support, but don't really support it, expect to have the miner blacklisted from rollntime. There is no reason to do this.
In other words, you're giving me a reason to remove rollntime completely in DiabloMiner. Good jorb. Or you could make it send X-Mining-Extensions. For now, I've whitelisted "Java" user agent... |
|
|
|
|
Announcement: Eligius will soon stop sending the X-Roll-Ntime header (and will reject ntime-changed shares from) miners which do not send at least "X-Mining-Extensions: rollntime" in their getwork headers. An exception to the rule will be made for User-Agents matching miners known to roll ntime correctly (currently, this is poclbm and newer cgminer versions), but authors of such miners are encouraged to advertise rollntime support anyway.
What this means for you: If you're using a miner that isn't either known by me to have working rollntime support and has a unique User-Agent header, or advertises having rollntime support explicitly, your miner's efficiency (accepted shares per getwork) will drop. If network latency is bad, you may get more "miner is idle" messages. It is recommended that miners use clients which support rollntime, such as poclbm.
This is one step toward improving our longpoll times and making the pool more efficient in general.
P.S. If you hack your client to advertise rollntime support, but don't really support it, expect to have the miner blacklisted from rollntime. There is no reason to do this.
|
|
|
|
Keep the delivery of the data consistent by being in big endian. It should be up to the coders to flip the endianness before feeding it to openCL. You can't just flip endians when you're hashing. |
|
|
|
|
In the attempt to implement noncerange, I came across a dilemma: while all the existing share data is in big-endian blocks of 32 bits (with larger numbers being little-endian otherwise), it seems OpenCL miners at least choose their range in little-endian. Since nonce is only 32-bits, and all 32-bit fields are standardized on big-endian (not to mention it being the standard network endian), I'd much prefer to maintain the actual nonce field as big-endian. Can someone familiar with OpenCL and/or other mining platforms (SSE2, etc) tell us whether endian will hurt performance, and if so which endian is needed to maintain the current performance? Miner implementations welcome also! (gMinor has broken noncerange support!)
|
|
|
|
|
New feature for beta-testing only (NO WARRANTY ETC): you can now append your address with "_workername" in your username to classify the shares. This has no effect on the JSON data, but does create a distinct identity in the database so you can monitor individual workers' uptime and hashrate. Currently it is not supported by Artefact2's graphs.
|
|
|
|
In the other you are guaranteed less than full payout for quite a long time, since you have to pay off unpaid shares which others have accumulated. You are getting less than proportional in this case, right? This is true of SMPPS and, to an extent, ESMPPS, but it is not true of RSMPPS or CPPS* which prioritize the present and future over the past. |
|
|
|
In a *MPPS pool you get paid the expected payout in the best case and less in the worst case.
On Prop. you get paid far more than expected in the best case and far less in the worst case (which evens out if there are no hoppers). Not quite. All variations of *MPPS will pay you extra for formerly underpaid blocks, making them even out even without hoppers. In the scenario where the pool never evens out, neither would proportional. |
|
|
|
No matter what reward method is used, when a pool is down to zero buffer on a long round, it must either underpay or create debt for the pool owner. That is an inevitable fact of pooled mining. Nothing can stop it. *MPPS attempts to mitigate it by offering to make up for the loss later.
Your mistake is assuming that the goal of a pool is to reward each share with the statistical average, exactly. The real goal of a pool is, however, to reward each share with the statistical average, on average (while reducing variance as much as possible). On the one hand you have PPS, which is 0 variance for the miner (with maximal risk to the operator); on the other hand, solo mining which has the highest variance; and a variety of methods in between. PS. If MPPS is what I think it is, then it is just as bad as the *SMPPS. *MPPS fit with your "real goal" much better than any other system currently. This is of course false, given that 1. *MPPS does not fit the goal. 2. Other systems such as PPLNS and the geometric method fit the goal. *MPPS fit the goal more or less exactly. PPLNS and geometric just add variance and obscurity to how well the goal is met. |
|
|
|
No matter what reward method is used, when a pool is down to zero buffer on a long round, it must either underpay or create debt for the pool owner. That is an inevitable fact of pooled mining. Nothing can stop it. *MPPS attempts to mitigate it by offering to make up for the loss later.
Your mistake is assuming that the goal of a pool is to reward each share with the statistical average, exactly. The real goal of a pool is, however, to reward each share with the statistical average, on average (while reducing variance as much as possible). On the one hand you have PPS, which is 0 variance for the miner (with maximal risk to the operator); on the other hand, solo mining which has the highest variance; and a variety of methods in between. PS. If MPPS is what I think it is, then it is just as bad as the *SMPPS. *MPPS fit with your "real goal" much better than any other system currently. |
|
|
|
Does this make sense, or am I missing something? You are correct. This is a fundamental problem with all *MPPS pools. When the balance is negative, miners know that their payment has a good chance to be delayed. It doesn't matter if the pool pays recent first (RSMPPS), strives for equal payment for all shares (EMPPS) or pays all unsaturated shares every round (SMPPS). And, since this should quickly cause the collapse of the pool, "delayed" really means "gone forever". Equalized SMPPS is ESMPPS, not EMPPS. Regular MPPS is not "vulnerable" to pool funds running out, because you have your own private limits that you are responsible for maintaining. No matter what reward method is used, when a pool is down to zero buffer on a long round, it must either underpay or create debt for the pool owner. That is an inevitable fact of pooled mining. Nothing can stop it. *MPPS attempts to mitigate it by offering to make up for the loss later. CPPSB is logically a combination of RSMPPS and SMPPS: When/if the pool reaches 0 buffer, it starts "discarding" the oldest shares in the round into the "extra credit" buckets, while maintaining full PPS value for the most recent and future shares (this to maintain the best possible deal for current miners, so they don't leave). When and only when it has extra funds on short blocks, it will then pay toward the "extra credit" buckets indiscriminately (backpay), until it is all given full PPS reward, and then start filling the "buffer" bucket. CPPSEB is similar, but tracks unpaid shares rather than indiscriminate unpaid value totals, and when it's giving backpay tries to distribute it so the unpaid shares are all paid off an equalized amount. |
|
|
|
I've been getting about 5% stales recently is this normal?
I'm getting between 2-4% lately (1 week timeframe), which is a bit worrying. Sometimes the 15-min window shows even up to 7% of current submitted shares being stale. I've had consistently under 2% (except for server issues/downtime) for a while now... Doesn't happen at a few other pools so it's not a hardware issue. That doesn't actually follow. Most other pools don't support the same functionality that Eligius does, so don't encounter the same issues. I would suggest trying with the latest poclbm (ideally my branch) and seeing how that works. |
|
|
|
|
The reality is that Unicode already has the de-facto BTC symbol B⃦ and that both new "proposals" are simply more or less font-specific variations of that. No action needs to be taken, and probably Unicode will not take it, because the glyph is already part of Unicode. All that needs to be done, is for people to optimize fonts for displaying it nicer.
|
|
|
|
|
Eligius also works on port 80
|
|
|
|
Ok, got the issues worked out and regenerated everything based on July 8 to 20 (12 days). Since Eligius-Su has had absurdly good luck on average, I decided to artificially drop 1/3 of the blocks to make it have somewhat bad luck. Since most of the PPS systems pay exactly PPS during good luck, I consider the bad luck scenario to be of more importance to "get right". In addition, I am now simulating 3 miners: the default constant 800 MH/s, the hopper 800 MH/s who only mines for the first 43% of difficulty shares, and the "newbie" 800 MH/s who mines constantly starting 2/3 into the graph. http://eligius.st/~luke-jr/samples/800MH-3/ |
|
|
|
Proportional Payout (PP) pools can be easily cheated by only submitting shares early in the round (see section 1, below). First, Proportional is a reward system, not a payout system. It is usually abbreviated "Prop.", not "PP". More importantly, what you describle is not cheating, but rather common sense: why should a miner contribute to a pool that is currently offering to pay him less than what his shares are realistically worth, when there are other pools willing to pay him fairly (or in the case of just-starting proportional rounds, potentially more)? The problem is with the proportional system itself overpaying and underpaying in a predictable way. Alternative schemes exist to address pool-hopping, but all come with disadvantages:
still exploitable by pool-hoppers (including PPLNS, slush's pool, see section 2)
increased BTC return variance for miners as compared to PP (PPLNS, slush's pool)
possible decreased returns (score-based systems)
increased risk for pools (PPS)
Pool complexity and obscurity - (all) None of these apply to the various SMPPS systems. Here, I present a new payout scheme, dubbed normalized Proportional Payout (nPP), which is mathematically impossible to cheat with hopping, while offering identical payout to miners which have a constant share submission rate. nPP requires no complex coding and pays out 100% (minus fees) of the generated BTC with every block (in other words, no BTC buffers) while not subjecting pools to variance risk. This work is based on statistics first formulated by Raulo. I'll call it NProp... If it's rewarding identical to constant miners, that means it's still rewarding unfairly and the real problem still exists. Buffers are the only way to pay fairly without creating a liability on the pool operator. Also, I feel it should be noted that for consistent miners, neither Slush and PPLNS increase variation. Your actual "NProp" system looks more or less identical to Slush's Score system, perhaps varying in some technical details. Unfortunately, it hurts part-time miners (such as pool hoppers) without really fixing the problems. These kinds of systems basically hold your earlier reward hostage if you don't keep mining when the pool offers to pay less than the value of your work. |
|
|
|
I had created a similar tool for my own purposes and it my code correctly determines the order since it seems to match with the payout queue from the new raw .txt file. It does draw lines every 50 BTC to give me a sense of how far out my payment is likely to be: http://twistymaze.net/eligius/I would suggest you move this to http://eligius.st/  |
|
|
|
This isn't very useful to be honest, since there are no block boundaries. Unless I am missing something important? Lack of usefulness is why I didn't publish it to begin with. There are no block boundaries and it's reordering constantly. |
|
|
|
I'd suggest you to not take me as a troll, cause that will only make you look like a fool. I'd suggest he does, since you've been doing an awful lot of trolling lately. But at the same time, I agree he should work a bit more on the security. |
|
|
|
|
Show Posts
