diff --git a/_includes/guide_block_chain.md b/_includes/guide_block_chain.md index a38086b5..ce1a6fba 100644 --- a/_includes/guide_block_chain.md +++ b/_includes/guide_block_chain.md @@ -20,9 +20,9 @@ A [block][]{:#term-block}{:.term} of one or more new transactions is collected into the transaction data part of a block. Copies of each transaction are hashed, and the hashes are then paired, hashed, paired again, and hashed again until a single hash remains, the -[Merkle root][]{:#term-merkle-root}{:.term} of a Merkle tree. +[merkle root][]{:#term-merkle-root}{:.term} of a merkle tree. -The Merkle root is stored in the block header. Each block also +The merkle root is stored in the block header. Each block also stores the hash of the previous block's header, chaining the blocks together. This ensures a transaction cannot be modified without modifying the block that records it and all following blocks. @@ -197,17 +197,17 @@ blocks in binary rawtransaction format prefixed by a block transaction sequence number. The rawtransaction format is hashed to create the transaction -identifier (txid). From these txids, the [Merkle tree][]{:#term-merkle-tree}{:.term} is constructed by pairing each +identifier (txid). From these txids, the [merkle tree][]{:#term-merkle-tree}{:.term} is constructed by pairing each txid with one other txid and then hashing them together. If there are an odd number of txids, the txid without a partner is hashed with a copy of itself. The resulting hashes themselves are each paired with one other hash and hashed together. Any hash without a partner is hashed with itself. The -process repeats until only one hash remains, the Merkle root. +process repeats until only one hash remains, the merkle root. For example, if transactions were merely joined (not hashed), a -five-transaction Merkle tree would look like the following text diagram: +five-transaction merkle tree would look like the following text diagram: {% endautocrossref %} @@ -224,16 +224,16 @@ A B C D E .........Transactions {% autocrossref %} As discussed in the Simplified Payment Verification (SPV) subsection, -the Merkle tree allows clients to verify for +the merkle tree allows clients to verify for themselves that a transaction was included in a block by obtaining the -Merkle root from a block header and a list of the intermediate hashes +merkle root from a block header and a list of the intermediate hashes from a full peer. The full peer does not need to be trusted: it is expensive to fake block headers and the intermediate hashes cannot be faked or the verification will fail. For example, to verify transaction D was added to the block, an SPV client only needs a copy of the C, AB, and EEEE hashes in addition to the -Merkle root; the client doesn't need to know anything about any of the +merkle root; the client doesn't need to know anything about any of the other transactions. If the five transactions in this block were all at the maximum size, downloading the entire block would require over 500,000 bytes---but downloading three hashes plus the block header diff --git a/_includes/guide_mining.md b/_includes/guide_mining.md index 4891e691..dcf9dabd 100644 --- a/_includes/guide_mining.md +++ b/_includes/guide_mining.md @@ -37,7 +37,7 @@ The mining hardware iterates through every possible value for the block header nonce and generates the corresponding hash. If none of the hashes are below the threshold, the mining hardware gets -an updated block header with a new Merkle root from the mining software; +an updated block header with a new merkle root from the mining software; this new block header is created by adding extra nonce data to the coinbase field of the coinbase transaction. @@ -71,7 +71,7 @@ miner checked a percentage of the possible hash values. The miner then sends to the pool a copy of the information the pool needs to validate that the header will hash below the target and that -the the block of transactions referred to by the header Merkle root field +the the block of transactions referred to by the header merkle root field is valid for the pool's purposes. (This usually means that the coinbase transaction must pay the pool.) @@ -139,10 +139,10 @@ provides the mining software with much more information: Using the transactions received, the mining software adds a nonce to the coinbase extra nonce field and then converts all the transactions into a -Merkle tree to derive a Merkle root it can use in a block header. +merkle tree to derive a merkle root it can use in a block header. Whenever the extra nonce field needs to be changed, the mining software -rebuilds the necessary parts of the Merkle tree and updates the time and -Merkle root fields in the block header. +rebuilds the necessary parts of the merkle tree and updates the time and +merkle root fields in the block header. Like all `bitcoind` RPCs, `getblocktemplate` is sent over HTTP. To ensure they get the most recent work, most miners use [HTTP longpoll][] to @@ -164,26 +164,26 @@ need to construct block headers on their own: 1. The information necessary to construct a coinbase transaction paying the pool. -2. The parts of the Merkle tree which need to be re-hashed to - create a new Merkle root when the coinbase transaction is - updated with a new extra nonce. The other parts of the Merkle +2. The parts of the merkle tree which need to be re-hashed to + create a new merkle root when the coinbase transaction is + updated with a new extra nonce. The other parts of the merkle tree, if any, are not sent, effectively limiting the amount of data which needs to be sent to (at most) about a kilobyte at current transaction volume. -3. All of the other non-Merkle root information necessary to construct a +3. All of the other non-merkle root information necessary to construct a block header for the next block. 4. The mining pool's current target threshold for accepting shares. Using the coinbase transaction received, the mining software adds a nonce to the coinbase extra nonce field, hashes the coinbase -transaction, and adds the hash to the received parts of the Merkle tree. -The tree is hashed as necessary to create a Merkle root, which is added +transaction, and adds the hash to the received parts of the merkle tree. +The tree is hashed as necessary to create a merkle root, which is added to the block header information received. Whenever the extra nonce field needs to be changed, the mining software updates and re-hashes the -coinbase transaction, rebuilds the Merkle root, and updates the header -Merkle root field. +coinbase transaction, rebuilds the merkle root, and updates the header +merkle root field. Unlike `getblocktemplate`, miners using Stratum cannot inspect or add transactions to the block they're currently mining. Also unlike diff --git a/_includes/guide_operating_modes.md b/_includes/guide_operating_modes.md index d205b8fa..bedd7bab 100644 --- a/_includes/guide_operating_modes.md +++ b/_includes/guide_operating_modes.md @@ -24,9 +24,9 @@ For a client to be fooled, an adversary would need to give a complete alternativ An alternative approach detailed in the [original Bitcoin paper][bitcoinpdf] is a client that only downloads the headers of blocks during the initial syncing process and then requests transactions from full nodes as needed. This scales linearly with the height of the block chain at only 80 bytes per block header, or up to 4.2MB per year, regardless of total block size. -As described in the white paper, the Merkle root in the block header along with a Merkle branch can prove to the SPV client that the transaction in question is embedded in a block in the block chain. This does not guarantee validity of the transactions that are embedded. Instead it demonstrates the amount of work required to perform a double-spend attack. +As described in the white paper, the merkle root in the block header along with a merkle branch can prove to the SPV client that the transaction in question is embedded in a block in the block chain. This does not guarantee validity of the transactions that are embedded. Instead it demonstrates the amount of work required to perform a double-spend attack. -The block's depth in the block chain corresponds to the cumulative difficulty that has been performed to build on top of that particular block. The SPV client knows the Merkle root and associated transaction information, and requests the respective Merkle branch from a full node. Once the Merkle branch has been retrieved, proving the existence of the transaction in the block, the SPV client can then look to block *depth* as a proxy for transaction validity and security. The cost of an attack on a user by a malicious node who inserts an invalid transaction grows with the cumulative difficulty built on top of that block, since the malicious node alone will be mining this forged chain. +The block's depth in the block chain corresponds to the cumulative difficulty that has been performed to build on top of that particular block. The SPV client knows the merkle root and associated transaction information, and requests the respective merkle branch from a full node. Once the merkle branch has been retrieved, proving the existence of the transaction in the block, the SPV client can then look to block *depth* as a proxy for transaction validity and security. The cost of an attack on a user by a malicious node who inserts an invalid transaction grows with the cumulative difficulty built on top of that block, since the malicious node alone will be mining this forged chain. {% endautocrossref %} diff --git a/_includes/ref_block_chain.md b/_includes/ref_block_chain.md index 1560a4f0..ed826949 100644 --- a/_includes/ref_block_chain.md +++ b/_includes/ref_block_chain.md @@ -70,7 +70,7 @@ The 80-byte block header contains the following six fields: block chain and ensures no previous block can be changed without also changing this block's header. -3. The *Merkle root* is a hash derived from hashes of all the +3. The *merkle root* is a hash derived from hashes of all the transactions included in this block. It ensures no transactions can be modified in this block without changing the block header hash. @@ -89,7 +89,7 @@ The 80-byte block header contains the following six fields: hash values for the header until they find a hash value less than or equal to the target threshold. If all values within the nonce's four bytes are tested, the time can be updated or the - coinbase transaction can be changed and the Merkle + coinbase transaction can be changed and the merkle root updated. {% endautocrossref %} diff --git a/_includes/ref_core_rpcs-abcdefg.md b/_includes/ref_core_rpcs-abcdefg.md index 2e8f27df..0ca49970 100644 --- a/_includes/ref_core_rpcs-abcdefg.md +++ b/_includes/ref_core_rpcs-abcdefg.md @@ -1232,7 +1232,7 @@ A hex-encoded block or the following JSON object described in segments. The block header *hash* (same as you provided); the number of *confirmations* (subsequent blocks), the *size* of the block in bytes, -the block *height*, the block *version*, and the *Merkle root* hash. +the block *height*, the block *version*, and the *merkle root* hash. {% endautocrossref %} @@ -3231,7 +3231,7 @@ block, and lets a miner return a successful header. *String; optional:* if header data is provided, it will be checked to see if it meets the target threshold (difficulty) and then affixed to a -block of transactions (which produces a matching Merkle root). Then the +block of transactions (which produces a matching merkle root). Then the complete block will be broadcast to the network. Data is in the same format as provided by the *data* output parameter (see below). diff --git a/_includes/references.md b/_includes/references.md index a79f55ad..f5ea6f7c 100644 --- a/_includes/references.md +++ b/_includes/references.md @@ -58,8 +58,8 @@ [merge]: /en/developer-guide#term-merge "Spending, in the same transaction, multiple outputs which can be traced back to different previous spenders, leaking information about how many satoshis you control" [merge avoidance]: /en/developer-guide#term-merge-avoidance "A strategy for selecting which outputs to spend that avoids merging outputs with different histories that could leak private information" [message]: /en/developer-guide#term-message "A parameter of bitcoin: URIs which allows the receiver to optionally specify a message to the spender" -[Merkle root]: /en/developer-guide#term-merkle-root "The root node of a Merkle tree descended from all the hashed pairs in the tree" -[Merkle tree]: /en/developer-guide#term-merkle-tree "A tree constructed by hashing paired data, then pairing and hashing the results until a single hash remains, the Merkle root" +[merkle root]: /en/developer-guide#term-merkle-root "The root node of a merkle tree descended from all the hashed pairs in the tree" +[merkle tree]: /en/developer-guide#term-merkle-tree "A tree constructed by hashing paired data, then pairing and hashing the results until a single hash remains, the merkle root" [micropayment channel]: /en/developer-guide#term-micropayment-channel [millibits]: /en/developer-guide#term-millibits "0.001 bitcoins (100,000 satoshis)" [mine]: /en/developer-guide#term-miner "Creating Bitcoin blocks which solve proof-of-work puzzles in exchange for block rewards and transaction fees"