I'm fine with 5%, but the reasoning for this increase is interesting. Is just-dice now 'tainted' in the eyes of those who deemed it too shady because dooglus was willing to go with just 1% fee? If so, increasing to 5% shouldn't convince them now. Maybe it'll convince those who hear about just-dice later and don't know it started at 1% (which they would have deemed shady). Of course, someone could take it as their personal quest to make everyone aware that the fee was 1% in the beginning, and was only increased to make people less likely to think it's a scam.

Use the stats API command.

Is it now using a higher voltage when it's overclocked?

In the OP cgminer screeshot, I can see the jalapeno is running at 36C / 3.07V. My 5.8GH/s jalapeno is usually around 56C / 3.8V. It has the older heatpipe heatsink, but isn't that voltage of 3.8V quite high? It does have two active chips, though, so at least it's not a single-chip version. cgminer stats output is saying "PROCESSOR 3: 201 MHz PROCESSOR 7: 194 MHz ENGINES: 30 FREQUENCY: 189 MHz"

Just wondering if my unit could take this overclocking, since the voltage is quite high already. The running voltage & temps (both before & after) would be useful information to include in any report of successful OC.

Yep, it's down. Curiously the tab is just loading forever, not getting any error message in Firefox.

I copied all my *coin blockchains from Debian Linux to FreeBSD. All clients were properly shut down on Linux. None of the newly compiled clients would work on FreeBSD because of database errors, until I removed the copied blockchains and started from scratch. Should the blockchain files be transferable between different operating systems? Can anyone explain why I had to do this?

I'm pretty sure CoinLab's baseline for $2.50 per GH/s per day assumes no electricity costs. With current BTC price of ~$103, it's almost there, ~$2.7. After the next difficulty change it might make sense to mine at CoinLab again.

My user ID is 2137. 2 BTC invested

Is it the same for BFL ASICs, or are HW errors included in their hashrate? I thought they were included in the hashrate for all devices, it's quite confusing if they are included for some but not for others.

That yellowed out image might have meaningful numbers to you, but you can't really expect others to decipher it easily, especially since even the column headers are yellowed out. Looks like output from some custom script to me. It's a rather common problem that people expect others to be able to understand some output snippet, just because they understand it themselves. I'm doing that all the time myself

I see only one other user has noticed the same bug that I'm experiencing. Maybe it's because there should be no reason to reload the page. Or is this really working correctly for everyone else?

https://bitcointalk.org/index.php?topic=43514.msg1453386;topicseen#msg1453386

After enabling Group by Price, and reloading the page, the checkbox functionality is reversed and I have to uncheck it to enable grouping again. This doesn't happen if I hit enter on the address bar, or close the tab and reopen the URL. Only when pressing F5 or the reload button on the address bar.

I'm not seeing any errors reported by Firefox on this page, using version 21.

BTW, what's the difference between reloading using F5 (or the reload button), compared to hitting enter on address bar? I didn't know there is any difference, but clearly there is, judging from the behavior of this bug. I guess it's because web pages can modify what's actually reloaded when using a refresh, while "going to a URL" always reloads completely.

http://kcmo2.gigamining.com/?ref=60&rig=2

Compare difficulty accepted with rejected+hardware errors.

I'm seeing the same thing on multiple rigs, which have all been restarted after the difficulty change. One was started only two hours ago, and it's already flipped between 15.6M and 19.3M three times. I have six pools configured: BitMinter, Bitparking, Ozcoin, Slush, Deepbit & 50BTC. Running a git version of 3.2.2 compiled today. I'll try enabling debug output on some rig and pastebin the relevant parts.

I updated sources from git and compiled a new version. Ironically, doing so resulted in this:

Error: Error loading wallet.dat: Wallet requires newer version of Onecoin

Hey, this is the 5th largest pool. I don't think we are doomed yet

Here's what ckolivas had to say about it on IRC: "cgminer keeps a database of blocks so changing chains means the database is wrong". I have no idea what consequences that would have. Maybe I misread the problems people were having with cgminer here. I was considering a similar chain-hopping method myself, but decided to go with restarting cgminer instead, because of the multiple chains warning.

From the third line of cgminer README (https://github.com/ckolivas/cgminer/blob/master/README): "Do not use on multiple block chains at the same time!". This notice was added in version 2.0.6.

I've seen complaints of random crashes and shares not being submitted here. The reason could simply be that cgminer is not designed to work this way.

I let the Jalapeno idle for 10 minutes and changed the USB header it was connected to. Now it's hashing at 5.75GH/s again. Thanks to KNK at BFL forums for suggesting this! But since the Jalapeno already slowed down once, I'm not so confident anymore that it will keep hashing at 5.75GH/s indefinitely without problems.

Somehow my Jalapeno hashrate dropped from 5.75GH/s to about 5.55GH/s. It had been mining stable at full speed for over a week previously. The drop happened after I briefly ran the Jalapeno with BitMinter client during some maintenance, but that might be purely coincidental. BitMinter client was also showing over 5.7GH/s during the short time I tried it. I've tried running the same cgminer binary that produced 5.75GH/s, and the newest version from git, but the Jalapeno just won't hash faster than 5.55GH/s now. Even the temps are about 5C lower now. Any ideas how the hashrate would suddenly plummet like that permanently?

EDIT: I moved this question to BFL forums (https://forums.butterflylabs.com/jalapeno-single-sc-support/3136-jalapeno-hashrate-dropped-200mh-s.html). If anyone has anyone insight that might be a better place to answer, so people searching through Google etc. would actually find the answer.

Please enlighten me on how that calculation is wrong. In my mind, it goes like this: 1317 transactions, a maximum of $0.01 stolen from each. That totals $13.17. It's hard to get 0.01*1317 wrong. Of course, not every transaction has had the maximum $0.01 stolen from it, so the total would be less than $13.17. So my transaction fees have been anywhere from 0.5% (naively expecting that 0.005 would be the average stolen fee) to 1% (13.17/(13.17+1276.26)) higher than expected. Yes, that might be called stealing. Do I care about it enough to whine endlessly on forums? No.

Have you considered that maybe your dickish attitude is why you aren't getting any help with your problems? You seem to have a crusade against Bitstamp.