It depends what you want to be secure against.  Using an encrypted volume for the VM makes it so that someone with physical access to your computer cannot see your data without the key - it provides local secrecy.  Using TOR makes it so the people you're connecting to cannot see your identity - it provides anonymity.  Neither of these inherently strengthens the other.

Actual security depends on other factors.  If the web browser in your VM has a security vulnerability, the site you connect to could exploit it to disclose your IP address and upload a copy of all the files in the VM.  If the VM has a vulnerability they may be able to view the rest of your computer as well.  To protect against this you need to run the latest versions of each.

One good option is to use Tails on a dedicated netbook with no hard drive, just a CD drive.  Tails at least makes sure that all internet traffic goes through TOR (it firewalls everything else off) and that no logs are kept after you shut down, and using a dedicated netbook prevents access to your data, but it still can't prevent disclosing your IP if there is a vulnerability in the included software.

A zero wipe changes it from "here run this utility" to requiring an electron microscope to maybe POSSIBLY recover something (at modern drive densities it's debatable whether it's possible at all).  That's close enough for most people.

There are already some "pay you to watch ads" services out there, so if I wanted to do that, I would.  Instead of getting slightly better payouts by submitting hashes with a JS/Java miner, I could just as easily mine BTC/LTC directly.

It certainly isn't enough to justify creating a new coin.  You might be able to make an ad-watching service that HAPPENS to mine LTC, but I don't see where there would be a synergistic effect from tying them together be worth the effort.

It depends what part you want to be open source.  Yubi uses OATH which is an open protocol with plenty of open source software supporting it.  If you want a hardware token that runs an open source firmware, I don't think that exists, but you could use an open source OATH soft token on either a PC or a cheap android device.

There are many other ways to do things (proof-of-stake, demurrage, different inflation schedules ... ) which MIGHT be better and which people want to try, but which are too much of a fundamental change to be appropriate for Bitcoin.  Thus alternate cryptocurrencies are born.  Most will be niche currencies that are mostly proofs of concept, but it's possible that one will get just the right combination of stuff to overcome Bitcoin's first mover advantage and replace it.

It still cuts and pastes. 

I suggest a non-OEM battery.  Anker (good, cheap, laptopmate_usa @ebay) and Lenmar (better, less cheap) have both treated me well.

To clarify: major releases (feature upgrades) are every 6 months (Ubuntu) or 24 months (Ubuntu LTS), but bugfixes and security updates are released whenever they are needed.


This isn't really a problem for a new user, but it's good to know why the alternatives exist.  Different preferences for tradeoffs like these are why there are so many distributions.


Ubuntu:  "Oh god, I have to schedule a couple hours to upgrade everything and make sure it all works afterward.  This sucks."

Gentoo:  "Oh god, this worked yesterday, why did they have to change it?"

Pick your poison. 

For general purpose use: http://www.ubuntu.com/

For an all-TOR, no traces left behind session, this is a useful live CD / USB (no install required): https://tails.boum.org/

Snow Leopard is OSX.  You're good to go.

Good to hear it worked out!  Always glad to help.

Yes, always wipe your hard drives...  AFTER you save your BTC. 

Makomk deserves most of the love, but if there's any left over you can send it to 165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g . 

.cpp and .h are C source code.  Your wallet should just be called wallet.dat.  It will usually be in /home/<username>/.bitcoin .

sudo cp new_wallet.db /media/usb_stick_name/

Do you have another USB stick?  If so just put it in and then:

Find the USB stick's name:
ls /media

Copy the recovered wallet there:
cp new_wallet.db /media/usb_stick_name/

Incorrect.  Quantum mechanics is a set of actual physical phenomena which are completely real and observable.

Quantum computers exist today.  In 2001 IBM successfully used Shor's Algorithm to factor 15 into 3x5, which is the smallest meaningful application possible.

The threat is not imminent, but it's definitely a concern in the long run (50+ years).  It's not yet known if a quantum computer powerful enough to crack crypto will ever be possible.  It's possible that the power requirements will prevent it from being feasible.  NMRQC (as used by IBM) certainly won't scale to crypto-cracking sizes.  Nonetheless, it's still a significant proof of concept.

As for ECDSA, the short term threat that it, like all public key crypto, is based on principles that are less thoroughly explored and understood than symmetric and one-way crypto.  It is therefore generally considered more likely that a significant cryptographic flaw will be found in ECDSA than in SHA2 or RIPEMD.



I suggest:  create a series of paper wallets and make one deposit to each address, using standard RIPEMD addresses, which I consider to be the strongest form.  By breaking it into a series of smaller wallets you remove the incentive to crack a single large wallet (in case of a partial break which requires considerable cost to complete).  When you eventually spend, send the change to another new address each time.

Then make several copies of the paper, and keep them in several safe locations.  You are far more likely to lose your coins because you either lost the keys or someone else found your wallet than due to a crypto break.

AES-256 ASICs can significantly outperform CPUs with AES-NI.  When you don't have to do all the other things a CPU has to do you can stamp a lot of AES-only cores onto relatively little silicon.

The idea of Scrypt is it requires lots of low latency, high bandwidth memory.  It's completely uneconomical on an FPGA.  An ASIC using external DRAM wouldn't be much faster than a CPU with external DRAM.  An ASIC with on-die RAM would be very expensive in terms of silicon and therefore monetary cost.

In other words, Scrypt already is pretty close to a CPU-optimized hash.  GPUs can accelerate it some, but not tremendously because memory is still a bottleneck.  ASIC versions wouldn't come out enough cheaper in $/Hps or J/H to justify the development; at almost any level it's easier to use cheap commodity hardware.  I'm not saying it's impossible; you just won't see the massive speedups like are possible with SHA.

Scrypt would probably benefit from an increased memory requirement.  Adjusting the memory requirement based on difficulty would probably make it an adequate CPU (and to a lesser degree GPU, which are just specialized CPUs after all) friendly hash for the foreseeable future.

Was the wallet encrypted?  There's a note on that thread that the tool doesn't work with encrypted wallets.  If it was using the encrypted format then we may have to modify it a bit.

Info on recovery utility here:  https://bitcointalk.org/index.php?topic=25091.0

You will need to burn a Linux boot disc using another computer.  SystemRescueCD is a good choice.  Put it in the mac, hold down the C key, power on, then release it when it starts to boot.

The thread has instructions on how to perform the recovery.  If you're not familiar with using Linux (let alone the command line) then you'll probably find it a bit confusing.  We'll help you through it.

Yes.  TURN THE COMPUTER OFF IMMEDIATELY.  Don't shut it down or anything, just pull the plug.

There is a utility that scan scan the whole hard drive for lost wallets.  I will get you more info in a moment.

It's an extremely small possibility because 2^160 is a very big number:

1461501637330902918203684832716283019655932542976

If 10 billion people generate a million addresses every day for 100 years, you end up with:
365000000000000000000

Notice that there are a LOT less digits in that number.  Due to the birthday paradox the possibility that SOME address will collide is considerably larger (but still remote), but the possibility that YOUR address will collide is practically zero.

As mentioned above, you can use the sig directly if you wish, but I would not recommend it.  The chance that it would be a problem on accident is vanishingly small.  The real concern is an attacker creating a collision on purpose.  ECDSA is considered much weaker cryptographically than RIPEMD160(SHA256()), so for practical purposes, you're probably better off using the MD160 key with a virgin address with no public spends (which would reveal the pubkey).