From fa9d0623a3153a2ea33540611c26378f05e0d7d4 Mon Sep 17 00:00:00 2001
From: MarcoFalke <*~=`'#}+{/-|&$^_@721217.xyz>
Date: Fri, 27 Feb 2026 17:15:15 +0100
Subject: [PATCH] doc: Use relative markdown links
---
CONTRIBUTING.md | 2 +-
doc/cjdns.md | 2 +-
doc/files.md | 6 +++---
doc/fuzzing.md | 2 +-
doc/managing-wallets.md | 2 +-
doc/multisig-tutorial.md | 2 +-
doc/offline-signing-tutorial.md | 4 ++--
7 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 83a0919a4d6..deb2b40a138 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -184,7 +184,7 @@ subsequent comment to the PR.
### Translation changes
Note that translations should not be submitted as pull requests. Please see
-[Translation Process](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md)
+[Translation Process](/doc/translation_process.md)
for more information on helping with translations.
### Work in Progress Changes and Requests for Comments
diff --git a/doc/cjdns.md b/doc/cjdns.md
index 35fe87adfac..00db83dce7e 100644
--- a/doc/cjdns.md
+++ b/doc/cjdns.md
@@ -100,7 +100,7 @@ number of CJDNS addresses known to your node.
In general, a node can be run with both an onion service and CJDNS (or any/all
of IPv4/IPv6/onion/I2P/CJDNS), which can provide a potential fallback if one of
the networks has issues. There are a number of ways to configure this; see
-[doc/tor.md](https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md) for
+[doc/tor.md](/doc/tor.md) for
details.
## CJDNS-related information in Bitcoin Core
diff --git a/doc/files.md b/doc/files.md
index 27fe5615ddd..8a11e08913c 100644
--- a/doc/files.md
+++ b/doc/files.md
@@ -109,12 +109,12 @@ These subdirectories and files are no longer used by Bitcoin Core:
Path | Description | Repository notes
---------------|-------------|-----------------
`banlist.dat` | Stores the addresses/subnets of banned nodes; superseded by `banlist.json` in 22.0 and completely ignored in 23.0 | [PR #20966](https://github.com/bitcoin/bitcoin/pull/20966), [PR #22570](https://github.com/bitcoin/bitcoin/pull/22570)
-`blktree/` | Blockchain index; replaced by `blocks/index/` in [0.8.0](https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.8.0.md#improvements) | [PR #2231](https://github.com/bitcoin/bitcoin/pull/2231), [`8fdc94cc`](https://github.com/bitcoin/bitcoin/commit/8fdc94cc8f0341e96b1edb3a5b56811c0b20bd15)
+`blktree/` | Blockchain index; replaced by `blocks/index/` in [0.8.0](/doc/release-notes/release-notes-0.8.0.md#improvements) | [PR #2231](https://github.com/bitcoin/bitcoin/pull/2231), [`8fdc94cc`](https://github.com/bitcoin/bitcoin/commit/8fdc94cc8f0341e96b1edb3a5b56811c0b20bd15)
`coins/` | Unspent transaction output database; replaced by `chainstate/` in 0.8.0 | [PR #2231](https://github.com/bitcoin/bitcoin/pull/2231), [`8fdc94cc`](https://github.com/bitcoin/bitcoin/commit/8fdc94cc8f0341e96b1edb3a5b56811c0b20bd15)
`blkindex.dat` | Blockchain index BDB database; replaced by {`chainstate/`, `blocks/index/`, `blocks/revNNNNN.dat`[\[2\]](#note2)} in 0.8.0 | [PR #1677](https://github.com/bitcoin/bitcoin/pull/1677)
`blk000?.dat` | Block data (custom format, 2 GiB per file); replaced by `blocks/blkNNNNN.dat`[\[2\]](#note2) in 0.8.0 | [PR #1677](https://github.com/bitcoin/bitcoin/pull/1677)
-`addr.dat` | Peer IP address BDB database; replaced by `peers.dat` in [0.7.0](https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.7.0.md) | [PR #1198](https://github.com/bitcoin/bitcoin/pull/1198), [`928d3a01`](https://github.com/bitcoin/bitcoin/commit/928d3a011cc66c7f907c4d053f674ea77dc611cc)
-`onion_private_key` | Cached Tor onion service private key for `-listenonion` option. Was used for Tor v2 services; replaced by `onion_v3_private_key` in [0.21.0](https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.21.0.md) | [PR #19954](https://github.com/bitcoin/bitcoin/pull/19954)
+`addr.dat` | Peer IP address BDB database; replaced by `peers.dat` in [0.7.0](/doc/release-notes/release-notes-0.7.0.md) | [PR #1198](https://github.com/bitcoin/bitcoin/pull/1198), [`928d3a01`](https://github.com/bitcoin/bitcoin/commit/928d3a011cc66c7f907c4d053f674ea77dc611cc)
+`onion_private_key` | Cached Tor onion service private key for `-listenonion` option. Was used for Tor v2 services; replaced by `onion_v3_private_key` in [0.21.0](/doc/release-notes/release-notes-0.21.0.md) | [PR #19954](https://github.com/bitcoin/bitcoin/pull/19954)
### Berkeley DB database based wallets
diff --git a/doc/fuzzing.md b/doc/fuzzing.md
index 7564bbd7e8a..4b108862cd9 100644
--- a/doc/fuzzing.md
+++ b/doc/fuzzing.md
@@ -30,7 +30,7 @@ more information.
## Fuzzing harnesses and output
-[`process_message`](https://github.com/bitcoin/bitcoin/blob/master/src/test/fuzz/process_message.cpp) is a fuzzing harness for the [`ProcessMessage(...)` function (`net_processing`)](https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp). The available fuzzing harnesses are found in [`src/test/fuzz/`](https://github.com/bitcoin/bitcoin/tree/master/src/test/fuzz).
+[`process_message`](/src/test/fuzz/process_message.cpp) is a fuzzing harness for the [`ProcessMessage(...)` function (`net_processing`)](/src/net_processing.cpp). The available fuzzing harnesses are found in [`src/test/fuzz/`](/src/test/fuzz).
The fuzzer will output `NEW` every time it has created a test input that covers new areas of the code under test. For more information on how to interpret the fuzzer output, see the [libFuzzer documentation](https://llvm.org/docs/LibFuzzer.html).
diff --git a/doc/managing-wallets.md b/doc/managing-wallets.md
index 3ff9834506b..f4f81ad6e72 100644
--- a/doc/managing-wallets.md
+++ b/doc/managing-wallets.md
@@ -102,7 +102,7 @@ If both the wallet and all backups are lost for any reason, the bitcoins related
The original Bitcoin Core wallet was a collection of unrelated private keys. If a non-HD wallet had received funds to an address and then was restored from a backup made before the address was generated, then any funds sent to that address would have been lost because there was no deterministic mechanism to derive the address again.
-Bitcoin Core [version 0.13](https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.13.0.md) introduced HD wallets with deterministic key derivation. With HD wallets, users no longer lose funds when restoring old backups because all addresses are derived from the HD wallet seed.
+Bitcoin Core [version 0.13](/doc/release-notes/release-notes-0.13.0.md) introduced HD wallets with deterministic key derivation. With HD wallets, users no longer lose funds when restoring old backups because all addresses are derived from the HD wallet seed.
This means that a single backup is enough to recover the coins at any time. It is still recommended to make regular backups (once a week) or after a significant number of new transactions to maintain the metadata, such as labels. Metadata cannot be retrieved from a blockchain rescan, so if the backup is too old, the metadata will be lost forever.
diff --git a/doc/multisig-tutorial.md b/doc/multisig-tutorial.md
index 6feb3108c8b..b6f496a32d3 100644
--- a/doc/multisig-tutorial.md
+++ b/doc/multisig-tutorial.md
@@ -2,7 +2,7 @@
Currently, it is possible to create a multisig wallet using Bitcoin Core only.
-Although there is already a brief explanation about the multisig in the [Descriptors documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#multisig), this tutorial proposes to use the signet (instead of regtest), bringing the reader closer to a real environment and explaining some functions in more detail.
+Although there is already a brief explanation about the multisig in the [Descriptors documentation](/doc/descriptors.md#multisig), this tutorial proposes to use the signet (instead of regtest), bringing the reader closer to a real environment and explaining some functions in more detail.
This tutorial uses [jq](https://github.com/stedolan/jq) JSON processor to process the results from RPC and stores the relevant values in bash variables. This makes the tutorial reproducible and easier to follow step by step.
diff --git a/doc/offline-signing-tutorial.md b/doc/offline-signing-tutorial.md
index 2b21af2441a..ffe156225b0 100644
--- a/doc/offline-signing-tutorial.md
+++ b/doc/offline-signing-tutorial.md
@@ -4,7 +4,7 @@ This tutorial will describe how to use two instances of Bitcoin Core, one online
Maintaining an air-gap between private keys and any network connections drastically reduces the opportunity for those keys to be exfiltrated from the user.
-This workflow uses [Partially Signed Bitcoin Transactions](https://github.com/bitcoin/bitcoin/blob/master/doc/psbt.md) (PSBTs) to transfer the transaction to and from the offline wallet for signing using the private keys.
+This workflow uses [Partially Signed Bitcoin Transactions](/doc/psbt.md) (PSBTs) to transfer the transaction to and from the offline wallet for signing using the private keys.
> [!NOTE]
> While this tutorial demonstrates the process using `signet` network, you should omit the `-signet` flag in the provided commands when working with `mainnet`.
@@ -37,7 +37,7 @@ We are going to first create an `offline_wallet` on the offline host. We will th
`bitcoin rpc` can also be substituted for `bitcoin-cli`.
> [!NOTE]
-> The use of a passphrase is crucial to encrypt the wallet.dat file. This encryption ensures that even if an unauthorized individual gains access to the offline host, they won't be able to access the wallet's contents. Further details about securing your wallet can be found in [Managing the Wallet](https://github.com/bitcoin/bitcoin/blob/master/doc/managing-wallets.md#12-encrypting-the-wallet)
+> The use of a passphrase is crucial to encrypt the wallet.dat file. This encryption ensures that even if an unauthorized individual gains access to the offline host, they won't be able to access the wallet's contents. Further details about securing your wallet can be found in [Managing the Wallet](/doc/managing-wallets.md#12-encrypting-the-wallet)
2. Export the public key-only descriptors from the offline host to a JSON file named `descriptors.json`. We use `jq` here to extract the `.descriptors` field from the full RPC response.