DevDocs: Block Chain: Transaction Data: Many corrections

_autocrossref.yaml

@@ -225,6 +225,9 @@ BIP70:
 BIP71:
 BIP72:
 
+## CVEs
+CVE-2012-2459:
+
 ## RPCs
 '`addmultisigaddress`': rpc addmultisigaddress
 '`addnode`': rpc addnode

_includes/guide_block_chain.md

@@ -181,21 +181,20 @@ are usually referenced by the hash of their header (often with the byte order re
 {% autocrossref %}
 
 Every block must include one or more transactions. The first one of these
-transactions must be a coinbase transaction which should collect and
+transactions must be a coinbase transaction, also called a generation transaction, which should collect and
-spend the block reward and any transaction fees paid by transactions included in this block.
+spend the block reward (comprised of a block subsidy and any transaction fees paid by transactions included in this block).
 
 The UTXO of a coinbase transaction has the special condition that
 it cannot be spent (used as an input) for at least 100 blocks. This temporarily
 prevents a miner from spending the transaction fees and block reward from a
-block that may later be orphaned (destroyed) after a block chain fork.
+block that may later be determined to be stale (and therefore the coinbase transaction destroyed) after a block chain fork.
 
 Blocks are not required to include any non-coinbase transactions, but
 miners almost always do include additional transactions in order to
 collect their transaction fees.
 
 All transactions, including the coinbase transaction, are encoded into
-blocks in binary rawtransaction format prefixed by a block transaction
+blocks in binary rawtransaction format.
-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
@@ -240,4 +239,8 @@ the maximum size, downloading the entire block would require over
 500,000 bytes---but downloading three hashes plus the block header
 requires only 140 bytes.
 
+Note: If identical txids are found within the same block, there is a possibility that the merkle tree may collide with a block with some or all duplicates removed due to how unbalanced merkle trees are implemented (duplicating the lone hash).
+Since it is impractical to have separate transactions with identical txids, this does not impose a burden on honest software, but must be checked if the invalid status of a block is to be cached;
+otherwise, a valid block with the duplicates eliminated could have the same merkle root and block hash, but be rejected by the cached invalid outcome, resulting in security bugs such as CVE-2012-2459.
+
 {% endautocrossref %}

_includes/references.md

@@ -175,6 +175,7 @@
 [core git]: https://github.com/bitcoin/bitcoin
 [core paymentrequest.proto]: https://github.com/bitcoin/bitcoin/blob/master/src/qt/paymentrequest.proto
 [core script.h]: https://github.com/bitcoin/bitcoin/blob/master/src/script.h
+[CVE-2012-2459]: https://en.bitcoin.it/wiki/CVEs#CVE-2012-2459
 [DER]: https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One
 [devex complex raw transaction]: /en/developer-examples#complex-raw-transaction
 [devex payment protocol]: /en/developer-examples#payment-protocol