Again I misunderstand verifying messages.  When verifying, it doesn't decode and present the message, one needs to put coding address, the exact message, and the signature then if it is accurate it will say Message verified.  Which it just did.

Thanks.  It was the FINCEN guidance I was referring to but then I take it that never became legally binding for US citizens?

Thank you for explaining the difference.

Then if I take the hash generated by the signature, paste it in and decode it I should see the message?  And if so then it's something else I'm not doing correctly.  For instance, I put a minimum diff of 121 for the Mercury on the address.  Then later that day I added two more miners who's diff might more correctly be 7 and 2 but didn't change the requested min diff of 121.  Would that prevent all config changes from being accepted?

The payout went smoothly with the new block.  I notice it seems less 'spendable', having 26 confirmations already but needing 94 more blocks, than BTC earned elsewhere.  Also the clear demarcation of 'Mined'.  I wonder if this will prove a problem with that obscure rule that mined bitcoins make one an international money transfer agent if one tries to use it for anything but barter.  Bitcoins mined on another pool have not that demarcation.

But the question I wish to ask, is the minimum payout stat changeable on the configuration page?  I have Bitcoin-QT on another machine than the one having the cookie storing the receive address.  I generated the signed message which included in the encrypted string a lowering of the minimum payout trigger to 0.1000btc but it didn't take.  After the initial payout since the signed message configuration change I expected the payout to be lowered but it was not.  Is the minimum not changeable below what is dictated by the value equation used by Eligius staff?

Yes, I saw luck was down in the teens but went back to bed for an hour, got up, made breakfast, looked again and luck was up above 300%, now 154%.  My earnings have finally been moved to the payout queue and will be paid with the next block.

I've switched to Eligius and have been stuck at 22 minutes left until payout since 3AM.  Is there a problem?  The page doesn't seem to be updating.

I've a payout 10 hours ago with zero confirmations.

What's the story with Slush today.  My miners are showing up missing hash, particularly my Mercury is missing 30GH/s.  It hadn't been shut down but worried about the missing 30GH/s I shut it down and applied an earlier firmware that has always had good success.  CGminer hadn't indicated the Mercury was missing 30GH/s.  So, it's back up a half hour now with the earlier firmware and still Slush is reading 106745.175 while CGminer is showing: KnC 0:                | 181.6G/139.7Gh/s | A:57924 R:1580 HW:2321 WU:2073.6/m and the Mercury web page is showing MHS av=139781.74.

That's a lot of gigahash to have been missing all morning.

I've been pretty damn loyal to Slush since I started mining and I gotta say, what looks like missing hash seems to happen a LOT.  I realize there's some averaging that makes it slow to register but still.

Thanks for the reply.  I've inspected the board closely with a loupe  The USB pins seem quite well soldered visually inspecting.  The ASIC seems to be just a little askew from dead center but I'm betting on the CP2102 as dead - ordered one from Digikey earlier today.  I replaced one once before and it took me two days to get it right so I know they can tolerate soldering and desoldering, not sure about my tolerance for difficult work without the best (expensive) tools however. 

I've measured continuity between the data pins and the corresponding rear surface mount pins on the USB, that earlier today, but perhaps the signals just aren't reaching the fingers in the USB plug.  Think I'll grab a USB extension, plug it in and measure....yes, continuity.  It seems to be in a suspend state according to the suspend pin out (12) although the reverse is indicated by the suspend-not pin out (12) as they are both high.  I believe it wouldn't be capable of identifying itself if in a suspended state.  A good unit immediately gets a device reset notation in linux to std out when plugged in.  I would expect to see a similar notation when I bring the reset pin to ground but nothing. 

I got the noctura NF-A9x14 somebody recommended.  Had to cut the tubing off the wires to fit, heavy mesh tubing, wires within.  Also read somewhere to relocate the nylon washers.  Second attempt at reassembly I put the washers under the plastic tubes instead of on top.  Just a little easier.  It's not been modified otherwise.  It arrived hashing at 4.6 but is up to 4.80GH/s, center figure of the 3 on bfgminer v3.1.2.  Haven't figured out how to get the java api stats using linux yet.  Not that compelled to shut it down to run it under Windows for its stats.  Want to flash to a better firmware but am wary.

