Introducing CherryPicking - new Windows & Linux Pool Hopper

[Milkshanks]

The problem is that Unitedminers is slow as hell, so while it takes them 6 hours to reach 42k shares, the other pools like MtRed reach that almost immediately.  So Cherrypicker will jump to MtRed when they find a block, but almost immediately they are no longer the pool with the fewest shares so it switched back to unitedminers.  If you have the latest version you can set in the settings.cfg the algorithm so that it will stay with faster pools and fall back on the slow pools.

Ah, the new STATIC_FAST option? I see. But from what I can see from the changelog, STATIC_FAST can "reduces variance and your income to some extent" How is that possible?

[muyoso]

The problem is that Unitedminers is slow as hell, so while it takes them 6 hours to reach 42k shares, the other pools like MtRed reach that almost immediately.  So Cherrypicker will jump to MtRed when they find a block, but almost immediately they are no longer the pool with the fewest shares so it switched back to unitedminers.  If you have the latest version you can set in the settings.cfg the algorithm so that it will stay with faster pools and fall back on the slow pools.

Ah, the new STATIC_FAST option? I see. But from what I can see from the changelog, STATIC_FAST can "reduces variance and your income to some extent" How is that possible?

If you are mining at MtRed and suddenly united miners has a short block, you missed out on it completely.  I am still unsure which is the best method myself.  I think I may just set unitedminers to BACKUP manually and let the normal algorithm do its business.

Edit: Actually I don't think that would work setting it as backup.  I have no idea what is the best method now.

[ampirebus]

So now that everything seems to be working well, is it possible to see our efficancy, or how much better we are doing?

That would be cool, cause I can't seem to keep proper track of my earnings with this much pools. Also, I'm wondering, isn't pool hopping roughly about finding the youngest block amongst pools and mining on that pool? Cause from what I see CherryPicking always tries to mine on unitedminers for example, wich is trying to solve a block for almost 6 hours now while other pools like mtred barely gets mined on by cherry. I know there is something i'm missing here, but I can't figure out what exactly that is.

The problem is that Unitedminers is slow as hell, so while it takes them 6 hours to reach 42k shares, the other pools like MtRed reach that almost immediately.  So Cherrypicker will jump to MtRed when they find a block, but almost immediately they are no longer the pool with the fewest shares so it switched back to unitedminers.  If you have the latest version you can set in the settings.cfg the algorithm so that it will stay with faster pools and fall back on the slow pools.

this exact thing happened to me so hard today, if the bot wouldve stayed at mtred we'd have made a killing but it ditched for unitedminers over and over again making the payouts pretty much nothing
(from mtred)
8/8/11 09:42pm    1h21m44s   50.12400000   377275   95 req.
8/8/11 08:20pm    1h23m51s   50.02543212   384953   89 req.

So All i have to do is change unitedminers to type=backup?

[Milkshanks]

No, it will most likely go to another slow pool. What you can do is create a settings.cfg file on your cfg folder and add this line to it:


Algorithm=STATIC_FAST

This way CherryPicking will always pick the fastest pool with the newest block and will only fall back to slower pools if necessary.

[hawks5999]

Wow. I see that United Miners has decided to stick with Proportional. I had them marked as PPLNS due to an earlier version of their FAQ. Turned out to be a good thing I didn't have them marked correctly.

[Bloodred]

As has been already pointed out, in theory mining on the pool with the least shares should be the most profitable, no matter the pools hash rate. This *should* increase your income but also increases your variance a lot (for example, a slow pool may only find a block once a week or something).

STATIC_FAST always mines on the fastest prop pool under 43% round shares (this translates to a priority value under 1.0 in CP). This reduces your variance because you're always mining on fast pool and you get payments more often. It theoretically decreases income because it may very well completely ignore slow pools that are earlier in the round than fast ones. Since these early shares are the most valuable, you'd be sacrificing your income for less variance.

