[OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #

[Luke-Jr]

I really like Eligius, but concerned that we have received no further word from Luke-Jr or WizKid. Their last post was 24+ hrs ago, and they didn't really have any useful info Do they care?

Unfortunately, I have no updates. I suspect our current server's host is at fault for at least some of these problems.
We have been working on setting up a new server - originally just for testing out upgrades, but if Hetzner is going to be failboat, we may just have to move entirely.

Edit: Part of the reason I suspect Hetzner is that in the process of trying to move the webserver, I am seeing a bottleneck limiting upload to like 20-30 kB/s to the new server. This is clearly way lower than we should be getting.

[BitMinerN8]

I really like Eligius, but concerned that we have received no further word from Luke-Jr or WizKid. Their last post was 24+ hrs ago, and they didn't really have any useful info Do they care?

Unfortunately, I have no updates. I suspect our current server's host is at fault for at least some of these problems.
We have been working on setting up a new server - originally just for testing out upgrades, but if Hetzner is going to be failboat, we may just have to move entirely.

Edit: Part of the reason I suspect Hetzner is that in the process of trying to move the webserver, I am seeing a bottleneck limiting upload to like 20-30 kB/s to the new server. This is clearly way lower than we should be getting.

Thanks for the update.

[BitMinerN8]

I also am seeing a stat that has issues, under "Estimated Position in Payout Queue" ... Maintaining your 3 hour hashrate average, this will take at least another 13 hours and 33 minutes at current network difficulty of 10076292.88.

The hours keep increasing, even though I have maintained my current hashrate for almost 2 days now. 

[klotzenhotz]

I also am seeing a stat that has issues, under "Estimated Position in Payout Queue" ... Maintaining your 3 hour hashrate average, this will take at least another 13 hours and 33 minutes at current network difficulty of 10076292.88.

The hours keep increasing, even though I have maintained my current hashrate for almost 2 days now.  

The same here. I'm working for the last missing 0.02 BTC to payout for three days with almost 400 MHash... usually this should be done in a single day.

Update: No progress, but suddenly "Error: Username xxxxxxxx not found in database".

[Subo1977]

Any Updates for the Problems ?

[Luke-Jr]

We're working on provisioning a new poolserver ASAP - wizkid057 has to be gone for a bit, so I'll probably be finishing it up.

On a side note, I created a bugfix for the poclbm (GUIMiner) bug with stratum, but m0mchil refuses to merge the fix.
If you prefer poclbm and/or stratum, you can post your complaint/encouragement here...

[nathanrees19]

We're working on provisioning a new poolserver ASAP - wizkid057 has to be gone for a bit, so I'll probably be finishing it up.

On a side note, I created a bugfix for the poclbm (GUIMiner) bug with stratum, but m0mchil refuses to merge the fix.
If you prefer poclbm and/or stratum, you can post your complaint/encouragement here...

Your pool sends a fractional difficulty below 1 and you have the nerve to say that poclbm is broken?

[Luke-Jr]

We're working on provisioning a new poolserver ASAP - wizkid057 has to be gone for a bit, so I'll probably be finishing it up.

On a side note, I created a bugfix for the poclbm (GUIMiner) bug with stratum, but m0mchil refuses to merge the fix.
If you prefer poclbm and/or stratum, you can post your complaint/encouragement here...

Your pool sends a fractional difficulty below 1 and you have the nerve to say that poclbm is broken?

It sends standard pdifficulty 1, as close as stratum allows approximating it.
poclbm doesn't send any shares meeting the difficulty set as it should per the stratum protocol, so yes, it is broken.

[nathanrees19]

standard pdifficulty

pdifficulty is not the standard.

[Luke-Jr]

standard pdifficulty

pdifficulty is not the standard.

Not sure where you've been mining all this time, but until very recently, all pools used pdifficulty 1.
In any case, Eligius is completely stratum-spec-compliant here.

[roy7]

https://en.bitcoin.it/wiki/Difficulty

Pools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard?

[Luke-Jr]

https://en.bitcoin.it/wiki/Difficulty

Pools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard?

There's two different standards, but bdiff only makes sense in the context of Bitcoin because of its floating-point block target.
Pdiff makes more sense for pools, miners, and blockchain-independent difficulty measurements, especially since it can be easily compressed down to a single byte (by counting the number of zero bits).

[nathanrees19]

standard pdifficulty

pdifficulty is not the standard.

Not sure where you've been mining all this time, but until very recently, all pools used pdifficulty 1.
In any case, Eligius is completely stratum-spec-compliant here.

The spec doesn't specify a minimum difficulty, but you'll note that the default difficulty is 1, not 0.9999847412109375, making 1 an implied minimum.

[nathanrees19]

https://en.bitcoin.it/wiki/Difficulty

Pools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard?

This exactly.

[nathanrees19]

especially since it can be easily compressed down to a single byte (by counting the number of zero bits).

In other words, pdiff is a hack.

[roy7]

especially since it can be easily compressed down to a single byte (by counting the number of zero bits).

In other words, pdiff is a hack.

slush called it a mistake everyone copied from him.

[Tia]

https://en.bitcoin.it/wiki/Difficulty

Pools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard?

There's two different standards, but bdiff only makes sense in the context of Bitcoin because of its floating-point block target.
Pdiff makes more sense for pools, miners, and blockchain-independent difficulty measurements, especially since it can be easily compressed down to a single byte (by counting the number of zero bits).

I am not fully comprehending the difference you suggest between a Pdiff of some number close to 1 (but technically under it) vs. 1 vs. bdiff  What difference does having Pdiff less than one vs. not? There must be some reason you'd want to do it that way, so out with it in layman's terms please. 

[Luke-Jr]

https://en.bitcoin.it/wiki/Difficulty

Pools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard?

There's two different standards, but bdiff only makes sense in the context of Bitcoin because of its floating-point block target.
Pdiff makes more sense for pools, miners, and blockchain-independent difficulty measurements, especially since it can be easily compressed down to a single byte (by counting the number of zero bits).

I am not fully comprehending the difference you suggest between a Pdiff of some number close to 1 (but technically under it) vs. 1 vs. bdiff  What difference does having Pdiff less than one vs. not? There must be some reason you'd want to do it that way, so out with it in layman's terms please. 

Pdiff 1 = target 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, or 32 zero-bits
Pdiff 2 = target 0x000000007FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, or 33 zero-bits
Pdiff 4 = target 0x000000003FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, or 34 zero-bits
etc

But Bitcoin stores the target in a floating-point number type with 23 bits of precision, so it truncates them:

Bdiff 1 = target 0x00000000FFFF0000000000000000000000000000000000000000000000000000
Bdiff 2 = target 0x000000007FFF0000000000000000000000000000000000000000000000000000
Bdiff 4 = target 0x000000003FFF0000000000000000000000000000000000000000000000000000
etc

[Luke-Jr]

especially since it can be easily compressed down to a single byte (by counting the number of zero bits).

In other words, pdiff is a hack.

On the contrary, bdiff is a hack.

Anyhow, the point is that poclbm has this bug that affects any pool that wants to continue using the standard pdiff 1 target.

[roy7]

On the contrary, bdiff is a hack.

Anyhow, the point is that poclbm has this bug that affects any pool that wants to continue using the standard pdiff 1 target.

Yes it's a hack, but it's the hack used by bitcoind so it's sort of the standard (one could argue correct) way to represent the numbers.

Yes, poclbm should gracefully handle it. But also eloipool could handle it by serving out 1 in this special case and use pdiff for any higher figures. When sending the value to the client, just ceil(pdiff,1.0) it? Call it a workaround for poclbm or whatever. Or check client name for poclbm and only serve it to them.

The other option is that you and the poclbm author both refuse to provide a work around and then no one wins, but all poclbm users trying to mine at eloipool pools lose.