It's true that if say price of XBT doubles or triples, currently unprofitable mining operations can suddenly become profitable.

Nop, paste it in the main directory, then start Bitcoin-QT it should detect the file and start importing.

HOW TO INSTALL?
You have to click on the "Completed order" receipt link for download. This receipt you would have received via e-mail. Then once clicked, a download will begin so just and save the file and remember where you saved it.

No, I verified its existence using my old forum backups.

Maybe Theymos is an NSA plant putting back doors from the 1990's into the forum?

http://www.nsa.gov/ia/_files/app/Reducing_the_Effectiveness_of_Pass-the-Hash.pdf

Prohibited in base58 for Bitcoin: and 1l - thats the only two pairs.  o and L are allowed though.

Theymos can change your name for free upon request, but if you plan on changing it often you should become a donator.

I believe that this is how the attack was done: After the 2011 hack of the forum, the attacker inserted some backdoors. These were removed by Mark Karpelles in his post-hack code audit, but a short time later, the attacker used the password hashes he obtained from the database in order to take control of an admin account and insert the backdoors back in. (There is a flaw in stock SMF allowing you to login as someone using only their password hash. No bruteforcing is required. This was fixed on this forum when the password system was overhauled over a year ago.) The backdoors were in obscure locations, so they weren't noticed until I did a complete code audit yesterday.

Because the backdoors were first planted in late 2011, the database could have been secretly accessed any time since then.

You are lucky that the hacker couldn't think of anything interesting to do; however that machine is not 100% secure unless it can be image-restored or reloaded. An intrusion detection system would have alerted to any system changes or the downtime. The hacker's goal may not have been to steal Bitcoins, it may have been to discover the site owner's identity or that of players or to log credentials.

We thwarted a hacking attempt on Bitcoin Video Casino and learned a lot. We wanted to share our experience so that other site operators can be prepared.

On Monday Sep 9th, an attempt to hack into Bitcoin Video Casino was made. We initially noticed something was amiss because our server had become unreachable for several hours. When our server eventually came back online again, we noticed that the machine had been restarted. Our server has had a 100% uptime since we launched (~185 days ago) and this is the first time it was restarted.

We snooped around a bit and found an open login by a user on /dev/tty1, a local controlling terminal. That's very bad. All logins should only be from psuedo-terminals (ptyX). More looking around found a script hiding in /etc called "bitcoin.sh" and a crontab entry meant to constantly restart the script. The script was nothing but a phone home to this intruder's Amazon EC2 instance and wasn't very clever, but it did the job it was intended to. Unfortunately for the hacker, he left his private key on our servers.

We took all of the standard precautions when building our website: offline cold storage of most Bitcoins, closing down open ports, disabling password logins (ssh keys only!), but most importantly we decided to use full disk encryption, with the disk decryption key encrypted with GPG.

The downside to full disk encryption is that our site cannot come up automatically after a reboot. That's fine, really, we never reboot the machine anyway. So once the would-be hacker restarted the machine, he had no way to access our database, our hot wallet, or our game source code as they reside on the encrypted disk. The hacker couldn't even mount the encrypted disks, as the decryption key isn't stored on the server.

We had a long talk with our hosting provider on how this happened. Nobody should be able to log into our machine locally (the /dev/tty1 part). We thought that someone local to our hosting provider's data center was trying to break in, but as we pressed for answers, we learned that a KVM device was installed that allowed remote access into our machine one day prior to the hack. The evidence that the device was plugged in was present in the kernel log ('dmesg'). While the machine was rebooted, the hacker modified /etc/sudoers and changed an account password so that he could have access after the reboot. Later, auth.log would verify his activity.

So why did someone working at the datacenter install a KVM on our machine when we didn't request it? It turns out that our hosting provider's billing software was actually where the hack began. An order was fraudulently placed on our account to install the KVM through his hacking of HostBill, the software our hosting provider uses. It's a particularly popular piece of software, so it's likely other hosting providers could be vulnerable.

Anyway, the long story short is that we didn't lose any of our Bitcoins or our game software because of one smart move: full disk encryption. We highly recommend to all you developers out there to use full disk encryption if you have sensitive data to protect on remote servers. Full disk encryption doesn't help thwart hot attacks while the site is live, but it does help tremendously when hackers could possibly get physical control of your remote-hosted machine.

Note: We also posted this to Reddit, so all of the redditors on here can see the post at http://www.reddit.com/r/Bitcoin/comments/1nicl9/we_thwarted_a_hacking_attempt_on_bitcoin_video/

I know this idea has lots of holes in it but,
(there is always a 'but')

Could a DEFENSIVE only Low Orbit Satoshi Cannon be developed to fight back against ddos on pools?

With a federal government shutdown, padlocks are expected to begin going up Tuesday at the gates of hundreds of national parks across the United States from Alcatraz Island in San Francisco Bay to the Washington Monument. Thousands of visitors will be sent home, and local businesses will suffer.

During the last government shutdown, for 28 days in 1995, national park closures sparked waves of angry calls to Congress and the White House.

"Once the shutdowns began, the reaction from people who wanted access to the parks was absolutely incredible," Bruce Babbitt, who was U.S. Interior Secretary
at the time, said in an interview Monday.

"The first call I got was from the governor of Wyoming, who was having a fit. He was saying 'You have to open Yellowstone. This is an outrage. Do something!'"

The Republican governor of Arizona, Fife Symington, sent National Guard troops to the Grand Canyon in an attempt to keep the park open, rather than risk losing tourism. Eventually, Arizona officials paid the National Park Service through state funds and donations to keep famous sites along the South Rim open.

I just want to see how long it takes to bust when able to double your bet at least 15x.