As for efficiency calculation - indeed the math itself is trivial, but the problem lies with actually getting the payment from every pool. CherryPicking can (and does) already scrape information from websites as well as JSON APIs, but we have 2 pretty significant issues:
1) Most pools do not provide this information via JSON API + user key or anything like that
2) Most pools do provide this information on a web page which would be easy enough to get, but only if you're logged in. This would mean having some sort of cookie/session emulation like a browser has which would be quite difficult and I suspect time consuming to implement. I haven't worked on anything like that before so there would be a significant learning curve for me as well and all this translates into lots of time. I believe there are much more important things to add/improve in CP for the time being.

@Bloodred

I have a suggestion that could improve your hopper a little, maybe you could add some option on argument so we can have 2 or more different config files. The reason for this is using different arguments on different situations. The way I see it you'd just need to add a argument to set from wich file CherryPicking should read the configs, if no argument is used, it'd read it from poclbm.cfg as always.


Edit: Either that or making a way so we can use this hopper as a proxy, being able to connect multiple miners to it. But I guess that would ask for a ton of coding work.

Yeah, I guess I could implement something like that. Making it a proxy would completely eliminate the advantage of client hopping though.

[MrWizard]

As has been already pointed out, in theory mining on the pool with the least shares should be the most profitable, no matter the pools hash rate. This *should* increase your income but also increases your variance a lot (for example, a slow pool may only find a block once a week or something).

STATIC_FAST always mines on the fastest prop pool under 43% round shares (this translates to a priority value under 1.0 in CP). This reduces your variance because you're always mining on fast pool and you get payments more often. It theoretically decreases income because it may very well completely ignore slow pools that are earlier in the round than fast ones. Since these early shares are the most valuable, you'd be sacrificing your income for less variance.

As for efficiency calculation - indeed the math itself is trivial, but the problem lies with actually getting the payment from every pool. CherryPicking can (and does) already scrape information from websites as well as JSON APIs, but we have 2 pretty significant issues:
1) Most pools do not provide this information via JSON API + user key or anything like that
2) Most pools do provide this information on a web page which would be easy enough to get, but only if you're logged in. This would mean having some sort of cookie/session emulation like a browser has which would be quite difficult and I suspect time consuming to implement. I haven't worked on anything like that before so there would be a significant learning curve for me as well and all this translates into lots of time. I believe there are much more important things to add/improve in CP for the time being.

@Bloodred

I have a suggestion that could improve your hopper a little, maybe you could add some option on argument so we can have 2 or more different config files. The reason for this is using different arguments on different situations. The way I see it you'd just need to add a argument to set from wich file CherryPicking should read the configs, if no argument is used, it'd read it from poclbm.cfg as always.


Edit: Either that or making a way so we can use this hopper as a proxy, being able to connect multiple miners to it. But I guess that would ask for a ton of coding work.

Yeah, I guess I could implement something like that. Making it a proxy would completely eliminate the advantage of client hopping though.

Regarding your point #2,   http://www.btc-poolwatch.com/   offers a web page where you can enter all your pool's APIs and it will show you your stats for your pools all on one page.  It even provides a running total of your balance.  All for the low price of free.

[Bloodred]

I don't know if that would be able to help in this endeavor, I've only quickly checked it out but communicating the API tokens to that website looks just about the same as logging in to the pools themselves. It's definitely using cookies/sessions since it remembers the settings you have.

[MrWizard]

I don't know if that would be able to help in this endeavor, I've only quickly checked it out but communicating the API tokens to that website looks just about the same as logging in to the pools themselves. It's definitely using cookies/sessions since it remembers the settings you have.

I did not mean to imply that you should make any effort to integrate btc-poolwatch.com into your product.  It is easy enough for us to enter our API's one time there and then use the web site to track our balances, etc. of our pools.

[max in montreal]

Damn it, I forgot to post this in the changelog.
Yes, yes you can.
Just type info and press Enter, I've added it in the latest version. The hash rate displayed is taken from poclbm's own averaging, it will probably be inaccurate right after a pool switch.

