Introducing CherryPicking - new Windows & Linux Pool Hopper

[DrHaribo]

BitMinter switched to a variation of PPLNS today, so if you were pool hopping us you may want to take us out of your setup. I don't want to "trick" anyone with the switch of reward system.

We'll still be paying out 5% extra for another 40+ blocks though, so we can be a good default pool to use.

[Bloodred]

i had a small issue upgrading from .066 to .067. CP was able to apply the patch update, but when i started the program i got an invalid or courrupt jarfile error. i have 4 rigs and the same thing happened on all of them. i completely reinstalled CP to see if that helped and i still got the invalid or corrupt jarfile error when i updated to version .067 whether i was updating from .063, .066, or .066a.

i couldn't find a post on how to roll back to a previous version, so i just renamed the current CherryPicking.jar to CherryPicking067.old. i then renamed the CherryPicking066.old to CherryPicking.jar and everything worked fine again. is this the proper way to go back to a previous version? CP still retained all the new updated functions of .067 even though i'm using the .066 .jar file. i don't know much about programming but i thought the code was in the .jar file, so how can the .066 file use the .067 updates, unless the code is not in the .jar file. in which case, what exactly is the difference in the .jar files if i can simply interchange them and not affect how CP runs?

The .old files the updater .bat makes are just the other .jar files renamed, so if you use any of those you're essentially using an older version. To re-update from an older one, download all the needed updates to get to the current version, then rename the respective .old file to CherryPicking.jar and apply the updates in order (the .old files will be generated again). I recommend re-upgrading from 0.6.5 or any older version.

In any case, I have re-uploaded the 0.6.6 to 0.6.7 update in case it somehow got corrupted, download that again to be sure. Here are also the correct checksums for 0.6.6 and 0.6.7:
0.6.7

Code:

  File: CherryPicking.jar
CRC-32: 9ccce5d1
   MD4: 6422bade46c6e4e59d5c6b304aeaa1ad
   MD5: c7009e1cb51af0d8d36b0a93c53318ac
 SHA-1: a99fff9ee398bb95b0ed097414529b45dc3c80bb

0.6.6

Code:

  File: CherryPicking.jar
CRC-32: cff79356
   MD4: c087ffd9704b0faa1ef6d86c0750e75e
   MD5: 619a959b53c7d2ae6c2c150c9d1a8a5e
 SHA-1: 388f6c1b70990439a958097ee505307983973df9

[NLA]

So what are some of the better pools for hopping to use? I'm hopping between 18 pools right now, and I'm looking for more (PROP) pools to get with -- or whatever pool seems to work best and dole out the most BTC. Looking at my SSH console right now, it looks like Eligius is feeding off of the 2100MH/s brute strength of my rig, and I'm wondering if my time would be better spent elsewhere (Ozco.in, Mtred).. I started making a DeepBit config file this afternoon but I dropped it half-way through because I wasn't sure if reading the *average* shares from the stats page was the proper value to input for the shares computation in CherryPicking.

Recommendations? Advice?

[organofcorti]

 Eligius is a fair pool, not a hopping pool. It doesn't have a standard proportional pool. The payout method is called SMPPS, and it's not hoppable.

[NLA]

Made a config for BTCGuild since bloodred is off twiddling his thumbs somewhere..

CONFIG FILES REMOVED BECAUSE THESE TWO POOLS DELAY STATS, PLEASE DON'T USE THEM.

Edit: Also, I've set ArsBitcoin as type BACKUP in the config, which I thought would mean it would ONLY hop to Ars if nothing else was available, or the other stuff was REALLY bad, but I seem to be hopping to Ars on a regular basis. Is this normal?

Would be nice if someone could piece together a config for btcmp~

[jduck1987]

NVM 

[tal0n4]

Very cool... thanks for the configs!

[blacbe]

hoping to deepbit is a bad idea because it's too fast and delays stats. i'm not sure about btcguild but i know it delays stats. maybe someone can make a comment on this

[Bloodred]

I'll be fully back in action tomorrow or the next day.

BTCGuild and Deepbit do not work, I haven't made cfgs for them with good reason. They are too fast and delay stats for too long (they get to over 43% of a round during the delay period so you're essentially hopping blind which cannot guarantee efficiency), furthermore in the case of Deepbit the average shares in the last 24h have pretty much nothing to do with the shares of the current round.

Anybody is of course free to try, but I advise not to.

[NLA]

I'll be fully back in action tomorrow or the next day.

BTCGuild and Deepbit do not work, I haven't made cfgs for them with good reason. They are too fast and delay stats for too long (they get to over 43% of a round during the delay period so you're essentially hopping blind which cannot guarantee efficiency), furthermore in the case of Deepbit the average shares in the last 24h have pretty much nothing to do with the shares of the current round.

Anybody is of course free to try, but I advise not to.

k, and as such I will remove my configs. It's a shame they're not hopable. :/

