Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB

[not.you]

After having miners on this pool continuously for more than a year I can say that it is a very, very, safe bet that mining is still working fine even when the website is down.  All the website down means is that you have to wait a bit to see stats again.  That's it.

I hope wizkid pops in though and mods that coin_moron idiot out of here.  Ignore works but when people respond to that stupidity I still wind up seeing it.

[Biffa]

Site and stats working fine again!

[Biffa]

is namecoin working again

I received a payout recently.

M

Confirmed, just had a big backlog Namecoin payout on the 9th November and some dust yesterday.

Thanks!

Hmm must be a manual process maybe? Its stopped again. 

[baddw]

is namecoin working again

I received a payout recently.

M

Confirmed, just had a big backlog Namecoin payout on the 9th November and some dust yesterday.

Thanks!

Hmm must be a manual process maybe? Its stopped again. 

Namecoin payouts have always been manual and, therefore, sometimes at odd intervals.

[praeluceo]

So I recently acquired some Prismas, and now have the unfortunate fact that I am now mining with some of my hashrate on GHash.io (I'd never even created an account with them before).

Would it be possible, since ASICMiner apparently is clueless on how to properly handle vardiff, to add a setting to an Eligius account that allows the miner to set a default minimum difficulty? I set the GHash.io difficulty to 1024 and it's working smoothly (other than the very frequent hardware issues). However the gear does nothing when pointed at Eligius.

I plan on setting up a bfgminer stratum proxy in the hopes that by manually setting -it's- difficulty, I can sanitize the traffic so I can mine on Eligius again. In the meantime, and for users who aren't quite as well equiped to do stuff like that, having the option to use a fixed minimum difficulty instead of vardiff would be nice.

I know ASICMiner needs to fix their miners and their controllers, but I can't control that, so I wanted to address it here in the hopes that it might be an easy(ish) fix, so I don't have to mine on GHash any longer than is absolutely necessary!

[mavericklm]

Fuck ghash! anything else is beter!

Can we buy some luck? somewhere?
damn!

[mdude77]

So I recently acquired some Prismas, and now have the unfortunate fact that I am now mining with some of my hashrate on GHash.io (I'd never even created an account with them before).

Would it be possible, since ASICMiner apparently is clueless on how to properly handle vardiff, to add a setting to an Eligius account that allows the miner to set a default minimum difficulty? I set the GHash.io difficulty to 1024 and it's working smoothly (other than the very frequent hardware issues). However the gear does nothing when pointed at Eligius.

I plan on setting up a bfgminer stratum proxy in the hopes that by manually setting -it's- difficulty, I can sanitize the traffic so I can mine on Eligius again. In the meantime, and for users who aren't quite as well equiped to do stuff like that, having the option to use a fixed minimum difficulty instead of vardiff would be nice.

I know ASICMiner needs to fix their miners and their controllers, but I can't control that, so I wanted to address it here in the hopes that it might be an easy(ish) fix, so I don't have to mine on GHash any longer than is absolutely necessary!

Slush's stratum miner will work too.

But be mindful how you do it.  If your proxy only passes on shares of size 1024, and the pool you mining at is expecting 128, you won't get proper credit.  If you have other non ASICminer hardware that works properly at lower difficulties, point them at your proxy to get the difficulty ramped up, then point your Prismas at your proxy.

M

[praeluceo]

So I recently acquired some Prismas, and now have the unfortunate fact that I am now mining with some of my hashrate on GHash.io (I'd never even created an account with them before).

Would it be possible, since ASICMiner apparently is clueless on how to properly handle vardiff, to add a setting to an Eligius account that allows the miner to set a default minimum difficulty? I set the GHash.io difficulty to 1024 and it's working smoothly (other than the very frequent hardware issues). However the gear does nothing when pointed at Eligius.

I plan on setting up a bfgminer stratum proxy in the hopes that by manually setting -it's- difficulty, I can sanitize the traffic so I can mine on Eligius again. In the meantime, and for users who aren't quite as well equiped to do stuff like that, having the option to use a fixed minimum difficulty instead of vardiff would be nice.

I know ASICMiner needs to fix their miners and their controllers, but I can't control that, so I wanted to address it here in the hopes that it might be an easy(ish) fix, so I don't have to mine on GHash any longer than is absolutely necessary!

Slush's stratum miner will work too.

But be mindful how you do it.  If your proxy only passes on shares of size 1024, and the pool you mining at is expecting 128, you won't get proper credit.  If you have other non ASICminer hardware that works properly at lower difficulties, point them at your proxy to get the difficulty ramped up, then point your Prismas at your proxy.

M

Yeah, that's a really good idea! I'll toss my S3s behind it too to soak up the low-difficulty work. I wonder what the optimum ratio would be. Obviously optimum is for AM to actually build functional hardware and offer customer support, but barring that. I wonder if the stratum proxy allows per-worker difficulty? So I can set the Prisma worker as 1024 or higher, and let the S3s float. Or is the proxy even smart enough to do QoS and distribute the higher difficulty shares to the Prismas, while relegating everything lower to the S3s?

I've used Slush's stratum_proxy before, but I like bfgminer better, not just because of its ties to Eligius, but because it offers a lot more functionality and settings I can tweak. We're looking to perform load-balancing on specific pools with varying percentages of the overall hashrate, and also looking to feed each worker with different difficulty work.

[baddw]

So I recently acquired some Prismas, and now have the unfortunate fact that I am now mining with some of my hashrate on GHash.io (I'd never even created an account with them before).

Would it be possible, since ASICMiner apparently is clueless on how to properly handle vardiff, to add a setting to an Eligius account that allows the miner to set a default minimum difficulty? I set the GHash.io difficulty to 1024 and it's working smoothly (other than the very frequent hardware issues). However the gear does nothing when pointed at Eligius.

I plan on setting up a bfgminer stratum proxy in the hopes that by manually setting -it's- difficulty, I can sanitize the traffic so I can mine on Eligius again. In the meantime, and for users who aren't quite as well equiped to do stuff like that, having the option to use a fixed minimum difficulty instead of vardiff would be nice.

I know ASICMiner needs to fix their miners and their controllers, but I can't control that, so I wanted to address it here in the hopes that it might be an easy(ish) fix, so I don't have to mine on GHash any longer than is absolutely necessary!

Slush's stratum miner will work too.

But be mindful how you do it.  If your proxy only passes on shares of size 1024, and the pool you mining at is expecting 128, you won't get proper credit.  If you have other non ASICminer hardware that works properly at lower difficulties, point them at your proxy to get the difficulty ramped up, then point your Prismas at your proxy.

M

Yeah, that's a really good idea! I'll toss my S3s behind it too to soak up the low-difficulty work. I wonder what the optimum ratio would be. Obviously optimum is for AM to actually build functional hardware and offer customer support, but barring that. I wonder if the stratum proxy allows per-worker difficulty? So I can set the Prisma worker as 1024 or higher, and let the S3s float. Or is the proxy even smart enough to do QoS and distribute the higher difficulty shares to the Prismas, while relegating everything lower to the S3s?

I've used Slush's stratum_proxy before, but I like bfgminer better, not just because of its ties to Eligius, but because it offers a lot more functionality and settings I can tweak. We're looking to perform load-balancing on specific pools with varying percentages of the overall hashrate, and also looking to feed each worker with different difficulty work.

Re: "distributing" higher difficulty shares.

You are thinking about it wrong.  All Bitcoin mining is the same difficulty to begin with.  It's no harder to hash a block with a given nonce than any other given nonce.  It's only the results that can be given a 'difficulty score' after the fact.

It's like if you are forced to roll dice all day.  Say you are told to roll a single die over and over again, and write down your results.  But the person only wants you to report rolls of 5 or above, and to discard rolls of 4 or less.  So your "dice rolling difficulty level" is 5, and your taskmaster can extrapolate how many times you actually rolled, period, from how many times you rolled 5 or above.  (By simply tripling the reported number in this simple case.) 

But it's no more "difficult" for your hand to roll a 1 or a 6.  It's the same process either way.  "Pool difficulty" in Bitcoin is simply a filtering mechanism so that you aren't reporting every single result to the pool, in order to save computing resources and bandwidth.  So what the proxy does is actually strip away the 256-difficulty results instead of passing them on to the pool.  It only lets the 1024-difficulty (or higher) results pass.

[praeluceo]

Yeah, that's a really good idea! I'll toss my S3s behind it too to soak up the low-difficulty work. I wonder what the optimum ratio would be. Obviously optimum is for AM to actually build functional hardware and offer customer support, but barring that. I wonder if the stratum proxy allows per-worker difficulty? So I can set the Prisma worker as 1024 or higher, and let the S3s float. Or is the proxy even smart enough to do QoS and distribute the higher difficulty shares to the Prismas, while relegating everything lower to the S3s?

I've used Slush's stratum_proxy before, but I like bfgminer better, not just because of its ties to Eligius, but because it offers a lot more functionality and settings I can tweak. We're looking to perform load-balancing on specific pools with varying percentages of the overall hashrate, and also looking to feed each worker with different difficulty work.

Re: "distributing" higher difficulty shares.

You are thinking about it wrong.  All Bitcoin mining is the same difficulty to begin with.  It's no harder to hash a block with a given nonce than any other given nonce.  It's only the results that can be given a 'difficulty score' after the fact.

It's like if you are forced to roll dice all day.  Say you are told to roll a single die over and over again, and write down your results.  But the person only wants you to report rolls of 5 or above, and to discard rolls of 4 or less.  So your "dice rolling difficulty level" is 5, and your taskmaster can extrapolate how many times you actually rolled, period, from how many times you rolled 5 or above.  (By simply tripling the reported number in this simple case.) 

But it's no more "difficult" for your hand to roll a 1 or a 6.  It's the same process either way.  "Pool difficulty" in Bitcoin is simply a filtering mechanism so that you aren't reporting every single result to the pool, in order to save computing resources and bandwidth.  So what the proxy does is actually strip away the 256-difficulty results instead of passing them on to the pool.  It only lets the 1024-difficulty (or higher) results pass.
[/quote]

Okay, so perhaps I'm misunderstanding how vardiff works, I thought you could request specific difficulties from the server, or it would provide them until you stopped solving them in a reasonable period of time, and then only issue blocks that are at or below your most reasonable share submission rate. So couldn't the proxy request blocks for which the pool has determined they will represent a higher difficulty? I didn't realize diff was calculated after "the dice roll", I thought it had something to do with how the work was parted out by the pool. It doesn't seem that the Prismas handle Extranonce2_size correctly and when it's too low, it just drops it for some reason, and so the pool never decides to send the higher difficulty shares.

From:
https://www.btcguild.com/new_protocol.php
http://support.bitcoin.cz/Knowledgebase/Article/View/2/1/how-does-vardiff-work

But I am very much a novice with all this!

[baddw]

Yeah, that's a really good idea! I'll toss my S3s behind it too to soak up the low-difficulty work. I wonder what the optimum ratio would be. Obviously optimum is for AM to actually build functional hardware and offer customer support, but barring that. I wonder if the stratum proxy allows per-worker difficulty? So I can set the Prisma worker as 1024 or higher, and let the S3s float. Or is the proxy even smart enough to do QoS and distribute the higher difficulty shares to the Prismas, while relegating everything lower to the S3s?

I've used Slush's stratum_proxy before, but I like bfgminer better, not just because of its ties to Eligius, but because it offers a lot more functionality and settings I can tweak. We're looking to perform load-balancing on specific pools with varying percentages of the overall hashrate, and also looking to feed each worker with different difficulty work.

Re: "distributing" higher difficulty shares.

You are thinking about it wrong.  All Bitcoin mining is the same difficulty to begin with.  It's no harder to hash a block with a given nonce than any other given nonce.  It's only the results that can be given a 'difficulty score' after the fact.

It's like if you are forced to roll dice all day.  Say you are told to roll a single die over and over again, and write down your results.  But the person only wants you to report rolls of 5 or above, and to discard rolls of 4 or less.  So your "dice rolling difficulty level" is 5, and your taskmaster can extrapolate how many times you actually rolled, period, from how many times you rolled 5 or above.  (By simply tripling the reported number in this simple case.) 

But it's no more "difficult" for your hand to roll a 1 or a 6.  It's the same process either way.  "Pool difficulty" in Bitcoin is simply a filtering mechanism so that you aren't reporting every single result to the pool, in order to save computing resources and bandwidth.  So what the proxy does is actually strip away the 256-difficulty results instead of passing them on to the pool.  It only lets the 1024-difficulty (or higher) results pass.

Okay, so perhaps I'm misunderstanding how vardiff works, I thought you could request specific difficulties from the server, or it would provide them until you stopped solving them in a reasonable period of time, and then only issue blocks that are at or below your most reasonable share submission rate. So couldn't the proxy request blocks for which the pool has determined they will represent a higher difficulty? I didn't realize diff was calculated after "the dice roll", I thought it had something to do with how the work was parted out by the pool. It doesn't seem that the Prismas handle Extranonce2_size correctly and when it's too low, it just drops it for some reason, and so the pool never decides to send the higher difficulty shares.

From:
https://www.btcguild.com/new_protocol.php
http://support.bitcoin.cz/Knowledgebase/Article/View/2/1/how-does-vardiff-work

But I am very much a novice with all this!

Vardiff is just the pool scaling the minimum allowable difficulty for your miners to report to it.  It is based on your hashrate, and scales up based on results from a low baseline.

For example, say your initial connection to the pool is at difficulty 16.  (I think that Eligius did this earlier this year... not sure what the current initial/minimum difficulty is now.)  So the pool only wants you to send back shares that meet the difficulty threshold of 16.  You have some pretty fast miners, so you send in a bunch of difficulty 16 (or higher) shares to the pool very quickly.  The pool says "woah woah woah, this is too much" and scales up your difficulty to 128.  So now you are only sending shares of difficulty 128 or higher.  This scales you to the rate that the pool wants you to report (e.g. a few times per minute).

So you are mining along at this rate and then you add a couple of new, powerful miners to your setup.  These new machines are kicking out difficulty-128+ shares every second or two.  So the pool scales you up again to difficulty 1024.  Now you are sending difficulty-1024+ shares a few times a minute.

I used the dice-rolling analogy for a reason.  The pool has no idea what the difficulty a given piece of work will be before you crunch it, just as you have no idea how a dice will roll before you roll it.  There is no way for the "blocks for which the pool has determined they will represent a higher difficulty" to exist... if they did, then the pool would have already done the hashing and would have no reason to give it to you!  Of course, if you have a high hashrate then the pool will give you larger chunks of work to process (bigger nonce range) so you don't run out too fast, but that's different from the difficulty setting.

A nonce is just a random string of characters.  The way that hashing works, a change of 1 bit in the input results in greater than half of the bits of the output flipping.  So a block with nonce 000000001 will give a hash that looks completely different than the block with nonce 000000002.  (More than half of the hash string will be different.)  The one with nonce 000000001 might have a difficulty of 1 while the one with nonce 000000002 might have a difficulty of 10 billion.  And it is impossible to tell beforehand.  That's the nature of hashing (and, BTW, what makes the whole thing secure).

Vardiff is just determining what level of difficulty results will be reported/'shared' back to the pool.  If the pool thinks that you are at difficulty 256 but your miners are set at difficulty 1024, then you will be underpaid by 1/4 because you are only reporting about 1/4 of the work that you're doing.  If the pool wants you at difficulty 1024 but your miners only go to 256, then (I guess?) the pool will cut you off because it doesn't want you spamming with 256 difficulty shares.  (Might be dependent upon specific implementation of the pool.)  When you "request a difficulty from the pool" then you are simply requesting it to set your minimum difficulty at a given level.  It has nothing to do with the work that you are given.

All of that being said, you don't really have to understand all of the above in order to fix your problem.  IMHO Setting up a proxy is the way to go here.  It will act as a filter for your miners and hopefully handle the vardiff negotiations correctly.  But others will be better informed than I.  I never reached the scale of mining where I had to worry about this stuff.

[praeluceo]

Vardiff is just the pool scaling the minimum allowable difficulty for your miners to report to it.  It is based on your hashrate, and scales up based on results from a low baseline.

For example, say your initial connection to the pool is at difficulty 16.  (I think that Eligius did this earlier this year... not sure what the current initial/minimum difficulty is now.)  So the pool only wants you to send back shares that meet the difficulty threshold of 16.  You have some pretty fast miners, so you send in a bunch of difficulty 16 (or higher) shares to the pool very quickly.  The pool says "woah woah woah, this is too much" and scales up your difficulty to 128.  So now you are only sending shares of difficulty 128 or higher.  This scales you to the rate that the pool wants you to report (e.g. a few times per minute).

So you are mining along at this rate and then you add a couple of new, powerful miners to your setup.  These new machines are kicking out difficulty-128+ shares every second or two.  So the pool scales you up again to difficulty 1024.  Now you are sending difficulty-1024+ shares a few times a minute.

I used the dice-rolling analogy for a reason.  The pool has no idea what the difficulty a given piece of work will be before you crunch it, just as you have no idea how a dice will roll before you roll it.  There is no way for the "blocks for which the pool has determined they will represent a higher difficulty" to exist... if they did, then the pool would have already done the hashing and would have no reason to give it to you!  Of course, if you have a high hashrate then the pool will give you larger chunks of work to process (bigger nonce range) so you don't run out too fast, but that's different from the difficulty setting.

A nonce is just a random string of characters.  The way that hashing works, a change of 1 bit in the input results in greater than half of the bits of the output flipping.  So a block with nonce 000000001 will give a hash that looks completely different than the block with nonce 000000002.  (More than half of the hash string will be different.)  The one with nonce 000000001 might have a difficulty of 1 while the one with nonce 000000002 might have a difficulty of 10 billion.  And it is impossible to tell beforehand.  That's the nature of hashing (and, BTW, what makes the whole thing secure).

Vardiff is just determining what level of difficulty results will be reported/'shared' back to the pool.  If the pool thinks that you are at difficulty 256 but your miners are set at difficulty 1024, then you will be underpaid by 1/4 because you are only reporting about 1/4 of the work that you're doing.  If the pool wants you at difficulty 1024 but your miners only go to 256, then (I guess?) the pool will cut you off because it doesn't want you spamming with 256 difficulty shares.  (Might be dependent upon specific implementation of the pool.)  When you "request a difficulty from the pool" then you are simply requesting it to set your minimum difficulty at a given level.  It has nothing to do with the work that you are given.

All of that being said, you don't really have to understand all of the above in order to fix your problem.  IMHO Setting up a proxy is the way to go here.  It will act as a filter for your miners and hopefully handle the vardiff negotiations correctly.  But others will be better informed than I.  I never reached the scale of mining where I had to worry about this stuff.

Thank you for the detailed answer, that does make sense. This isn't as much a scale issue though, as a misimplemented miner (although with the number of these things I purchased, it is also a scale issue).

Luckily, we swapped out the BE controller today for a simple raspberry pi running cgminer, and it is now submitting correct requests to Eligius and we're mining successfully! It hasn't even been 3 hours yet though, so we'll see after 12 hours how stable it ends up being, but so far, it looks great! I have 2 S3s and 3 Prismas right now, if you want to see how just the Prismas look (the S3s are rented out right now) you can see the graph here:

http://eligius.st/~wizkid057/newstats/userstats.php/1LzrnS91BvE9KVeKZSYyWBgXF3YHTZYCN1

These machines have been dogs to get running. But it's cold outside, and our power and controller are stable, so hopefully with the latest patches applied to cgminer, these guys will be mining reliably for the foreseeable future (which is, until I can sell them!)

No more GHash, yay!

[sorry2xs]

is the pool under ddos

[praeluceo]

is the pool under ddos

no

[mavericklm]

problem with the payout queue?

[Biffa]

Well stats stopped updating around 8 hours ago, but thats the middle of the night for the Elgius crew so give wiz a few hours to get up and I'm sure it'll be fine after a bit of a kicking

[mavericklm]

no stress! just seen it.
payment to wallet and hash rate is normal

[wizkid057]

Looks like one of my maintenance scripts had a minor issue overnight.  Fixed the problem and running maintenance again.  Should be all fixed in a couple of hours.

Pool is fine, was just a stats issue.

[praeluceo]

Looks like one of my maintenance scripts had a minor issue overnight.  Fixed the problem and running maintenance again.  Should be all fixed in a couple of hours.

Pool is fine, was just a stats issue.

No worries, thanks for all of your hard work on our pool Wizkid!

[kenj]

is namecoin working again

I received a payout recently.

M

Hello
How come that i never seen a namecoin payout since I started mining at Eligius??
I started about three month´s ago with app 1TH/s, and two month´s with merged mining.
And my signature was fine so no probs there.