It's not counterfeiting.  It's just fractional reserve banking.  MtGox "loaned out" a million bitcoins that it didn't actually have.   

Heh, if the bitcoin blockchain had as many unresolvable splits as the bible, it would have been a complete and utter failure by this point.  No one would be able to agree on who spent what and how now possesses what.

Either that, or local areas would just have their own "denominations" of bitcoin.   

Markets might generally thrive on efficiency, but it typically seems like government-manipulated markets thrive on corruption, and my guess is that banks have a strong ability and strong motive to maintain credit cards and all the rest, since they make such a tidy profit off of it all.  For better or worse, market forces aren't the only forces at work here.

While it's significantly more difficult than simply throwing money at it, you might look into ways you could sell items or services of some form and accept payment in bitcoin.  That way you can get your hands on some bitcoins without spending a lot of cash, just some time and effort.  This is also probably the single most important method of supporting the concept, since merchants are what bitcoin needs to ultimately be valuable as something more than a hedge investment.

Physics class taught me how to do nearly all unit conversions.  First, start with the ratio of one unit to another and represent it as a fraction, with the desired unit on top:


Then multiply that fraction by the value you currently know over a unitless 1:


The units that you start with will cancel out, since one is on top and the other on bottom.  You'll be left with just the unit type you want.


Now actually do the math, and you have your value:

That's entirely true, and is relevant for most applications of cryptographic hash functions.  But in this case, we have that nonce value that is completely open to us, and we're only trying to find any one hash among a huge number of acceptable hashes.

For a simplistic example, consider our hash function to be the sum of digits as above, but keep taking the sum of digits until only one digit remains.  1337 -> 14 -> 5, 983542 -> 31 -> 4, 183954235098345 -> 69 -> 15 -> 6.

Now say that we want to get a hash that is 9; that is, we're setting the difficulty such that only roughly one in nine streams of digits will be accepted.  We then take some content that is known, add a couple of nonce digits to the beginning of the known stream of digits, and generate the hash to find out if it is accepted.  That's the essence of the current process used by miners.  For the given hash function and difficulty, we'd need to perform on average 9 hashes with random 2-digit nonces before finding a match.

But Peter proposes the following:  Let's assume that our hash is 9, since in the end that's what it'll have to be anyway.  Now say we're trying to hash ??8645, where ?? are the two nonce digits.  We can reverse this in the following manner:  We know that the given digits add up to 23, which will then add up to 5.  We can then see that we're 4 short, so if our two nonce digits contributed four more, we'd have our hash.  So we choose our nonce to be 13 and end up with 138645 -> 27 -> 9.  We've found a nonce that produces an acceptable hash in roughly the time it takes to do just a single hash, rather than having to do on average 9 hashes.  (Even in this case it's probably more complicated than the specific example I picked, but I'm still pretty sure it would be proportional to the time complexity of a single hash, and would be independent of the difficulty intended by limiting the range of acceptable hashes.)

Given the much higher rarities of randomly finding an acceptable hash in the current Bitcoin mining environment, if that could be reduced down to anything even remotely close to being proportional to the time it takes to perform a single hash, that would completely ruin the whole point.  But offhand I don't know if it's actually feasible, given modern day cryptographically strong hash algorithms, to take an assumed hash and a mostly known stream of content, and then reverse the process to find out what the small unknown bit of content needs to be to "solve the equation".  Seeing as how the process is substantially different from what is typically considered within the field of cryptography however, I wouldn't be surprised if the Bitcoin situation provides significantly weaker security than is currently presumed.

That makes sense to me, as long as I have "normal money" to spend.  But if I keep spending it, eventually I will run out, unless I replenish my supply by earning more of it one way or another.  But when I think about that, I believe I'd be more inclined to earn bitcoin specifically due to its deflationary nature.  So eventually I would have no "normal money" left, and only bitcoin, and would gladly spend bitcoin to buy goods and services, regardless of the fact that it'll be worth more in the future than it is now.  But critics never think that far, do they?

If bitcoin depended upon calculations that served some alternative purpose in addition to securing the bitcoin network, then there is a very real likelihood that the strength of the security would be compromised.  The value of cryptographic hashing is that for all practical purposes it is so close to random that it cannot be reversed.  If the calculated output of confirming a block were an actual useful value for some other purpose, then except for maybe some very specific cases (and I'm not confident such cases even exist), that output would have significantly more of a pattern than a pure cryptographic hash.  And that pattern could be used to find exploits that could weaken the desirable features of bitcoin.  People find some awfully clever ways to defeat various cryptographic security schemes.  Even the slightest move away from focusing on pure security can open up some very subtle weaknesses in an algorithm.

Offhand, the only thing I can think of is the following (and it is highly dependent on details that I don't know, but others might):  Let's say that there is some unrelated application that needs to make a lot of hashes during its ordinary operation.  Whenever it needs to do a hash, it takes the data that it is going to hash, uses it as a nonce for an unconfirmed bitcoin block, and then hashes the bitcoin block.  If the nonce comes at the very beginning, then given most hashing functions, you should be able to grab the hash value out of the algorithm after just the nonce portion has been hashed, send that back to the application, and continue with the hashing until the full bitcoin block has been hashed.  Then compare the final hash to see if it passes the difficulty or not.  If so, you've confirmed a block.  Either way, you've hashed your unrelated data.

If the nonce does not come at the very beginning of the bitcoin block, then you can't do the above.  If the hash function in use cannot give a current hash at any arbitrary point in the process, then it won't work either.  And regardless, the above probably wouldn't generate nonces at a high enough rate to be anywhere close to competetive, even for applications that generate a lot of hashes.  (If you know of programs that routinely hash hundreds of millions of independent pieces of data per second for hours on end, then such application might be candidates for this scheme.)

And there might be other issues that prevent the above idea from being implemented; I'm certainly no expert, and I could have overlooked any number of complications.  But if there were no complications other than that the current bitcoin algorithm doesn't allow it for reasons such as the ones already considered, then that could be an opening for an alternative to bitcoin, one that has all of bitcoin's advantages (other than existing market share), plus an additional benefit:  the ability to do useful work while mining.

But again, I'm not optimistic.  I only take the time to write this idea as I thought it up in case it actually happens to have any merit, and someone goes off and does something useful with it.

Your wallet doesn't technically contain your bitcoins.  It only contains the keys which authorize you to use them.  There is one key per address, so you should only need to create a backup whenever you create a new address.  (I've been told that when you first create a wallet, multiple addresses are pre-made under the hood, which means that after a single backup, you're good until you've made more addresses beyond this initial amount.)

And yes, you can definitely reuse the same address as much as you want.  Addresses are basically like public boxes that anyone can see inside, learn the history of, and deposit bitcoins into, but only the person with the key can pull bitcoins out of.  Reusing a single address lets everyone else also easily determine that all the transactions into and out of that box are related by all being to or from the same person, thus decreasing anonymity.  And if all your money is stored behind a single address, then if someone else acquires your key to just that one address, then they have complete access to your money.  Keeping money in multiple addresses helps avoid this, except that a single wallet can contain many keys, so that to really be secure from key theft, it helps to have multiple wallets, each with just a few addresses in them.  But that complicates things a lot, obviously.  It's a bit of a tradeoff between increasing security and increasing convenience.  (They're both pretty high as it is, but if you want one to be even higher, then the other typically has to go down some.)

Disclaimer:  I am a bitcoin noob.  I cannot guarantee that I am completely accurate.