SPV nodes

ch06.asciidoc

@@ -151,10 +151,38 @@ This process of comparing the local blockchain with the peers and retrieving any
 .Node synchronizing the blockchain by retrieving blocks from a peer
 image::images/InventorySynchronization.png["InventorySynchronization"]
 
-=== Simple Payment Verification Nodes
+=== Simple Payment Verification (SPV) Nodes
+
+Not all nodes have the ability to store the full blockchain. Many bitcoin clients are designed to run on space- and power-constrained devices, such as smartphones, tablets or embedded systems. For such devices, a _simple payment verification_ (SPV) method is used to allow them to operate without storing the full blockchain. These types of clients are called SPV clients or lightweight clients. As bitcoin adoption surges, the SPV node is becoming the most common form of bitcoin node, especially for bitcoin wallets. 
+
+SPV nodes operate the same as full-blockchain nodes, they route network messages, validate transactions and blocks, and construct transactions in the same way. The main difference is that they lack a full copy of the blockchain and verify transactions using a slightly different methodology that relies on peers to provide partial views of relevant parts of the blockchain on-demand.
+
+Simple Payment Verification verifies transactions by reference to their _depth_ in the blockchain instead of their _height_. Whereas a full-blockchain node will construct a fully verified chain of thousands of blocks and transactions reaching down the blockchain (back in time) all the way to the genesis block, an SPV node will verify the chain of a few blocks layered over the one containing a transaction of interest. 
+
+For example, when examining a transaction in block 300,000, a full node links all 300,000 blocks down to the genesis block, establishing the validity of the transaction by confirming to a height from zero to 300,000. An SPV node instead waits until is sees the six blocks 300,001 through 300,006 piled on top of the block containing the transaction and verifies it by establishing its depth under blocks 300,006 to 300,001. The fact that other nodes on the network accepted block 300,000 and then did the necessary work to produce 6 more blocks on top of it is proof enough.
+
+The SPV node still verifies the transaction and the chain of blocks above it independently. It is not depending on the authority of another system for verification. However, it's verification process depends on a small sample of the total blockchain. As a result it is vulnerable to manipulation if all the information it receives is falsified. SPV nodes depend on connecting to enough randomly selected peers to ensure they are not being spoon-fed disinformation. 
+
+Still, SPV nodes can be compromised if their network connection or operating environment is thoroughly compromised and simulated by an adversary. Since they do not verify the totality of the proof-of-work that comprises bitcoin's security proof, they cannot defend against all attacks. They can be given a misleading chain of blocks that has been calculated specifically to falsify a transaction and they can be prevented from connecting to an honest node to see through the ruse. They lack a local blockchain with which to establish a deep history of the bitcoin ledger which would be impossible to fabricate. A sandboxed SPV node is like a denizen of the Matrix, in that it thinks it is experiencing objective reality even though it is in simulation. 
+
+For most practical purposes, well-connected SPV nodes are secure enough, striking the right balance between resource needs, practicality and security. For the truly security conscious, however, nothing beats running a full blockchain node. 
+
+[TIP]
+====
+A full blockchain node verifies a transaction by checking the chain of thousands of blocks below it, whereas an SPV node checks how deep the block is buried by a handful of blocks above it. 
+====
+
+Since SPV nodes need to retrieve specific blocks and transaction chains in order to selectively verify a single transaction, they also create a privacy risk. Unlike full-blockchain nodes that collect all blocks and transactions, SPV node requests for specific data can inadvertently reveal the addresses that are in use in a wallet. For example, a third party monitoring a network could keep track of all the transactions and blocks requested by a wallet on an SPV node and use those to associate bitcoin addresses with the user of that wallet, destroying the user's privacy. 
+
+Shortly after the introduction of SPV/lightweight nodes, the bitcoin developers added a feature called _bloom filters_ to address the privacy risks of SPV nodes. Bloom filters allow SPV nodes to receive a subset of the blocks and transactions without revealing precisely which addresses they are interested in, through a filtering mechanism that uses probabilities rather than fixed patterns. 
 
 === Bloom Filters
 
+
+
+
+
+
 === Independent Verification of Transactions
 
 In the previous chapter we saw how wallet software creates transactions by collecting UTXO, providing the appropriate unlocking scripts and then constructing new outputs assigned to a new owner. The resulting transaction is then sent to the neighboring nodes in the bitcoin network so that it may be propagated across the entire bitcoin network.