adoc: fix links after doc split

We must now use the xref style references, to link between independent
*.adoc files:
https://docs.asciidoctor.org/asciidoc/latest/macros/inter-document-xref/

Author: willcl-ark

06_p2p.adoc

@@ -97,7 +97,7 @@ Further down in `ThreadDNSAddressSeed()` we see such a magic number:
 unsigned int nMaxIPs = 256; // Limits number of IPs learned from a DNS seed
 ----
 
-If after 60 seconds we have not made any connections, then `ThreadOpenConnections` will deserialize the hardcoded seeds and https://github.com/bitcoin/bitcoin/blob/v23.0/src/net.cpp#L1960-L1987[add^] them to <<Addrman,addrman>> as candidates for connection.
+If after 60 seconds we have not made any connections, then `ThreadOpenConnections` will deserialize the hardcoded seeds and https://github.com/bitcoin/bitcoin/blob/v23.0/src/net.cpp#L1960-L1987[add^] them to xref:addrman.adoc#[addrman]  as candidates for connection.
 ////
 
 include::message-relay.adoc[]

addition-removal-mempool.adoc

@@ -1,12 +1,12 @@
-:page-title: Additional and removal of transactions
+:page-title: Addition and removal of transactions
 :page-nav_order: 30
 :page-parent: Mempool
 :mermaid-puppeteer-config: ./puppeteer-config.json
 include::links-onepage.adoc[]
 == Addition to the mempool
 
 Transactions are added to the mempool via `addUnchecked()` as part of the `AcceptToMemoryPool()` flow.
-See <<{transaction-validation}transaction_validation>> for more information on how this flow is entered.
+See xref:transaction-validation.adoc[Transaction validation] for more information on how this flow is entered.
 
 WARNING: The function name `addUnchecked` specifically refers to the fact that no checks are being performed, so this must not be called until policy checks have passed.
 
@@ -41,7 +41,7 @@ Transactions are removed from the mempool for a number of reasons:
 
 . A new block has been connected `removeForBlock()`
 . A re-org is taking place `removeForReorg()`
-. The transaction has <<{mempool-lifecycle}default_mempool_expire,expired>> `Expire()`
+. The transaction has xref:mempool-lifecycle.adoc#default_mempool_expire[expired] `Expire()`
 . The transaction is being replaced by a higher-fee version `MemPoolAccept::Finalize()`
 . The mempool must be trimmed back down below its maximum size `TrimToSize()`
 

addrman.adoc

@@ -5,7 +5,7 @@ include::links-onepage.adoc[]
 === Addrman
 
 Addrman is the in-memory database of peers and consists of the new and tried tables.
-These tables are stored in `peers.dat` and serve as cache for network information that the node gathered from previous connections, so that if it is rebooted it can quickly reestablish connections with its former peer network and avoid performing <<{bootstrapping}bootstrapping, the seeding process>> again. 
+These tables are stored in `peers.dat` and serve as cache for network information that the node gathered from previous connections, so that if it is rebooted it can quickly re-establish connections with its former peer network and avoid performing xref:bootstrapping.adoc[bootstrapping] again.
 
 Addrman is setup using `LoadAddrman` from _src/addrdb.cpp_, passing in the `NetGroupManager`, our global program `args` and a pointer to the (to be initialized) `Addrman`.
 `args` are used to determine whether consistency checks should run and to pass on the `datadir` value in order to attempt deserialization on any addrman database (`peers.dat`) that is found.
@@ -102,7 +102,7 @@ TIP: The nonces generated by the randomizer are used to detect us making new con
 Connman is started via `node.connman->Start()` in _init.cpp_.
 This begins by calling `init()` which binds to any ports selected, before starting up an I2P session if the I2P proxy is found.
 Next it schedules sending `GETADDR` to any seednodes provided (via `-seednodes`) using the `ThreadOpenConnections()` loop, and then continues by loading anchor connections from _anchors.dat_.
-Following this the various <<{threads}net_threads,net threads>> are started up.
+Following this the various xref:threads.adoc#net_threads[net threads] are started up.
 
 As connman has a pointer to the node's addrman it can directly fetch new addresses to serve via `CConnman:GetAddresses()`.
 If new addresses are requested from a remote P2P node (via `GETADDR`), then it will use a https://github.com/bitcoin/bitcoin/blob/v23.0/src/net.h#L1129-L1154[cached^] addr response to respond with.

block-relay.adoc

