Thin Client Security - Revision history

Waldyrious: tweak category sort key

2018-05-22T08:20:05Z

tweak category sort key

← Older revision		Revision as of 08:20, 22 May 2018
Line 91:		Line 91:

	[[Category:Technical]]		[[Category:Technical]]
	[[category:Clients]]		[[category:Clients\| ]]
	[[Category:Security]]		[[Category:Security]]

Luke-jr: Remove inappropriate uses of SPV

2016-11-23T09:42:35Z

Remove inappropriate uses of SPV

← Older revision		Revision as of 09:42, 23 November 2016
Line 1:		Line 1:
	Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page 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.		Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page 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 Node vs. ~~SPV~~ ==		== Full Node vs. Thin Clients ==

	It is important to distinguish between block height verification and block depth verification.		It is important to distinguish between block height verification and block depth verification.
Line 7:		Line 7:
	A full node client verifies that all preceding blocks are valid in order to guarantee that a transaction is valid. Currently only the Satoshi client, libbitcoin, and btcd do full node verification. Full nodes are the fundamental anchor of trustless security in the Bitcoin system.		A full node client verifies that all preceding blocks are valid in order to guarantee that a transaction is valid. Currently only the Satoshi client, libbitcoin, and btcd do full node verification. Full nodes are the fundamental anchor of trustless security in the Bitcoin system.

	A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. ~~SPV~~ clients don't verify the preceding blocks, they use the number of confirmations (whether they are valid or not) as a measure of the likelihood of a [[Chain_Reorganization\|block chain reorganization]] producing a new longer fork which excludes the transaction.		A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. Thin clients don't verify the preceding blocks, they use the number of confirmations (whether they are valid or not) as a measure of the likelihood of a [[Chain_Reorganization\|block chain reorganization]] producing a new longer fork which excludes the transaction.

	== Full Node Clients ==		== Full Node Clients ==
Line 27:		Line 27:
	Satoshi's original paper mentions the possibility of pruning individual transactions, which allows for full nodes which verify the entire transaction history but do not retain it. Because users are required to download and verify the block chain from some other node initially, this change isn't costless.		Satoshi's original paper mentions the possibility of pruning individual transactions, which allows for full nodes which verify the entire transaction history but do not retain it. Because users are required to download and verify the block chain from some other node initially, this change isn't costless.

	== ~~Simplified Payment Verification (SPV)~~ Clients ==		== Thin Clients ==

	This client downloads a complete copy of the headers for all blocks in the entire block chain. This means that the download and storage requirements scale linearly with the amount of time since Bitcoin was invented.		This client downloads a complete copy of the headers for all blocks in the entire block chain. This means that the download and storage requirements scale linearly with the amount of time since Bitcoin was invented.
Line 35:		Line 35:
	==== Block Depth Check ====		==== Block Depth 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 will be costly to forge.		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 a thin client essentially trusts that a transaction X blocks deep will be costly to forge.

	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. 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.		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. 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.
Line 41:		Line 41:

	==== [[BitCoinJ\|bitcoinj]] ====		==== [[BitCoinJ\|bitcoinj]] ====

	~~Simplified Payment Verification is the verification mechanism used in [[BitCoinJ\|bitcoinj]].~~

	A security analysis of some of the issues in bitcoinj can be found [https://bitcoinj.github.io/security-model here]; however:		A security analysis of some of the issues in bitcoinj can be found [https://bitcoinj.github.io/security-model here]; however:
Line 50:		Line 48:

	==== [https://bitcointalk.org/index.php?topic=128055.0 picocoin] ====		==== [https://bitcointalk.org/index.php?topic=128055.0 picocoin] ====

	~~Simplified Payment Verification is the verification mechanism used in picocoin.~~

	The library (libccoin) that picocoin is based on includes code for validating scripts and blocks; this could potentially be used to implement a full-chain client.		The library (libccoin) that picocoin is based on includes code for validating scripts and blocks; this could potentially be used to implement a full-chain client.
Line 90:		Line 86:
	* The [[Weaknesses#Sybil_attack\|sybil attack (also known as "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.		* The [[Weaknesses#Sybil_attack\|sybil attack (also known as "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.
	* [http://bitcoin.stackexchange.com/questions/2613/how-secure-are-various-models-of-bitcoin-clients related discussion on Stack Exchange]		* [http://bitcoin.stackexchange.com/questions/2613/how-secure-are-various-models-of-bitcoin-clients related discussion on Stack Exchange]
	* A hypothesized [https://bitcointalk.org/index.php?topic=134318.msg1441171#msg1441171 intermediate security class] between ~~SPV~~ and full-chain validation.		* A hypothesized [https://bitcointalk.org/index.php?topic=134318.msg1441171#msg1441171 intermediate security class] between thin clients and full-chain validation.

	<references>		<references>

Pigeons: /* bitcoinj */ URL change

2016-02-25T22:28:35Z

bitcoinj: URL change

← Older revision		Revision as of 22:28, 25 February 2016
Line 44:		Line 44:
	Simplified Payment Verification is the verification mechanism used in [[BitCoinJ\|bitcoinj]].		Simplified Payment Verification is the verification mechanism used in [[BitCoinJ\|bitcoinj]].

	A security analysis of some of the issues in bitcoinj can be found [~~http~~://~~code~~.~~google~~.~~com/p/bitcoinj/wiki~~/~~SecurityModel~~ here]; however:		A security analysis of some of the issues in bitcoinj can be found [https://bitcoinj.github.io/security-model here]; however:

	* The claim that "picking 10 nodes and requiring all of them to be consistent needs much less trust" overlooks the problem of [https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes "cancer nodes"] and [http://en.wikipedia.org/wiki/Sybil_attack Sybil attacks].		* The claim that "picking 10 nodes and requiring all of them to be consistent needs much less trust" overlooks the problem of [https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes "cancer nodes"] and [http://en.wikipedia.org/wiki/Sybil_attack Sybil attacks].

Evoskuil: /* Full Node Clients */ add libbitcoin-server

2015-06-06T19:21:45Z

Full Node Clients: add libbitcoin-server

← Older revision		Revision as of 19:21, 6 June 2015
Line 18:		Line 18:

	==== [https://github.com/conformal/btcd btcd] ====		==== [https://github.com/conformal/btcd btcd] ====

			==== [[Libbitcoin\|libbitcoin-server]] ====

	=== Block Retention ===		=== Block Retention ===
Line 24:		Line 26:

	Satoshi's original paper mentions the possibility of pruning individual transactions, which allows for full nodes which verify the entire transaction history but do not retain it. Because users are required to download and verify the block chain from some other node initially, this change isn't costless.		Satoshi's original paper mentions the possibility of pruning individual transactions, which allows for full nodes which verify the entire transaction history but do not retain it. Because users are required to download and verify the block chain from some other node initially, this change isn't costless.


	== Simplified Payment Verification (SPV) Clients ==		== Simplified Payment Verification (SPV) Clients ==

Lapp0: Removed link to ambiguous comment

2015-03-02T20:37:42Z

Removed link to ambiguous comment

← Older revision		Revision as of 20:37, 2 March 2015
Line 8:		Line 8:

	A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients don't verify the preceding blocks, they use the number of confirmations (whether they are valid or not) as a measure of the likelihood of a [[Chain_Reorganization\|block chain reorganization]] producing a new longer fork which excludes the transaction.		A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients don't verify the preceding blocks, they use the number of confirmations (whether they are valid or not) as a measure of the likelihood of a [[Chain_Reorganization\|block chain reorganization]] producing a new longer fork which excludes the transaction.

	~~See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].~~

	== Full Node Clients ==		== Full Node Clients ==

Lapp0: typo

2015-02-28T18:15:21Z

typo

← Older revision		Revision as of 18:15, 28 February 2015
Line 7:		Line 7:
	A full node client verifies that all preceding blocks are valid in order to guarantee that a transaction is valid. Currently only the Satoshi client, libbitcoin, and btcd do full node verification. Full nodes are the fundamental anchor of trustless security in the Bitcoin system.		A full node client verifies that all preceding blocks are valid in order to guarantee that a transaction is valid. Currently only the Satoshi client, libbitcoin, and btcd do full node verification. Full nodes are the fundamental anchor of trustless security in the Bitcoin system.

	A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV don't verify the preceding blocks, they use the number of confirmations (whether they are valid or not) as a measure of the likelihood of a [[Chain_Reorganization\|block chain reorganization]] producing a new longer fork which excludes the transaction.		A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients don't verify the preceding blocks, they use the number of confirmations (whether they are valid or not) as a measure of the likelihood of a [[Chain_Reorganization\|block chain reorganization]] producing a new longer fork which excludes the transaction.

	See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].		See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].

Lapp0: Replace "valid" with "irreversible" where appropriate without adding incorrect statements to the article.

2015-02-28T18:08:54Z

Replace "valid" with "irreversible" where appropriate without adding incorrect statements to the article.

← Older revision		Revision as of 18:08, 28 February 2015
Line 1:		Line 1:
	Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page 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.		Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page 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.

	== ~~Block Height~~ vs. ~~Depth~~ ==		== Full Node vs. SPV ==

	It is important to distinguish between block height verification and block depth verification.		It is important to distinguish between block height verification and block depth verification.

	A client verifies ~~the height H of a block by checking~~ that ~~there are H block '''before''' it,~~ all ~~of which~~ are ~~well-formed and obey the maximum-difficulty-adjustment-rate rule~~. Currently only the Satoshi client, libbitcoin, and btcd do ~~block height~~ verification. ~~Block height is~~ the fundamental anchor of trustless security in the Bitcoin system.		A full node client verifies that all preceding blocks are valid in order to guarantee that a transaction is valid. Currently only the Satoshi client, libbitcoin, and btcd do full node verification. Full nodes are the fundamental anchor of trustless security in the Bitcoin system.

	A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV ~~clients substitute block depth for block height as a transaction acceptance check. All clients~~ use ~~block depth~~ as a measure of the ~~liklihood~~ of a [[Chain_Reorganization\|block chain reorganization]] producing a new longer fork which excludes the transaction.		A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV don't verify the preceding blocks, they use the number of confirmations (whether they are valid or not) as a measure of the likelihood of a [[Chain_Reorganization\|block chain reorganization]] producing a new longer fork which excludes the transaction.

	See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].		See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].

	== Full~~-Chain~~ Clients ==		== Full Node 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 comparisons below.		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 comparisons below.

	~~=== Block '''Height''' as a Transaction Acceptance Check ===~~		A full-node client uses the [[Protocol_rules#Blocks well-formed\|difficultywise-longest]] valid block chain it can find. A transaction's ''depth'' (the number of blocks or confirmations ''after'' it) is used to determine the likelihood of the transaction being double-spent due to the emergence of a longer fork.

	A full-~~chain~~ client ~~trusts~~ the [[Protocol_rules#Blocks well-formed\|difficultywise-longest]] block chain it can find. Any transaction on the difficultywise-longest well-formed chain is considered to have been accepted by the network. Therefore, the acceptance of a transaction is determined by its height -- i.e. how many blocks come ''before'' it.

	A transaction's ''depth'' (the number of blocks ''after'' it) is used to determine ~~''irreversibility'' --~~ the likelihood of the transaction being ~~undone~~ due to the emergence of a longer fork.

	==== [[bitcoind\|bitcoin-qt]] ====		==== [[bitcoind\|bitcoin-qt]] ====
Line 29:		Line 25:
	Once a full-chain client has downloaded the entire chain, it typically retains it (as the Satoshi client did/does).		Once a full-chain client has downloaded the entire chain, it typically retains it (as the Satoshi client did/does).

	Satoshi's original paper mentions the possibility of pruning individual transactions ~~from the Merkle tree~~, which allows for ~~pruned~~ full~~-chain~~ nodes, which verify the entire transaction history but do not retain it.		Satoshi's original paper mentions the possibility of pruning individual transactions, which allows for full nodes which verify the entire transaction history but do not retain it. Because users are required to download and verify the block chain from some other node initially, this change isn't costless.


	~~== Header-Only Clients ==~~

	These client downloads a complete copy of the headers for all blocks in the entire block chain. 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) Clients ==

	~~=== Simplified Payment Verification (SPV) ===~~		This client downloads a complete copy of the headers for all blocks in the entire block chain. This means that the download and storage requirements scale linearly with the amount of time since Bitcoin was invented.

	This scheme is described in section 8 of the [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].		This scheme is described in section 8 of the [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].

	==== Block ~~'''~~Depth~~''' as a Transaction Acceptance~~ Check ====		==== Block Depth 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. Therefore, the acceptance of a transaction is determined by its depth -- i.e. how many blocks come ''after'' it. Other thin client protocols also include this assumption.		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 will be costly to forge.

	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 ''after'' it has already decided that a transaction is accepted (i.e. no [[Double-spending\|double-spends]]), as a gauge of ''irreversibility'' --~~ how likely it is that a longer fork in the chain will emerge which excludes that transaction.		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. 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 acceptance; 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.


Line 79:		Line 69:
	If such UOT hashes were included in the block chain, a client which shipped with a [https://en.bitcoin.it/wiki/Vocabulary checkpoint] block that had a UOT would only need to download blocks after the checkpoint. Moreover, once the client had downloaded those blocks and confirmed their UOTs, it could discard all but the most recent block containing a UOT.		If such UOT hashes were included in the block chain, a client which shipped with a [https://en.bitcoin.it/wiki/Vocabulary checkpoint] block that had a UOT would only need to download blocks after the checkpoint. Moreover, once the client had downloaded those blocks and confirmed their UOTs, it could discard all but the most recent block containing a UOT.

	This would also let a thin client reduce the question of "is this output unspent" to the question of "is this block super-well-formed" where "well-formed" means "well-formed according to the normal block chain 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.		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.

	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 block chain 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 ~~well-formedness~~ 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 do any of the blocks in the chain contain them. The [https://bitcointalk.org/index.php?topic=91954 ultraprune] feature added to bitcoind-0.8 maintains a similar data structure on the client's disk. It does not put this data structure or its hash anywhere in the block chain.		Note that at the present moment no standard format for such Unused Output Tree hashes has been agreed upon, nor do any of the blocks in the chain contain them. The [https://bitcointalk.org/index.php?topic=91954 ultraprune] feature added to bitcoind-0.8 maintains a similar data structure on the client's disk. It does not put this data structure or its hash anywhere in the block chain.
Line 89:		Line 75:
	== Server-Trusting Clients ==		== 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.		These clients involve a high 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.

	All thin clients listed below currently connect to a single server, and are vulnerable to an attack similar to a double-spend. The attack can be run by that single server - the server can just lie to them that they received a Bitcoin transaction, and they, assuming the server does not lie, perform some service, transfer funds or send goods without actually receiving any Bitcoin in exchange. Therefore, they are implicitly trusting it.		All thin clients listed below currently connect to a single server, and are vulnerable to an attack similar to a double-spend. The attack can be run by that single server - the server can just lie to them that they received a Bitcoin transaction, and they, assuming the server does not lie, perform some service, transfer funds or send goods without actually receiving any Bitcoin in exchange. Therefore, they are implicitly trusting it.

Eldentyrell: Refine distinction between "acceptance" and "irreversibility"

2015-02-28T06:08:10Z

Refine distinction between "acceptance" and "irreversibility"

Eldentyrell: Replace "valid" with "irreversible" where appropriate (see talk)

2015-02-28T06:03:05Z

Replace "valid" with "irreversible" where appropriate (see talk)

← Older revision		Revision as of 06:03, 28 February 2015
Line 1:		Line 1:
	Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page 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.		Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page 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 Node~~ vs. ~~SPV~~ ==		== Block Height vs. Depth ==

	It is important to distinguish between block height verification and block depth verification.		It is important to distinguish between block height verification and block depth verification.

	A ~~full node~~ client verifies that all ~~preceding blocks~~ are ~~valid in order to guarantee that a transaction is valid~~. Currently only the Satoshi client, libbitcoin, and btcd do ~~full node~~ verification. ~~Full nodes are~~ the fundamental anchor of trustless security in the Bitcoin system.		A client verifies the height H of a block by checking that there are H block '''before''' it, all of which are well-formed and obey the maximum-difficulty-adjustment-rate rule. Currently only the Satoshi client, libbitcoin, and btcd do block height verification. Block height is the fundamental anchor of trustless security in the Bitcoin system.

	A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients substitute block depth for block height as a transaction ~~validity~~ check. All clients use block depth as a measure of the ~~likelihood~~ of a [[Chain_Reorganization\|block chain reorganization]] producing a new longer fork which excludes the transaction.		A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients substitute block depth for block height as a transaction irreversibility check. All clients use block depth as a measure of the liklihood of a [[Chain_Reorganization\|block chain reorganization]] producing a new longer fork which excludes the transaction.

	See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].		See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].

	== Full ~~Node~~ Clients ==		== 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 comparisons below.		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 comparisons below.

	A full-~~node~~ client ~~uses~~ the [[Protocol_rules#Blocks well-formed\|difficultywise-longest]] ~~valid~~ block chain it can find. A transaction's ''depth'' (the number of blocks ~~or confirmations~~ ''after'' it) is used to determine the likelihood of the transaction being ~~double-spent~~ due to the emergence of a longer fork.		=== Block '''Height''' as a Transaction Irreversibility Check ===

			A full-chain client trusts the [[Protocol_rules#Blocks well-formed\|difficultywise-longest]] block chain it can find. Any transaction on the difficultywise-longest well-formed chain is considered irreversible. Therefore, the irreversibility of a transaction is determined by its height -- i.e. how many blocks come ''before'' it. A transaction's ''depth'' (the number of blocks ''after'' it) is used to determine the likelihood of the transaction being undone due to the emergence of a longer fork.

	==== [[bitcoind\|bitcoin-qt]] ====		==== [[bitcoind\|bitcoin-qt]] ====
Line 25:		Line 27:
	Once a full-chain client has downloaded the entire chain, it typically retains it (as the Satoshi client did/does).		Once a full-chain client has downloaded the entire chain, it typically retains it (as the Satoshi client did/does).

	Satoshi's original paper mentions the possibility of pruning individual transactions, which allows for full nodes which verify the entire transaction history but do not retain it~~. Because users are required to download and verify the block chain from some other node initially, this change isn't costless~~.		Satoshi's original paper mentions the possibility of pruning individual transactions from the Merkle tree, which allows for pruned full-chain nodes, which verify the entire transaction history but do not retain it.


	== ~~Simplified Payment Verification (SPV)~~ Clients ==		== Header-Only Clients ==

	~~This~~ client downloads a complete copy of the headers for all blocks in the entire block chain. This means that the download and storage requirements scale linearly with the amount of time since ~~Bitcoin~~ was invented.		These client downloads a complete copy of the headers for all blocks in the entire block chain. 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 [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].		This scheme is described in section 8 of the [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].

	==== Block Depth Check ====		==== Block '''Depth''' as a Transaction Irreversibility 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. Therefore, the irreversibility of a transaction is determined by its depth -- i.e. how many blocks come ''after'' it. 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 irreversible (i.e. no [[Double-spending\|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 will be costly to forge~~.		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 irreversibility; the SPV client does'''.

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


Line 69:		Line 77:
	If such UOT hashes were included in the block chain, a client which shipped with a [https://en.bitcoin.it/wiki/Vocabulary checkpoint] block that had a UOT would only need to download blocks after the checkpoint. Moreover, once the client had downloaded those blocks and confirmed their UOTs, it could discard all but the most recent block containing a UOT.		If such UOT hashes were included in the block chain, a client which shipped with a [https://en.bitcoin.it/wiki/Vocabulary checkpoint] block that had a UOT would only need to download blocks after the checkpoint. Moreover, once the client had downloaded those blocks and confirmed their UOTs, it could discard all but the most recent block containing 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.		This would also let a thin client reduce the question of "is this output unspent" to the question of "is this block super-well-formed" where "well-formed" means "well-formed according to the normal block chain 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 block chain 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 well-formedness 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 do any of the blocks in the chain contain them. The [https://bitcointalk.org/index.php?topic=91954 ultraprune] feature added to bitcoind-0.8 maintains a similar data structure on the client's disk. It does not put this data structure or its hash anywhere in the block chain.		Note that at the present moment no standard format for such Unused Output Tree hashes has been agreed upon, nor do any of the blocks in the chain contain them. The [https://bitcointalk.org/index.php?topic=91954 ultraprune] feature added to bitcoind-0.8 maintains a similar data structure on the client's disk. It does not put this data structure or its hash anywhere in the block chain.
Line 75:		Line 87:
	== Server-Trusting Clients ==		== Server-Trusting Clients ==

	These clients involve ~~a high~~ 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.		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.

	All thin clients listed below currently connect to a single server, and are vulnerable to an attack similar to a double-spend. The attack can be run by that single server - the server can just lie to them that they received a Bitcoin transaction, and they, assuming the server does not lie, perform some service, transfer funds or send goods without actually receiving any Bitcoin in exchange. Therefore, they are implicitly trusting it.		All thin clients listed below currently connect to a single server, and are vulnerable to an attack similar to a double-spend. The attack can be run by that single server - the server can just lie to them that they received a Bitcoin transaction, and they, assuming the server does not lie, perform some service, transfer funds or send goods without actually receiving any Bitcoin in exchange. Therefore, they are implicitly trusting it.

Lapp0: Attempted to remove all misuses of terms (especially "valid") and inventions of new terms (full-chain, super-well-formed), etc in order to make the article more sane. If you have any specific grievances, mention it in the talk page before reverting.

2015-02-27T05:22:53Z

Attempted to remove all misuses of terms (especially "valid") and inventions of new terms (full-chain, super-well-formed), etc in order to make the article more sane. If you have any specific grievances, mention it in the talk page before reverting.

← Older revision		Revision as of 05:22, 27 February 2015
Line 1:		Line 1:
	Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page 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.		Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page 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.

	== ~~Block Height~~ vs. ~~Depth~~ ==		== Full Node vs. SPV ==

	It is important to distinguish between block height verification and block depth verification.		It is important to distinguish between block height verification and block depth verification.

	A client verifies ~~the height H of a block by checking~~ that ~~there are H block '''before''' it,~~ all ~~of which~~ are ~~well-formed and obey the maximum-difficulty-adjustment-rate rule~~. Currently only the Satoshi client, libbitcoin, and btcd do ~~block height~~ verification. ~~Block height is~~ the fundamental anchor of trustless security in the Bitcoin system.		A full node client verifies that all preceding blocks are valid in order to guarantee that a transaction is valid. Currently only the Satoshi client, libbitcoin, and btcd do full node verification. Full nodes are the fundamental anchor of trustless security in the Bitcoin system.

	A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients substitute block depth for block height as a transaction validity check. All clients use block depth as a measure of the ~~liklihood~~ of a [[Chain_Reorganization\|block chain reorganization]] producing a new longer fork which excludes the transaction.		A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients substitute block depth for block height as a transaction validity check. All clients use block depth as a measure of the likelihood of a [[Chain_Reorganization\|block chain reorganization]] producing a new longer fork which excludes the transaction.

	See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].		See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].

	== Full~~-Chain~~ Clients ==		== Full Node 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 comparisons below.		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 comparisons below.

	~~=== Block '''Height''' as a Transaction Validity Check ===~~		A full-node client uses the [[Protocol_rules#Blocks well-formed\|difficultywise-longest]] valid block chain it can find. A transaction's ''depth'' (the number of blocks or confirmations ''after'' it) is used to determine the likelihood of the transaction being double-spent due to the emergence of a longer fork.

	A full-~~chain~~ client ~~trusts~~ the [[Protocol_rules#Blocks well-formed\|difficultywise-longest]] block chain it can find. ~~Any transaction on the difficultywise-longest well-formed chain is considered valid. Therefore, the validity of a transaction is determined by its height -- i.e. how many blocks come ''before'' it.~~ A transaction's ''depth'' (the number of blocks ''after'' it) is used to determine the likelihood of the transaction being ~~invalidated~~ due to the emergence of a longer fork.

	==== [[bitcoind\|bitcoin-qt]] ====		==== [[bitcoind\|bitcoin-qt]] ====
Line 27:		Line 25:
	Once a full-chain client has downloaded the entire chain, it typically retains it (as the Satoshi client did/does).		Once a full-chain client has downloaded the entire chain, it typically retains it (as the Satoshi client did/does).

	Satoshi's original paper mentions the possibility of pruning individual transactions ~~from the Merkle tree~~, which allows for ~~pruned~~ full~~-chain~~ nodes, which verify the entire transaction history but do not retain it.		Satoshi's original paper mentions the possibility of pruning individual transactions, which allows for full nodes which verify the entire transaction history but do not retain it. Because users are required to download and verify the block chain from some other node initially, this change isn't costless.


	== ~~Header-Only~~ Clients ==		== Simplified Payment Verification (SPV) Clients ==

	~~These~~ client downloads a complete copy of the headers for all blocks in the entire block chain. 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~~.		This client downloads a complete copy of the headers for all blocks in the entire block chain. This means that the download and storage requirements scale linearly with the amount of time since Bitcoin was invented.

	~~=== Simplified Payment Verification (SPV) ===~~

	This scheme is described in section 8 of the [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].		This scheme is described in section 8 of the [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].

	==== Block ~~'''~~Depth~~''' as a Transaction Validity~~ Check ====		==== Block Depth 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. Therefore, the validity of a transaction is determined by its depth -- i.e. how many blocks come ''after'' it. 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-spending\|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'''~~.		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 will be costly to forge.

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


Line 77:		Line 69:
	If such UOT hashes were included in the block chain, a client which shipped with a [https://en.bitcoin.it/wiki/Vocabulary checkpoint] block that had a UOT would only need to download blocks after the checkpoint. Moreover, once the client had downloaded those blocks and confirmed their UOTs, it could discard all but the most recent block containing a UOT.		If such UOT hashes were included in the block chain, a client which shipped with a [https://en.bitcoin.it/wiki/Vocabulary checkpoint] block that had a UOT would only need to download blocks after the checkpoint. Moreover, once the client had downloaded those blocks and confirmed their UOTs, it could discard all but the most recent block containing a UOT.

	This would also let a thin client reduce the question of "is this output unspent" to the question of "is this block super-well-formed" where "well-formed" means "well-formed according to the normal block chain 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.		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.

	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 block chain 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 ~~well-formedness~~ 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 do any of the blocks in the chain contain them. The [https://bitcointalk.org/index.php?topic=91954 ultraprune] feature added to bitcoind-0.8 maintains a similar data structure on the client's disk. It does not put this data structure or its hash anywhere in the block chain.		Note that at the present moment no standard format for such Unused Output Tree hashes has been agreed upon, nor do any of the blocks in the chain contain them. The [https://bitcointalk.org/index.php?topic=91954 ultraprune] feature added to bitcoind-0.8 maintains a similar data structure on the client's disk. It does not put this data structure or its hash anywhere in the block chain.
Line 87:		Line 75:
	== Server-Trusting Clients ==		== 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.		These clients involve a high 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.

	All thin clients listed below currently connect to a single server, and are vulnerable to an attack similar to a double-spend. The attack can be run by that single server - the server can just lie to them that they received a Bitcoin transaction, and they, assuming the server does not lie, perform some service, transfer funds or send goods without actually receiving any Bitcoin in exchange. Therefore, they are implicitly trusting it.		All thin clients listed below currently connect to a single server, and are vulnerable to an attack similar to a double-spend. The attack can be run by that single server - the server can just lie to them that they received a Bitcoin transaction, and they, assuming the server does not lie, perform some service, transfer funds or send goods without actually receiving any Bitcoin in exchange. Therefore, they are implicitly trusting it.

← Older revision		Revision as of 06:08, 28 February 2015
Line 7:		Line 7:
	A client verifies the height H of a block by checking that there are H block '''before''' it, all of which are well-formed and obey the maximum-difficulty-adjustment-rate rule. Currently only the Satoshi client, libbitcoin, and btcd do block height verification. Block height is the fundamental anchor of trustless security in the Bitcoin system.		A client verifies the height H of a block by checking that there are H block '''before''' it, all of which are well-formed and obey the maximum-difficulty-adjustment-rate rule. Currently only the Satoshi client, libbitcoin, and btcd do block height verification. Block height is the fundamental anchor of trustless security in the Bitcoin system.

	A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients substitute block depth for block height as a transaction ~~irreversibility~~ check. All clients use block depth as a measure of the liklihood of a [[Chain_Reorganization\|block chain reorganization]] producing a new longer fork which excludes the transaction.		A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients substitute block depth for block height as a transaction acceptance check. All clients use block depth as a measure of the liklihood of a [[Chain_Reorganization\|block chain reorganization]] producing a new longer fork which excludes the transaction.

	See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].		See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].
Line 15:		Line 15:
	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 comparisons below.		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 comparisons below.

	=== Block '''Height''' as a Transaction ~~Irreversibility~~ Check ===		=== Block '''Height''' as a Transaction Acceptance Check ===

	A full-chain client trusts the [[Protocol_rules#Blocks well-formed\|difficultywise-longest]] block chain it can find. Any transaction on the difficultywise-longest well-formed chain is considered ~~irreversible~~. Therefore, the ~~irreversibility~~ of a transaction is determined by its height -- i.e. how many blocks come ''before'' it. A transaction's ''depth'' (the number of blocks ''after'' it) is used to determine the likelihood of the transaction being undone due to the emergence of a longer fork.		A full-chain client trusts the [[Protocol_rules#Blocks well-formed\|difficultywise-longest]] block chain it can find. Any transaction on the difficultywise-longest well-formed chain is considered to have been accepted by the network. Therefore, the acceptance of a transaction is determined by its height -- i.e. how many blocks come ''before'' it.

			A transaction's ''depth'' (the number of blocks ''after'' it) is used to determine ''irreversibility'' -- the likelihood of the transaction being undone due to the emergence of a longer fork.

	==== [[bitcoind\|bitcoin-qt]] ====		==== [[bitcoind\|bitcoin-qt]] ====
Line 38:		Line 40:
	This scheme is described in section 8 of the [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].		This scheme is described in section 8 of the [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].

	==== Block '''Depth''' as a Transaction ~~Irreversibility~~ Check ====		==== Block '''Depth''' as a Transaction Acceptance 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. Therefore, the ~~irreversibility~~ of a transaction is determined by its depth -- i.e. how many blocks come ''after'' it. Other thin client protocols also include this assumption.		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. Therefore, the acceptance of a transaction is determined by its depth -- i.e. how many blocks come ''after'' it. 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 ~~irreversible~~ (i.e. no [[Double-spending\|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.		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 ''after'' it has already decided that a transaction is accepted (i.e. no [[Double-spending\|double-spends]]), as a gauge of ''irreversibility'' -- 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 ~~irreversibility~~; 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 acceptance; 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.		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.