Topic: del - page 8. (Read 16660 times)
btcmine and bitcoins-lc are over 2 days still pending!
For me it's 8 days pending. That's why I didn't use this pool anymore for 7 days. I lost too many shares at the original multipool. I don't want to repeat that here.
/sign
we need payouts more than anything else to continue. I pointed my miners back before 2 days but took em away again yesterday.
btcmine and bitcoins-lc are over 2 days still pending!
For me it's 8 days pending. That's why I didn't use this pool anymore for 7 days. I lost too many shares at the original multipool. I don't want to repeat that here.
Otherwise, I might get around to adding the pool eventually
The minecoin operator has already announced to put a fair reward system in place asap. If his speed > your speed, you might actually have better things to do.
Fair reward systems aren't always detrimental to hoppers.
Over one week with multipool on eligius-eu (old scoring system) I got efficiency of 1.9 over 2000 shares, on bitcoinpool 1.3, and btcmine I got 0.735 over 25000 shares. It really depends on the math behind the implementation. eligius is always my backup now for example, because their anti-hopping algo doesn't actually punish hoppers it just doesn't reward them.
Otherwise, I might get around to adding the pool eventually
The minecoin operator has already announced to put a fair reward system in place asap. If his speed > your speed, you might actually have better things to do.
Nick, there is no need to do the reward 100% exact for the pending pools.
Anything that seems nearly fair would work. We all would win if you dont focus on getting complicated rewardsystem butmore new pools. Is there a way to do it something like 95% accurate but fast implemented?
Anything that seems nearly fair would work. We all would win if you dont focus on getting complicated rewardsystem butmore new pools. Is there a way to do it something like 95% accurate but fast implemented?
found my own answer: http://forum.bitcoin.org/index.php?topic=17970.msg286403#msg286403
Heres the code for minecoin. Is it in your pools.conf?
Code:
minecoin
mineco.in:3000
https://mineco.in/stats.json
$time=~s/^.*"duration":(\d+).*$/$1/;$shares=~s/^.*"shares_this_round":(\d+).*/$1/;$rate=~s/^.*"hashrate":(\d+).*/$1/;$rate = int($rate/10**9);
utility_1
I've never used minecoin, but wouldn't be opposed to adding it in. However, I don't want to add yet another pool that won't convert its shares. If you feel up to writing a rewards function too, I'll add it into the rotation. Otherwise, I might get around to adding the pool eventually
The auto-refresh sounds reasonable, whenever I get some time for some more tweaking.
It looks like the pool is down.
It works fine. Reconnect to multiclone....
Heres the code for minecoin. Is it in your pools.conf?
The line that starts with "$time" is a full line, no enter downs.
And I was wondering if you could add an auto reload to the account status page?
Code:
minecoin
mineco.in:3000
https://mineco.in/stats.json
$time=~s/^.*"duration":(\d+).*$/$1/;$shares=~s/^.*"shares_this_round":(\d+).*/$1/;$rate=~s/^.*"hashrate":(\d+).*/$1/;$rate = int($rate/10**9);
utility_1
The line that starts with "$time" is a full line, no enter downs.
And I was wondering if you could add an auto reload to the account status page?
Code:
i see slush into multiclone shares! i though only real prop. pools are on it! 
According to what author of multipool said, score based pools should also be effective in the hopping-mix..less than proportional, but sometimes, when other pools having long rounds, the system decides to switch to slush. I had efficiency on slush with multipool about 1,3..
is this normal from deepbit?
135301 Fri Jul 8 13:09:21 2011 20 19.278 0.00000000 0.000 0.00000000
135300 Fri Jul 8 13:03:03 2011 13 15.489 0.00000000 0.000 0.00000000
135299 Fri Jul 8 12:48:40 2011 4 4.321 0.00000000 0.000 0.00000000
135298 Fri Jul 8 12:40:01 2011 15 19.658 0.00000000 0.000 0.00000000
135296 Fri Jul 8 12:28:09 2011 21 22.369 0.00000000 0.000 0.00000000
135295 Fri Jul 8 12:01:56 2011 26 26.617 0.00000000 0.000 0.00000000
135293 Fri Jul 8 11:56:22 2011 25 24.605 0.00000000 0.000 0.00000000
135291 Fri Jul 8 11:39:03 2011 12 11.233 0.00042231 1.100 0.00000202
135290 Fri Jul 8 11:16:05 2011 30 34.810 0.00064758 0.675 0.00000000
135301 Fri Jul 8 13:09:21 2011 20 19.278 0.00000000 0.000 0.00000000
135300 Fri Jul 8 13:03:03 2011 13 15.489 0.00000000 0.000 0.00000000
135299 Fri Jul 8 12:48:40 2011 4 4.321 0.00000000 0.000 0.00000000
135298 Fri Jul 8 12:40:01 2011 15 19.658 0.00000000 0.000 0.00000000
135296 Fri Jul 8 12:28:09 2011 21 22.369 0.00000000 0.000 0.00000000
135295 Fri Jul 8 12:01:56 2011 26 26.617 0.00000000 0.000 0.00000000
135293 Fri Jul 8 11:56:22 2011 25 24.605 0.00000000 0.000 0.00000000
135291 Fri Jul 8 11:39:03 2011 12 11.233 0.00042231 1.100 0.00000202
135290 Fri Jul 8 11:16:05 2011 30 34.810 0.00064758 0.675 0.00000000
I'd think the better fallback would be a SMPPS pool, since that by definition would have a utility of 1.0. With the hashrate devoted to solo on multiclone, I feel that the pool would have to be even luckier than arsbc to get anything.
+1
The new thread for Multiclone is a good idea -- I had intended to start one once I had worked out the remaining kinks with Multiclone. I'll probably start my own Multiclone thread (so I can own/edit/etc the main post) in a few days.
Anyway, I think I figured out the issue with the recent flakyness -- it had to do with a partial removal of the solo pool I tried to do, while maintaining pool protection.
I've reverted that tweak, so let's hope things are more solid now.
Anyway, I think I figured out the issue with the recent flakyness -- it had to do with a partial removal of the solo pool I tried to do, while maintaining pool protection.
I've reverted that tweak, so let's hope things are more solid now.
Jump to: