Thin Client Security
Recently there have been a number of proposals for bitcoin clients which do not store a copy of the entire block chain. I will refer to all such clients as "thin clients". This page is meant to be a place to try to make sense of the security and trust implications of the various schemes.
Thin Client Strategies
Chain-Header-Only Clients
These client downloads a complete copy of the headers for all blocks in the entire blockchain. This means that the download and storage requirements scale linearly with the amount of time since bitcoin was invented; it would be preferable to have the scaling be logarithmic or even constant.
Simplified Payment Verification (SPV)
This scheme is described in section 8 of the original bitcoin whitepaper.
Block Depth as a Transaction Validity Check
As Satoshi writes, "[the thin client] can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it." If we take "X" to be the "number of blocks added after it", then SPV essentially trusts that a transaction X blocks deep in the chain does not have inputs which were already spent further back in the chain. This is very different from the trust model in the "thick" client: the thick client verifies that a transaction's inputs are unspent by actually checking the whole chain up to that point -- there is no "X blocks deep" involved here. The thick client uses "X blocks deep" (aka "confirmations") only once it has already decided that a transaction is valid (i.e. no double-spends). At that point it uses "X blocks deep" to decide how likely it is that a longer fork in the chain will emerge which excludes that transaction.
It is very important to understand how the same property ("X blocks deep") is used to verify two different properties in the thick client and SPV cases. The thick client never uses block depth as a measure of transaction validity; the SPV client does.
This is a concern in a situation where an SPV client is subjected to a double-spend attack by somebody who controls its network connection. For example, suppose you are at a wi-fi cafe and are paying for something using your smartphone -- the cafe owner controls your network connection. Satoshi acknowledges this implicitly when he writes that "the verification is reliable as long as honest nodes control the network" -- to be completely pedantic, this means that the verification is reliable as long as honest nodes control the part of the network that the SPV client is able to communicate with. In an attack-by-ISP scenario this may not be a sufficiently strong security property. The attacker would not need to overpower "the rest of the network" because the client is unable to communicate with it.
Server-Trusting Clients
These clients involve some (usually low) level of trust in the server they rely upon. Mechanisms for authenticating the server, and that the server has not been compromised, are usually not explained.
BCCAPI
Clients are vulnerable to a double-spend attack against them by the server. Therefore, they are implicitly trusting it.
Electrum
Clients are vulnerable to a double-spend attack against them by the server. Therefore, they are implicitly trusting it.