Continuum Mining Pool: No fees; Client uptime monitoring via twitter and email

[martok]

I have been able to login using "worker;payto" now for some reason.. Although I had tried quotes before and it was not working. My problem now is how do I get an accurate hashrate for the workers combined, as well as unconfirmed balance? If you do an rpc-call to the payment address, it does not properly display either clienthashrate(paytoaddr) or currentbalance(paytoaddr)

Should be fixed. You can now pass either a worker or payment address to balancecurrent or hashrate. For the confirmed balance though, you can only query the address that is to actually be paid (payto in your instance). If specific worker balances are needed, I can add a call for that at some point.

[1713579249]

1713579249

[1713579249]

1713579249

[1713579249]

1713579249

[Transcendental]

I can confirm that these functions are now operational, thanks.

[Etherael]

I've been mining for a while now with this poclbm invocation;

./poclbm.py -v -w 128 -d 0 --user 12DbPbfp2twBTfjSBW9QhVQ5PrGb2puisV0pps --pass any --host continuumpool.com --port 8332

The hashes are going through;

01/06/2011 14:30:01, 7869656a, accepted                     
01/06/2011 14:30:36, long poll: new block 00000648a0f3b516 
01/06/2011 14:31:49, b7c004ce, accepted                     
01/06/2011 14:31:53, e9698573, accepted                     
01/06/2011 14:32:09, bc9158e3, accepted                     
01/06/2011 14:32:20, 3988c4da, accepted                     
01/06/2011 14:32:40, e4c0a789, accepted                     
01/06/2011 14:32:49, 77ff441b, accepted                     
01/06/2011 14:33:19, bf329670, accepted                     
01/06/2011 14:34:56, b450a6a0, accepted                     
01/06/2011 14:35:07, 73f1a043, accepted       

However on the continuumpool page I am getting 0 for my hash rate and ?> for confirmed payouts at 12DbPbfp2twBTfjSBW9QhVQ5PrGb2puisV

Any idea what's going on here?

[Meni Rosenfeld]

For those wanting PPS payment, it is now live. Simply use yourpaymentaddress;pps or yourpaymentaddress0pps as the username. PPS miners will not affect regular miners and PPS carries a 5% expected fee. Regular mining is of course still at no fee. However, PPS was requested so there it is.

edit: PPS payout rate:
http://www.continuumpool.com/ppsrate.php
or preferably through the ppsrate RPC call.

edit: You can now pass a boolean pps (null by default) argument to hashrate.
pps => null = overall hashrate
pps => false regular miners only
pps => true only pps miners

I hope you have carefully evaluated the risks of PPS due to sabotage as well as normal variance. Tycho takes 10% for a reason.

Also, does "overall hash rate" include PPS miners? It would be more useful to know the hashrate of the score-based so we can know its variance.

However on the continuumpool page I am getting 0 for my hash rate and ?> for confirmed payouts at 12DbPbfp2twBTfjSBW9QhVQ5PrGb2puisV

Any idea what's going on here?

I don't know if that's the problem, but I noticed that when I copy-paste my address I often get a stray space which causes it to be unrecognized.

Note to martok - trim spaces from the input.

[martok]

Also, does "overall hash rate" include PPS miners? It would be more useful to know the hashrate of the score-based so we can know its variance.

Overall hashrate is currently only score-based miners as pps doesn't really factor into normal pool performance.

If PPS is abused, it will go away but will not affect the score-based payouts.

I don't know if that's the problem, but I noticed that when I copy-paste my address I often get a stray space which causes it to be unrecognized.

Note to martok - trim spaces from the input.

Indeed, will do.

[martok]

Btw, I am curious as to how useful publishing the share and score logs would be. Particularly whether that ensures pool integrity given that the worker solution is included. I would not be willing to publish the IP addresses of workers but could make previous round sharelog data available less IP address. So, would that be useful to anyone? Does anyone object IE are their privacy concerns here of which I am not aware?

[Etherael]

Tried an escaped ; as the separator, also tried a different address, still the same output from the pool side monitors..

Any other ideas? I was under the impression that if it wasn't registering the correct address, it wouldn't accept my hashes?

[Meni Rosenfeld]

I don't know if that's the problem, but I noticed that when I copy-paste my address I often get a stray space which causes it to be unrecognized.

Note to martok - trim spaces from the input.

Indeed, will do.

I noticed now that my comment may have been a little ambiguous - to clarify, I was referring to getting statistics from continuumpool.com, not to the miner flags.

Tried an escaped ; as the separator, also tried a different address, still the same output from the pool side monitors..

Any other ideas? I was under the impression that if it wasn't registering the correct address, it wouldn't accept my hashes?

Did you try it without pps? This should help narrow down the problem.

[martok]

Tried an escaped ; as the separator, also tried a different address, still the same output from the pool side monitors..

Any other ideas? I was under the impression that if it wasn't registering the correct address, it wouldn't accept my hashes?