@@ -29,7 +29,7 @@ Because `-blocksonly` is a global startup option, it therefore applies to all co
 block-relay-only connections are a specific type of connection which is used by Bitcoin Core full nodes to only participate in block relay.
 
 As currently implemented block-relay-only connections (introduced in https://github.com/bitcoin/bitcoin/pull/15759[PR#15759^]), disables both transaction and address relay.
-Bitcoin Core nodes per default settings make two *outbound* block-relay-only connections in addition to 8 regular outbound connections (also see <<{p2p-attacks}eclipse_attacks>> for more use cases of these connections).
+Bitcoin Core nodes per default settings make two *outbound* block-relay-only connections in addition to 8 regular outbound connections (also see xref:p2p-attacks.adoc#eclipse_attacks[eclipse attacks] for more use cases of these connections).
 
 
 [id=blocksonly-vs-block-relay-only]

calculating-balance.adoc

@@ -93,7 +93,7 @@ PR https://github.com/bitcoin/bitcoin/pull/19602[19602^] enables migration of le
 Although legacy wallets are now effectively end of life it's still relevant to have documentation for legacy wallets.
 ****
 
-See the section on how wallets determine whether transactions belong to them using the <<{transaction-identification}ismine-enum,IsMine>> enum for more in-depth information.
+See the section on how wallets determine whether transactions belong to them using the xref:transaction-identification.adoc#ismine-enum[enum] for more in-depth information.
 
 === Conflict tracking
 

coin-selection.adoc

@@ -6,7 +6,7 @@ include::links-onepage.adoc[]
 === Coin selection
 
 See https://bitcoinops.org/en/topics/coin-selection/[Bitcoin Optech^] for more information on coin selection.
-There is a section digging deeper into the coin selection code found <<{constructing-transactions}coin-selection,below>>.
+There is a section digging deeper into the coin selection code found xref:constructing-transactions.adoc#coin-selection[below].
 To select inputs to a transaction our primary considerations are privacy and fees.
 
 The below sections form an overview of creating a transaction via `CreateTransactionInternal()`.
@@ -47,7 +47,7 @@ If this is still unsuccessful it increases the number of ancestors and descendan
 ==== `AttemptSelection()`
 
 This function is orchestrating the <<GroupOutputs,Output group>> creation, and then the <<selectCoins,coin selection>>.
-Currently, this is always based on the <<{constructing-transactions}coin-selection,waste metric>>.
+Currently, this is always based on the xref:constructing-transactions.adoc#coin-selection[waste metric].
 
 It is using 3 algorithms and then selecting the "best" of the three (based on the waste metric):
 

consensus-and-validation.adoc

@@ -15,7 +15,7 @@ WARNING: If all nodes do not compute consensus values identically (including edg
 
 For more information on how the bitcoin networks' decentralized consensus mechanism works see the Mastering Bitcoin section on https://github.com/bitcoinbook/bitcoinbook/tree/develop/ch10.asciidoc#decentralized-consensus[decentralized consensus^].
 
-TIP: In Bitcoin Core there are an extra level of validation checks applied to incoming transactions in addition to consensus checks called "policy" which have a slightly different purpose, see <<{consensus-v-policy}consensus_vs_policy>> for more information on the differences between the two.
+TIP: In Bitcoin Core there are an extra level of validation checks applied to incoming transactions in addition to consensus checks called "policy" which have a slightly different purpose, see xref:consensus-v-policy.adoc#consensus_vs_policy[consensus vs policy] for more information on the differences between the two.
 
 Consensus::
 A collection of functions and variables which **must** be computed identically to all https://bitnodes.io/nodes/[other^] nodes on the network in order to remain in consensus and therefore on the main chain.

consensus-bugs.adoc

@@ -109,7 +109,7 @@ Do you think this approach -- first altering policy, followed later by consensus
 Are there circumstances where it might not make sense?
 ====
 
-Having OpenSSL as a consensus-critical dependency to the project was ultimately fixed in https://github.com/bitcoin/bitcoin/pull/6954[PR#6954^] which switched to using the in-house libsecp256k1 library (as a <<{subtrees}subtrees,subtree>>) for signature verification.
+Having OpenSSL as a consensus-critical dependency to the project was ultimately fixed in https://github.com/bitcoin/bitcoin/pull/6954[PR#6954^] which switched to using the in-house libsecp256k1 library (as a xref:subtrees.adoc#subtrees[subtree]) for signature verification.
 
 [[database_consensus]]
 === Database consensus
@@ -188,7 +188,7 @@ If they do, then the changes will end up being either a soft or hard fork, depen
 
 WARNING: As <<Database consensus,described>>, certain Bitcoin Core components, such as the block database can also unwittingly introduce forking behaviour, even though they do not directly modify consensus rules.
 
-Some of the components which are known to alter consensus behaviour, and should therefore be approached with caution, are listed in the section <<{locating-consensus-code}consensus-components,consensus components>>.
+Some of the components which are known to alter consensus behaviour, and should therefore be approached with caution, are listed in the section xref:locating-consensus-code.adoc#consensus-components[consensus components].
 
 Changes are not made to consensus values or computations without extreme levels of review and necessity.
 In contrast, changes such as refactoring can be (and are) made to areas of consensus code, when we can be sure that they will not alter consensus validation.

consensus-exercises.adoc

@@ -14,7 +14,7 @@ Contextual checks require some knowledge of the current "state", e.g. ChainState
 
 Context-free checks only require the information required in the transaction itself.
 
-For more info, see <<{transaction-validation}glozow-tx-mempool-validation,glozow's notes>> on transaction "Validation and Submission to the Mempool".
+For more info, see xref:transaction-validation.adoc#glozow-tx-mempool-validation[glozow's notes] on transaction "Validation and Submission to the Mempool".
 ====
 
 What are some examples of each?::

consensus-specification.adoc

@@ -5,7 +5,7 @@ include::links-onepage.adoc[]
 == Bitcoin core consensus specification
 
 A common question is where the bitcoin protocol is documented, i.e. specified.
-However bitcoin does not have a formal specification, even though many ideas have some specification (in <<{bips}bips>>) to aid re-implementation.
+However bitcoin does not have a formal specification, even though many ideas have some specification (in xref:bips.adoc[BIPS]) to aid re-implementation.
 
 IMPORTANT: The requirements to be compliant with "the bitcoin spec" are to be bug-for-bug compatible with the Bitcoin Core implementation.
 

cwallet.adoc

@@ -40,6 +40,6 @@ These include options such as `-addresstype`, `-changetype`, `-mintxfee` and `-m
 It is at this stage that warnings for unusual or unsafe values of these arguments are generated to be returned to the user.
 
 After the wallet is fully initialized and setup, its keypool will be topped up before the wallet is locked and registered with the Validation interface, which will handle callback notifications generated during the (optional) upcoming chain rescan.
-The rescan is smart in detecting the wallet "birthday" using metadata stored in the <<{scriptpubkeymanagers}scriptpubkeymanagers,SPKM>> and won't scan blocks produced before this date.
+The rescan is smart in detecting the wallet "birthday" using metadata stored in the xref:scriptpubkeymanagers.adoc#scriptpubkeymanagers[SPKM] and won't scan blocks produced before this date.
 
 Finally, the `walletinterface` is setup for the wallet before the `WalletInstance` is returned to the caller.

exercise-intro.adoc

@@ -1,7 +1,7 @@
 include::links-onepage.adoc[]
 
 ****
-Using either `bitcoin-cli` in your terminal, or a <<{contributor-exercises}test_shell_nodes,Jupyter Notebook>> in conjunction with the `TestShell` class from the Bitcoin Core Test Framework, try to complete the following exercises.
+Using either `bitcoin-cli` in your terminal, or a xref:contributor-exercises.adoc#test_shell_nodes[Jupyter notebook] in conjunction with the `TestShell` class from the Bitcoin Core Test Framework, try to complete the following exercises.
 
 Changes to the codebase will require you to re-compile afterwards.
 

gui-building.adoc

@@ -20,7 +20,7 @@ If the build is configured with `--enable-multiprocess` then additional binaries
 == Qt
 
 QT is currently very intertwined with the rest of the codebase.
-See the library <<{library-structure}library-dependency-graph,depencency graph>> for more context.
+See the library xref:library-structure.adoc#library-dependency-graph[depencency graph] for more context.
 
 Developers would ideally like to reduce these dependencies in the future.
 

gui-initialization.adoc

@@ -9,7 +9,7 @@ The loading point for the GUI is _src/qt/main.cpp_.
 `GuiMain` starts by calling `SetupEnvironment()` which amongst other things, configures the runtime locale and charset.
 
 Next an empty `NodeContext` is set up, which is then populated into a fully-fledged node interface via being passed to `interfaces::MakeNode()`, which returns an `interfaces::Node`.
-Recall that in <<{wallet-init}wallet_component_initialisation>> we also saw the wallet utilizing a `NodeContext` as part of its `WalletInitInterface`.
+Recall that in xref:wallet-init.adoc#wallet_component_initialisation[wallet component initialization] we also saw the wallet utilizing a `NodeContext` as part of its `WalletInitInterface`.
 In both cases the `NodeContext` is being used to pass chain and network references around without needing to create globals.
 
 After some QT setup, command-line and application arguments are parsed.

input-checks.adoc

@@ -73,7 +73,7 @@ This is going to check the transaction against our individual node's policies.
 ====
 Note that local node policies are not necessarily consensus-binding, but are designed to help prevent resource exhaustion (e.g. DoS) on our node.
 
-See the <<{transaction-validation}transaction_validation>> and <<{locating-consensus-code}consensus_in_bitcoin_core>> sections for more information on the differences between policy and consensus.
+See the xref:transaction-validation.adoc#transaction_validation[transaction validation] and xref:locating-consensus-code.adoc#consensus_in_bitcoin_core[consensus in bitcoin core] sections for more information on the differences between policy and consensus.
 ====
 
 `PolicyScriptChecks()` starts with initialisation of the transaction into a `CTransaction`, before beginning to https://github.com/bitcoin/bitcoin/blob/v23.0/src/validation.cpp#L973-L999[check^] the input scripts against the script flags.
@@ -177,7 +177,7 @@ static bool CheckInputsFromMempoolAndCache(const CTransaction& tx, TxValidationS
 `PackageMempoolChecks` are designed to "Enforce package mempool ancestor/descendant limits (distinct from individual ancestor/descendant limits done in PreChecks)".
 They take a vector of ``CTransactionRef``s and a `PackageValidationState`.
 
-Again we take <<{single-transactions}multiple_locks,two locks>> before checking that the transactions are not in the mempool.
+Again we take xref:single-transactions.adoc#multiple_locks[two locks] before checking that the transactions are not in the mempool.
 Any transactions which are part of the package and were in the mempool will have already been removed by `MemPoolAccept::AcceptPackage()`.
 
 Finally we check the package limits, which consists of checking the {ancestor|descendant} {count|size}.

locating-consensus-code.adoc

@@ -20,7 +20,7 @@ Components of consensus-related code can be found across the Bitcoin Core codeba
 ----
 
 Consensus-critical functions can also be found in proximity to code which could affect whether a node considers a transaction or block valid.
-This could extend to, for example, block storage <<{consensus-bugs}database_consensus,database>> code.
+This could extend to, for example, block storage xref:consensus-bugs.adoc#database_consensus[database] code.
 
 An abbreviated list of some of the more notable consensus functions and variables is shown below.
 

mempool-lifecycle.adoc

@@ -67,7 +67,7 @@ While the node is running the mempool is persisted in memory.
 By default the mempool is limited to 300MB as specified by `DEFAULT_MAX_MEMPOOL_SIZE`.
 This can be overridden by the program option `maxmempoolsize`.
 
-See <<{mempool-tx-format}mempool_tx_format>> for more information on what data counts towards this limit, or review the `CTxMemPool` data members which store current usage metrics e.g. `CTxMemPool::cachedInnerUsage` and the implementation of e.g. `CTxMemPool::DynamicMemoryUsage()`.
+See xref:mempool-tx-format.adoc#mempool_tx_format[mempool tx format] for more information on what data counts towards this limit, or review the `CTxMemPool` data members which store current usage metrics e.g. `CTxMemPool::cachedInnerUsage` and the implementation of e.g. `CTxMemPool::DynamicMemoryUsage()`.
 
 === Mempool shutdown
 

multiple-transactions.adoc

@@ -13,12 +13,12 @@ It's currently only available from tests (`test/tx_package_tests.cpp`) and the `
 
 This validation flow has been created for usage with Package Mempool Accept, which glozow has written up in a https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a[gist^] (https://archive.ph/Uhewe[archive^]).
 
-The flow here is similar to <{single-transactions}<accept_single_transaction, `AcceptSingleTransaction()`>> in that we start by grabbing `cs_main` before initializing validation state and workspaces, however this time we use `PackageValidationState` and a vector of workspaces, `std::vector<Workspace>`.
+The flow here is similar to xref:single-transactions.adoc#accept_single_transaction[`AcceptSingleTransaction()`] in that we start by grabbing `cs_main` before initializing validation state and workspaces, however this time we use `PackageValidationState` and a vector of workspaces, `std::vector<Workspace>`.
 Each transaction therefore has it's own workspace but all transactions in the package share a single validation state.
 This aligns with the goal of either accepting or rejecting the entire package as a single entity.
 
 Next come two `for` loops over the vector of workspaces (i.e. transactions).
-The first performs the <<{input-checks}prechecks,`PreChecks()`>>, but this time also freeing up coins to be spent by other transactions in this package.
+The first performs the xref:input-checks.adoc#prechecks[`PreChecks()`], but this time also freeing up coins to be spent by other transactions in this package.
 This would not usually be possible (nor make sense) _within_ an `AcceptTransaction()` flow, but within a package we want to be able to validate transactions who use as inputs, other transactions not yet added to our mempool:
 
 [source,cpp,options=nowrap]