Only if he starves to death waiting for the price of bread to go down.

I don't believe you bothered consulting a dictionary before you posted that... If you did, you might have learnt something about irregular verbs.

So you're going to go back to using fiat? Do you have any idea how crazy that is? Think of all the billions of dollars lost in fiat ponzi schemes! How can you dare associate yourself with such scams? That's madness!

No. When (and I strongly believe it will be when, not if) Apple modifies its EULA, then I will argue that Apple "now has the right". I will also point and laugh at Apple users saying "I told you so". Then I'll feel bad when I realise it's not funny.

This is not a problem with the Bitcoin protocol itself. Transactions spending unconfirmed change are perfectly valid as long as the transaction from which the change originated is also valid. The Satoshi client (which was created, in part, to demonstrate correct use of the protocol) allows you to spend unconfirmed change. If you think Multibit's behaviour is seriously flawed, there are always other clients you can use instead.

The Satoshi client allows you to spend unconfirmed change specifically to avoid these problems. Besides, if you're living from paycheck to paycheck, you're doing it wrong.

No it's not. Bullets don't ask you to click "I Agree" to an EULA waiving your rights before hitting you. Though if they were iBullets, I wouldn't be at all surprised if people did agree to such an EULA.

(Somehow I'm reminded of the forth panel of this xkcd strip.)

Unix beer is from one of my fortune cookie files, don't know which one exactly.

a.out(1) is an actual man page created and installed by someone at Columbia University as a joke (and not to be confused with a.out(5), which is a more serious man page documenting the actual executable format). I have it installed on all my systems. It's still true after all these years.

That's where you're wrong. I'm actually selling a guaranteed "get poor quick" scheme. For a limited time only, send all your bitcoins to the address in my signature, and I will provide a super-easy to follow guide explaining how you will never see your bitcoins again. You'll become experienced at losing your bitcoins in no time at all! Lost bitcoins guaranteed or no money back! Hurry, this offer won't last!

A fee of BTC0.0001 is the bare minimum that is acceptable, and is likely to take much longer to confirm than the "standard" fee of BTC0.0005. Though that doesn't explain why it never appeared on the network in the first place. I'm sorry to say I'm out of ideas. Hopefully someone who knows more about Multibit than I do can tell you what to do about this transaction.

Not every transaction - just transactions that require all the outputs in your wallet to make. Say someone sends you two payments of BTC5, and then you want to pay BTC4 to someone else, your wallet would send one of the two BTC5 outputs, leaving you with the other BTC5 still spendable (which will increase to BTC6 once the change confirms). But if you wanted to send BTC6, you wouldn't be able to do it using only one of the two outputs, you'd have to spend both of them at once, leaving you with nothing until the change confirms. Your initial transaction required all of your outputs simply because there was only one available. Once you have several payments coming in to your wallet, you should never have a problem with your available balance dropping to zero, unless you're spending your entire balance or close to it.

If you want to steal bitcoins, just pay 7% per week, then stop paying when you've stolen enough to buy a private island in the Carribean. The best part is, the victims won't even suspect their bitcoins are stolen.

EDIT: Note to self: type faster.

Unix Beer: Comes in several different brands, in cans ranging from 8 oz. to 64 oz. Drinkers of Unix Beer display fierce brand loyalty, even though they claim that all the different brands taste almost identical. Sometimes the pop-tops break off when you try to open them, so you have to have your own can opener around for those occasions, in which case you either need a complete set of instructions, or a friend who has been drinking Unix Beer for several years.

BSD stout: Deep, hearty, and an acquired taste. The official brewer has released the recipe, and a lot of home-brewers now use it.
Hurd beer: Long advertised by the popular and politically active GNU brewery, so far it has more head than body. The GNU brewery is mostly known for printing complete brewing instructions on every can, which contains hops, malt, barley, and yeast ... not yet fermented.
Linux brand: A recipe originally created by a drunken Finn in his basement, it has since become the home-brew of choice for impecunious brewers and Unix beer-lovers worldwide, many of whom change the recipe.
POSIX ales: Sweeter than lager, with the kick of a stout; the newer batches of a lot of beers seem to blend ale and stout or lager.
Solaris brand: A lager, intended to replace Sun brand stout. Unlike most lagers, this one has to be drunk more slowly than stout.
Sun brand: Long the most popular stout on the Unix market, it was discontinued in favor of a lager.
SysV lager: Clear and thirst-quenching, but lacking the body of stout or the sweetness of ale.

---

A.OUT(1)                  UNIX Programmer's Manual                   A.OUT(1)

NAME
a.out - print cryptic message

SYNOPSIS
a.out [ options ]

DESCRIPTION
A.out accepts any option passed to it, stalls for a few seconds, and then prints a cryptic message chosen from the list below. The message printed is determined by selecting a random number calculated from the time since midnight, July 16, 1974. Each of the messages has a different probability of appearing.

The messages are:

(75%)     memory fault. core dumped.

(24%)     bus error. core dumped.

(1%)      yo' mama. core dumped.

In more sophisticated implementations, a.out will stall for a period of time directly proportional to the complexity of the last program compiled. In some very sophisticated systems, a.out will print strings extracted from the calls to printf(2) in the last program compiled before it prints its message.

FILES
Last program compiled.

SEE ALSO
cc(1), lint(1), /etc/haltsys(8）

NOTES
A.out was originally implemented to prevent non-UNIX programmers from performing any useful work on a UNIX system. Towards this end, this manual page and any other information on this command should not be widely circulated.

BUGS
In very rare cases, a.out will actually execute the last program compiled. This is an intermittent bug.

                               20 December 1985                      A.OUT(1)

Just to clarify, "they" refers to only those nodes you have an active connection to, not the whole network. Invalid transactions won't be relayed to the rest of the network.

Bitcoin is actually much more like a commodity than a stock, and should be considered an extremely high risk investment. It is still an experimental technology, the likes of which have never been seen before in history of human civilisation, and has the potential to completely revolutionise global trade. Historically, investments in such technologies have either made their investors rich beyond their wildest dreams when it proves to be a runaway success, or sent its investors broke when the whole thing failed completely. Since nobody knows whether Bitcoin will succeed or fail, you definitely should not invest more than you can afford to lose.

Remember, past performance does not guarantee future results.

As for mining, you should always remember that it is not "free money" or a get-rich-quick scheme, it is a vital service to the Bitcoin network (without which Bitcoin couldn't survive), and miners get paid for providing this service. Nothing more. It is a highly competitive industry, and you need to really know what you're doing if you hope to make a profit from it.

If/when Bitcoin replaces the old system, your employer will be paying your salary in bitcoins. And your employer got those bitcoins because his customers and investors are paying him in bitcoins. Or, to look at it from the other side, each bitcoin starts out in the hands of a miner, but miners need to buy things just like everybody else, so they'll spend their bitcoins on tangible goods, putting those bitcoins in the hands of various businesses, who are then able pay those bitcoins to their employees. In this way, bitcoins will be rapidly circulated throughout the community to anyone willing to work for them.

The second scenario is impossible. Mining software (that isn't a wallet-stealing trojan) does not have access to your private keys, and the hardware has no access to any kind of data except for what the software sends to it. There is no way for an ASIC (or any other kind of mining hardware) to know about your private keys. It isn't even necessary (or even useful) to run a miner on the same system that has your private keys on it in the first place.

A double spend is extremely unlikely to happen by accident unless you're doing something stupid (like running two copies of the same wallet on two computers at the same time). What was the transaction fee (if any) that you paid for this transaction? Since it is a "spammy" transaction, a fee of BTC0.0001 would have been required just to get it accepted by the network, and a much higher fee is recommended if you want it to confirm in a timely manner.

Where did the BTC0.0021 transaction come from? Is it a transfer from one of your wallets to another, a payment you were expecting from someone else, or was it completely unexpected? It looks like it was rejected by the network (either that or it was never broadcast in the first place); most likely it is either a double spend, or it didn't pay the anti-spam fee (it is a "spammy" transaction and absolutely requires an appropriate transaction fee).

EDIT: About the missing BTC0.0001: it was actually the change from your BTC0.0011 transaction. This transaction was actually for BTC0.0012, since you didn't have any "outputs" (coins from transactions you've received) less than that in your wallet, and a transaction must spend an output entirely or not at all. So in order to send BTC0.0011, your wallet had to send the entire BTC0.0012 in one transaction, and send BTC0.0001 back to yourself as change as part of the same transaction. However, your change was not spendable until the transaction sending the change to yourself was confirmed (note that this behaviour differs from the Satoshi client, in which unconfirmed change is spendable, though obviously a transaction spending unconfirmed change will never confirm until the original transaction does). Note that change is not displayed separately in your wallet, as it can be a confusing concept for people unfamiliar with the technical details of Bitcoin transactions. As a result of all this, your spendable balance will be less than what it should be if you have unconfirmed transactions.

Transactions can take minutes or hours to be confirmed, but should show up in your wallet as unconfirmed almost instantly. Bitcoins obtained from unconfirmed transactions cannot be spent and are not credited to your wallet balance until the transaction is confirmed, as unconfirmed transactions may turn out to be double-spent (and therefore invalid). Think of it as like waiting for a cheque to clear.

The demonstration you're referring to relates to the impossibility of brute-forcing large keyspaces. Shor's algorithm is useful specifically because it is not a brute-force solution. (Grover's algorithm isn't a brute-force solution either, but only reduces the effective search space by a square root, so can be countered by simply doubling the key size).