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

[dbbit]

I read somewhere that with the _workername change, there is an issue with the VARDIFF being individually calculated rather than aggregated (though I think it should be individually calculated, but anyway).


However...

My miners were all running at "diff 16", so I've changed all of them from just being ADDRESS to ADDRESS_worker about 30 minutes ago specifically so that they don't aggregate.

But now it's just submitting "diff 0" shares according to mining_proxy. (What is a "diff 0" difficulty anyway - never seen that before?).


The minimum that I've set it to in the configuration UI is 8. Of course, that's set for ADDRESS and not ADDRESS_worker, so I'm not sure whether the UI option is supposed to work, but either way, I did expect VARDIFF to automatically update to around 8 by now for my new "ADDRESS_worker" style shares.

How long does it take for Eligius's VARDIFF to update?

[HellDiverUK]

With 30GH/s going through BFGMiner to Eligius, it takes a few minutes to go from Diff 0 to Diff 8 - BFG complains about work underruns, and then difficulty seems to go up.  How it works I don't know.

[dbbit]

As of right now, each worker's variable difficulty is calculated individually, so, your workers will likely get lower difficulty work when they're split up, for now... Luke-Jr is working on an update to the

It's on mining_proxy, not BFGMINER (the actual miner itself is an ASICMINER blade). It's still showed "Diff 0" after almost 3 hours.

I just tried logging in again as 'ADDRESS' instead of 'ADDRESS_worker'.

In that case VARDIFF updates within a couple of minutes. Switching back to 'ADDRESS_worker' and it stays at 0-ish (see-below).

As of right now, each worker's variable difficulty is calculated individually, so, your workers will likely get lower difficulty work when they're split up, for now... Luke-Jr is working on an update to the

So it seems like the 'ADDRESS_worker' configuration has a larger bug that this - it's not just that it will only calculate individually, it won't update VARDIFF at all, staying at 1.



As far as my difficulty display of "0" is concerned, it is actually 1. For small values of 1...

Setting new difficulty: 0.999984741211
Setting new difficulty: 3.99993896484
Ughm. Doing our floating point math on a Pentium, are we? 

When it gets up to 8 however, it works:
Setting new difficulty: 8

Not sure if this is an Eligius bug or a mining_proxy bug. However, neither Slush nor BTCGuild shows a non-integer difficulty update on the same mining_proxy software.

[Luke-Jr]

As far as my difficulty display of "0" is concerned, it is actually 1. For small values of 1...

Setting new difficulty: 0.999984741211
Setting new difficulty: 3.99993896484
Ughm. Doing our floating point math on a Pentium, are we?  

When it gets up to 8 however, it works:
Setting new difficulty: 8

Not sure if this is an Eligius bug or a mining_proxy bug. However, neither Slush nor BTCGuild shows a non-integer difficulty update on the same mining_proxy software.

It's a "bug" in the stratum protocol, which use bdifficulty instead of pdifficulty.
Pdifficulty 1 (standard for pools) is defined as a target with 32 leading zero bits.
Bdifficulty 1 is the same, after being truncated in a 24+8 bit floating point format ("bits", also used in blocks).
Eligius uses pdifficulty, since it can be stored cleanly in 4 bits instead of 32 (remember it needs to store the difficulty for every share).

BFGMiner also consistently displays pdifficulty correctly.

[dbbit]

It's a "bug" in the stratum protocol, which use bdifficulty instead of pdifficulty.
Pdifficulty 1 (standard for pools) is defined as a target with 32 leading zero bits.
Bdifficulty 1 is the same, after being truncated in a 24+8 bit floating point format ("bits", also used in blocks).
Eligius uses pdifficulty, since it can be stored cleanly in 4 bits instead of 32 (remember it needs to store the difficulty for every share).

BFGMiner also consistently displays pdifficulty correctly.

That makes perfect sense. Thanks!

Ok, so I have more news on the 'ADDRESS' vs. 'ADDRESS_worker' issue.

It seems what happens is this:
a) If I funnel 4 blades through 1 stratum/getwork proxy server with 4 different user accounts *, I get the issue where they all stay at difficulty "1".
b) If I funnel 4 blades through 1 stratum/getwork proxy server with the same user account, they'll VARDIFF up to 16.
c) If I use 1 proxy server per blade under 1 user account, everything works fine, and they VARDIFF up to 4 or 8 within a few minutes.

* Actually, I've only tried different workers - don't know yet what will happen with multiple wallet addresses. I'll try that next.

So it seems like somehow the pool doesn't like multiple user accounts coming from a single (IP+Port) endpoint. Other pools also don't really work great with this, e.g. BTCGuild & Slush will ignore the individual user accounts, and just VARDIFF you on the overall endpoint. Eligius is unique though by not adjusting the VARDIFF at all in the single ENDPOINT-multiple users case.

