I do not see payment from last block solve of 05-27. That's the only issue I've seen.
EDIT: now I see it... 5/28/11 11:00
Topic: Continuum Mining Pool: No fees; Client uptime monitoring via twitter and email - page 12. (Read 50243 times)
May 28, 2011, 08:40:50 AM
May 28, 2011, 01:39:34 AM
Thanks for the work on this pool - was hoping someone would implement Meni Rosenfeld's algo. Couple of comments -
Well, it's far from perfect but we're getting there.Quote
my hashrate is reported at continuumpool as 10 - 30% higher than it actually is ( I'm at an average of 350 MH/s as reported by poclbm and R tools, I'm seeing 400 to 450MH/s from the website). I'm not complaining, and it's probably normal variability, but I thought you'd want to know.
I'm pretty sure it's just variability. It's just reporting the shares it gets back within 5 minutes so you may have been just hitting a lot of shares. There is a report above that hashrate was 15% below poclbm so maybe the formula could use some smoothing. I don't really pay much attention to it personally.Quote
also, on www.continuumpool.com you've written:
I searched for RPC in the forums and got wayyyyy too many hits - do you have a link I've missed in this thread?
Check out the first few posts in this thread for RPC documentation and PERL code samples. They should get you on your way. I'll link the source code to those little scripts on wwww.continuumpool.com as well as that might help people write their own monitors. Quote
The RPC interface can be accessed via rpc.pl and is documented in the Bitcoin forum.
I searched for RPC in the forums and got wayyyyy too many hits - do you have a link I've missed in this thread?
May 27, 2011, 10:00:14 PM
Thanks for the work on this pool - was hoping someone would implement Meni Rosenfeld's algo. Couple of comments -
my hashrate is reported at continuumpool as 10 - 30% higher than it actually is ( I'm at an average of 350 MH/s as reported by poclbm and R tools, I'm seeing 400 to 450MH/s from the website). I'm not complaining, and it's probably normal variability, but I thought you'd want to know.
also, on www.continuumpool.com you've written:
I searched for RPC in the forums and got wayyyyy too many hits - do you have a link I've missed in this thread?
Cheers
my hashrate is reported at continuumpool as 10 - 30% higher than it actually is ( I'm at an average of 350 MH/s as reported by poclbm and R tools, I'm seeing 400 to 450MH/s from the website). I'm not complaining, and it's probably normal variability, but I thought you'd want to know.
also, on www.continuumpool.com you've written:
Quote
The RPC interface can be accessed via rpc.pl and is documented in the Bitcoin forum.
I searched for RPC in the forums and got wayyyyy too many hits - do you have a link I've missed in this thread?
Cheers
May 27, 2011, 08:05:32 PM
You can now aggregate your worker payments by logging in with
workeraddr;paymentaddr
as your username. workeraddr is still the primary address to which notification monitors are tied etc, paymentaddr is the address to which payments can be sent. So for example, if you have multiple workers, you can set the same paymentaddr for all of them to get to the 1 BTC payment threshold faster.
workeraddr;paymentaddr
as your username. workeraddr is still the primary address to which notification monitors are tied etc, paymentaddr is the address to which payments can be sent. So for example, if you have multiple workers, you can set the same paymentaddr for all of them to get to the 1 BTC payment threshold faster.
May 27, 2011, 08:00:57 PM
I uh, invited some friends. How's the server holding up?
Indeed, and they found a block.Server load is pretty much where it was when we started. Sitting at 0.3 with most of that being consumed by bitcoind itself.
Looks to me like it's having issues, the miners are going idle a lot, and the rpc is down.
Is this still the case? I have been implementing the payout aggregation stuff so had to restart the pool a couple times. If it's still happening, let me know and I'll start through the logs.
May 27, 2011, 06:43:55 PM
I uh, invited some friends. How's the server holding up?
Indeed, and they found a block.Server load is pretty much where it was when we started. Sitting at 0.3 with most of that being consumed by bitcoind itself.
Looks to me like it's having issues, the miners are going idle a lot, and the rpc is down.
May 27, 2011, 06:08:39 PM
Once you get multiple miners to single address working (and perhaps a bit more hash power) I might move to your pool 
Lack of registration requirement is great.
Lack of registration requirement is great. May 27, 2011, 05:56:09 PM
I uh, invited some friends. How's the server holding up?
Indeed, and they found a block.Server load is pretty much where it was when we started. Sitting at 0.3 with most of that being consumed by bitcoind itself.
May 27, 2011, 05:51:47 PM
I uh, invited some friends. How's the server holding up?
May 27, 2011, 04:42:51 PM
Any chance of setting up an IRC channel?
I'm not usually around IRC but if you need immediate help, feel free to post here or mension @continuumpool on Twitter.
Quote
Also, are payments made only when balance hits 1 BTC? Manual payouts would be a nice option too.
Unfortunately, I don't see an easy way to do this. The problem isn't that we can't, it's that since workers are effectively unauthenticated, there is no secure way you could tell the pool, send balance of address x out immediately. You have no way of proving you own address x and since TX fees will likely apply, well....I am however working on combining payouts to multiple workers. If I have workers a, b, c and d mining, it may not make sense to have four seperate payments generated. So, I should be able to tell the pool to combine those payments and send to address e. We even have an unused message field for that, the client password. Again, due to the proof of ownership problem, the feature will only apply to those shares submitted with the payment address as password and not previous shares but it should work.
May 27, 2011, 04:18:46 PM
You guys are my new standard backup pool. Throwing my ~785 Mhash/s at you while my main pool is down.
Any chance of setting up an IRC channel?
Also, are payments made only when balance hits 1 BTC? Manual payouts would be a nice option too.
Any chance of setting up an IRC channel?
Also, are payments made only when balance hits 1 BTC? Manual payouts would be a nice option too.
May 27, 2011, 01:36:34 PM
Edit: Hm, I've just checked at http://www.continuumpool.com/ and it reports my mining rate is ~15% lower than what is reported by poclbm. Any idea why this is? (Sorry if this was discussed before and I didn't notice)
15% seems like a lot. Though I get some variance on this as well. Here is the function I use. To summarize, it just takes the shares over the last 5 minutes and calculates the expected hashrate from there. If you see anything glaring, let me know.sub hashrate : Public(worker:str)
{
my ($self, $params) = @_;
my ($shares);
my $dbh = $self->{dbh};
my $worker = $params->{worker};
my $sec = 300;
my $y = Math::BigInt->new("26959535291011309493156476344723991336010898738574164086137773096960");
$shares = $dbh->selectrow_arrayref(qq{
select count(*) from share
where worker=? and time >= now() - interval '$sec seconds'
and our_result='t'},
undef, ($worker));
my $x = Math::BigInt->new(2);
$x->bpow(256);
$x->bmul($shares->
- );
$x->bdiv($y);
return $x->numify();
}
May 27, 2011, 11:05:47 AM
Looks like another 2-3 Ghash/s just hopped on board last night (CDT).
Edit: Hm, I've just checked at http://www.continuumpool.com/ and it reports my mining rate is ~15% lower than what is reported by poclbm. Any idea why this is? (Sorry if this was discussed before and I didn't notice)Mine's been fluctuating both higher and lower than poclbm, I think it's just the variability?
May 27, 2011, 10:37:02 AM
Looks like another 2-3 Ghash/s just hopped on board last night (CDT).
I added ~1.5 Ghash/s 5 hours ago. I put my mining where my math is (hey, that's a really nice-sounding paraphrase!)Detail: I added my 370MH/s personal computer immediately when I found this. But my mining rigs are harder to access and I was busy so I postponed it. Then my personal MB died and this miner was down until I got a replacement. Then the PSU for one of my mining rigs died, so I did some switching hardware around which left my PC unsuitable for mining. But at the same time I switched my mining rigs from slush, which total about 1.9GH/s.
Edit: Hm, I've just checked at http://www.continuumpool.com/ and it reports my mining rate is ~15% lower than what is reported by poclbm. Any idea why this is? (Sorry if this was discussed before and I didn't notice)
May 27, 2011, 10:26:57 AM
Looks like another 2-3 Ghash/s just hopped on board last night (CDT).
May 26, 2011, 10:43:11 PM
I am using the scoring algorithm described here:
https://bitcointalksearch.org/topic/geometric-method-new-cheat-proof-mining-pool-scoring-method-4787
It was designed to prevent pool-hopping attacks.
My understanding of reading this algorithm is that it only works if the pool takes fees... yet you claim no fees. How does that work?https://bitcointalksearch.org/topic/geometric-method-new-cheat-proof-mining-pool-scoring-method-4787
It was designed to prevent pool-hopping attacks.
The algorithm does work using fees but it works such that I can set my expected comission to 0. This is done by setting a positive variable fee and a negative fixed fee. In other words, in some rounds, the operator fee will be positive and in others it will be negative with an expected overall payout of 0. Last round for example, my fee was negative.
May 26, 2011, 04:58:46 PM
I am using the scoring algorithm described here:
https://bitcointalksearch.org/topic/geometric-method-new-cheat-proof-mining-pool-scoring-method-4787
It was designed to prevent pool-hopping attacks.
My understanding of reading this algorithm is that it only works if the pool takes fees... yet you claim no fees. How does that work?https://bitcointalksearch.org/topic/geometric-method-new-cheat-proof-mining-pool-scoring-method-4787
It was designed to prevent pool-hopping attacks.
The algorithm does work using fees but it works such that I can set my expected comission to 0. This is done by setting a positive variable fee and a negative fixed fee. In other words, in some rounds, the operator fee will be positive and in others it will be negative with an expected overall payout of 0. Last round for example, my fee was negative.
May 26, 2011, 04:28:08 PM
I am using the scoring algorithm described here:
https://bitcointalksearch.org/topic/geometric-method-new-cheat-proof-mining-pool-scoring-method-4787
It was designed to prevent pool-hopping attacks.
My understanding of reading this algorithm is that it only works if the pool takes fees... yet you claim no fees. How does that work?https://bitcointalksearch.org/topic/geometric-method-new-cheat-proof-mining-pool-scoring-method-4787
It was designed to prevent pool-hopping attacks.
Seems like a clone of Luke's (Eligius) pool, but it doesn't really matter. The more pools the better.
Eligius is an Excellent pool. I wanted to do more with notifications of downed miners though. IE when a miner is down, I want an SMS etc. Luke definitely has the payment system right though.
May 26, 2011, 02:42:44 PM
RPC should be fixed. Sorry folks.
New RPC confirmed working for me.
May 26, 2011, 02:41:01 PM
RPC should be fixed. Sorry folks.
Jump to: