[ANN] CoinLab Protected Pool

[mckoss]

Ok I see what's wrong here. The expire= parameter with x-roll-ntime is how many seconds after the getwork is sent that the miner is allowed to roll time for... it is NOT how many "seconds of rolling equivalent" they're allowed to add to the timestamp. That should be limited only by what bitcoin would accept, which is a maximum of 7200 seconds.

The spec seems to imply (to me) BOTH the allowed values of the timestamp AND a deadline time for which they will be accepted.  As a practical matter, we even accept work with larger timestamp rolls as long as the block being worked on is still current.

[-ck]

Ok I see what's wrong here. The expire= parameter with x-roll-ntime is how many seconds after the getwork is sent that the miner is allowed to roll time for... it is NOT how many "seconds of rolling equivalent" they're allowed to add to the timestamp. That should be limited only by what bitcoin would accept, which is a maximum of 7200 seconds.

The spec seems to imply (to me) BOTH the allowed values of the timestamp AND a deadline time for which they will be accepted.  As a practical matter, we even accept work with larger timestamp rolls as long as the block being worked on is still current.

I suggest you ignore the timestamp entirely so long as it's within 2 hours of the getwork generation since that's how the spec is implemented by mining software and other pools alike.

[mckoss]

An update on our LONGPOLL experiment.

Please stop "experimenting" with the live pool.

Point taken.

Our pool has a guarantee of accepting work - even if it is stale - for a fixed amount of time from when we generated the work for the miner.  Right now, this
is set to 60 seconds.  This information is implied by our getwork headers:

I'm not sure why you guarantee aka pay for work if it is stale. I would rather you didn't and lowered your fee.

As for why some miners are working on really old work: This is most likely a problem with your long poll implementation.

Specifically I would look to see if your server is closing connections without sending any kind of response, aka timing out connections. cgminer is coded to keep a long poll connection open for 1 hour.

Our server is configured to allow longpolls to be held open for up to 90 minutes; after that the connection is dropped (and the client should see the dropped connection so it can re-establish it).  It's possible we have some other bug in our pool, but our median work age runs about 45 seconds - so it seems the majority of miners are having no problem getting recent work.  Regardless of long-poll connections dropping, our headers clearly indicate (to me) that the work should be refreshed each 60 seconds.  So even if we do have a bug where miners are silently having their long-polls dropped, they should be unilaterally fetching new getwork every 60 seconds.

As to the policy of accepting older work - we wanted to remove any consideration of communication latency being a barrier to adopting our pool.  We assume the risk of latency we introduce into the system - as a miner, you get credit for all work you do (as long as you get reasonably fresh work from us - i.e., no more than 60 seconds old).  We felt that places the incentives on us to improve our pool performance, but doesn't penalize miners when we have latency issues.

[mckoss]

Ok I see what's wrong here. The expire= parameter with x-roll-ntime is how many seconds after the getwork is sent that the miner is allowed to roll time for... it is NOT how many "seconds of rolling equivalent" they're allowed to add to the timestamp. That should be limited only by what bitcoin would accept, which is a maximum of 7200 seconds.

The spec seems to imply (to me) BOTH the allowed values of the timestamp AND a deadline time for which they will be accepted.  As a practical matter, we even accept work with larger timestamp rolls as long as the block being worked on is still current.

I suggest you ignore the timestamp entirely so long as it's within 2 hours of the getwork generation since that's how the spec is implemented by mining software and other pools alike.

We do.  The only thing we check is work age.  We measure how old the work we gave you is.  If it's stale, we still give you credit if it falls within our 60 second grace period.  So PLEASE DO send stale shares to us (but please also refresh your getworks each 60 seconds).  If you do both of those, I see no reason why miners on our pool would see anything but 0% stales.

[organofcorti]

We do.  The only thing we check is work age.  We measure how old the work we gave you is.  If it's stale, we still give you credit if it falls within our 60 second grace period.  So PLEASE DO send stale shares to us (but please also refresh your getworks each 60 seconds).  If you do both of those, I see no reason why miners on our pool would see anything but 0% stales.

What is the pool's stale rate?

[khminer]

Hi,

is there any issue withe the stats. My miner is up and running but my stats are not updaded for about to hours.

[TheHarbinger]

Hi,

is there any issue withe the stats. My miner is up and running but my stats are not updaded for about to hours.

Seeing the same thing here.  Stats are broken for sure, I hope the shares are still counting.

[shmadz]

Hi,

is there any issue withe the stats. My miner is up and running but my stats are not updaded for about to hours.

Seeing the same thing here.  Stats are broken for sure, I hope the shares are still counting.

ditto, stat chart shows several hours at 0 and my share total for the week is about 10% below expected.

funny thing is, I'm pretty sure that my miners were connected and working just fine. (It gets very cold and very quiet very quickly when they stop

[-ck]

Ok I see what's wrong here. The expire= parameter with x-roll-ntime is how many seconds after the getwork is sent that the miner is allowed to roll time for... it is NOT how many "seconds of rolling equivalent" they're allowed to add to the timestamp. That should be limited only by what bitcoin would accept, which is a maximum of 7200 seconds.

The spec seems to imply (to me) BOTH the allowed values of the timestamp AND a deadline time for which they will be accepted.  As a practical matter, we even accept work with larger timestamp rolls as long as the block being worked on is still current.

I suggest you ignore the timestamp entirely so long as it's within 2 hours of the getwork generation since that's how the spec is implemented by mining software and other pools alike.

