Do you want the King to investigate this?  What the heck do you mean royal commission?

I am curious about this as well.

Thanks

In the online fraud community, if you can come across someones SS# along with bank info, you can easily gain access to their online banking and keep an eye on the deposits as well...

This may be turning into an easy way for thieves to get physical access to the money they're stealing.

I use a tool called pwqgen:

nux@stone:~$ pwqgen random=81
Under8Aroma-levy7boyish3Tutor
brass5cork!Trim=Warmth=Cycle
Rudder+colon$Dense2radio$Guilty
Tariff2Maybe7Bark7ribbon2wipe
Warp9noun_Dove-Tweed*Gang

You can even get somewhat readable/memorizeable passwords if you want

nux@stone:~$ pwqgen
Nicely+French&Viola

Lol this is silly.  Comments like this make me wonder who's behind the forum username.

Anyways, cool tattoo.  Quick, easy and fun way to make some extra cash with that bounty.

One feature I thought would be handy is something like a worker group.

Essentially a way to mass manage a handful of workers.  For example, create a pool, and update 9 workers at once to all use it with the same login, password, priority etc.

I currently just use SQL to do it manually.  Add a worker_id/pool_id combo manually, and then an UPDATE .. WHERE pool_id = to add a pool to every one of those workers.

After watching tshark, poclbm.py output, and tailing the access log for the proxy, I have determined that a low KeepAliveTimeout setting in the Apache config was the culprit.

The KeepAliveTimeout on my server was 3 seconds, and the ask rate was 5.  This caused the miner to try to use a KeepAlive session, only to find it timed out.  Then it had to establish a new connection.  This was giving the connection issues I was seeing.

Essentially what this means is the KeepAliveTimeout setting has to be higher than the ask rate.  I would suggest adding a few seconds on top to make sure there's a little wiggle room.

Anyone else having this issue?  I tried a fresh install of the proxy and still having the problem.

This only started after upgrading to  the latest poclbm.

Here's my output:

proxy.hostname.net:80 11/07/2011 11:31:01, Setting pool g11 @ proxy.hostname.net:80
                                                                                proxy.hostname.net:80 11/07/2011 11:31:02, Using new LP URL /index.php/1/aHR0cDovL3VzZWFzdC5idGNndWlsZC5jb206ODMzMi9MUA%3D%3D
proxy.hostname.net:80 11/07/2011 11:31:02, LP connected to proxy.hostname.net:80
proxy.hostname.net:80 229016 khash/snicating with bitcoin RPC 0 2
proxy.hostname.net:80 229331 khash/snicating with bitcoin RPC 0 2
proxy.hostname.net:80 11/07/2011 11:32:15, 02463d19, accepted 0 2
proxy.hostname.net:80 Problems communicating with bitcoin RPC 0 2
proxy.hostname.net:80 11/07/2011 11:32:34, c30efce9, accepted 0 2
proxy.hostname.net:80 228730 khash/snicating with bitcoin RPC 0 2
proxy.hostname.net:80 11/07/2011 11:33:56, 1888d04e, accepted 0 2
proxy.hostname.net:80 11/07/2011 11:34:42, 92512293, accepted 0 2
proxy.hostname.net:80 215716 khash/snicating with bitcoin RPC 0 2

I'm using the latest version of the proxy software, and the latest poclbm.  Since updating to the more verbose poclbm (week or two ago) I see this error all the time:

proxy.hostname.net:80 Problems communicating with bitcoin RPC 0 2

Then it recovers from 0mhash/s and looks like this

proxy.hostname.net:80 93870 khash/sunicating with bitcoin RPC 0 2

until it gets back up to the normal speed (which takes just a second or so).

I see this happen every few seconds give or take.  Has anyone else seen issues like this?  Since the last week or so I've had to stop using this awesome software as that error slows down my hashing.

Thanks

Edit: I'm running Apache on Debian.  Server is tuned to handle a lot of load, and is nowhere near capacity.  I'm not finding any issues in the error_log files and not sure how I can debug further at this point.

There was just 30 in stock 20 minutes ago or so.

When you install an application and it asks for your password to continue, entering that password allows it to operate as root to normally modify system files or something similar.

Having root wont do you any good to get the wallet file in itself, but the moment you log in as that user and mount the encrypted drive, it will be accessible by root as if there were no encryption.

I'd say it's a rock solid setup, and until Macs become a much bigger target it will continue to be.  Just be mindful of what applications you allow to install on your system.  There was a recent Mac "virus" that was just a file distributed to people.  Only the people that decided to install it were infected.  Stuff like that is what you'd have to worry about.

If someone gets access to your machine as root, they can wait for you to login to the secure account next time and easily copy the wallet file.

Mac's aren't as big of a target for malware anyways, and to have an encrypted account on the machine get compromised isn't very likely.

But it would only take you typing in your password to install one piece of software as root to compromise this setup.

Does google get a new wallet each time it visits - or are these possibly users wallets that had their data reported to google via the toolbar, or possibly to alexa or any other similar company?

http://www.google.com/search?q=site:instawallet.org&hl=en&prmd=ivns&filter=0&biw=1576&bih=636&num=100

They said they would give 24 hour notice before trading starts.  The only change they made was not open the site with trading closed earlier.

They still gave 24 hour notice of trading opening.  You just can't get into your account as soon.

Any luck in moving the voltage without flashing the BIOS?  I was able to confirm that the GPU clock was able to move above the limits I saw on the previous version.

Is there any ETA as to when mtgox.com will be operational again?

Thanks

The thing is with Other, is they're not in the same pool.  So if the other hash rate topped 51% it wouldn't have the same effect as deepbit or another pool.

I recently got into BTC, and outfitted a previously unused desktop from 4 years ago with 2xRadeon 5770s.  It had two PCI express slots so it worked fine.

Been running fine for days.

So old equipment definitely can work well with new video cards.

You can run the bitcoind with -daemon flag.

From there you can run bitcoind help to get list of commands, but one of them is:

bitcoind setgenerate true

You can also point poclbml.py or whatever mining application you have at the bitcoind instance to mine solo.