Topic: Introducing CherryPicking - new Windows & Linux Pool Hopper - page 31. (Read 43136 times)
Added 3 more pools to the .cfg archive (bitcoinpool, btcserv - very very slow, poolmunity).
I'm still getting the same errors even after moving over the certificate file you linked to. 
Thank you!
If anybody would like a .cfg for any pool that isn't in the archive I posted just post a link to it and I'll write a config file. The pools in the archive are by no means the only supported pools, if a pool displays the round shares and hash rate either in a JSON API or on a normal web page (that doesn't require a log in), then it can be hopped using CherryPicking.
If anybody would like a .cfg for any pool that isn't in the archive I posted just post a link to it and I'll write a config file. The pools in the archive are by no means the only supported pools, if a pool displays the round shares and hash rate either in a JSON API or on a normal web page (that doesn't require a log in), then it can be hopped using CherryPicking.
Just bought this (0.1 BTC is a lot for me) and configured as many pools as I could. Gonna start it up in a while.
Thank you for the additional information.
I plan on hopping as many pools as possible within reason, I
've just finished setting everything up (registering workers on previously unused pools etc) and plan on "unleashing the beast" tomorrow. Before I was running 4 miners all at slush's pool or switching them between mtred and deepbit.
I plan on hopping as many pools as possible within reason, I
've just finished setting everything up (registering workers on previously unused pools etc) and plan on "unleashing the beast" tomorrow. Before I was running 4 miners all at slush's pool or switching them between mtred and deepbit.
@everyone talking about PPLNS I've coded the groundwork for a simulator and had it randomly generate 1,000,000 rounds today, I'll apply my algorithm and slight variations on that and see once and for all if it's harming efficiency. If it is, I'll just demote PPLNS completely to backup.
That really is dependent on how many pools you add. If you hop a single prop pool and a backup pool you'd get roughly 28% extra. If you add lots of prop pools it can even be over 100% extra (you'd double your income). Of course your luck and the pools' luck also play a role, a single mining day probably isn't enough for completely relevant data, especially considering some prop pools are very slow. Even so, you should still add them as hash rate doesn't really have an impact on your gain.
About SMPPS, I'll add a profile for that in the next version (in testing now) so you don't mine on those if they're unlucky.
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?
Thanks!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?
That really is dependent on how many pools you add. If you hop a single prop pool and a backup pool you'd get roughly 28% extra. If you add lots of prop pools it can even be over 100% extra (you'd double your income). Of course your luck and the pools' luck also play a role, a single mining day probably isn't enough for completely relevant data, especially considering some prop pools are very slow. Even so, you should still add them as hash rate doesn't really have an impact on your gain.
About SMPPS, I'll add a profile for that in the next version (in testing now) so you don't mine on those if they're unlucky.
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?
If you went from mining on a score based or SMPPS based mine expect increased variability in your rewards. Give it at least a week to see the true returns from hopping. 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?
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?
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?
You should let it run for 48 hours IMHO and it will depend on how many pools you run.
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?
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?
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.
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.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.
@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.
@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.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'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.
@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
@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
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.if it didn't, pool hopping would not work
read the bithopper thread for monte carlo simulations of PPLNS
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:
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
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.
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.
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.
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.
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?
Jump to: