Are there any evidence (other than not being cracked so far) that the Bitcoin protocol is secure? "How secure" is it?
(I realize that this might not qualify as a meaningful question - feel free to edit if you can improve it. Also, if you liked this question, you might like the Bitcoin Proposal.)
There are several uses of cryptographic algorithms in the protocol.
To move money from one account to another, you need to collect some data (the previous transaction(s) which got you the money, the target account, the amount you want to transfer) and sign them, using the private key which belongs to your account.
For this signature Bitcoin uses the ECDSA algorithm.
If I can fake your signature, I can also steal your money.
The (public) addresses of the accounts are given as address = version || hash || checksum, where version = 0 (one byte), hash = RIPEMD-160(SHA-256(public-key)) and checksum = first 4 bytes of SHA-256(SHA-256(version || hash)). (The checksum mainly protects against transmission errors.)
If I can somehow generate a private key whose corresponding public key has the same SHA-256 hash as your one, it will have the same address, and I can steal your money. If I can create a fitting private key for your public key, this is also possible.
For now, there is no known attack at the ECDSA algorithm (and I think even with second-preimage attacks at SHA-2 to find a second public key with same hash, you would need an attack at ECDSA to get a useful private key).
It is much easier for now to use a trojan or such to steal the actual private key of the owner. (But this would be off-topic here.)
For a transaction to be deemed valid, it has to be included in the block chain, e.g. in one of the blocks consisting this chain.
To create this block, a miner uses a Merkle tree of hashes, which refer the individual transactions included in this block, the previous block, and some other data. This tree uses SHA-256, too.
A block is considered valid (e.g. other peers will accept it, and build their own blocks on it) if the hash of the header is lower than some number (the "target"). This can be reached by manipulating one part of the block, the nonce value, calculating the hash, and repeating until one is lucky hitting the right nonce to make this block valid.
If there are several valid blocks running around (which are not descendants of each other), "good" miners will usually build on the one with the longest chain.
So, how could we cheat here?
If we can break SHA-2, e.g. by finding a faster way to get the right nonce than trying many of them, we can generate the blocks faster than everyone else. This would mean that we will get all of the mined coins, at first. Having a monopole, we can also effectively decide which transactions to include and which ones not (this could be a denial-of-service for competitors who want to transmit money).
I'm not sure if we could in fact include bogus transactions this way (or by other SHA-2 breaks means) in our Merkle tree - I think the receivers of a blocks should still check if its transactions have actually a valid signature.
For now, no such break of SHA-2 is known.
Most of what the bitcoin system does consists of using well-known algorithms for their intended purposes. It is unlikely that there will be a fundamental or algorithmic problem in these parts of the system.
There may be a software bug in the reference client, of course. There once was such a bug -- an overflow bug that allowed people to create transactions that spent absurd numbers of bitcoins, effectively creating them without limits. Once this was detected, a new client was deployed and the corrupt blocks were rejected, effectively undoing all transactions after the first buggy transaction.
While this fixed the problem, it does point out one weakness: software bugs could result in large sections of the block chain being 'undone' as if those transactions never occurred. One workaround to this is to store all transactions that sent coins to you. If they're ever undone, you can then resubmit them. Assuming the person sending the coins to you didn't intend a double-spend attack, the transactions should still be valid. So that should mitigate the risk, assuming the person exploiting the bug wasn't also trying to specifically double-spend coins to you and someone else.
The bitcoin system does do one thing in a very fundamentally unique way, that is the way it is determined which blocks are part of the official public hash chain. This does have some known weaknesses, such as the 51% attack which allows someone who controls more than half the hashing power in the network to launch double-spending attacks or deny any transactions he wishes.
It may, of course, also have completely unknown attacks. It's pretty hard to assess that risk.
There are a number of known attacks that can occur right at the point of block formation. The most recent one, transaction malleability, wasn't really the reason for Mt Gox's demise, but it surely created some problems (and for the most part has been fixed). Unfortunately there is a theoretical, but pretty convincing theory, about what has been called cartel or selfish mining attack, that works with much less than 51% of the hashing power. Clearly switching the 'proof of work' can perhaps subvert the attacker, but that is not built into the code. Currently there are no 'parachutes' inside of bitcoin in case these attacks are made.
Bitcoin blockchain allows immutability ( along with transparency). This means if once you write data it is nearly impractical to change the data. Since, the new blocks keep getting added to store upcoming data and to change any bit of data you need to change all upcoming blocks, breaking so much of encryptions while coping up with more of blocks that are formed in impractical.
