# How secure is the Bitcoin protocol?

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.)

-
Now that Bitcoin SE is open, should this question be moved there? –  ripper234 Jan 2 '12 at 7:39

There are several uses of cryptographic algorithms in the protocol.

## Accounts/Transactions

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.)

## The Block chain

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.

-
SHA-265 should be SHA-256, I guess. And is it really RIPEMD-160(SHA-256(public-key))+SHA-256(SHA-256(public-key)) with one RIPEMD-160 and three SHA-256? Is + addition, concatenation, or XOR ? –  fgrieu Aug 25 '11 at 7:34
Good catch. I meant concatenation, but it shows that I misread the specification here - the second+third SHA-265 are applied on the output of RIPEMD-160, not on the original key, and one will only take the first four bytes of the result. (I'll update this.) –  Paŭlo Ebermann Aug 25 '11 at 11:43
The cascade RIPEMD-160(SHA-256(..)) seems adequate. Using two hashes to build a checksum is strange, but of course this is not a security issue. –  fgrieu Aug 25 '11 at 12:24