Dev Docs: Change MerkleBlock To Merkle Block (But Not P2P Message Form)

_autocrossref.yaml

@@ -140,7 +140,7 @@ message header:
 message headers: message header
 message payload:
 '`merchant_data`': pp merchant data
-merkleblock: merkleblock message
+merkle block:
 '`merkleblock` message': merkleblock message
 '`merkleblock` messages': merkleblock message
 merkle root:

_includes/example_p2p_networking.md

@@ -5,9 +5,9 @@
 {% autocrossref %}
 
 For the `merkleblock` message documentation on the reference page, an
-actual merkleblock was retrieved from the network and manually
+actual merkle block was retrieved from the network and manually
 processed.  This section walks through each step of the process,
-demonstrating basic network communication and merkleblock processing.
+demonstrating basic network communication and merkle block processing.
 
 {% highlight python %}
 
@@ -93,7 +93,7 @@ send("getdata",
 )
 {% endhighlight %}
 
-We request a merkleblock for transactions matching our filter,
+We request a merkle block for transactions matching our filter,
 completing our script.
 
 To run the script, we simply pipe it to the Unix [`netcat`
@@ -114,7 +114,7 @@ Part of the response is shown in the section below.
 
 {% autocrossref %}
 
-In the section above, we retrieved a merkleblock from the network; now
+In the section above, we retrieved a merkle block from the network; now
 we will parse it. Most of the block header has been omitted. For
 a more complete hexdump, see the example in the [`merkleblock` message
 section][merkleblock message].

_includes/guide_operating_modes.md

@@ -66,7 +66,7 @@ Removal of elements can only be done by scrapping the bloom filter and re-creati
 
 {% autocrossref %}
 
-Rather than viewing the false positive rates as a liability, it is used to create a tunable parameter that represents the desired privacy level and bandwidth trade-off. A SPV client creates their Bloom filter and sends it to a full node using the message `filterload`, which sets the filter for which transactions are desired. The command `filteradd` allows addition of desired data to the filter without needing to send a totally new Bloom filter, and `filterclear` allows the connection to revert to standard block discovery mechanisms. If the filter has been loaded, then full nodes will send a modified form of blocks, called a merkleblock. The merkleblock is simply the block header with the merkle branch associated with the set Bloom filter. 
+Rather than viewing the false positive rates as a liability, it is used to create a tunable parameter that represents the desired privacy level and bandwidth trade-off. A SPV client creates their Bloom filter and sends it to a full node using the message `filterload`, which sets the filter for which transactions are desired. The command `filteradd` allows addition of desired data to the filter without needing to send a totally new Bloom filter, and `filterclear` allows the connection to revert to standard block discovery mechanisms. If the filter has been loaded, then full nodes will send a modified form of blocks, called a merkle block. The merkle block is simply the block header with the merkle branch associated with the set Bloom filter. 
 
 An SPV client can not only add transactions as elements to the filter, but also public keys, data from signature
 scripts and pubkey scripts, and more. This enables P2SH transaction finding.

_includes/ref_p2p_networking.md

@@ -475,7 +475,7 @@ following checks (order doesn't matter):
   knows how many confirmations this block has.
 
 For a detailed example of parsing a `merkleblock` message, please see
-the corresponding [merkleblock examples section][section merkleblock
+the corresponding [merkle block examples section][section merkleblock
 example].
 
 **Creating A MerkleBlock**
@@ -554,7 +554,7 @@ format. It can be sent in a variety of situations;
   inventory type of `MSG_TX`.
 
 * **MerkleBlock Response:** Bitcoin Core will send it in response to a
-  `getdata` message that requests a merkleblock with an inventory type
+  `getdata` message that requests a merkle block with an inventory type
   of `MSG_MERKLEBLOCK`. (This is in addition to sending a `merkleblock`
   message.) Each `tx` message in this case provides a matched
   transaction from that block.

_includes/references.md

@@ -52,7 +52,7 @@
 [genesis block]: /en/developer-guide#term-genesis-block "The first block created; also called block 0"
 [getaddr message]: /en/developer-reference#getaddr "A P2P protool message used to request an addr message containing connection information for other nodes"
 [getblocks message]: /en/developer-reference#getblocks "A P2P protocol message used to request an inv message containing a range of block header hashes"
-[getdata message]: /en/developer-reference#getdata "A P2P protocol message used to request one or more transactions, blocks, or merkleblocks"
+[getdata message]: /en/developer-reference#getdata "A P2P protocol message used to request one or more transactions, blocks, or merkle blocks"
 [getheaders message]: /en/developer-reference#getheaders "A P2P protocol message used to request a range of block headers"
 [hard fork]: /en/developer-guide#term-hard-fork "A permanent divergence in the the block chain, commonly occurs when non-upgraded nodes can't validate blocks created by upgraded nodes following newer consensus rules."
 [hardened extended private key]: /en/developer-guide#term-hardened-extended-private-key "A private key whose corresponding public key cannot derive child keys"
@@ -77,6 +77,7 @@
 [mempool message]: /en/developer-reference#mempool "A P2P protocol message used to request one or more inv messages with currently-unconfirmed transactions"
 [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"
+[merkle block]: /en/developer-reference#merkleblock "A partial merkle tree connecting transactions matching a bloom filter to the merkle root of a block"
 [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"
 [merkleblock message]: /en/developer-reference#merkleblock "A P2P protocol message used to request a filtered block useful for SPV proofs"
@@ -89,7 +90,7 @@
 [minimum fee]: /en/developer-guide#term-minimum-fee "The minimum fee a transaction must pay in most circumstances to be mined or broadcast by peers across the network"
 [msg_tx]: /en/developer-reference#term-msg_tx "The TXID data type identifier of an inventory on the P2P network"
 [msg_block]: /en/developer-reference#term-msg_block "The block header hash data type identifier of an inventory on the P2P network"
-[msg_filtered_block]: /en/developer-reference#term-msg_block "An alternative to the block header hash data type identifier of an inventory on the P2P network used to request a merkleblock"
+[msg_filtered_block]: /en/developer-reference#term-msg_block "An alternative to the block header hash data type identifier of an inventory on the P2P network used to request a merkle block"
 [multisig]: /en/developer-guide#term-multisig "An pubkey script using OP_CHECKMULTISIG to check for multiple signatures"
 [nbits]: /en/developer-reference#target-nbits "The encoded form of the target threshold as it appears in the block header"
 [network]: /en/developer-guide#term-network "The Bitcoin P2P network which broadcasts transactions and blocks"