Bugfix: "merkle root" and "merkle tree" are common nouns, so generally lowercase

_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

_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
+rebuilds the necessary parts of the merkle tree and updates the time and
-Merkle root fields in the block header.
+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
+2. The parts of the merkle tree which need to be re-hashed to
-   create a new Merkle root when the coinbase transaction is
+   create a new merkle root when the coinbase transaction is
-   updated with a new extra nonce. The other parts of the Merkle
+   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.
+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
+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
+coinbase transaction, rebuilds the merkle root, and updates the header
-Merkle root field.
+merkle root field.
 
 Unlike `getblocktemplate`, miners using Stratum cannot inspect or add
 transactions to the block they're currently mining. Also unlike

_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 %}
 

_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 %}

_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).
 

_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 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 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"