From 5966a9ecb8d56e15d691ed0c531e62fd4714498f Mon Sep 17 00:00:00 2001 From: Michalis Kargakis Date: Thu, 24 Jul 2014 22:35:08 +0300 Subject: [PATCH 1/2] Various fixes --- ch07.asciidoc | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/ch07.asciidoc b/ch07.asciidoc index aa931c41..340c4c1a 100644 --- a/ch07.asciidoc +++ b/ch07.asciidoc @@ -16,7 +16,7 @@ One way to think about the blockchain is like layers in a geological formation, === Structure of a Block -A block is a container data structure that aggregates transactions for inclusion in the public ledger, the blockchain. The block is made of a header, containing metadata, followed by a long list of transactions that make up the bulk of it's size. The block header is 80 bytes, whereas the average transaction is at least 250 bytes and the average block contains more than 500 transactions. A complete block, with all transactions, is therefore 1000 times larger than the block header. +A block is a container data structure that aggregates transactions for inclusion in the public ledger, the blockchain. The block is made of a header, containing metadata, followed by a long list of transactions that make up the bulk of its size. The block header is 80 bytes, whereas the average transaction is at least 250 bytes and the average block contains more than 500 transactions. A complete block, with all transactions, is therefore 1000 times larger than the block header. [[block_structure]] .The structure of a block @@ -47,7 +47,7 @@ The block header consists of three sets of block metadata. First, there is a ref | 4 bytes | Nonce | A counter used for the proof-of-work algorithm |======= -The Nonce, Difficulty Target and Timestamp are used in the mining process and will be discussed in more detail in <>. +The Nonce, Difficulty Target, and Timestamp are used in the mining process and will be discussed in more detail in <>. [[block_hash]] === Block Identifiers - Block Header Hash and Block Height @@ -67,7 +67,7 @@ A block's _block hash_ always identifies a single block uniquely. A block also a === The Genesis Block -The first block in the blockchain is called the _genesis block_ and was created in 2009. It is the "common ancestor" of all the blocks in the blockchain, meaning that if you start at any block and follow the chain backwards in time you will eventually arrive at the _genesis block_. +The first block in the blockchain is called the _genesis block_ and was created in 2009. It is the "common ancestor" of all the blocks in the blockchain, meaning that if you start at any block and follow the chain backwards in time, you will eventually arrive at the _genesis block_. Every node always starts with a blockchain of at least one block because the genesis block is statically encoded within the bitcoin client software, such that it cannot be altered. Every node always "knows" the genesis block's hash and structure, the fixed time it was created and even the single transaction within. Thus, every node has the starting point for the blockchain, a secure "root" from which to build a trusted blockchain. @@ -108,7 +108,7 @@ The genesis block contains a hidden message within it. The coinbase transaction Bitcoin nodes maintain a local copy of the blockchain, starting at the genesis block. The local copy of the blockchain is constantly updated as new blocks are found and used to extend the chain. As a node receives incoming blocks from the network, it will validate these blocks and then link them to the existing blockchain. To establish a link, a node will examine the incoming block header and look for the "previous block hash". -Let's assume for example that a node has 277,314 blocks in the local copy of the blockchain. The last block the node knows about is block 277,314, with a block header hash of +00000000000000027e7ba6fe7bad39faf3b5a83daed765f05f7d1b71a1632249+. +Let's assume, for example, that a node has 277,314 blocks in the local copy of the blockchain. The last block the node knows about is block 277,314, with a block header hash of +00000000000000027e7ba6fe7bad39faf3b5a83daed765f05f7d1b71a1632249+. The bitcoin node then receives a new block from the network, which it parses as follows: ---- @@ -149,7 +149,7 @@ Merkle trees are used in bitcoin to summarize all the transactions in a block, p When N data elements are hashed and summarized in a Merkle Tree, you can check to see if any one data element is included in the tree with at most +2*log~2~(N)+ calculations, making this a very efficient data structure. -The merkle tree is constructed bottom-up. In the example below, we start with four transactions A, B, C and D, which form the _leaves_ of the Merkle Tree, shown in the diagram at the bottom. The transactions are not stored in the merkle tree, rather their data is hashed and the resulting hash is stored in each leaf node as H~A~, H~B~, H~C~ and H~D~: +The merkle tree is constructed bottom-up. In the example below, we start with four transactions A, B, C and D, which form the _leaves_ of the Merkle Tree, shown in the diagram at the bottom. The transactions are not stored in the merkle tree, rather their data are hashed and the resulting hash is stored in each leaf node as H~A~, H~B~, H~C~ and H~D~: +H~A~ = SHA256(SHA256(Transaction A))+ @@ -163,7 +163,7 @@ The process continues until there is only one node at the top, the node known as .Calculating the nodes in a Merkle Tree image::images/MerkleTree.png["merkle_tree"] -Since the merkle tree is a binary tree, it needs an even number of leaf nodes. If there is an odd number of transactions to summarize, the last transaction hash is duplicated to create an even number of leaf nodes, also known as a _balanced tree_. This is shown in the example below, where transaction C is duplicated: +Since the merkle tree is a binary tree, it needs an even number of leaf nodes. If there is an odd number of transactions to summarize, the last transaction hash will be duplicated to create an even number of leaf nodes, also known as a _balanced tree_. This is shown in the example below, where transaction C is duplicated: [[merkle_tree_odd]] .An even number of data elements, by duplicating one data element @@ -200,7 +200,7 @@ As you can see from the table above, while the block size increases rapidly, fro Merkle trees are used extensively by Simple Payment Verification nodes. SPV nodes don't have all transactions and do not download full blocks, just block headers. In order to verify that a transaction is included in a block, without having to download all the transactions in the block, they use an _authentication path_, or merkle path. -Consider for example an SPV node that is interested in incoming payments to an address contained in its wallet. The SPV node will establish a bloom filter on its connections to peers to limit the transactions received to only those containing addresses of interest. When a peer sees a transaction that matches the bloom filter, it will send that block using a +merkleblock+ message. The +merkleblock+ message contains the block header as well as a merkle path that links the transaction of interest to the merkle root in the block. The SPV node can use this merkle path to connect the transaction to the block and verify that the transaction is included in the block. The SPV node also uses the block header to link the block to the rest of the blockchain. The combination of these two links, between the transaction and block, and between the block and blockchain, proves that the transaction is recorded in the blockchain. All in all, the SPV node will have received less than a kilobyte of data for the block header and merkle path, an amount of data that is a thousand times less than a full block (about 1 megabyte currently) +Consider for example an SPV node that is interested in incoming payments to an address contained in its wallet. The SPV node will establish a bloom filter on its connections to peers to limit the transactions received to only those containing addresses of interest. When a peer sees a transaction that matches the bloom filter, it will send that block using a +merkleblock+ message. The +merkleblock+ message contains the block header as well as a merkle path that links the transaction of interest to the merkle root in the block. The SPV node can use this merkle path to connect the transaction to the block and verify that the transaction is included in the block. The SPV node also uses the block header to link the block to the rest of the blockchain. The combination of these two links, between the transaction and block, and between the block and blockchain, proves that the transaction is recorded in the blockchain. All in all, the SPV node will have received less than a kilobyte of data for the block header and merkle path, an amount of data that is more than a thousand times less than a full block (about 1 megabyte currently) From b4cb4da5de94a7687d779f12cadeb23ddb61ea1a Mon Sep 17 00:00:00 2001 From: "Minh T. Nguyen" Date: Thu, 24 Jul 2014 23:27:59 -0700 Subject: [PATCH 2/2] I believe 'data' is always treated singular. --- ch07.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch07.asciidoc b/ch07.asciidoc index 340c4c1a..650342d7 100644 --- a/ch07.asciidoc +++ b/ch07.asciidoc @@ -149,7 +149,7 @@ Merkle trees are used in bitcoin to summarize all the transactions in a block, p When N data elements are hashed and summarized in a Merkle Tree, you can check to see if any one data element is included in the tree with at most +2*log~2~(N)+ calculations, making this a very efficient data structure. -The merkle tree is constructed bottom-up. In the example below, we start with four transactions A, B, C and D, which form the _leaves_ of the Merkle Tree, shown in the diagram at the bottom. The transactions are not stored in the merkle tree, rather their data are hashed and the resulting hash is stored in each leaf node as H~A~, H~B~, H~C~ and H~D~: +The merkle tree is constructed bottom-up. In the example below, we start with four transactions A, B, C and D, which form the _leaves_ of the Merkle Tree, shown in the diagram at the bottom. The transactions are not stored in the merkle tree, rather their data is hashed and the resulting hash is stored in each leaf node as H~A~, H~B~, H~C~ and H~D~: +H~A~ = SHA256(SHA256(Transaction A))+