Think I found you.
Are you mining now? Can you confirm balances are being updated?I will manually credit any previously submitted shares from my logs.

Edit: Credited 572 shares.

[Etherael]

Hey there martok,


./poclbm.py -v -w 128 -d 0 --user=1LLdCXQohpJcZpKrwGc9ebgfKrDanYuwKC\;pps --pass=any --host continuumpool.com --port 8332


Is the current invocation I'm using, I can't see a hashrate or balance for either the previous address or this one however.

Since you seem to be willing to just rollover my pool into the one we finally end up identifying I'll just leave this thing mining till we figure it out

[Etherael]

I can now see a hashrate being reported for 1LLdCXQohpJcZpKrwGc9ebgfKrDanYuwKC, that's good enough for me, I assume the balance probably won't show till > 1btc?

[martok]

I can now see a hashrate being reported for 1LLdCXQohpJcZpKrwGc9ebgfKrDanYuwKC, that's good enough for me, I assume the balance probably won't show till > 1btc?

Balance is updated in realtime. And now it is for PPS as well.
Your new address's balance should climb each time you submit a share.
Note that the hashrate is over a 5 minute window so if you haven't submitted a share within that window, it goes to 0.

[Etherael]

All good with balance updates now too, thanks very much for your help Martok, best of luck with your pool.

[Meni Rosenfeld]

Btw, I am curious as to how useful publishing the share and score logs would be. Particularly whether that ensures pool integrity given that the worker solution is included. I would not be willing to publish the IP addresses of workers but could make previous round sharelog data available less IP address. So, would that be useful to anyone? Does anyone object IE are their privacy concerns here of which I am not aware?

This is a very important issue. I think it will be very useful if you publish such logs. Ideally, for each completed round you would have a table of shares (maybe downloadable in csv format) with the following info: Share #ID, Timestamp, score (as a proportion of the total round score), worker Bitcoin address, hash.
In case people are uncomfortable with their addresses' payout info being displayed, you could show stats only for the shares submitted by the user. For this you will probably need some sort of login system.

[martok]

Btw, I am curious as to how useful publishing the share and score logs would be. Particularly whether that ensures pool integrity given that the worker solution is included. I would not be willing to publish the IP addresses of workers but could make previous round sharelog data available less IP address. So, would that be useful to anyone? Does anyone object IE are their privacy concerns here of which I am not aware?

This is a very important issue. I think it will be very useful if you publish such logs. Ideally, for each completed round you would have a table of shares (maybe downloadable in csv format) with the following info: Share #ID, Timestamp, score (as a proportion of the total round score), worker Bitcoin address, hash.
In case people are uncomfortable with their addresses' payout info being displayed, you could show stats only for the shares submitted by the user. For this you will probably need some sort of login system.

I don't see how publishing bitcoin addresses could be a privacy issue but I could just hash them or take a crc32 etc. My thought was to just dump out the share table per round (time,worker,lscore,solution. If someone analyzing the data wants scores as a proportion of total, they can just calculate it using the formula in your thread.

[Transcendental]

My client hash rate is again malfunctioning and only display 1/4 of what I'm currently outputting.. I also cannot check unconfirmed balance.

[martok]

Ok, balancecurrent is really expensive in terms of performance and RPC is timing out with this long a round. I am trying to figure a faster way to do this.

As for hashrate, did the miner submit an unusually low number of shares during the interval you checked?

[Meni Rosenfeld]

Ok, balancecurrent is really expensive in terms of performance and RPC is timing out with this long a round. I am trying to figure a faster way to do this.

Assuming the problem is summing over all the shares of the worker, note that shares older than the last 10,000 or so will have negligible score, so you can just find out the ID of the last share and use "where ID > X-10000" or similar.

[martok]

Ok, balancecurrent is really expensive in terms of performance and RPC is timing out with this long a round. I am trying to figure a faster way to do this.

Assuming the problem is summing over all the shares of the worker, note that shares older than the last 10,000 or so will have negligible score, so you can just find out the ID of the last share and use "where ID > X-10000" or similar.

Great, that's a big help. Yeah, it's the big table scan that's bogging it down.

Edit: balance updated to only scan last 10,000 shares. Note that the final round payment calculation still scans all shares.

[Meni Rosenfeld]

Ok, balancecurrent is really expensive in terms of performance and RPC is timing out with this long a round. I am trying to figure a faster way to do this.

Assuming the problem is summing over all the shares of the worker, note that shares older than the last 10,000 or so will have negligible score, so you can just find out the ID of the last share and use "where ID > X-10000" or similar.

Great, that's a big help. Yeah, it's the big table scan that's bogging it down.

Edit: balance updated to only scan last 10,000 shares. Note that the final round payment calculation still scans all shares.

There's still room for improvement in the final calculation. At the current r, shares older than 17,000 will have score less than double-precision granularity, so they won't have any effect anyway.