mirror of
https://github.com/bitcoin/bitcoin.git
synced 2026-03-16 16:32:47 +00:00
doc: Use relative markdown links
This commit is contained in:
parent
ceff6771b8
commit
fa9d0623a3
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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`<sup>[\[2\]](#note2)</sup>} 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`<sup>[\[2\]](#note2)</sup> 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
|
||||
|
||||
|
||||
@ -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).
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user