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.