blacbe to the rescue again. thank you

getting a new error from bitlc.net:

java.security.cert.CertificateException: no subject alternative DNS name matching www.bitlc.net found

anyone able to help? i've already tried to reinstall the java security certificate again and that didn't fix it.

thanks again blacbe, but i'm still having isssues with the java certificate. i copied the jssecacerts file to my Java\jre6\lib\security directory and replaced the existing file. how exactly do i add bitlc.net to the jssecacerts file now? double clicking the installcert.java doesn't seem to do anything

thanks blacbe. have you had any problems connecting to bitlc.net? did they change their page layout as well because i haven't been able to connect to them for the last few days

can you post your updated cfg for them

mtred changed their stats a little so the current profile no longer works for them. i'm not sure exactly what changed but i get the same error

any update on the eta of 0.6.8? specifically, a way to prioritize merged mining pools

i'm having an issue with arsbitcoin. sometimes, but not all the time, CP will list their efficiency number as 10.0 even though they are a SMPPS pool. however, when i switch them to backup(PPS), it goes back to 1.00256....here is my cfg file for them

Type=SMPPS
Host=arsbitcoin.com
Port=8344
JSON=https://arsbitcoin.com/api.php
HashEx1="hashrate":"\d+
HashEx2=\d+
SharesEx1="currentroundshares":"\d+
SharesEx2=\d+
Div=1e3

bloodred, you still here?

so with merged mining becoming active now in a few pools (eligius, slush) and others no doubt looking into it, are there plans to adapt CP to this?

it sounds like a good feature for CP to have. but what exactly do you mean by 40% bonus? is this compared to just sitting in an only BTC pps pool 24/7? do you mean hopping several merged pools or just staying on one? and with changing difficulty and exchange rates surly merged mining can't always give a steady 40% increase in BTC.

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?

obviously, no one is going to be convinced of the other side's opinion on hopping. both sides bring up valid points, but i don't see any legal evidence to backup the claims of fraud, deception, or theft. it's just different interpretations of math. as stated by a previous post, it is more an issue of taking advantage of those not aware of certain facts about hopping, which is not illegal. why is it the responsibility of the pool to provide such information about hopping? a pool tells you its payment method which is all you need to know. information about hopping and how it works on different payout methods is freely available. heck, there are even mathematical papers written on it referred to earlier in the thread. where is the intentional deception, the fraud? is it in the pool not telling you that their pool is susceptible to hopping? this information is not hidden by the pool; it simply requires you to do a minimal amount of research. maybe if the pool didn't tell you the payment method you could claim fraud but all the math is open for anyone to see. it is the responsibility of the miner to choose their pool, and if they choose poorly because they failed to inform themselves of certain facts it remains the miner's decision and the miner's responsibility. i mine where i choose to because i can, because there are no restrictions as to how, when or where i mine. i believe that is a great asset of bitcoin.

it can't be a very significant delay/fake. it has been my 2nd biggest earning pool and i have over 250% efficiency there for over a month of mining, which is pretty comparable to the other proportional pools i use

Its always prudent to do a little research before making accusations. Had you read this thread or even searched it, you would see other people including myself have encountered and easily fixed your problem by either reinstalling poclbm or downloading a different version. I found m0mchils version to work perfectly

het scatterbrain, you haven't taken difficulty changes into account. If you plot the coins you get in your bitcoin client against days, you'll see a slight curve. You can do one of two things:

• Calculate the expected payment per share for each difficulty (50/difficulty), add up the total shares for the period and multiply, and you'll get what you would have gotten at a fee-free pps pool
• Only average your results per difficulty period

Hope this helps.
[/quote]

i realize i didn't account for difficulty. i wasn't exactly sure how or if it was applicable. there were 2 difficulties in my data and it went down by only 83000 when it changed; a pretty small amount compared to most of the other difficulty changes i've seen. small enough i thought to not really have an effect on how it would impact results if it was applicable. is that a poor assumption?

why exactly does difficulty need to be applied at all? how does it change the ratio of my actual earned BTC/day/Ghash/s to somone's BTC/day/Ghash/s who mines at a PPS pool?

bloodred, is it possible to put together a cfg file for bitminter? nice little prop pool at 70 Ghash/s

all i did was take my average BTC/day for the 1 month period and divided by my hashrate(in Ghash/s)

so if i was mining 5 BTC/day at 7 Ghash/s: 5/7 = .714 BTC/day/Ghash/s, almost as good as my average  . it's a good stat to use when calculating how long a card will take to pay itself off. using that example, a new 5970 from newegg, with price tag of $500 and hash rate of 800 Mhash/s, would get about .5712 BTC/day. assuming current price(1BTC=$8.3) and difficulty remain the same, it would take about 60 BTC, or 105 days to pay off. this is not including electricity costs. using a common mining calculator, such as http://www.alloscomp.com/bitcoin/calculator.php or http://98.200.247.249:81/btc_calc.php, shows it would take about 133 days to pay off if you didn't pool hop. CP is giving me more than a whole months advantage over those poor saps who think pool hopping is unfair, or more than 2 months if i used my 5 day average (which will most likely drop) but is still crazy! now if only i had a 20Ghash farm...

please correct me if any of the math looks wrong

Been using dynamic fast multiplicative. I would like to try the others but i've been doing so well with this one I don't want to change it

I have 5 cards running on win7 x64 as well with no problems. My guess is the 6950 with unlocked shaders is crashing. I have 2 6950s that worked fine with unlocked shaders until I used them for mining, then they would crash after a few hours. I had to switch back to stock bios to keep them working while mining. Try running just your 6950 solo and see if your system still crashes. If not just go through your cards solo mining 1 by 1 until you find the one that's unstable

Nofee has never worked for me either. I can connect to them but all I get is rpc errors so I dropped them altogether. I think there is an updated cfg file for btcserv a few pages back that should work, but I still get a lot of connection problems with them too