"Eventually" would mean a security flaw. If it is not included, the money sender can never be sure whether someday somebody will use the transaction he signed to take money.

But consider the following attack:

1. A draws a transaction X to B, this means there is a transaction signed with A's private key.
2. The transaction does not get included for a long time.
3. A draws a new transaction Y to B, which gets included.
4. Now, B can use X to steal money from A.

Yes, you should never send cash via mail. But that doesn't happen with the usual use of cash: face to face.

The transaction would remain unconfirmed/0 on the sender's client, but the money is not still owned by the sender since it might still be included in a block some time in the future. In theory you could patch your client to reclaim these transactions by simply assuming it never happened.

An easy way to do this now would be to export all your keys (using bitcointools) and then import them into a new wallet then start bitcoin with the -rescan option. This would reclaim the bitcoins but if the transaction ever got included later on them they would just disappear, so if you e.g. transfer your entire balance to a new account then the old transaction would never be included as it would be seen as a double spend...

This is why you need to wait for confirmations before accepting bitcoins

Will

Similar noobish question; I've noticed after like 6 confirmations, it doesn't say unconfirmed anymore, Is it always going to be that way?

QFT

are you asking whether the client will always use 6 as the threshold at which it tells the user that the transaction is confirmed, or asking whether a confirmed transaction can ever become unconfirmed?

Will

Read section 11 of the bitcoin paper. Basically as number of blocks chained to the block containing your transaction increases, the chances if an attacker who is able to control a set portion of the bitcoin network being able to double spend the transaction reduces exponentially. Assuming an attacker e.g. a large pool, controls 30% of the network, it takes 24 confirmations to ensure less than a 0.1% chance of a successful attack. The exact numbers are in the paper.

6 seems like a reasonable number. Some merchants accept fewer e.g. 3 for small transactions. If you were buying a car with bitcoins, I would probably like to see at least 30.

If one pool ends up controlling a large part of the mining for the bitcoin network in the future, I wouldn't be surprised if the default number in the client is raised to reflect the additional risk.

Will