DevDocs: Block Chain: Block Height and Forking: Many corrections

_autocrossref.yaml

@@ -114,8 +114,6 @@ op codes: op code
 '`op_hash160`': op_hash160
 '`op_return`': op_return
 '`op_verify`': op_verify
-orphan:
-orphaned: orphan
 outputs: output
 output:
 output index:
@@ -188,6 +186,8 @@ signature scripts: signature script
 signatures: signature
 SPV:
 stack:
+stale block:
+stale blocks: stale block
 standard script:
 standard scripts: standard script
 standard transaction: standard script

_includes/guide_block_chain.md

@@ -137,11 +137,12 @@ a block does not slow down hashing with extra I/O.
 {% autocrossref %}
 
 Any Bitcoin miner who successfully hashes a block header to a value
-below the target threshold can add the entire block to the block chain.
+below the target threshold can add the entire block to the block chain
-(Assuming the block is otherwise valid.) These blocks are commonly addressed
+(assuming the block is otherwise valid).
+These blocks are commonly addressed
 by their [block height][]{:#term-block-height}{:.term}---the number of blocks between them and the first Bitcoin
 block (block 0, most commonly known as the [genesis block]{:#term-genesis-block}{:.term}). For example,
-block 2016 is where difficulty could have been first adjusted.
+block 2016 is where difficulty could have first been adjusted.
 
 ![Common And Uncommon Block Chain Forks](/img/dev/en-blockchain-fork.svg)
 
@@ -151,15 +152,18 @@ creates an apparent [fork][accidental fork]{:#term-accidental-fork}{:.term} in t
 illustration above.
 
 When miners produce simultaneous blocks at the end of the block chain, each
-peer individually chooses which block to trust. (In the absence of
+node individually chooses which block to accept. In the absence of
-other considerations, discussed below, peers usually trust the first
+other considerations, discussed below, nodes usually use the first
-block they see.)
+block they see.
 
 Eventually a miner produces another block which attaches to only one of
 the competing simultaneously-mined blocks. This makes that side of
-the fork longer than the other side. Assuming a fork only contains valid
+the fork stronger than the other side.
-blocks, normal peers always follow the longest fork (the most difficult chain
+Assuming a fork only contains valid
-to recreate) and throw away ([orphan][]{:#term-orphan}{:.term}) blocks belonging to shorter forks.
+blocks, normal peers always follow the the most difficult chain
+to recreate and throw away [stale blocks][stale block]{:#term-stale-block}{:.term} belonging to shorter forks.
+(Stale blocks are also sometimes called orphans or orphan blocks, but
+those terms are also used for blocks without a known parent block.)
 
 [Long-term forks][long-term fork]{:#term-long-term-fork}{:.term} are possible if different miners work at cross-purposes,
 such as some miners diligently working to extend the block chain at the
@@ -168,7 +172,7 @@ transaction history.
 
 Since multiple blocks can have the same height during a block chain fork, block
 height should not be used as a globally unique identifier. Instead, blocks
-are usually referenced by the SHA256(SHA256()) hash of their header.
+are usually referenced by the hash of their header (often with the byte order reversed, and in hexadecimal).
 
 {% endautocrossref %}
 

_includes/references.md

@@ -78,7 +78,6 @@
 [op_hash160]: /en/developer-reference#term-op-hash160 "Operation which converts the entry below it on the stack into a RIPEMD(SHA256()) hashed version of itself"
 [op_return]: /en/developer-reference#term-op-return "Operation which terminates the script in failure"
 [op_verify]: /en/developer-reference#term-op-verify "Operation which terminates the script if the entry below it on the stack is non-true (zero)"
-[orphan]: /en/developer-guide#term-orphan "Blocks which were successfully mined but which aren't included on the current valid block chain"
 [output]: /en/developer-guide#term-output "The output of a transaction which transfers value to a pubkey script"
 [output index]: /en/developer-guide#term-output-index "The sequentially-numbered index of outputs in a single transaction starting from 0"
 [P2PKH]: /en/developer-guide#term-p2pkh "A pubkey script which Pays To PubKey Hashes (P2PKH), allowing spending of satoshis to anyone with a Bitcoin address"
@@ -136,6 +135,7 @@
 [spv]: /en/developer-guide#simplified-payment-verification-spv "A method for verifying particular transactions were included in blocks without downloading the entire contents of the block chain"
 [ssl signature]: /en/developer-examples#term-ssl-signature "Signatures created and recognized by major SSL implementations such as OpenSSL"
 [stack]: /en/developer-guide#term-stack "An evaluation stack used in Bitcoin's script language"
+[stale block]: /en/developer-guide#term-stale-block "Blocks which were successfully mined but which aren't included on the current valid block chain"
 [standard script]: /en/developer-guide#standard-transactions "A pubkey script which matches the IsStandard() patterns specified in Bitcoin Core---or a transaction containing only standard outputs. Only standard transactions are mined or broadcast by peers running the default Bitcoin Core software"
 [target]: /en/developer-guide#term-target "The threshold below which a block header hash must be in order for the block to be added to the block chain"
 [testnet]: /en/developer-examples#testnet "A Bitcoin-like network where the satoshis have no real-world value to allow risk-free testing"