fix: missing tx validation pages

Author: willcl-ark

consensus-and-validation.adoc

@@ -1,7 +1,7 @@
-= Consensus and Validation
 :page-nav_order: 20
 :page-has_children: true
 include::links-onepage.adoc[]
+= Consensus and Validation
 
 TIP: This section has been updated to Bitcoin Core @ https://github.com/bitcoin/bitcoin/tree/v23.0[v23.0^]
 

input-checks.adoc

@@ -1,6 +1,7 @@
 :page-title: Input validation
 :page-nav_order: 20
 :page-parent: Transaction Validation
+:page-grand_parent: Consensus and Validation
 include::links-onepage.adoc[]
 [[prechecks]]
 === PreChecks

multiple-transactions.adoc

@@ -1,8 +1,8 @@
 :page-title: Multiple transactions
 :page-nav_order: 10
 :page-parent: Transaction Validation
+:page-grand_parent: Consensus and Validation
 include::links-onepage.adoc[]
-
 [#multiple_transactions]
 === Multiple transactions (and packages)
 

single-transactions.adoc

@@ -1,6 +1,7 @@
 :page-title: Single transactions
 :page-nav_order: 0
 :page-parent: Transaction Validation
+:page-grand_parent: Consensus and Validation
 :mermaid-puppeteer-config: ./puppeteer-config.json
 [[single_transactions]]
 === Single transactions

transaction-validation.adoc

@@ -1,12 +1,11 @@
-== Transaction validation
 :page-title: Transaction Validation
 :page-nav_order: 90
 :page-parent: Consensus and Validation
 :page-has_children: true
 :mermaid-puppeteer-config: ./puppeteer-config.json
 include::links-onepage.adoc[]
-
 [#transaction_validation]
+== Transaction validation
 Transactions can originate from the P2P network, the wallet, RPCs or from tests.
 
 Transactions which originate from the wallet, RPCs or individually from the P2P network (from a `NetMsgType::TX` message) will follow a validation pathway which includes adding them to the mempool.

transactions-from-blocks.adoc

@@ -1,6 +1,7 @@
 :page-title: Transactions from blocks
 :page-nav_order: 30
 :page-parent: Transaction Validation
+:page-grand_parent: Consensus and Validation
 :mermaid-puppeteer-config: ./puppeteer-config.json
 [[transactions_from_blocks]]
 === Transactions from blocks
@@ -14,7 +15,6 @@ Transactions learned about from blocks:
 This means that we can validate these transactions based only on our copy of the UTXO set and the data contained within the block itself.
 We call `ProcessBlock()` when processing new blocks received from the P2P network (in _net_processing.cpp_) from net message types: `NetMsgType::CMPCTBLOCK`, `NetMsgType::BLOCKTXN` and `NetMsgType::BLOCK`.
 
-
 .Abbreviated block transaction validation
 [mermaid,target=block-tx-validation,id=block-tx-validation]
 ....
@@ -86,7 +86,6 @@ In these cases this block may still be useful to us in the future.
 
 Once the block has been written to disk by `AcceptBlock()` full validation of the block and its transactions begins via `CChainState::ActivateBestChain()` and its inner call to `ActivateBestChainStep()`.
 
-////
 As part of `ProcessBlock()` we end up calling `CheckBlock()` twice: once on the inner `ProcessNewBlock()` and, if this first is successful, once again inside of `AcceptBlock()`.
 We find the following code comment inside `ProcessBlock()`:
 
@@ -128,7 +127,6 @@ Therefore we call `CheckBlock()` first, and only try `AcceptBlock()` if this pas
 
 Note here how the developers have had to balance consideration for sensitive validation code, staying in consensus with the rest of the network and avoiding potential P2P DoS attacks.
 This type of thinking is common across the codebase.
-////
 
 ////
 TODO: Note that the primary validation occurs inside `ConnectBlock()`, not `CheckBlock()` and `AcceptBlock()`