Introducing CherryPicking - new Windows & Linux Pool Hopper

[gigica viteazu`]

oh, i`m not interested in pool hopping ... sorry

thank you

[hawks5999]

oh, i don't properly understand pool hopping ... sorry

thank you

Fixed that.

[gigica viteazu`]

oh, i don't properly understand pool hopping ... sorry

thank you

Fixed that.

i did not say that

[iopq]

Wait, explain why I would want to use this over BitHopper.

[hawks5999]

Wait, explain why I would want to use this over BitHopper.

1. Bitclockers screws with BH but after a day appears they don't with CP
2. CP seems to have some functional algos for pools that BH is still trying to figure out (score/pplns/etc - I know BH has some support for these as well).
3. BH requires some python setup steps that are not required for CP (just java). I know that there is now an exe that bundles all that stuff but not everyone follows the thread close enough to know that.

I'm not saying you should use CP or BH. I currently am using both concurrently (but not together). I think the work by c00w and ryouiki, et al is outstanding.

Basically, different strokes for different folks.

[iopq]

functional algorithm for PPLNS? lol?

[Bloodred]

Might as well submit shares to PPLNS pools if you're pretty sure to hit the N-share payment window and have a small chance to get them payed twice. This currently would work best with PPLNS pools with small N, such as 0.5 * diff

Do note that it DOES NOT use the prop hopping algorithm for PPLNS (or score pools for that matter).

Wait, explain why I would want to use this over BitHopper.

Think of it as an alternative, but these are a few advantages:
1) Score/PPLNS hopping, and no, not prop-style hopping which would be useless/detrimental to your income (there's a SMPPS profile for backup pools coming in the next version)
2) Less stales (no proxying)
3) Easier to get running on Windows, you only need Java which lots of people already have

[iopq]

PPLNS hopping

doesn't work unless you can predict the future

[Stupidpal]

So even if I mine at a low 120 mhash/sec and make around 0.07 BTC a day, this will help me make more?

[Bloodred]

doesn't work unless you can predict the future

Which you can with decent enough certainty if you take a look at the CDF curve for bitcoin block finding. It's a gamble, yes, but it can be a gamble with only a minuscule chance of you losing.

So even if I mine at a low 120 mhash/sec and make around 0.07 BTC a day, this will help me make more?

Yes, if you take the time to make accounts for lots of pools and enable them in CherryPicking you could get a good 50-100% extra, even more, the more pools (proportional pools mainly) you hop the more income you get. Your own hash rate doesn't matter in the process, you should still gain the same fraction of your current income as somebody mining at 2GH/s.

[MrWizard]

OK Bloodred it's time to earn your .1BTC. 

I am getting the following errors:
.
.
.
02-08-11 03:53:58 * Updating pools
02-08-11 03:53:58 * 8mtred
02-08-11 03:53:58 * Error occured while trying to communicate or open a connection to https://mtred.com/api/user/key/17e1395c3a140715cab6755aa52c4410
* sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
02-08-11 03:53:58 * Update error or pool considered invalid (lagging or down)
02-08-11 03:53:58 * 12rfcpool
02-08-11 03:53:59 * Error occured while trying to communicate or open a connection to https://www.rfcpool.com/api/pool/stats
* sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
02-08-11 03:53:59 * Update error or pool considered invalid (lagging or down)
02-08-11 03:53:59 * 14triple
02-08-11 03:54:01 * Update error or pool considered invalid (lagging or down)
.
.
.
For 14triple looks like the address of the JSON has changed.  Needs a new config file.
But for 8mtred and 12rfcpool I worked on this for 1/2 day with no luck.  I tried importing all the certificate authority keys used by the mtred https site into Java - User certificates but no luck.  Really need help on this.  Thanks.

[Bloodred]

That's a Java thing, it doesn't consider those SSL certificates trustworthy so it won't connect. You're right about having to get the certificates, the following method should work.

You can do it in a few ways:
1) Install the certificates yourself, you need to compile the code you can find right here and run the InstallCert.jar file that results. Note that I'm not the author or anything like that.
2) You can run the InstallCert.jar file that I compiled (link below)
3) You can just copy the file that I got by running InstallCert myself (link below as well)

What this does is download the SSL certificate so that Java can find it and not moan about CherryPicking connecting to the websites that use it.

Now, no matter what you chose, you'll end up with a file named jssecacerts that you need to copy to your Java\jre6\lib\security directory. After that you're good to go.

To run InstallCert.jar:

Code:

java -jar InstallCert.jar hostname

Replace hostname with the website with the untrusted SSL certificate, then when InstallCerts asks something type "1" and press Enter. It will create the jssecacerts file. You need to do this once for each hostname and then copy the latest file to that directory.

Here is the link with the already made jssecacerts file and InstallCert compiled by myself.

As for triple, adding this line to your .cfg file should do the trick. I forgot to update it from an older version. Oops

Code:

SharesRemove= 

Note that the last character on the line is a space, it's "SharesRemove= ", without the quotes of course. This tells CherryPicking to remove the spaces from the shares string before trying to parse it to a number.

[MrWizard]

That's a Java thing, it doesn't consider those SSL certificates trustworthy so it won't connect. You're right about having to get the certificates, the following method should work.

You can do it in a few ways:
1) Install the certificates yourself, you need to compile the code you can find right here and run the InstallCert.jar file that results. Note that I'm not the author or anything like that.
2) You can run the InstallCert.jar file that I compiled (link below)
3) You can just copy the file that I got by running InstallCert myself (link below as well)

What this does is download the SSL certificate so that Java can find it and not moan about CherryPicking connecting to the websites that use it.

Now, no matter what you chose, you'll end up with a file named jssecacerts that you need to copy to your Java\jre6\lib\security directory. After that you're good to go.

To run InstallCert.jar:

Code:

java -jar InstallCert.jar hostname

Replace hostname with the website with the untrusted SSL certificate, then when InstallCerts asks something type "1" and press Enter. It will create the jssecacerts file. You need to do this once for each hostname and then copy the latest file to that directory.

Here is the link with the already made jssecacerts file and InstallCert compiled by myself.

As for triple, adding this line to your .cfg file should do the trick. I forgot to update it from an older version. Oops

Code:

SharesRemove= 

Note that the last character on the line is a space, it's "SharesRemove= ", without the quotes of course. This tells CherryPicking to remove the spaces from the shares string before trying to parse it to a number.

Thanks!  Works great.  I did actually find the source for InstallCert.java myself in my research, but not knowing java coding I did not know how to compile it.
Other users please take note, the hostname should be the normal web site address, e.g. www.mtred.com  not https://www.mtred.com

[iopq]

doesn't work unless you can predict the future

Which you can with decent enough certainty if you take a look at the CDF curve for bitcoin block finding. It's a gamble, yes, but it can be a gamble with only a minuscule chance of you losing.

no, you can't, even when a block has 1,000,000 shares the next share has the same probability to find a block as the very first one
if it didn't, pool hopping would not work

read the bithopper thread for monte carlo simulations of PPLNS

[Bloodred]

@MrWizard I'm glad it works!

@iopq
The chance is equal for each share, yes, but the more "bad" shares you have in a row the less likely it is for you to continue getting only bad shares. If you flip a coin 10 times you don't have a 50% chance to only get heads or to only get tails just because the chance is 50% when you toss the coin once. For example, if a pool is currently at 0.1 * D into the current round it's much more likely for the round not to end in the next 0.5 * D shares than it is if you had 9.5 * D shares. It's quite likely for a round to get to 0.6 * D shares, but it's very, very unlikely for a round to get to 10 * D shares (this is plainly visible, I don't even know if any pool ever had a round that long).

On average, you find a block every D shares and each share has the same chance of being the "good" one, so they get a 1/D chance.
The chance to find a block on the first share is 1/D. The chance not to find it is 1-1/D

The chance not to find a block on the 2nd share (if we're at the 2nd share it means the first one was "bad") is (1-1/D)*(1-1/D) = (1-1/D)^2 (the probability of the 1st share being bad multiplied by the probability of the 2nd share being bad, which is, as you've pointed out, the same)
The probability of finding a block on the 2nd share is 1-(1-1/D)^2

Now if we keep on doing this for N shares, we get the probability to find a block after N shares:
1-(1-1/D)^N
1/D is obviously a very small number but larger than 0 and certainly under 1.
1-1/D is therefore also less than 1
(1-1/D)^N is therefore getting closer and closer to 0, the larger N is. This is to say, the chance of not finding a block is getting closer and closer to 0 the more bad shares a pool gets. The chance to actually find the block is therefore getting closer and closer to 1.

If you mine a round when the chance of the block ending is very close to 1, you're essentially almost certain to be mining in the PPLNS payment window, because it's very, very unlikely for the round to go on much further and for the payment window to move past your shares. If you're not missing the payment window you're not making any less than on a backup pool, but a few of your shares get the chance of being paid for twice if the next round is short and the payment windows overlap (and shorter rounds are more likely than very long ones).
You have no clue exactly which share will be the one to find the block, I agree because each individual share has the same chance, but the overall round lengths have to conform to the CDF curve (and they do, there's a graph on slush's pool's website with both the theoretical and experimental curves, which overlap).

PPLNS is heavily penalized though and the likelihood of CherryPicking actually hopping to a PPLNS pool is very small.

Graph of that function

[Aexoden]

@iopq
The chance is equal for each share, yes, but the more "bad" shares you have in a row the less likely it is for you to continue getting only bad shares. If you flip a coin 10 times you don't have a 50% chance to only get heads or to only get tails just because the chance is 50% when you toss the coin once. For example, if a pool is currently at 0.1 * D into the current round it's much more likely for the round not to end in the next 0.5 * D shares than it is if you had 9.5 * D shares. It's quite likely for a round to get to 0.6 * D shares, but it's very, very unlikely for a round to get to 10 * D shares (this is plainly visible, I don't even know if any pool ever had a round that long).

It sounds nice in theory, but it's completely untrue. A given share doesn't know or care about any of the shares that have preceded it. It still has exactly a 1/D chance of being a valid block. The consequence of this is that no matter how many shares there are in a round, the round will take, on average, another D shares.

It's true that, considered as a whole, a round of, say, a billion shares is extremely unlikely. However, if a pool does somehow make it a billion shares without finding a block, they're still no closer to finding a block when they started. It's still going to average another D shares.

[iopq]

@iopq
The chance is equal for each share, yes, but the more "bad" shares you have in a row the less likely it is for you to continue getting only bad shares.

false, I stopped reading there

[Sukrim]

doesn't work unless you can predict the future

Which you can with decent enough certainty if you take a look at the CDF curve for bitcoin block finding. It's a gamble, yes, but it can be a gamble with only a minuscule chance of you losing.

CDF is counting for the whole pool, not for everyone in it. If you stay from the beginning of the round in the pool, then the CDF applies to you too. The moment you hop in, it starts at 0% for you individually.

Maybe it is easier for you to understand by coin tosses: If someone ("the pool") constantly flips coins and has started already a week ago, betting to hit 10 times head in a row, it is very likely that he'd hit this within this week.
If you however jump in after 1 week and say "now he has tossed the coin so often, without hitting 10 times head in a row - it's more likely now!", you're wrong. It's only more likely for him to have reached this number sometimes within that week, but that does not make it more likely for him to reach it in the future, so if you the jump in after this one week, it still changes nothing about the chance of getting a hit.

In "real world" Bitcoin pools something else happens interestingly - hashrate goes down on long blocks usually (since people are used to prop. pools where it makes sense to leave on long rounds). This makes it even harder/take longer to find a block on a long round (not chance per share wise but shares per time wise), however the reward on the other hand grows with this, so it evens out.

PPLNS is however a good thing to have as backup pool, as it can never go into a minus (unlike *SMPPS pools) and will in the long run always pay expected values. It has more variance though.

[hawks5999]

PPLNS is heavily penalized though and the likelihood of CherryPicking actually hopping to a PPLNS pool is very small.

PPLNS is however a good thing to have as backup pool, as it can never go into a minus (unlike *SMPPS pools) and will in the long run always pay expected values. It has more variance though.

Let's take these two statements together and call the issue closed. Semantic arguments about something you rarely if ever use and only as a backup detracts from development of new features.

[ampirebus]

so i just bought this because .1 BTC is nothing to me, thats not even a dollar

anyways i have between 1.0-1.4Ghash depending on how hard i push my rig, and right now i get ~.5BTC/24 hours

I will report how different my returns are after letting this run for 24 hours, what should i expect though?