I've worked around it for now, but I am running a free Stratum/Getwork cloud-based proxy currently for BTCGuild + Slush. I'd like to open it up to Eligius, but can't do that if there can't be multiple users per endpoint. Otherwise all my users will get a "1" difficulty.

[Luke-Jr]

Ok, so I have more news on the 'ADDRESS' vs. 'ADDRESS_worker' issue.

It seems what happens is this:
a) If I funnel 4 blades through 1 stratum/getwork proxy server with 4 different user accounts *, I get the issue where they all stay at difficulty "1".
b) If I funnel 4 blades through 1 stratum/getwork proxy server with the same user account, they'll VARDIFF up to 16.
c) If I use 1 proxy server per blade under 1 user account, everything works fine, and they VARDIFF up to 4 or 8 within a few minutes.

This is behaving exactly as I would expect.
Stratum doesn't "really" support multiple users on a single connection: it uses the same jobs and difficulty for all of them.
While the jobs are easily split up by your proxy, there is simply no way to express different difficulties per user/worker.
Since Eloipool tracks difficulty per user/worker, it doesn't even try and always sends the (pool's) minimum difficulty if there are multiple users/workers on a connection.
The only reasonable solution I can see to this problem, is to use the lowest difficulty of all users.

* Actually, I've only tried different workers - don't know yet what will happen with multiple wallet addresses. I'll try that next.

Eloipool doesn't know or care whether two usernames have the same address or not.

[amer]

That makes perfect sense. Thanks!

Ok, so I have more news on the 'ADDRESS' vs. 'ADDRESS_worker' issue.

It seems what happens is this:
a) If I funnel 4 blades through 1 stratum/getwork proxy server with 4 different user accounts *, I get the issue where they all stay at difficulty "1".
b) If I funnel 4 blades through 1 stratum/getwork proxy server with the same user account, they'll VARDIFF up to 16.
c) If I use 1 proxy server per blade under 1 user account, everything works fine, and they VARDIFF up to 4 or 8 within a few minutes.

* Actually, I've only tried different workers - don't know yet what will happen with multiple wallet addresses. I'll try that next.

So it seems like somehow the pool doesn't like multiple user accounts coming from a single (IP+Port) endpoint. Other pools also don't really work great with this, e.g. BTCGuild & Slush will ignore the individual user accounts, and just VARDIFF you on the overall endpoint. Eligius is unique though by not adjusting the VARDIFF at all in the single ENDPOINT-multiple users case.

I've worked around it for now, but I am running a free Stratum/Getwork cloud-based proxy currently for BTCGuild + Slush. I'd like to open it up to Eligius, but can't do that if there can't be multiple users per endpoint. Otherwise all my users will get a "1" difficulty.

Sorry if this is a dumb question, but what exactly is wrong with option c? Is separate accounts per blade a requirement?

[dbbit]

Sorry if this is a dumb question, but what exactly is wrong with option c? Is separate accounts per blade a requirement?

It is fine when it's me alone. I just run one instance per blade and point each blade at a different proxy.

However, I am also experimenting with some cloud getwork->stratum proxy servers for other people to connect to. See:
https://bitcointalk.org/index.php?topic=292170.msg3127181#msg3127181

However, there isn't a way to automatically split incoming users to different proxies. So what happens is that people all tend to connect to the same port. It's slightly annoying with BTCGuild & Slush since it ends up with 128- or 256- difficulty proxies, but it would be MUCH worse if those proxies run at 1 (since I have to pay for the bandwidth). Hence, currently I can't open those cloud proxies for Eligius.

I guess I could create some sort of registration mechanism and give each user a different port, but that sounds too much like work...

I may also one day rewrite the proxy server to do per-user mapping (or rather do it a Stratum->Stratum redirect proxy once I understand the Stratum protocol better), but again I'm not quite there yet either.

I was just hoping for a quick fix to provide Eligius support in the mean time.

[tarui]

do I need to change anything for the Setting new difficulty for avalon?

[2GOOD]

lol now i saw this block:
http://eligius.st/~wizkid057/newstats/blockinfo.php/00000000000000074ef0fb6f18e367b64fee580b6590c7e14c6a93d594390474

so fast that it was not included in payment, too bad the next are way above diff.

I have a suggestion for wizkid057 and luke, if possible to make a differend Eligius Offline Wallet that way we'll have access to that information, because from the current address http://blockchain.info/address/18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B it is not clear what part of the funds are for the pool.

[mobile]

A while back I remember reading a couple of posts that were relative to this question. After searching the hell out of the forum with no luck, Ill feel better if I ask so its clear.

1)
In the [Configurable Options] section: after inputting data into the sections that are appropriate to me I Submit Changes and the page returns blank (as if I made no changes / default)  Now I am aware of the notice:

You may set all options now, and they will take effect as backend support is completed!