We do.  The only thing we check is work age.  We measure how old the work we gave you is.  If it's stale, we still give you credit if it falls within our 60 second grace period.  So PLEASE DO send stale shares to us (but please also refresh your getworks each 60 seconds).  If you do both of those, I see no reason why miners on our pool would see anything but 0% stales.

Great And cgminer submits stale by default unless it has tried multiple times to submit it and the pool is unresponsive.

[mckoss]

Hi,

is there any issue withe the stats. My miner is up and running but my stats are not updaded for about to hours.

Seeing the same thing here.  Stats are broken for sure, I hope the shares are still counting.

ditto, stat chart shows several hours at 0 and my share total for the week is about 10% below expected.

funny thing is, I'm pretty sure that my miners were connected and working just fine. (It gets very cold and very quiet very quickly when they stop

I had a critical server go down twice this week - for a total of 9 hours (ouch - I know - our monitoring alerts also failed).  I found the problem with the server, and I was able to capture all the earned shares (though your online stats do not yet reflect the shares earned during in those two gaps - I hope to get that back up some time Sunday).

The server that went down was responsible for recording credits into our credits database.  I was able to recover data from our raw share reporting data store - it's just going to take me a little while to migrate it back into our credits database where you can see it again.

I hope you'll be patient with me.  I promise to recover the data that was lost - you'll be credited for every share earned (and we'll kick in some bonus credits to thank you for your patience).

[jjiimm_64]

Thanks Mike.

I switched back after the LP change and share/p/d counts have been pretty solid, although the json stats are borked i think..

[mckoss]

I just finished recovering credits for accounts that were mining during our two outages:

122.5 minutes in duration 2012-10-26 15:23:19 to 2012-10-26 17:25:48. (GMT)
Shares earned from Sat Oct 27 2012 11:57:00 GMT+0000 (UTC) to Sat Oct 27 2012 19:49:00 GMT+0000 (UTC).

I also fixed the root cause of our backend server crashes.

For those of you that were showing missing credits - you should be back to normal now - plus a little bit.  I added a 30% bonus on all shares reported during these credit outages just to make sure everyone is made whole.

If you still see a discrepancy not in your favor, please let us know and we can look more closely at your account.

Going to bed now...

- Mike

[jjiimm_64]

I just finished recovering credits for accounts that were mining during our two outages:

122.5 minutes in duration 2012-10-26 15:23:19 to 2012-10-26 17:25:48. (GMT)
Shares earned from Sat Oct 27 2012 11:57:00 GMT+0000 (UTC) to Sat Oct 27 2012 19:49:00 GMT+0000 (UTC).

I also fixed the root cause of our backend server crashes.

For those of you that were showing missing credits - you should be back to normal now - plus a little bit.  I added a 30% bonus on all shares reported during these credit outages just to make sure everyone is made whole.

If you still see a discrepancy not in your favor, please let us know and we can look more closely at your account.

Going to bed now...

- Mike

Thank you sir.

[TheHarbinger]

As much as I hate when a pool I'm on has a problem, with a 30% bonus being paid for when it does, I'm kind of hoping you guys have more problems for a longer period of time.   

Anyway, yeah, looks like the missing shares have been credited, and then some.

the holes in the stats went from...
                                                                                                                        _____
                                                                                                                        |      |
                                                                                                                        |      |
/\-/\-/\-/\-/\-|      |/\-\/-\/-\/-\/-\/-                  to                          /\-/\-/\-/\-/\-/\-|      |/\-/\/-\/-\/-\/-\/-\/
                   |      |                                                                                         
                   |      |
                   _____

[CoinLab]

Update:  We are not going to meet our previously predicted ship date of 11/1 for our custom HPC client.   It now looks like we'll need about another two weeks before we can release the Beta.  Sorry for the delay, this is our top priority and we're working hard on it!

[Transisto]

Update:  We are not going to meet our previously predicted ship date of 11/1 for our custom HPC client.   It now looks like we'll need about another two weeks before we can release the Beta.  Sorry for the delay, this is our top priority and we're working hard on it!

Does the release of the "beta" client signify the imminent end of mining only clients ?

What is the ETA on the termination of loyalty points program ?

[CoinLab]

Does the release of the "beta" client signify the imminent end of mining only clients ?

What is the ETA on the termination of loyalty points program ?

Once we've released our HPC client for Windows and Linux, we'll give miners a grace period of a few weeks to switch over their miners.  After that, miners will still be able to mine with any client, but will only be able to earn or redeem loyalty points with our client.

My rough ETA on when we'll require the switch would be mid-December. Our Loyalty Point program will continue after that, but it will only be accessible through our HPC client.

[jcpham]

I do not mind being a guinea pig to test/develop it when you are ready.

[yochdog]

I have several workers that are connected to coinlab, and claim to be submitting shares......but are not listed on the worker page.

Any ideas what is going on?  More importantly, where are the shares going? 

[CoinLab]

I have several workers that are connected to coinlab, and claim to be submitting shares......but are not listed on the worker page.

Any ideas what is going on?  More importantly, where are the shares going? 

We solved this issue, but the underlying cause hasn't been fixed yet.  If anyone has a high number of workers and isn't seeing an estimated hashrate for one of their workers, let me know and we can fix it manually in the mean time. Fix should be out in the next week or two - we're nose to the grindstone on the HPC client now.

Also, if you have linux machine(s) with NVIDIA cards, please send us a message telling us what models and how many you have. Our first HPC customer's current kernel (gene sequencing!) has a bug when run on AMDs.  We're going to try to get them to prioritize a fix on this, but we can get them online fastest if we can find 64 linux boxes with NVIDIA cards in them.  Thanks!