Also, bloodred, every now and then CherryPicking will just spend a long with just one GPU doing mining while the others idle @ 0 (making me think they've crashed) while the console log spits out "Failed to connect, retrying..." messages. Is it possible you could implement some feature that when a minute or so goes by and there's problems connecting, the miner switches to a backup pool (which is very reliable) and mines with that pool, checking back on the original pool every few minutes or so? During this time that no mining is taking place, no money is being made, and my 2150MH/s machine is being reduced to a 400MH/s drop-in-the-bucket.

[Bloodred]

That feature is actually already implemented and has been implemented from release, so you're saying you've encountered a bug with it?

When using poclbm, it invalidates a pool for 10 minutes if it receives 8 "Problem communicating with bitcoin RPC" errors in a 30s period. With Phoenix, it invalidates if it receives 3 "Failed to connect, retrying" errors in 40s. However, these checks are only made for Miner0 as they are meant to detect network errors (since everything is running on the same machine and on the same connection).

If Miner0 is working and the rest aren't it's very likely that the problem lies elsewhere, not with the pool or the network. They could have indeed crashed or have some other issues, such as bad miner accounts (be very careful with these, some pools accept shares even if your accounts are wrong, so in essence you'd be mining for nothing). If you have wrong accounts for certain pools and certain GPUs, those may not work on those pools but would be perfectly fine on others, so they would seem to stop randomly.

Also, please check actual GPU load to make sure they aren't working, that's a sure-fire way of knowing.

[NLA]

Seems to be a problem with either the pool or the miner or CherryPicking.. the other night Miner0 was running just fine, and the other 4 miners were running @ 0MH/s with lots of connection errors. A little while later, the pools were updated, and all the miners were back up and working again at full blast, submitting shares to the various pools.

I also monitored the temperatures while this was happening.. during the time that all but Miner0 were idling, they were running at a low temperature, and when the pools were updated, they increased in temperature again and returned to mining. This suggests to me that the clocks and GPU loads weren't the problem.

[Bloodred]

If Miner0 was running and then the others started on a hop it could very well be the account information issue I suggested. CherryPicking does not handle networking for the actual miners, so it's pretty much impossible for different instances of the same software (the miners) on the same machine to have network issues while others work.

[organofcorti]

How to hop 5 out now! Ever wonder why pool hopping works? Wonder no longer. No math required.

[NLA]

So what other pools would CherryPicking work best with? When I think of pools that CherryPicking should have, I look through

https://github.com/c00w/bitHopper/blob/master/pools.cfg

and see pools like Deepbit, Swepool (which is down right now?), RFCPool, BTCWorld, BTCGuild, BitMinersUnion, and others, and I'm not sure which ones I should make a config for, and which ones are most compatible, etc.

[wtfman]

How to hop 5 out now! Ever wonder why pool hopping works? Wonder no longer. No math required.

I dont understand that at all to be honest. Also you are not even "pool hopping" in your example.

Reason: proportional payout rewards shorter rounds more, and shorter rounds are more likely.

That would imply that simply mining in a prop pool would have a higher expected value than PPS and that is obviously not true.

[organofcorti]

How to hop 5 out now! Ever wonder why pool hopping works? Wonder no longer. No math required.

I dont understand that at all to be honest. Also you are not even "pool hopping" in your example.

Reason: proportional payout rewards shorter rounds more, and shorter rounds are more likely.

That would imply that simply mining in a prop pool would have a higher expected value than PPS and that is obviously not true.

I've probably not explained as well as i thought. In 1.   PPS vs full time mining I showed the non hopping situation. In 2. PPS vs the first share in a round I look at the situation of a miner submitting only 1 share each and every round. This is equivalent to submitting the first share in each round, or 'hopping off' after only one share. This is still pool hopping.

The actual full quote of the tl;dr is:

•   Submitting a single share before the end of a round is worth much more on a proportional pool than on a PPS pool (on average, ~14 times more efficient than PPS at current D)
•   Reason: proportional payout rewards shorter rounds more, and shorter rounds are more likely.

So what I mean was that the reason the first share submitted in each round is worth so much more than the other shares is that the proportional payout rewards shorter rounds more (one share round is worth 50 btc) and that because shorter rounds are more likely because of the nature of block solving, earlier shares are worth more than later ones - hence the reason for pool hopping.

This part that explains it is:

•   1/total shares is a hyperbolic function which hits a maximum of 50 coins for a round consisting of one share;
•   The total number of shares to find a block averages to D but because of the nature of the process of block finding shorter rounds are more likely than longer ones eg. a round has a 62% chance of ending before D shares have been submitted to a pool.

Together these two facts mean that 1/(low total shares) is more likely than 1/(high total shares). Since the cumulative payout for a single share submitted before the end of each and every round will be the sum of:

Code:

1/total shares round 1 + 1/total shares round 2 + 1/ total shares round 3 + …

and since the total round shares tend to be smaller, over time the payout tends to be larger than the PPS value of the share which does not vary.

So, I guess I failed at trying to make it an explanation accessible to everyone - what could I have done differently in terms of what you know about pool hopping?

Thanks for the feedback

[organofcorti]

Rather than have discussions about the 'How to hop' blog here, I'm posting update announcements about new 'how to hop' posts at here. Make a comment to subscribe!

Also, there's a new 'How to hop', and the last one has been rewritten with errors removed - wtfman you might be interested in that.

Enjoy!

[blacbe]

mtred switched to pps payouts only. use it as a backup or take it off your hop list

http://www.reddit.com/r/mtred/comments/l7ik5/after_the_current_block_mtred_will_be_offering/

Hoppers have been growing in size compared to the PPS users and the server has seen a decrease in funds because of this.

For a short period of time we will be looking at the results of rewarding purely via PPS.

This test will last between 2-6 weeks.

Thanks, RR

[tal0n4]

Thanks for the heads up...