Which leads me to believe that my config'ed options were saved but not showing. Am I wrong?

One of the reasons I was concerned of these options not being saved is adjusting my minimum payout. I know there has been a lot of discussion on minimum payouts, payment queues and I do not want to invoke friction or be flammed by mentioning this or perhaps missing a post or something in the FAQ. This leads me to my second question.

2)
I am a small time miner, I set my minimum payout to the lowest allowed (0.01048576) Now that I have exceeded this minimum balance I am concerned that I am still set at the default minimum (0.16777216). I know it can take time to see your address in the payout queue etc, etc etc I have read all of that but having the Estimated Position in Payout Queue staring in my face telling me that I still have 0.15 left till payout which will take at least another 1 month, 3 weeks, 2 days and 6 hours at current network difficulty of 112628548.67 is disheartening and lead me to inquire with all of your fine folks.

Last and not least, special thanks to LukeJr and Wizkid for their hard work in this pool. Special thanks to all the contributors that answer questions to other in this thread. I enjoy following the thread and mining on this pool over other pools. The clean cut basic interface yet specific graphs was something that attracted me and much more. Cheers

[JakeTri]

In the [Configurable Options] section: after inputting data into the sections that are appropriate to me I Submit Changes and the page returns blank (as if I made no changes / default)

Did you signed the configuration message with your Bitcoin QT client ?
After you input the signed message and push the Submit Changes, did you got Signature passes! or Signature fails! on the top part of the page right after Welcome, <your bitcoin address> ?

[mobile]

In the [Configurable Options] section: after inputting data into the sections that are appropriate to me I Submit Changes and the page returns blank (as if I made no changes / default)

Did you signed the configuration message with your Bitcoin QT client ?
After you input the signed message and push the Submit Changes, did you got Signature passes! or Signature fails! on the top part of the page right after Welcome, <your bitcoin address> ?

I actually did not carry through in signing my address. I was more concerned with setting the minimum payout. Granted, at this rate (670 Mh/s) I will accumulate 0.15xxxBTC queued for payout in 2 months  . I have a feeling I should not worry (as it states this is all in BETA stage) but wanted to clarify. Thanks a lot...

[JakeTri]

In the [Configurable Options] section: after inputting data into the sections that are appropriate to me I Submit Changes and the page returns blank (as if I made no changes / default)

Did you signed the configuration message with your Bitcoin QT client ?
After you input the signed message and push the Submit Changes, did you got Signature passes! or Signature fails! on the top part of the page right after Welcome, <your bitcoin address> ?

I actually did not carry through in signing my address. I was more concerned with setting the minimum payout. Granted, at this rate (670 Mh/s) I will accumulate 0.15xxxBTC queued for payout in 2 months  . I have a feeling I should not worry (as it states this is all in BETA stage) but wanted to clarify. Thanks a lot...

The only way to save the settings is by signing the settings string with your address.

[mobile]

In the [Configurable Options] section: after inputting data into the sections that are appropriate to me I Submit Changes and the page returns blank (as if I made no changes / default)

Did you signed the configuration message with your Bitcoin QT client ?
After you input the signed message and push the Submit Changes, did you got Signature passes! or Signature fails! on the top part of the page right after Welcome, <your bitcoin address> ?

I actually did not carry through in signing my address. I was more concerned with setting the minimum payout. Granted, at this rate (670 Mh/s) I will accumulate 0.15xxxBTC queued for payout in 2 months  . I have a feeling I should not worry (as it states this is all in BETA stage) but wanted to clarify. Thanks a lot...

The only way to save the settings is by signing the settings string with your address.

Slightly stressful because I keep getting signature failed. I used a inputs.io addresss. Im pasting the data that lies in between the (-----BEGIN SIGNATURE----- data-----END BITCOIN SIGNED MESSAGE-----) in the signature section right?  Quite embarrassing granted this is elementary and Ive signed messages before. Anyways will have to play around with it a bit further. Thank you kindly...

I got it working. Not sure if its related but i unchecked the "Format Message" box and it worked. Thanks again!

[nox_]

Hey Wizkid and Luke-Jnr,

Been using Eligius for a few months now.

Just want to say - Great pool and great work! I'll send a donation over.

[donut]

What's going on today, 504 Gateway Timeout on the website?

[GrapeApe]

What's going on today, 504 Gateway Timeout on the website?

Yeah it seems like the website is down but shares are still being accepted so all is most likely fine. Wizkid057 will be on it soon enough.

[wizkid057]

What's going on today, 504 Gateway Timeout on the website?

Yeah it seems like the website is down but shares are still being accepted so all is most likely fine. Wizkid057 will be on it soon enough.

Web server is acting up. I'm going to migrate it to a better setup soon.

[GrapeApe]

Hey I was wondering what the formula should be for determining min. difficulty setting? For example if I mine at 10 GH/s what would be best min. diff. setting?