Had a BE go bad recently.  Troubleshooting: Not communicating; looked at voltages on the edge connector and found 7 to 6 on a good unit showing a little over a volt but on the faulty unit over 3 volts; cleaned a spot between a couple of pins on the inside side of the BE chip and now have the same voltage between edge pins 7 and 6 but not communicating.  The LED was flashing the correct sequence and duration so it wasn't the CP2102->crystal but found both the SUSPEND and SUSPEND-NOT pins high.  They should be complementary.  Not shorted so internal or elsewhere on the board.  Tried a manual reset of the CP2102 bringing the reset pin to ground but that was no help either.  The CP2102 seems to have the proper voltages aside from the SUSPEND and SUSPEND-NOT pins.  Since they're the states of an inverter input and output it's disallowed logic.  Anyone seen this and know of a fix aside from replacing the CP2102?  I note I had been getting strange high frequency noise on my network, it stopped around the time this went belly up.

Looking over the RPi flashing of a Jalapeno on http://randomcontent.wolfnexus.net/RandomSite/reflashing-a-butterfly-labs-jalapeno-with-only-a-raspberry-pi/

I see the last post, when a customer had gotten his Jalapeno mid-October, that something failed and there were no success posts following.  He had erased the firmware but hadn't succeeded in getting the new firmware installed.  A reply from Wolfnexus states:

Looks like one of the settings in the STEPPINGS file is incorrect or missing. This is due to the change in MCU that the Jalapenos are now using. I haven't yet had time to look into what needs to be changed, nor do I have one of the newer Jalapenos to test with. Any other users out there care to share what they did to resolve this issue?

Since mine was shipped about the same time as the one that failed to take the new firmware, I'm hesitant about giving it a try myself.  Mine is marginally above about 10% less than the 5GH/s expected.  They indicated they would give 5GH/s because the power figure was so much higher than what was specified at the time the pre-order was placed but then they said Hell, those pre-orders went so cheaply we'll ship most of those (non-upgraded) as a little better than 4.5GH/s.

I had mine apart and looked for the buck converter which required faster FETs than they had been using but only found a no-name replacement in its stead.  So, they're using different, cheaper, chips now. 

On the other hand it could be that Wolfnexus gave a face-saving reply to the user he suspected of not following procedure to the letter.

So, anybody who managed to replace the firmware in a Jalapeno manufactured after the first week in October, I'd appreciate knowing.

Loose ground wire internal of a switching supply to a laptop - might have put noise on the line causing the 2 RPi to go down and other systems to falter.  Love the 0.98 firmware.

Two laptops have become non-functional.  An RPi has stopped working, not accepting connections, another RPi running cgminer also isn't connecting, another laptop does ping yahoo just fine so it's not the internet - also this is getting posted....

somethings up.  I'm fighting with all my machines, someone hates me.

somebody doesn't like me helping competition - i post and pool stops responding, distributed denial of service attack?

I was getting >50% HW errors with firmwares over 0.94.  Moving down and enabling cores, using the higher voltage I get 4.5% (my maht hw*100/accepted).

Find out at what page users started reporting reception of miners and what they did that was or was not successful at improving performance.  (chuckles)

I'd suggest shutting down, then putting light pressure on the tops of the VRMs one at a time.  Don't expect to put enough pressure to get a snap sound.  Then boot and install firmware 0.90, run enablecores.bin, shutdown, wait 30 seconds, startup.  Open a new browser, go to your webpage address, sign in, hit check status, wait a few seconds, give it a control+F5, the browser refreshes, at this point sometimes it will only show 2 or 3 cores.  Close IE, open a new instance of IE, repeat the process, you should now see all cores and at what percentage they're running.  If there's an improvement you can move up in firmware versions or stay with 0.90.  Anything over 0.94 will use less energy.  Then decide if the increased power usage warrants the additional GH/s and go with the firmware you feel is best.

 going back to 0.90, running enablecores.bin,

Down here where it might cost $5.50/100watts/month, and I think the difference per module is more like 148w now up to 258w, at the wall for me with a somewhat less efficient power supply, but if yours goes up 150w/module at the wall to 250w/module at the wall you're looking at 400watts/hour for for a month.  If at 7.5¢/kwh it costs me ~$5.50/100watts continually for a month, then at Hawaii power rates and 4 modules not 1, what will your power cost increase be?  Of course the BBB power is now divided by 4 so that's a little less.

And you now have 200+watts more at the wall for each Saturn?