aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/README.md1
-rw-r--r--doc/bips.md5
-rw-r--r--doc/build-unix.md2
-rw-r--r--doc/dependencies.md2
-rw-r--r--doc/descriptors.md10
-rw-r--r--doc/developer-notes.md4
-rw-r--r--doc/i2p.md10
-rw-r--r--doc/managing-wallets.md6
-rw-r--r--doc/p2p-bad-ports.md114
-rw-r--r--doc/policy/packages.md15
-rw-r--r--doc/release-notes-23508.md9
-rw-r--r--doc/release-notes.md154
-rw-r--r--doc/release-process.md7
-rw-r--r--doc/tor.md12
-rw-r--r--doc/tracing.md33
15 files changed, 181 insertions, 203 deletions
diff --git a/doc/README.md b/doc/README.md
index 2800937d30..c200ac3753 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -79,6 +79,7 @@ The Bitcoin repo's [root README](/README.md) contains relevant information on th
- [Init Scripts (systemd/upstart/openrc)](init.md)
- [Managing Wallets](managing-wallets.md)
- [Multisig Tutorial](multisig-tutorial.md)
+- [P2P bad ports definition and list](p2p-bad-ports.md)
- [PSBT support](psbt.md)
- [Reduce Memory](reduce-memory.md)
- [Reduce Traffic](reduce-traffic.md)
diff --git a/doc/bips.md b/doc/bips.md
index 27adcedd31..0f3f61daf1 100644
--- a/doc/bips.md
+++ b/doc/bips.md
@@ -1,4 +1,4 @@
-BIPs that are implemented by Bitcoin Core (up-to-date up to **v22.0**):
+BIPs that are implemented by Bitcoin Core (up-to-date up to **v23.0**):
* [`BIP 9`](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki): The changes allowing multiple soft-forks to be deployed in parallel have been implemented since **v0.12.1** ([PR #7575](https://github.com/bitcoin/bitcoin/pull/7575))
* [`BIP 11`](https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki): Multisig outputs are standard since **v0.6.0** ([PR #669](https://github.com/bitcoin/bitcoin/pull/669)).
@@ -42,7 +42,8 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v22.0**):
* [`BIP 147`](https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki): NULLDUMMY softfork as of **v0.13.1** ([PR 8636](https://github.com/bitcoin/bitcoin/pull/8636) and [PR 8937](https://github.com/bitcoin/bitcoin/pull/8937)), *buried* since **v0.19.0** ([PR #16060](https://github.com/bitcoin/bitcoin/pull/16060)).
* [`BIP 152`](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki): Compact block transfer and related optimizations are used as of **v0.13.0** ([PR 8068](https://github.com/bitcoin/bitcoin/pull/8068)).
* [`BIP 155`](https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki): The 'addrv2' and 'sendaddrv2' messages which enable relay of Tor V3 addresses (and other networks) are supported as of **v0.21.0** ([PR 19954](https://github.com/bitcoin/bitcoin/pull/19954)).
-* [`BIP 158`](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki): Compact Block Filters for Light Clients can be indexed as of **v0.19.0** ([PR #14121](https://github.com/bitcoin/bitcoin/pull/14121)).
+* [`BIP 157`](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki)
+ [`158`](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki): Compact Block Filters for Light Clients can be indexed as of **v0.19.0** ([PR #14121](https://github.com/bitcoin/bitcoin/pull/14121)) and served to peers on the P2P network as of **v0.21.0** ([PR #16442](https://github.com/bitcoin/bitcoin/pull/16442)).
* [`BIP 159`](https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki): The `NODE_NETWORK_LIMITED` service bit is signalled as of **v0.16.0** ([PR 11740](https://github.com/bitcoin/bitcoin/pull/11740)), and such nodes are connected to as of **v0.17.0** ([PR 10387](https://github.com/bitcoin/bitcoin/pull/10387)).
* [`BIP 173`](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki): Bech32 addresses for native Segregated Witness outputs are supported as of **v0.16.0** ([PR 11167](https://github.com/bitcoin/bitcoin/pull/11167)). Bech32 addresses are generated by default as of **v0.20.0** ([PR 16884](https://github.com/bitcoin/bitcoin/pull/16884)).
* [`BIP 174`](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki): RPCs to operate on Partially Signed Bitcoin Transactions (PSBT) are present as of **v0.17.0** ([PR 13557](https://github.com/bitcoin/bitcoin/pull/13557)).
diff --git a/doc/build-unix.md b/doc/build-unix.md
index 38844cdf81..15fe63d047 100644
--- a/doc/build-unix.md
+++ b/doc/build-unix.md
@@ -82,7 +82,7 @@ Build requirements:
Now, you can either build from self-compiled [depends](/depends/README.md) or install the required dependencies:
- sudo apt-get install libevent-dev libboost-dev libboost-test-dev
+ sudo apt-get install libevent-dev libboost-dev
SQLite is required for the descriptor wallet:
diff --git a/doc/dependencies.md b/doc/dependencies.md
index 6e1869bfea..21af338119 100644
--- a/doc/dependencies.md
+++ b/doc/dependencies.md
@@ -6,7 +6,7 @@ These are the dependencies currently used by Bitcoin Core. You can find instruct
| Dependency | Version used | Minimum required | CVEs | Shared | [Bundled Qt library](https://doc.qt.io/qt-5/configure-options.html#third-party-libraries) |
| --- | --- | --- | --- | --- | --- |
| Berkeley DB | [4.8.30](https://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index.html) | 4.8.x | No | | |
-| Boost | [1.71.0](https://www.boost.org/users/download/) | [1.64.0](https://github.com/bitcoin/bitcoin/pull/22320) | No | | |
+| Boost | [1.77.0](https://www.boost.org/users/download/) | [1.64.0](https://github.com/bitcoin/bitcoin/pull/22320) | No | | |
| Clang<sup>[ \* ](#note1)</sup> | | [7.0](https://releases.llvm.org/download.html) (C++17 & std::filesystem support) | | | |
| Fontconfig | [2.12.6](https://www.freedesktop.org/software/fontconfig/release/) | | No | Yes | |
| FreeType | [2.11.0](https://download.savannah.gnu.org/releases/freetype) | | No | | [Yes](https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk) (Android only) |
diff --git a/doc/descriptors.md b/doc/descriptors.md
index 57a0f99d70..ab2face4f0 100644
--- a/doc/descriptors.md
+++ b/doc/descriptors.md
@@ -33,6 +33,7 @@ Output descriptors currently support:
- Pay-to-taproot outputs (P2TR), through the `tr` function.
- Multisig scripts, through the `multi` function.
- Multisig scripts where the public keys are sorted lexicographically, through the `sortedmulti` function.
+- Multisig scripts inside taproot script trees, through the `multi_a` (and `sortedmulti_a`) function.
- Any type of supported address through the `addr` function.
- Raw hex scripts through the `raw` function.
- Public keys (compressed and uncompressed) in hex notation, or BIP32 extended pubkeys with derivation paths.
@@ -56,6 +57,7 @@ Output descriptors currently support:
- `wsh(multi(1,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))` describes a set of *1-of-2* P2WSH multisig outputs where the first multisig key is the *1/0/`i`* child of the first specified xpub and the second multisig key is the *0/0/`i`* child of the second specified xpub, and `i` is any number in a configurable range (`0-1000` by default).
- `wsh(sortedmulti(1,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))` describes a set of *1-of-2* P2WSH multisig outputs where one multisig key is the *1/0/`i`* child of the first specified xpub and the other multisig key is the *0/0/`i`* child of the second specified xpub, and `i` is any number in a configurable range (`0-1000` by default). The order of public keys in the resulting witnessScripts is determined by the lexicographic order of the public keys at that index.
- `tr(c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5,{pk(fff97bd5755eeea420453a14355235d382f6472f8568a18b2f057a1460297556),pk(e493dbf1c10d80f3581e4904930b1404cc6c13900ee0758474fa94abe8c4cd13)})` describes a P2TR output with the `c6...` x-only pubkey as internal key, and two script paths.
+- `tr(c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5,sortedmulti_a(2,2f8bde4d1a07209355b4a7250a5c5128e88b84bddc619ab7cba8d569b240efe4,5cbdf0646e5db4eaa398f365f2ea7a0e3d419b7e0330e39ce92bddedcac4f9bc))` describes a P2TR output with the `c6...` x-only pubkey as internal key, and a single `multi_a` script that needs 2 signatures with 2 specified x-only keys, which will be sorted lexicographically.
## Reference
@@ -68,8 +70,10 @@ Descriptors consist of several types of expressions. The top level expression is
- `pkh(KEY)` (not inside `tr`): P2PKH output for the given public key (use `addr` if you only know the pubkey hash).
- `wpkh(KEY)` (top level or inside `sh` only): P2WPKH output for the given compressed pubkey.
- `combo(KEY)` (top level only): an alias for the collection of `pk(KEY)` and `pkh(KEY)`. If the key is compressed, it also includes `wpkh(KEY)` and `sh(wpkh(KEY))`.
-- `multi(k,KEY_1,KEY_2,...,KEY_n)` (not inside `tr`): k-of-n multisig script.
+- `multi(k,KEY_1,KEY_2,...,KEY_n)` (not inside `tr`): k-of-n multisig script using OP_CHECKMULTISIG.
- `sortedmulti(k,KEY_1,KEY_2,...,KEY_n)` (not inside `tr`): k-of-n multisig script with keys sorted lexicographically in the resulting script.
+- `multi_a(k,KEY_1,KEY_2,...,KEY_N)` (only inside `tr`): k-of-n multisig script using OP_CHECKSIG, OP_CHECKSIGADD, and OP_NUMEQUAL.
+- `sortedmulti_a(k,KEY_1,KEY_2,...,KEY_N)` (only inside `tr`): similar to `multi_a`, but the (x-only) public keys in it will be sorted lexicographically.
- `tr(KEY)` or `tr(KEY,TREE)` (top level only): P2TR output with the specified key as internal key, and optionally a tree of script paths.
- `addr(ADDR)` (top level only): the script which ADDR expands to.
- `raw(HEX)` (top level only): the script whose hex encoding is HEX.
@@ -90,12 +94,12 @@ Descriptors consist of several types of expressions. The top level expression is
- Optionally followed by a single `/*` or `/*'` final step to denote all (direct) unhardened or hardened children.
- The usage of hardened derivation steps requires providing the private key.
+(Anywhere a `'` suffix is permitted to denote hardened derivation, the suffix `h` can be used instead.)
+
`TREE` expressions:
- any `SCRIPT` expression
- An open brace `{`, a `TREE` expression, a comma `,`, a `TREE` expression, and a closing brace `}`
-(Anywhere a `'` suffix is permitted to denote hardened derivation, the suffix `h` can be used instead.)
-
`ADDR` expressions are any type of supported address:
- P2PKH addresses (base58, of the form `1...` for mainnet or `[nm]...` for testnet). Note that P2PKH addresses in descriptors cannot be used for P2PK outputs (use the `pk` function instead).
- P2SH addresses (base58, of the form `3...` for mainnet or `2...` for testnet, defined in [BIP 13](https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki)).
diff --git a/doc/developer-notes.md b/doc/developer-notes.md
index 1888897856..bfb64093e1 100644
--- a/doc/developer-notes.md
+++ b/doc/developer-notes.md
@@ -331,7 +331,7 @@ other input.
failure, it will throw an exception, which can be caught to recover from the
error.
- For example, a nullptr dereference or any other logic bug in RPC code
- means that the RPC code is faulty and can not be executed. However, the
+ means that the RPC code is faulty and cannot be executed. However, the
logic bug can be shown to the user and the program can continue to run.
* `Assume` should be used to document assumptions when program execution can
safely continue even if the assumption is violated. In debug builds it
@@ -1199,7 +1199,7 @@ A few guidelines for introducing and reviewing new RPC interfaces:
- Don't forget to fill in the argument names correctly in the RPC command table.
- - *Rationale*: If not, the call can not be used with name-based arguments.
+ - *Rationale*: If not, the call cannot be used with name-based arguments.
- Add every non-string RPC argument `(method, idx, name)` to the table `vRPCConvertParams` in `rpc/client.cpp`.
diff --git a/doc/i2p.md b/doc/i2p.md
index 5f631c11ca..e45b5efb9b 100644
--- a/doc/i2p.md
+++ b/doc/i2p.md
@@ -65,13 +65,9 @@ logging` for more information.
-onlynet=i2p
```
-Make outgoing connections only to I2P addresses. Incoming connections are not
-affected by this option. It can be specified multiple times to allow multiple
-network types, e.g. onlynet=ipv4, onlynet=ipv6, onlynet=onion, onlynet=i2p.
-
-Warning: if you use -onlynet with values other than onion, and the -onion or
--proxy option is set, then outgoing onion connections will still be made; use
--noonion or -onion=0 to disable outbound onion connections in this case.
+Make automatic outbound connections only to I2P addresses. Inbound and manual
+connections are not affected by this option. It can be specified multiple times
+to allow multiple networks, e.g. onlynet=onion, onlynet=i2p.
I2P support was added to Bitcoin Core in version 22.0 and there may be fewer I2P
peers than Tor or IP ones. Therefore, using I2P alone without other networks may
diff --git a/doc/managing-wallets.md b/doc/managing-wallets.md
index aab6d131bd..6c1e13c503 100644
--- a/doc/managing-wallets.md
+++ b/doc/managing-wallets.md
@@ -12,11 +12,9 @@ In the GUI, the `Create a new wallet` button is displayed on the main screen whe
The following command, for example, creates a descriptor wallet. More information about this command may be found by running `bitcoin-cli help createwallet`.
```
-$ bitcoin-cli -named createwallet wallet_name="wallet-01" descriptors=true
+$ bitcoin-cli createwallet "wallet-01"
```
-The `descriptors` parameter can be omitted if the intention is to create a legacy wallet. For now, the default type is the legacy wallet, but that is expected to change in a future release.
-
By default, wallets are created in the `wallets` folder of the data directory, which varies by operating system, as shown below. The user can change the default by using the `-datadir` or `-walletdir` initialization parameters.
| Operating System | Default wallet directory |
@@ -54,7 +52,7 @@ Only the wallet's private key is encrypted. All other wallet information, such a
The wallet's private key can also be encrypted in the `createwallet` command via the `passphrase` argument:
```
-$ bitcoin-cli -named createwallet wallet_name="wallet-01" descriptors=true passphrase="passphrase"
+$ bitcoin-cli -named createwallet wallet_name="wallet-01" passphrase="passphrase"
```
Note that if the passphrase is lost, all the coins in the wallet will also be lost forever.
diff --git a/doc/p2p-bad-ports.md b/doc/p2p-bad-ports.md
new file mode 100644
index 0000000000..4f717f97a2
--- /dev/null
+++ b/doc/p2p-bad-ports.md
@@ -0,0 +1,114 @@
+When Bitcoin Core automatically opens outgoing P2P connections, it chooses
+a peer (address and port) from its list of potential peers. This list is
+populated with unchecked data gossiped over the P2P network by other peers.
+
+A malicious actor may gossip an address:port where no Bitcoin node is listening,
+or one where a service is listening that is not related to the Bitcoin network.
+As a result, this service may occasionally get connection attempts from Bitcoin
+nodes.
+
+"Bad" ports are ones used by services which are usually not open to the public
+and usually require authentication. A connection attempt (by Bitcoin Core,
+trying to connect because it thinks there is a Bitcoin node on that
+address:port) to such service may be considered a malicious action by an
+ultra-paranoid administrator. An example for such a port is 22 (ssh). On the
+other hand, connection attempts to public services that usually do not require
+authentication are unlikely to be considered a malicious action,
+e.g. port 80 (http).
+
+Below is a list of "bad" ports which Bitcoin Core avoids when choosing a peer to
+connect to. If a node is listening on such a port, it will likely receive fewer
+incoming connections.
+
+ 1: tcpmux
+ 7: echo
+ 9: discard
+ 11: systat
+ 13: daytime
+ 15: netstat
+ 17: qotd
+ 19: chargen
+ 20: ftp data
+ 21: ftp access
+ 22: ssh
+ 23: telnet
+ 25: smtp
+ 37: time
+ 42: name
+ 43: nicname
+ 53: domain
+ 69: tftp
+ 77: priv-rjs
+ 79: finger
+ 87: ttylink
+ 95: supdup
+ 101: hostname
+ 102: iso-tsap
+ 103: gppitnp
+ 104: acr-nema
+ 109: pop2
+ 110: pop3
+ 111: sunrpc
+ 113: auth
+ 115: sftp
+ 117: uucp-path
+ 119: nntp
+ 123: NTP
+ 135: loc-srv /epmap
+ 137: netbios
+ 139: netbios
+ 143: imap2
+ 161: snmp
+ 179: BGP
+ 389: ldap
+ 427: SLP (Also used by Apple Filing Protocol)
+ 465: smtp+ssl
+ 512: print / exec
+ 513: login
+ 514: shell
+ 515: printer
+ 526: tempo
+ 530: courier
+ 531: chat
+ 532: netnews
+ 540: uucp
+ 548: AFP (Apple Filing Protocol)
+ 554: rtsp
+ 556: remotefs
+ 563: nntp+ssl
+ 587: smtp (rfc6409)
+ 601: syslog-conn (rfc3195)
+ 636: ldap+ssl
+ 989: ftps-data
+ 990: ftps
+ 993: ldap+ssl
+ 995: pop3+ssl
+ 1719: h323gatestat
+ 1720: h323hostcall
+ 1723: pptp
+ 2049: nfs
+ 3659: apple-sasl / PasswordServer
+ 4045: lockd
+ 5060: sip
+ 5061: sips
+ 6000: X11
+ 6566: sane-port
+ 6665: Alternate IRC
+ 6666: Alternate IRC
+ 6667: Standard IRC
+ 6668: Alternate IRC
+ 6669: Alternate IRC
+ 6697: IRC + TLS
+ 10080: Amanda
+
+For further information see:
+
+[pull/23306](https://github.com/bitcoin/bitcoin/pull/23306#issuecomment-947516736)
+
+[pull/23542](https://github.com/bitcoin/bitcoin/pull/23542)
+
+[fetch.spec.whatwg.org](https://fetch.spec.whatwg.org/#port-blocking)
+
+[chromium.googlesource.com](https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/net/base/port_util.cc)
+
+[hg.mozilla.org](https://hg.mozilla.org/mozilla-central/file/tip/netwerk/base/nsIOService.cpp)
diff --git a/doc/policy/packages.md b/doc/policy/packages.md
index 07698f2af2..7f7fbe18cd 100644
--- a/doc/policy/packages.md
+++ b/doc/policy/packages.md
@@ -57,3 +57,18 @@ test accepts):
- Warning: Batched fee-bumping may be unsafe for some use cases. Users and application developers
should take caution if utilizing multi-parent packages.
+
+* Transactions in the package that have the same txid as another transaction already in the mempool
+ will be removed from the package prior to submission ("deduplication").
+
+ - *Rationale*: Node operators are free to set their mempool policies however they please, nodes
+ may receive transactions in different orders, and malicious counterparties may try to take
+ advantage of policy differences to pin or delay propagation of transactions. As such, it's
+ possible for some package transaction(s) to already be in the mempool, and there is no need to
+ repeat validation for those transactions or double-count them in fees.
+
+ - *Rationale*: We want to prevent potential censorship vectors. We should not reject entire
+ packages because we already have one of the transactions. Also, if an attacker first broadcasts
+ a competing package or transaction with a mutated witness, even though the two
+ same-txid-different-witness transactions are conflicting and cannot replace each other, the
+ honest package should still be considered for acceptance.
diff --git a/doc/release-notes-23508.md b/doc/release-notes-23508.md
deleted file mode 100644
index 098654e00b..0000000000
--- a/doc/release-notes-23508.md
+++ /dev/null
@@ -1,9 +0,0 @@
-Updated RPCs
-------------
-
-- Information on soft fork status has been moved from `getblockchaininfo`
- to `getdeploymentinfo` which allows querying soft fork status at any
- block, rather than just at the chain tip. Inclusion of soft fork
- status in `getblockchaininfo` can currently be restored using the
- configuration `-deprecatedrpc=softforks`, but this will be removed in
- a future release. (#23508)
diff --git a/doc/release-notes.md b/doc/release-notes.md
index 7a47d76bba..2342342ae2 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -6,7 +6,7 @@ template to create the initial release notes draft.*
for the process.*
*Create the draft, named* "*version* Release Notes Draft"
-*(e.g. "22.0 Release Notes Draft"), as a collaborative wiki in:*
+*(e.g. "23.0 Release Notes Draft"), as a collaborative wiki in:*
https://github.com/bitcoin-core/bitcoin-devwiki/wiki/
@@ -54,159 +54,9 @@ unsupported systems.
Notable changes
===============
-P2P and network changes
------------------------
-
-- A bitcoind node will no longer rumour addresses to inbound peers by default.
- They will become eligible for address gossip after sending an ADDR, ADDRV2,
- or GETADDR message. (#21528)
-
-Fee estimation changes
-----------------------
-
-- Fee estimation now takes the feerate of replacement (RBF) transactions into
- account. (#22539)
-
-Rescan startup parameter removed
---------------------------------
-
-The `-rescan` startup parameter has been removed. Wallets which require
-rescanning due to corruption will still be rescanned on startup.
-Otherwise, please use the `rescanblockchain` RPC to trigger a rescan. (#23123)
-
-Updated RPCs
-------------
-
-- The `validateaddress` RPC now returns an `error_locations` array for invalid
- addresses, with the indices of invalid character locations in the address (if
- known). For example, this will attempt to locate up to two Bech32 errors, and
- return their locations if successful. Success and correctness are only guaranteed
- if fewer than two substitution errors have been made.
- The error message returned in the `error` field now also returns more specific
- errors when decoding fails. (#16807)
-
-- The `-deprecatedrpc=addresses` configuration option has been removed. RPCs
- `gettxout`, `getrawtransaction`, `decoderawtransaction`, `decodescript`,
- `gettransaction verbose=true` and REST endpoints `/rest/tx`, `/rest/getutxos`,
- `/rest/block` no longer return the `addresses` and `reqSigs` fields, which
- were previously deprecated in 22.0. (#22650)
-- The `getblock` RPC command now supports verbosity level 3 containing transaction inputs'
- `prevout` information. The existing `/rest/block/` REST endpoint is modified to contain
- this information too. Every `vin` field will contain an additional `prevout` subfield
- describing the spent output. `prevout` contains the following keys:
- - `generated` - true if the spent coins was a coinbase.
- - `height`
- - `value`
- - `scriptPubKey`
-
-- The top-level fee fields `fee`, `modifiedfee`, `ancestorfees` and `descendantfees`
- returned by RPCs `getmempoolentry`,`getrawmempool(verbose=true)`,
- `getmempoolancestors(verbose=true)` and `getmempooldescendants(verbose=true)`
- are deprecated and will be removed in the next major version (use
- `-deprecated=fees` if needed in this version). The same fee fields can be accessed
- through the `fees` object in the result. WARNING: deprecated
- fields `ancestorfees` and `descendantfees` are denominated in sats, whereas all
- fields in the `fees` object are denominated in BTC. (#22689)
-
-- Both `createmultisig` and `addmultisigaddress` now include a `warnings`
- field, which will show a warning if a non-legacy address type is requested
- when using uncompressed public keys. (#23113)
-
-New RPCs
---------
-
-Build System
+Example item
------------
-Files
------
-
-* On startup, the list of banned hosts and networks (via `setban` RPC) in
- `banlist.dat` is ignored and only `banlist.json` is considered. Bitcoin Core
- version 22.x is the only version that can read `banlist.dat` and also write
- it to `banlist.json`. If `banlist.json` already exists, version 22.x will not
- try to translate the `banlist.dat` into json. After an upgrade, `listbanned`
- can be used to double check the parsed entries. (#22570)
-
-New settings
-------------
-
-Updated settings
-----------------
-
-- In previous releases, the meaning of the command line option
- `-persistmempool` (without a value provided) incorrectly disabled mempool
- persistence. `-persistmempool` is now treated like other boolean options to
- mean `-persistmempool=1`. Passing `-persistmempool=0`, `-persistmempool=1`
- and `-nopersistmempool` is unaffected. (#23061)
-
-- `-maxuploadtarget` now allows human readable byte units [k|K|m|M|g|G|t|T].
- E.g. `-maxuploadtarget=500g`. No whitespace, +- or fractions allowed.
- Default is `M` if no suffix provided. (#23249)
-
-Tools and Utilities
--------------------
-
-- Update `-getinfo` to return data in a user-friendly format that also reduces vertical space. (#21832)
-
-- CLI `-addrinfo` now returns a single field for the number of `onion` addresses
- known to the node instead of separate `torv2` and `torv3` fields, as support
- for Tor V2 addresses was removed from Bitcoin Core in 22.0. (#22544)
-
-Wallet
-------
-
-- `upgradewallet` will now automatically flush the keypool if upgrading
- from a non-HD wallet to an HD wallet, to immediately start using the
- newly-generated HD keys. (#23093)
-
-- a new RPC `newkeypool` has been added, which will flush (entirely
- clear and refill) the keypool. (#23093)
-
-- `listunspent` now includes `ancestorcount`, `ancestorsize`, and
- `ancestorfees` for each transaction output that is still in the mempool.
- (#12677)
-
-- `lockunspent` now optionally takes a third parameter, `persistent`, which
- causes the lock to be written persistently to the wallet database. This
- allows UTXOs to remain locked even after node restarts or crashes. (#23065)
-
-- `receivedby` RPCs now include coinbase transactions. Previously, the
- following wallet RPCs excluded coinbase transactions: `getreceivedbyaddress`,
- `getreceivedbylabel`, `listreceivedbyaddress`, `listreceivedbylabel`. This
- release changes this behaviour and returns results accounting for received
- coins from coinbase outputs. The previous behaviour can be restored using the
- configuration `-deprecatedrpc=exclude_coinbase`, but may be removed in a
- future release. (#14707)
-
-- A new option in the same `receivedby` RPCs, `include_immature_coinbase`
- (default=`false`), determines whether to account for immature coinbase
- transactions. Immature coinbase transactions are coinbase transactions that
- have 100 or fewer confirmations, and are not spendable. (#14707)
-
-GUI changes
------------
-
-- UTXOs which are locked via the GUI are now stored persistently in the
- wallet database, so are not lost on node shutdown or crash. (#23065)
-
-- The Bech32 checkbox has been replaced with a dropdown for all address types, including the new Bech32m (BIP-350) standard for Taproot enabled wallets.
-
-Low-level changes
-=================
-
-RPC
----
-
-- `getblockchaininfo` now returns a new `time` field, that provides the chain tip time. (#22407)
-
-Tests
------
-
-- For the `regtest` network the activation heights of several softforks were
- set to block height 1. They can be changed by the runtime setting
- `-testactivationheight=name@height`. (#22818)
-
Credits
=======
diff --git a/doc/release-process.md b/doc/release-process.md
index f786b345b1..5a74f72b6e 100644
--- a/doc/release-process.md
+++ b/doc/release-process.md
@@ -6,13 +6,14 @@ Release Process
### Before every release candidate
* Update translations see [translation_process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md#synchronising-translations).
-* Update manpages, see [gen-manpages.sh](https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/README.md#gen-manpagessh).
* Update release candidate version in `configure.ac` (`CLIENT_VERSION_RC`).
+* Update manpages (after rebuilding the binaries), see [gen-manpages.py](https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/README.md#gen-manpagespy).
### Before every major and minor release
* Update [bips.md](bips.md) to account for changes since the last release (don't forget to bump the version number on the first line).
* Update version in `configure.ac` (don't forget to set `CLIENT_VERSION_RC` to `0`).
+* Update manpages (see previous section)
* Write release notes (see "Write the release notes" below).
### Before every major release
@@ -97,7 +98,7 @@ Checkout the Bitcoin Core version you'd like to build:
pushd ./bitcoin
SIGNER='(your builder key, ie bluematt, sipa, etc)'
VERSION='(new version without v-prefix, e.g. 0.20.0)'
-git fetch "v${VERSION}"
+git fetch origin "v${VERSION}"
git checkout "v${VERSION}"
popd
```
@@ -118,7 +119,7 @@ details.
### Build and attest to build outputs:
Follow the relevant Guix README.md sections:
-- [Performing a build](/contrib/guix/README.md#performing-a-build)
+- [Building](/contrib/guix/README.md#building)
- [Attesting to build outputs](/contrib/guix/README.md#attesting-to-build-outputs)
### Verify other builders' signatures to your own. (Optional)
diff --git a/doc/tor.md b/doc/tor.md
index d23d8a1810..b7c4f7d425 100644
--- a/doc/tor.md
+++ b/doc/tor.md
@@ -55,14 +55,10 @@ outgoing connections, but more is possible.
-seednode=X SOCKS5. In Tor mode, such addresses can also be exchanged with
other P2P nodes.
- -onlynet=onion Make outgoing connections only to .onion addresses. Incoming
- connections are not affected by this option. This option can be
- specified multiple times to allow multiple network types, e.g.
- onlynet=ipv4, onlynet=ipv6, onlynet=onion, onlynet=i2p.
- Warning: if you use -onlynet with values other than onion, and
- the -onion or -proxy option is set, then outgoing onion
- connections will still be made; use -noonion or -onion=0 to
- disable outbound onion connections in this case.
+ -onlynet=onion Make automatic outbound connections only to .onion addresses.
+ Inbound and manual connections are not affected by this option.
+ It can be specified multiple times to allow multiple networks,
+ e.g. onlynet=onion, onlynet=i2p.
In a typical situation, this suffices to run behind a Tor proxy:
diff --git a/doc/tracing.md b/doc/tracing.md
index 5b9ba09c2f..6ec6a6c218 100644
--- a/doc/tracing.md
+++ b/doc/tracing.md
@@ -110,23 +110,31 @@ Arguments passed:
### Context `utxocache`
+The following tracepoints cover the in-memory UTXO cache. UTXOs are, for example,
+added to and removed (spent) from the cache when we connect a new block.
+**Note**: Bitcoin Core uses temporary clones of the _main_ UTXO cache
+(`chainstate.CoinsTip()`). For example, the RPCs `generateblock` and
+`getblocktemplate` call `TestBlockValidity()`, which applies the UTXO set
+changes to a temporary cache. Similarly, mempool consistency checks, which are
+frequent on regtest, also apply the the UTXO set changes to a temporary cache.
+Changes to the _main_ UTXO cache and to temporary caches trigger the tracepoints.
+We can't tell if a temporary cache or the _main_ cache was changed.
+
#### Tracepoint `utxocache:flush`
-Is called *after* the caches and indexes are flushed depending on the mode
-`CChainState::FlushStateToDisk` is called with.
+Is called *after* the in-memory UTXO cache is flushed.
Arguments passed:
-1. Duration in microseconds as `int64`
+1. Time it took to flush the cache microseconds as `int64`
2. Flush state mode as `uint32`. It's an enumerator class with values `0`
(`NONE`), `1` (`IF_NEEDED`), `2` (`PERIODIC`), `3` (`ALWAYS`)
-3. Number of coins flushed as `uint64`
-4. Memory usage in bytes as `uint64`
-5. If the flush was pruned as `bool`
-6. If it was full flush as `bool`
+3. Cache size (number of coins) before the flush as `uint64`
+4. Cache memory usage in bytes as `uint64`
+5. If pruning caused the flush as `bool`
#### Tracepoint `utxocache:add`
-It is called when a new coin is added to the UTXO cache.
+Is called when a coin is added to a UTXO cache. This can be a temporary UTXO cache too.
Arguments passed:
1. Transaction ID (hash) as `pointer to unsigned chars` (i.e. 32 bytes in little-endian)
@@ -137,7 +145,7 @@ Arguments passed:
#### Tracepoint `utxocache:spent`
-It is called when a coin is spent from the UTXO cache.
+Is called when a coin is spent from a UTXO cache. This can be a temporary UTXO cache too.
Arguments passed:
1. Transaction ID (hash) as `pointer to unsigned chars` (i.e. 32 bytes in little-endian)
@@ -148,14 +156,17 @@ Arguments passed:
#### Tracepoint `utxocache:uncache`
-It is called when the UTXO with the given outpoint is removed from the cache.
+Is called when a coin is purposefully unloaded from a UTXO cache. This
+happens, for example, when we load an UTXO into a cache when trying to accept
+a transaction that turns out to be invalid. The loaded UTXO is uncached to avoid
+filling our UTXO cache up with irrelevant UTXOs.
Arguments passed:
1. Transaction ID (hash) as `pointer to unsigned chars` (i.e. 32 bytes in little-endian)
2. Output index as `uint32`
3. Block height the coin was uncached, as `uint32`
4. Value of the coin as `int64`
-. If the coin is a coinbase as `bool`
+5. If the coin is a coinbase as `bool`
## Adding tracepoints to Bitcoin Core
generated by cgit v1.2.3 (git 2.26.2) at 2024-09-16 05:42:19 +0000