would be cool if this info could appear exery x seconds...

[Bloodred]

I don't know if that would be able to help in this endeavor, I've only quickly checked it out but communicating the API tokens to that website looks just about the same as logging in to the pools themselves. It's definitely using cookies/sessions since it remembers the settings you have.

I did not mean to imply that you should make any effort to integrate btc-poolwatch.com into your product.  It is easy enough for us to enter our API's one time there and then use the web site to track our balances, etc. of our pools.

I did not mean that. What I mean is this: for CP to be able to access your version of btc-poolwatch.com it needs to store some cookies/support a session or something like that so that btc-poolwatch.com can identify you and show your own info. If you configure poolwatch from a browser and then just point CP to the URL, CP won't get the page with your info, it'll get the generic page.

This is basically the same thing that's required in order to log in to a pool's own website, so in the end it doesn't make the task much easier. Sure, now you have 1 web site instead of lots of web sites, but if I already had a framework to use with 1 web site I could just as easily use it for more than one.

Damn it, I forgot to post this in the changelog.
Yes, yes you can.
Just type info and press Enter, I've added it in the latest version. The hash rate displayed is taken from poclbm's own averaging, it will probably be inaccurate right after a pool switch.

would be cool if this info could appear exery x seconds...

Sure, that isn't a problem, I can make the next version do that. Once with each pool update or at a different interval?

[max in montreal]

when running phoenix, the bottom line in the window shows the stats. I could always see my hashrate for the miner and accepted rejected, its there permantly. I think this is a cool feature.

[Bloodred]

I could try to do something like that.

[Psychonautchn]

I'm getting a number of "[Miner0] pool.unitedminers.com:8332 upstream RPC error" I checked the config file and the port is correct so I'm not sure why the errors keep popping up. Also, any progress on resolving the problem with the security certificates? I still have a few pools down because of that issue.

[Bloodred]

Probably something wrong with the pool, that is a poclbm error message.

As for the certificates, make sure the file is in the right place and if that doesn't solve it try making a clean JRE install. The certificates themselves are there since other people use the same files and they work. I can't replicate this issue on any of my computers so it's difficult to pinpoint a cause.


Also noticed a bug in 0.6.4: the stale percentage is wrong, divide it by 100 to get the real value. For example, if you get 120% stales the real value is 1.2% stales.

[ampirebus]

I've removed 22BTCPOOL24 and  23BTCWorld because they are making me lose a lot of potential income . If you've kept them in your pools.cfg cycle and you're getting efficient returns let me know, otherwise be warned.

[ampirebus]

I was going to suggest bitcoinpool but after reading their TOS I found then too much of and anal retentive control freeks.    They will freeze your account if there is no activity in a 28 day period, they will freeze your account if you are not "efficient", they will freeze your account if they feel like it  

Donating to the pool ameliorates this problem:
http://www.bitcoinpool.com/forum/viewtopic.php?f=1&t=103&p=2449&hilit=donate#p2449

i set my donation % at bitcoinpool to be 2% and i still got banned...

whats the deal here? i suggest everyone using cherrypicker check their accoutns as if i was banned so were you probably

[muyoso]

i set my donation % at bitcoinpool to be 2% and i still got banned...

whats the deal here? i suggest everyone using cherrypicker check their accoutns as if i was banned so were you probably

Donating 1% and don't think I am banned.

[Milkshanks]

whats the deal here? i suggest everyone using cherrypicker check their accoutns as if i was banned so were you probably

Bitcoin Pool is weird, they like to ban ppl randomly and they keep your coins, I advise you not to use it.


Also, there are a lot of pool cfg files that don't have the "Miner" option, should I just add it? Btw, I'd like to know from you guys if you people had better results using STATIC_FAST or NORMAL algorithms, I'm currently testing STATIC_FAST,  and UpdateTime 300

[Bloodred]

Yes, you need to add the Miner entries yourself.