ch6 transaction processing and fork images

ch06.asciidoc

@@ -10,7 +10,7 @@ Bitcoin's blockchain is the global public ledger (list) of all transactions, whi
 
 But how can everyone in the network agree on a single universal "truth" about who owns what, without having to trust anyone? All traditional payment systems depend on a trust model that has a central authority providing a clearinghouse service, basically verifying and clearing all transactions. Bitcoin has no central authority, yet somehow every node has a complete copy of a public ledger that it can trust as the authoritative record. The blockchain is not created by a central authority, but is assembled independently by every node in the network. Somehow, every node in the network, acting on information transmitted across insecure network connections can arrive at the same conclusion and assemble a copy of the same public ledger as everyone else. This chapter examines the process by which the bitcoin network achieves global consensus without central authority.
 
-Satoshi Nakamoto's main invention is the decentralized mechanism for emergent consensus. All the properties of bitcoin, including currency, transactions, payments and the security model that does not depend on trust or any central authority derive from this invention. 
+Satoshi Nakamoto's main invention is the decentralized mechanism for emergent consensus. All the properties of bitcoin, including currency, transactions, payments and the security model that does not depend central authority or trust derive from this invention. 
 
 Bitcoin's consensus emerges from the interplay of three processes that occur independently on nodes across the network: 
 
@@ -18,19 +18,48 @@ Bitcoin's consensus emerges from the interplay of three processes that occur ind
 * Independent aggregation of those transactions into new blocks by mining nodes, coupled with demonstrated computation through a Proof-of-Work algorithm
 * Independent assembly of the new blocks by every full node into a chain and selection of the chain with the most cumulative computation demonstrated through Proof-of-Work
 
-In the next few sections we will examine each of these processes and how they interact to create the emergent property of network-wide consensus that allows any bitcoin node to assemble its own copy of the authoritative, trusted, public, global ledger.
+In the next few sections we will examine these processes and how they interact to create the emergent property of network-wide consensus that allows any bitcoin node to assemble its own copy of the authoritative, trusted, public, global ledger.
 
+=== Independent Transaction Verification
 
+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. 
 
+Every bitcoin node that receives a transaction will first verify the transaction before forwarding it to its neighbors. This ensures that only valid transactions are propagated across the network, while invalid transactions are discarded at the first node that encounters them. 
 
+Each node verifies transaction against a long checklist of criteria:
+
+* Check the syntactic correctness of the transaction's data structure
+* Make sure neither lists of inputs or outputs are empty
+* The transaction size in bytes is less than MAX_BLOCK_SIZE
+* Each output value, as well as the total, must be in the legal money range
+* Check none of the inputs have hash=0, N=-1 (coinbase transactions should not be relayed)
+* Check that nLockTime is less than or equal to INT_MAX
+* Check that the transaction size in bytes is greater than or equal to 100
+* Check the number of signature operations contained in the transaction is less than the signature operation limit
+* Reject "nonstandard" transactions: unlocking script (scriptSig) doing anything other than pushing numbers on the stack, or the locking script (scriptPubkey) not matching isStandard forms
+* Check if we already have a matching transaction in the pool, or in a block in the main branch, if so reject this transaction
+* For each input, if the referenced output exists in any other transaction in the pool, reject this transaction.
+* For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions, if a matching transaction is not in there already.
+* For each input, if the referenced output transaction is a coinbase output, it must have at least COINBASE_MATURITY (100) confirmations; else reject this transaction
+* For each input, if the referenced output does not exist (e.g. never existed or has already been spent), reject this transaction
+* Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range
+* Reject if the sum of input values < sum of output values
+* Reject if transaction fee would be too low to get into an empty block
+* Verify the unlocking scripts for each input against the corresponding output locking scripts. 
+
+If all the conditions are met, the transaction is accepted as valid and added to the transaction pool (the list of unconfirmed transactions), matched against the user's wallet if the node is keeping a wallet and finally, relayed to the neighboring nodes to propagate on the network
+
+By independently verifying each transaction as it is received and before propagating it, every node builds a pool of valid new transactions (the transaction pool), roughly in the same order. 
+
+=== The Blockchain
 
 Bitcoin's core innovation is the _blockchain_, a distributed, timestamped ledger. The ledger consists of a cryptographically verified chain of _blocks_ in historical order, each of which contains transactions, new coins and a signature (hash) of the previous block. Each full bitcoin node in the network keeps a complete local replica of the blockchain, and independently verify all transactions and balances from that replica. 
 
 In this chapter we will look at the structure of the blockchain and the blocks within it. We will examine various mechanisms for querying the blockchain database to retrieve information about blocks and transactions. Finally, we will see how new blocks are added to the blockchain through the mechanism of distributed consensus based on a Proof-of-Work algorithm, known as "mining".
 
-=== The Blockchain
 
-The blockchain data structure is an ordered linked list of blocks of transactions. The blockchain can be stored as a flat file, or in a simple database. {what does flat file mean?} The bitcoin core client stores the blockchain metadata using Google's LevelDB database. 
+
+The blockchain data structure is an ordered linked list of blocks of transactions. The blockchain can be stored as a flat file, or in a simple database. The bitcoin core client stores the blockchain metadata using Google's LevelDB database. 
 
 The blockchain is made of blocks, which are generated {not are generated - maybe are usually computed / created / produced / found / mined} every ten minutes on average and hold several hundred transactions that occurred during the previous ten minutes. {is this true? is it always those that occurred during the previous 10 min?} Each block is identified by a hash, generated using the SHA256 cryptographic hash algorithm on the header of the block. {who generates this hash?} Each block also {references the previous block's hash - thereby linking the two together} contains a link to the previous block in the chain, by reference to the previous block's hash. Since a block contains a cryptographic hash of the previous block as a reference, the hash proves that the previous block was known when the current block was created. The hash of the previous block is also part of the data that creates the hash of the current block, making the ancestry of each block an immutable part of its identity. The chain of hashes guarantees that a block cannot be modified retrospectively without forcing the re-computation of all following blocks, because a retrospective change in any block would change the hash, thereby changing the reference in the next block whose hash also changes, and so on. As new blocks are added to the chain, they strengthen the immutability of the ledger by effectively incorporating all previous blocks by reference in their cryptographic hash.