Difference between revisions of "Thin Client Security"

From Bitcoin Wiki
Jump to: navigation, search
Line 14: Line 14:
  
  
==== Block Depth as a Transaction Validity Check ====
+
=== 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.
+
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.  Other thin client protocols also include this assumption.
 +
 
 +
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'''.
 
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'''.

Revision as of 00:59, 15 January 2012

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.

Full-Chain Clients

The "thick" bitcoin client downloads a copy of the entire chain, including all transactions (not just headers). It will be used as the reference point for security comparisions below.

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. Other thin client protocols also include this assumption.

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.

Unused Output Tree in the Blockchain

There have been several proposals (the first appears to be this one by gmaxwell) to form a tree of unused transaction outputs at each block in the chain, hash it as a Merkle tree, and encode the root hash in the block chain (probably as part of the coinbase input).

If such hashes were included in the blockchain it would let a thin client reduce the question of "is this output unspent" to the question of "is this block super-valid" where "super-valid" means "valid according to the normal blockchain rules and additionally has an Unused Output Tree which is accurate and truthful". This is still a long way from the low level of trust involved in the thick client, but it is a major improvement over all existing proposals.

It is unlikely that bitcoin would ever arrive at a state where every single block had a UOT, since this would require upgrading 100% of the miners on the network, or else convincing enough miners to reject blocks which do not contain a UOT. The latter strategy risks creating blockchain forks, which can be expensive (in reward terms) to miners. Therefore, any UOT strategy would need to cope with the fact that not every block contains a UOT.

Hostile miners may insert blocks into the chain which have what claims to be a UOT, but which is actually invalid. It is unlikely that such blocks could be kept out of the chain because, again, this would require adding a new block validity criterion, and miners implementing this new criterion would risk "mining on the wrong side" of a fork, which could cost them a lot of money. Therefore, any UOT strategy would need to cope with the fact that not every block containing a UOT entry can be trusted.

Note that at the present moment no standard format for such Unused Output Tree hashes has been agreed upon, nor are do any of the blocks in the chain contain them.

Server-Trusting Clients

These clients involve some (usually low) level of trust in the server they rely upon. Mechanisms for authenticating the server, and for confirming 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.

Other

  • A thread on bitcoin-dev
  • A question on bitcoin.stackexchange.com
  • The "cancer nodes" paragraph explains some of the issues with thin clients that base security on trusting whatever "a majority of the IP addresses I can see" say.