diff options
Diffstat (limited to 'doc')
41 files changed, 714 insertions, 315 deletions
diff --git a/doc/REST-interface.md b/doc/REST-interface.md index a704b969df..2d7d0e3769 100644 --- a/doc/REST-interface.md +++ b/doc/REST-interface.md @@ -134,11 +134,15 @@ Returns various information about the transaction mempool. Only supports JSON as output format. Refer to the `getmempoolinfo` RPC help for details. -`GET /rest/mempool/contents.json` +`GET /rest/mempool/contents.json?verbose=<true|false>&mempool_sequence=<false|true>` Returns the transactions in the mempool. Only supports JSON as output format. -Refer to the `getrawmempool` RPC help for details. +Refer to the `getrawmempool` RPC help for details. Defaults to setting +`verbose=true` and `mempool_sequence=false`. + +*Query parameters for `verbose` and `mempool_sequence` available in 25.0 and up.* + Risks ------------- diff --git a/doc/bips.md b/doc/bips.md index 1d5c91b8bd..94213f8048 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 **v24.0**): +BIPs that are implemented by Bitcoin Core: * [`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)). diff --git a/doc/build-openbsd.md b/doc/build-openbsd.md index 255995a517..96ee714341 100644 --- a/doc/build-openbsd.md +++ b/doc/build-openbsd.md @@ -1,6 +1,6 @@ # OpenBSD Build Guide -**Updated for OpenBSD [7.1](https://www.openbsd.org/71.html)** +**Updated for OpenBSD [7.3](https://www.openbsd.org/73.html)** This guide describes how to build bitcoind, command-line utilities, and GUI on OpenBSD. @@ -80,10 +80,6 @@ export AUTOMAKE_VERSION=1.16 ### 1. Configuration -Note that external signer support is currently not available on OpenBSD, since -the used header-only library Boost.Process fails to compile (certain system -calls and preprocessor defines like `waitid()` and `WEXITED` are missing). - There are many ways to configure Bitcoin Core, here are a few common examples: ##### Descriptor Wallet and GUI: diff --git a/doc/build-unix.md b/doc/build-unix.md index 0960ae1577..3633d4f811 100644 --- a/doc/build-unix.md +++ b/doc/build-unix.md @@ -4,16 +4,6 @@ Some notes on how to build Bitcoin Core in Unix. (For BSD specific instructions, see `build-*bsd.md` in this directory.) -Note ---------------------- -Always use absolute paths to configure and compile Bitcoin Core and the dependencies. -For example, when specifying the path of the dependency: - - ../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX - -Here BDB_PREFIX must be an absolute path - it is defined using $(pwd) which ensures -the usage of the absolute path. - To Build --------------------- @@ -24,12 +14,11 @@ make # use "-j N" for N parallel jobs make install # optional ``` -This will build bitcoin-qt as well, if the dependencies are met. - -See [dependencies.md](dependencies.md) for a complete overview. +See below for instructions on how to [install the dependencies on popular Linux +distributions](#linux-distribution-specific-instructions), or the +[dependencies](#dependencies) section for a complete overview. -Memory Requirements --------------------- +## Memory Requirements C++ compilers are memory-hungry. It is recommended to have at least 1.5 GB of memory available when compiling Bitcoin Core. On systems with less, gcc can be @@ -57,7 +46,7 @@ Build requirements: sudo apt-get install build-essential libtool autotools-dev automake pkg-config bsdmainutils python3 -Now, you can either build from self-compiled [depends](/depends/README.md) or install the required dependencies: +Now, you can either build from self-compiled [depends](#dependencies) or install the required dependencies: sudo apt-get install libevent-dev libboost-dev @@ -65,7 +54,7 @@ SQLite is required for the descriptor wallet: sudo apt install libsqlite3-dev -Berkeley DB is required for the legacy wallet. Ubuntu and Debian have their own `libdb-dev` and `libdb++-dev` packages, +Berkeley DB is only required for the legacy wallet. Ubuntu and Debian have their own `libdb-dev` and `libdb++-dev` packages, but these will install Berkeley DB 5.1 or later. This will break binary wallet compatibility with the distributed executables, which are based on BerkeleyDB 4.8. If you do not care about wallet compatibility, pass `--with-incompatible-bdb` to configure. Otherwise, you can build Berkeley DB [yourself](#berkeley-db). @@ -114,7 +103,7 @@ Build requirements: sudo dnf install gcc-c++ libtool make autoconf automake python3 -Now, you can either build from self-compiled [depends](/depends/README.md) or install the required dependencies: +Now, you can either build from self-compiled [depends](#dependencies) or install the required dependencies: sudo dnf install libevent-devel boost-devel @@ -126,7 +115,7 @@ Berkeley DB is required for the legacy wallet: sudo dnf install libdb4-devel libdb4-cxx-devel -Newer Fedora releases, since Fedora 33, have only `libdb-devel` and `libdb-cxx-devel` packages, but these will install +Berkeley DB is only required for the legacy wallet. Newer Fedora releases have only `libdb-devel` and `libdb-cxx-devel` packages, but these will install Berkeley DB 5.3 or later. This will break binary wallet compatibility with the distributed executables, which are based on Berkeley DB 4.8. If you do not care about wallet compatibility, pass `--with-incompatible-bdb` to configure. Otherwise, you can build Berkeley DB [yourself](#berkeley-db). @@ -166,27 +155,13 @@ libqrencode (optional) can be installed with: Once these are installed, they will be found by configure and a bitcoin-qt executable will be built by default. -Notes ------ -The release is built with GCC and then "strip bitcoind" to strip the debug -symbols, which reduces the executable size by about 90%. +## Dependencies -miniupnpc ---------- +See [dependencies.md](dependencies.md) for a complete overview, and +[depends](/depends/README.md) on how to compile them yourself, if you wish to +not use the packages of your Linux distribution. -[miniupnpc](https://miniupnp.tuxfamily.org) may be used for UPnP port mapping. It can be downloaded from [here]( -https://miniupnp.tuxfamily.org/files/). UPnP support is compiled in and -turned off by default. - -libnatpmp ---------- - -[libnatpmp](https://miniupnp.tuxfamily.org/libnatpmp.html) may be used for NAT-PMP port mapping. It can be downloaded -from [here](https://miniupnp.tuxfamily.org/files/). NAT-PMP support is compiled in and -turned off by default. - -Berkeley DB ------------ +### Berkeley DB The legacy wallet uses Berkeley DB. To ensure backwards compatibility it is recommended to use Berkeley DB 4.8. If you have to build it yourself, and don't @@ -205,53 +180,9 @@ export BDB_PREFIX="/path/to/bitcoin/depends/x86_64-pc-linux-gnu" BDB_CFLAGS="-I${BDB_PREFIX}/include" ``` -**Note**: You only need Berkeley DB if the legacy wallet is enabled (see [*Disable-wallet mode*](#disable-wallet-mode)). - -Security --------- -To help make your Bitcoin Core installation more secure by making certain attacks impossible to -exploit even if a vulnerability is found, binaries are hardened by default. -This can be disabled with: - -Hardening Flags: +**Note**: Make sure that `BDB_PREFIX` is an absolute path. - ./configure --enable-hardening - ./configure --disable-hardening - - -Hardening enables the following features: -* _Position Independent Executable_: Build position independent code to take advantage of Address Space Layout Randomization - offered by some kernels. Attackers who can cause execution of code at an arbitrary memory - location are thwarted if they don't know where anything useful is located. - The stack and heap are randomly located by default, but this allows the code section to be - randomly located as well. - - On an AMD64 processor where a library was not compiled with -fPIC, this will cause an error - such as: "relocation R_X86_64_32 against `......' can not be used when making a shared object;" - - To test that you have built PIE executable, install scanelf, part of paxutils, and use: - - scanelf -e ./bitcoin - - The output should contain: - - TYPE - ET_DYN - -* _Non-executable Stack_: If the stack is executable then trivial stack-based buffer overflow exploits are possible if - vulnerable buffers are found. By default, Bitcoin Core should be built with a non-executable stack, - but if one of the libraries it uses asks for an executable stack or someone makes a mistake - and uses a compiler extension which requires an executable stack, it will silently build an - executable without the non-executable stack protection. - - To verify that the stack is non-executable after compiling use: - `scanelf -e ./bitcoin` - - The output should contain: - STK/REL/PTL - RW- R-- RW- - - The STK RW- means that the stack is readable and writeable but not executable. +**Note**: You only need Berkeley DB if the legacy wallet is enabled (see [*Disable-wallet mode*](#disable-wallet-mode)). Disable-wallet mode -------------------- diff --git a/doc/cjdns.md b/doc/cjdns.md index b69564729f..031cd1978b 100644 --- a/doc/cjdns.md +++ b/doc/cjdns.md @@ -112,5 +112,4 @@ There are several ways to see your CJDNS address in Bitcoin Core: To see which CJDNS peers your node is connected to, use `bitcoin-cli -netinfo 4` or the `getpeerinfo` RPC (i.e. `bitcoin-cli getpeerinfo`). -To see which CJDNS addresses your node knows, use the `getnodeaddresses 0 cjdns` -RPC. +You can use the `getnodeaddresses` RPC to fetch a number of CJDNS peers known to your node; run `bitcoin-cli help getnodeaddresses` for details. diff --git a/doc/dependencies.md b/doc/dependencies.md index a9ca5b3e7a..804f796abe 100644 --- a/doc/dependencies.md +++ b/doc/dependencies.md @@ -8,9 +8,9 @@ You can find installation instructions in the `build-*.md` file for your platfor | --- | --- | | [Autoconf](https://www.gnu.org/software/autoconf/) | [2.69](https://github.com/bitcoin/bitcoin/pull/17769) | | [Automake](https://www.gnu.org/software/automake/) | [1.13](https://github.com/bitcoin/bitcoin/pull/18290) | -| [Clang](https://clang.llvm.org) | [8.0](https://github.com/bitcoin/bitcoin/pull/24164) | -| [GCC](https://gcc.gnu.org) | [8.1](https://github.com/bitcoin/bitcoin/pull/23060) | -| [Python](https://www.python.org) (tests) | [3.7](https://github.com/bitcoin/bitcoin/pull/26226) | +| [Clang](https://clang.llvm.org) | [10.0](https://github.com/bitcoin/bitcoin/pull/27682) | +| [GCC](https://gcc.gnu.org) | [9.1](https://github.com/bitcoin/bitcoin/pull/27662) | +| [Python](https://www.python.org) (scripts, tests) | [3.8](https://github.com/bitcoin/bitcoin/pull/27483) | | [systemtap](https://sourceware.org/systemtap/) ([tracing](tracing.md))| N/A | ## Required @@ -20,7 +20,7 @@ You can find installation instructions in the `build-*.md` file for your platfor | [Boost](../depends/packages/boost.mk) | [link](https://www.boost.org/users/download/) | [1.81.0](https://github.com/bitcoin/bitcoin/pull/26557) | [1.64.0](https://github.com/bitcoin/bitcoin/pull/22320) | No | | [libevent](../depends/packages/libevent.mk) | [link](https://github.com/libevent/libevent/releases) | [2.1.12-stable](https://github.com/bitcoin/bitcoin/pull/21991) | [2.1.8](https://github.com/bitcoin/bitcoin/pull/24681) | No | | glibc | [link](https://www.gnu.org/software/libc/) | N/A | [2.27](https://github.com/bitcoin/bitcoin/pull/27029) | Yes | -| Linux Kernel | [link](https://www.kernel.org/) | N/A | 3.2.0 | Yes | +| Linux Kernel | [link](https://www.kernel.org/) | N/A | [3.17.0](https://github.com/bitcoin/bitcoin/pull/27699) | Yes | ## Optional @@ -29,7 +29,7 @@ You can find installation instructions in the `build-*.md` file for your platfor | --- | --- | --- | --- | --- | | [Fontconfig](../depends/packages/fontconfig.mk) | [link](https://www.freedesktop.org/wiki/Software/fontconfig/) | [2.12.6](https://github.com/bitcoin/bitcoin/pull/23495) | 2.6 | Yes | | [FreeType](../depends/packages/freetype.mk) | [link](https://freetype.org) | [2.11.0](https://github.com/bitcoin/bitcoin/commit/01544dd78ccc0b0474571da854e27adef97137fb) | 2.3.0 | Yes | -| [qrencode](../depends/packages/qrencode.mk) | [link](https://fukuchi.org/works/qrencode/) | [3.4.4](https://github.com/bitcoin/bitcoin/pull/6373) | | No | +| [qrencode](../depends/packages/qrencode.mk) | [link](https://fukuchi.org/works/qrencode/) | [4.1.1](https://github.com/bitcoin/bitcoin/pull/27312) | | No | | [Qt](../depends/packages/qt.mk) | [link](https://download.qt.io/official_releases/qt/) | [5.15.5](https://github.com/bitcoin/bitcoin/pull/25719) | [5.11.3](https://github.com/bitcoin/bitcoin/pull/24132) | No | ### Networking @@ -47,4 +47,4 @@ You can find installation instructions in the `build-*.md` file for your platfor | Dependency | Releases | Version used | Minimum required | Runtime | | --- | --- | --- | --- | --- | | [Berkeley DB](../depends/packages/bdb.mk) (legacy wallet) | [link](https://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index.html) | 4.8.30 | 4.8.x | No | -| [SQLite](../depends/packages/sqlite.mk) | [link](https://sqlite.org) | [3.32.1](https://github.com/bitcoin/bitcoin/pull/19077) | [3.7.17](https://github.com/bitcoin/bitcoin/pull/19077) | No | +| [SQLite](../depends/packages/sqlite.mk) | [link](https://sqlite.org) | [3.38.5](https://github.com/bitcoin/bitcoin/pull/25378) | [3.7.17](https://github.com/bitcoin/bitcoin/pull/19077) | No | diff --git a/doc/design/assumeutxo.md b/doc/design/assumeutxo.md index ea51b1b87f..469c551536 100644 --- a/doc/design/assumeutxo.md +++ b/doc/design/assumeutxo.md @@ -3,9 +3,9 @@ Assumeutxo is a feature that allows fast bootstrapping of a validating bitcoind instance with a very similar security model to assumevalid. -The RPC commands `dumptxoutset` and `loadtxoutset` are used to respectively generate -and load UTXO snapshots. The utility script `./contrib/devtools/utxo_snapshot.sh` may -be of use. +The RPC commands `dumptxoutset` and `loadtxoutset` (yet to be merged) are used to +respectively generate and load UTXO snapshots. The utility script +`./contrib/devtools/utxo_snapshot.sh` may be of use. ## General background @@ -22,10 +22,6 @@ be of use. chainstate running asynchronously in the background. We also use this flag to control which index entries are added to setBlockIndexCandidates during LoadBlockIndex(). -- Indexing implementations via BaseIndex can no longer assume that indexation happens - sequentially, since background validation chainstates can submit BlockConnected - events out of order with the active chain. - - The concept of UTXO snapshots is treated as an implementation detail that lives behind the ChainstateManager interface. The external presentation of the changes required to facilitate the use of UTXO snapshots is the understanding that there are @@ -76,9 +72,15 @@ original chainstate remains in use as active. Once the snapshot chainstate is loaded and validated, it is promoted to active chainstate and a sync to tip begins. A new chainstate directory is created in the -datadir for the snapshot chainstate called `chainstate_snapshot`. When this directory -is present in the datadir, the snapshot chainstate will be detected and loaded as -active on node startup (via `DetectSnapshotChainstate()`). +datadir for the snapshot chainstate called `chainstate_snapshot`. + +When this directory is present in the datadir, the snapshot chainstate will be detected +and loaded as active on node startup (via `DetectSnapshotChainstate()`). + +A special file is created within that directory, `base_blockhash`, which contains the +serialized `uint256` of the base block of the snapshot. This is used to reinitialize +the snapshot chainstate on subsequent inits. Otherwise, the directory is a normal +leveldb database. | | | | ---------- | ----------- | @@ -88,7 +90,7 @@ active on node startup (via `DetectSnapshotChainstate()`). The snapshot begins to sync to tip from its base block, technically in parallel with the original chainstate, but it is given priority during block download and is allocated most of the cache (see `MaybeRebalanceCaches()` and usages) as our chief -consideration is getting to network tip. +goal is getting to network tip. **Failure consideration:** if shutdown happens at any point during this phase, both chainstates will be detected during the next init and the process will resume. @@ -107,33 +109,32 @@ sequentially. ### Background chainstate hits snapshot base block Once the tip of the background chainstate hits the base block of the snapshot -chainstate, we stop use of the background chainstate by setting `m_stop_use` (not yet -committed - see #15606), in `CompleteSnapshotValidation()`, which is checked in -`ActivateBestChain()`). We hash the background chainstate's UTXO set contents and -ensure it matches the compiled value in `CMainParams::m_assumeutxo_data`. - -The background chainstate data lingers on disk until shutdown, when in -`ChainstateManager::Reset()`, the background chainstate is cleaned up with -`ValidatedSnapshotShutdownCleanup()`, which renames the `chainstate_[hash]` datadir as -`chainstate`. +chainstate, we stop use of the background chainstate by setting `m_disabled`, in +`CompleteSnapshotValidation()`, which is checked in `ActivateBestChain()`). We hash the +background chainstate's UTXO set contents and ensure it matches the compiled value in +`CMainParams::m_assumeutxo_data`. | | | | ---------- | ----------- | -| number of chainstates | 2 (ibd has `m_stop_use=true`) | +| number of chainstates | 2 (ibd has `m_disabled=true`) | | active chainstate | snapshot | -**Failure consideration:** if bitcoind unexpectedly halts after `m_stop_use` is set on -the background chainstate but before `CompleteSnapshotValidation()` can finish, the -need to complete snapshot validation will be detected on subsequent init by -`ChainstateManager::CheckForUncleanShutdown()`. +The background chainstate data lingers on disk until the program is restarted. ### Bitcoind restarts sometime after snapshot validation has completed -When bitcoind initializes again, what began as the snapshot chainstate is now -indistinguishable from a chainstate that has been built from the traditional IBD -process, and will be initialized as such. +After a shutdown and subsequent restart, `LoadChainstate()` cleans up the background +chainstate with `ValidatedSnapshotCleanup()`, which renames the `chainstate_snapshot` +datadir as `chainstate` and removes the now unnecessary background chainstate data. | | | | ---------- | ----------- | | number of chainstates | 1 | -| active chainstate | ibd | +| active chainstate | ibd (was snapshot, but is now fully validated) | + +What began as the snapshot chainstate is now indistinguishable from a chainstate that +has been built from the traditional IBD process, and will be initialized as such. + +A file will be left in `chainstate/base_blockhash`, which indicates that the +chainstate, even though now fully validated, was originally started from a snapshot +with the corresponding base blockhash. diff --git a/doc/developer-notes.md b/doc/developer-notes.md index f15df1bf73..08dde2aa61 100644 --- a/doc/developer-notes.md +++ b/doc/developer-notes.md @@ -111,8 +111,8 @@ code. - `static_assert` is preferred over `assert` where possible. Generally; compile-time checking is preferred over run-time checking. - Use a named cast or functional cast, not a C-Style cast. When casting between integer types, use functional casts such as `int(x)` or `int{x}` - instead of `(int) x`. When casting between more complex types, use static_cast. - Use reinterpret_cast and const_cast as appropriate. + instead of `(int) x`. When casting between more complex types, use `static_cast`. + Use `reinterpret_cast` and `const_cast` as appropriate. For function calls a namespace should be specified explicitly, unless such functions have been declared within it. Otherwise, [argument-dependent lookup](https://en.cppreference.com/w/cpp/language/adl), also known as ADL, could be @@ -217,11 +217,14 @@ apt install clang-tidy bear clang Then, pass clang as compiler to configure, and use bear to produce the `compile_commands.json`: ```sh -./autogen.sh && ./configure CC=clang CXX=clang++ -make clean && bear make -j $(nproc) # For bear 2.x -make clean && bear -- make -j $(nproc) # For bear 3.x +./autogen.sh && ./configure CC=clang CXX=clang++ --enable-suppress-external-warnings +make clean && bear --config src/.bear-tidy-config -- make -j $(nproc) ``` +The output is denoised of errors from external dependencies and includes with +`--enable-suppress-external-warnings` and `--config src/.bear-tidy-config`. Both +options may be omitted to view the full list of errors. + To run clang-tidy on all source files: ```sh @@ -857,12 +860,12 @@ Strings and formatting buffer overflows, and surprises with `\0` characters. Also, some C string manipulations tend to act differently depending on platform, or even the user locale. -- Use `ParseInt32`, `ParseInt64`, `ParseUInt32`, `ParseUInt64`, `ParseDouble` from `utilstrencodings.h` for number parsing. +- Use `ToIntegral` from [`strencodings.h`](/src/util/strencodings.h) for number parsing. In legacy code you might also find `ParseInt*` family of functions, `ParseDouble` or `LocaleIndependentAtoi`. - *Rationale*: These functions do overflow checking and avoid pesky locale issues. - Avoid using locale dependent functions if possible. You can use the provided - [`lint-locale-dependence.sh`](/test/lint/lint-locale-dependence.sh) + [`lint-locale-dependence.py`](/test/lint/lint-locale-dependence.py) to check for accidental use of locale dependent functions. - *Rationale*: Unnecessary locale dependence can cause bugs that are very tricky to isolate and fix. diff --git a/doc/i2p.md b/doc/i2p.md index 0432136554..cfff426617 100644 --- a/doc/i2p.md +++ b/doc/i2p.md @@ -109,8 +109,7 @@ incoming I2P connections (`-i2pacceptincoming`): To see which I2P peers your node is connected to, use `bitcoin-cli -netinfo 4` or the `getpeerinfo` RPC (e.g. `bitcoin-cli getpeerinfo`). -To see which I2P addresses your node knows, use the `getnodeaddresses 0 i2p` -RPC. +You can use the `getnodeaddresses` RPC to fetch a number of I2P peers known to your node; run `bitcoin-cli help getnodeaddresses` for details. ## Compatibility diff --git a/doc/policy/packages.md b/doc/policy/packages.md index 274854ddf9..2a5758318a 100644 --- a/doc/policy/packages.md +++ b/doc/policy/packages.md @@ -80,24 +80,37 @@ test accepts): If any transactions in the package are already in the mempool, they are not submitted again ("deduplicated") and are thus excluded from this calculation. -To meet the two feerate requirements of a mempool, i.e., the pre-configured minimum relay feerate -(`-minrelaytxfee`) and the dynamic mempool minimum feerate, the total package feerate is used instead -of the individual feerate. The individual transactions are allowed to be below the feerate -requirements if the package meets the feerate requirements. For example, the parent(s) in the -package can pay no fees but be paid for by the child. - -*Rationale*: This can be thought of as "CPFP within a package," solving the issue of a parent not -meeting minimum fees on its own. This would allow contracting applications to adjust their fees at -broadcast time instead of overshooting or risking becoming stuck or pinned. - -*Rationale*: It would be incorrect to use the fees of transactions that are already in the mempool, as -we do not want a transaction's fees to be double-counted. +To meet the dynamic mempool minimum feerate, i.e., the feerate determined by the transactions +evicted when the mempool reaches capacity (not the static minimum relay feerate), the total package +feerate instead of individual feerate can be used. For example, if the mempool minimum feerate is +5sat/vB and a 1sat/vB parent transaction has a high-feerate child, it may be accepted if +submitted as a package. + +*Rationale*: This can be thought of as "CPFP within a package," solving the issue of a presigned +transaction (i.e. in which a replacement transaction with a higher fee cannot be signed) being +rejected from the mempool when transaction volume is high and the mempool minimum feerate rises. + +Note: Package feerate cannot be used to meet the minimum relay feerate (`-minrelaytxfee`) +requirement. For example, if the mempool minimum feerate is 5sat/vB and the minimum relay feerate is +set to 5satvB, a 1sat/vB parent transaction with a high-feerate child will not be accepted, even if +submitted as a package. + +*Rationale*: Avoid situations in which the mempool contains non-bumped transactions below min relay +feerate (which we consider to have pay 0 fees and thus receiving free relay). While package +submission would ensure these transactions are bumped at the time of entry, it is not guaranteed +that the transaction will always be bumped. For example, a later transaction could replace the +fee-bumping child without still bumping the parent. These no-longer-bumped transactions should be +removed during a replacement, but we do not have a DoS-resistant way of removing them or enforcing a +limit on their quantity. Instead, prevent their entry into the mempool. Implementation Note: Transactions within a package are always validated individually first, and package validation is used for the transactions that failed. Since package feerate is only calculated using transactions that are not in the mempool, this implementation detail affects the outcome of package validation. +*Rationale*: It would be incorrect to use the fees of transactions that are already in the mempool, as +we do not want a transaction's fees to be double-counted. + *Rationale*: Packages are intended for incentive-compatible fee-bumping: transaction B is a "legitimate" fee-bump for transaction A only if B is a descendant of A and has a *higher* feerate than A. We want to prevent "parents pay for children" behavior; fees of parents should not help diff --git a/doc/reduce-memory.md b/doc/reduce-memory.md index 25205258b8..dbe88d45f3 100644 --- a/doc/reduce-memory.md +++ b/doc/reduce-memory.md @@ -43,7 +43,7 @@ threads take up 8MiB for the thread stack on a 64-bit system, and 4MiB in a ## Linux specific -By default, since glibc `2.10`, the C library will create up to two heap arenas per core. This is known to cause excessive memory usage in some scenarios. To avoid this make a script that sets `MALLOC_ARENA_MAX` before starting bitcoind: +By default, glibc will create up to two heap arenas per core. This is known to cause excessive memory usage in some scenarios. To avoid this make a script that sets `MALLOC_ARENA_MAX` before starting bitcoind: ```bash #!/usr/bin/env bash diff --git a/doc/release-notes-19762.md b/doc/release-notes-19762.md deleted file mode 100644 index 4dc45fb2c8..0000000000 --- a/doc/release-notes-19762.md +++ /dev/null @@ -1,19 +0,0 @@ -JSON-RPC ---- - -All JSON-RPC methods accept a new [named -parameter](JSON-RPC-interface.md#parameter-passing) called `args` that can -contain positional parameter values. This is a convenience to allow some -parameter values to be passed by name without having to name every value. The -python test framework and `bitcoin-cli` tool both take advantage of this, so -for example: - -```sh -bitcoin-cli -named createwallet wallet_name=mywallet load_on_startup=1 -``` - -Can now be shortened to: - -```sh -bitcoin-cli -named createwallet mywallet load_on_startup=1 -``` diff --git a/doc/release-notes-22087.md b/doc/release-notes-22087.md deleted file mode 100644 index 8d7fd242b2..0000000000 --- a/doc/release-notes-22087.md +++ /dev/null @@ -1,4 +0,0 @@ -Updated settings ----------------- - -- Ports specified in `-port` and `-rpcport` options are now validated at startup. Values that previously worked and were considered valid can now result in errors. (#22087) diff --git a/doc/release-notes-23395.md b/doc/release-notes-23395.md deleted file mode 100644 index b9d7d9409c..0000000000 --- a/doc/release-notes-23395.md +++ /dev/null @@ -1,8 +0,0 @@ -Notable changes -=============== - -New settings ------------- - -- The `shutdownnotify` option is used to specify a command to execute synchronously -before Bitcoin Core has begun its shutdown sequence. (#23395) diff --git a/doc/release-notes-25158.md b/doc/release-notes-25158.md new file mode 100644 index 0000000000..ce8ab53ddd --- /dev/null +++ b/doc/release-notes-25158.md @@ -0,0 +1,6 @@ +RPC Wallet +---------- + +- The `gettransaction`, `listtransactions`, `listsinceblock` RPCs now return + the `abandoned` field for all transactions. Previously, the "abandoned" field + was only returned for sent transactions. (#25158)
\ No newline at end of file diff --git a/doc/release-notes-25375.md b/doc/release-notes-25375.md deleted file mode 100644 index 504a2644f4..0000000000 --- a/doc/release-notes-25375.md +++ /dev/null @@ -1,11 +0,0 @@ -Updated RPCs --------- - -The `minconf` option, which allows a user to specify the minimum number -of confirmations a UTXO being spent has, and the `maxconf` option, -which allows specifying the maximum number of confirmations, have been -added to the following RPCs: -- `fundrawtransaction` -- `send` -- `walletcreatefundedpsbt` -- `sendall` diff --git a/doc/release-notes-25412.md b/doc/release-notes-25412.md deleted file mode 100644 index b11fe73d45..0000000000 --- a/doc/release-notes-25412.md +++ /dev/null @@ -1,5 +0,0 @@ -New REST endpoint ------------------ - -- A new `/rest/deploymentinfo` endpoint has been added for fetching various - state info regarding deployments of consensus changes. (#25412) diff --git a/doc/release-notes-25574.md b/doc/release-notes-25574.md deleted file mode 100644 index 312a99d95b..0000000000 --- a/doc/release-notes-25574.md +++ /dev/null @@ -1,13 +0,0 @@ -Updated settings ----------------- - -If the `-checkblocks` or `-checklevel` options are explicitly provided by the -user, but the verification checks cannot be completed due to an insufficient -dbcache, Bitcoin Core will now return an error at startup. (#25574) - -RPC ---- -The `-verifychain` RPC will now return `false` if the checks didn't fail, -but couldn't be completed at the desired depth and level. This could be due -to missing data while pruning, due to an insufficient dbcache or due to -the node being shutdown before the call could finish. (#25574) diff --git a/doc/release-notes-25730.md b/doc/release-notes-25730.md deleted file mode 100644 index 33393cf314..0000000000 --- a/doc/release-notes-25730.md +++ /dev/null @@ -1,6 +0,0 @@ -RPC Wallet ----------- - -- RPC `listunspent` now has a new argument `include_immature_coinbase` - to include coinbase UTXOs that don't meet the minimum spendability - depth requirement (which before were silently skipped). (#25730)
\ No newline at end of file diff --git a/doc/release-notes-25934.md b/doc/release-notes-25934.md deleted file mode 100644 index b4f1ae0d3c..0000000000 --- a/doc/release-notes-25934.md +++ /dev/null @@ -1,8 +0,0 @@ -Low-level changes -================= - -RPC ---- - -- RPC `listsinceblock` now accepts an optional `label` argument - to fetch incoming transactions having the specified label. (#25934)
\ No newline at end of file diff --git a/doc/release-notes-25943.md b/doc/release-notes-25943.md deleted file mode 100644 index 81b0a48b5d..0000000000 --- a/doc/release-notes-25943.md +++ /dev/null @@ -1,4 +0,0 @@ -New RPC Argument --------- -- `sendrawtransaction` has a new, optional argument, `maxburnamount` with a default value of `0`. Any transaction containing an unspendable output with a value greater than `maxburnamount` will not be submitted. At present, the outputs deemed unspendable are those with scripts that begin with an `OP_RETURN` code (known as 'datacarriers'), scripts that exceed the maximum script size, and scripts that contain invalid opcodes. - diff --git a/doc/release-notes-25957.md b/doc/release-notes-25957.md deleted file mode 100644 index c71afa2c2e..0000000000 --- a/doc/release-notes-25957.md +++ /dev/null @@ -1,9 +0,0 @@ -Wallet ------- - -- Rescans for descriptor wallets are now significantly faster if compact - block filters (BIP158) are available. Since those are not constructed - by default, the configuration option "-blockfilterindex=1" has to be - provided to take advantage of the optimization. This improves the - performance of the RPC calls `rescanblockchain`, `importdescriptors` - and `restorewallet`. (#25957) diff --git a/doc/release-notes-26076.md b/doc/release-notes-26076.md new file mode 100644 index 0000000000..f95e4be0e3 --- /dev/null +++ b/doc/release-notes-26076.md @@ -0,0 +1,13 @@ +RPC +--- + +- The `listdescriptors`, `decodepsbt` and similar RPC methods now show `h` rather than apostrophe (`'`) to indicate + hardened derivation. This does not apply when using the `private` parameter, which + matches the marker used when descriptor was generated or imported. Newly created + wallets use `h`. This change makes it easier to handle descriptor strings manually. + E.g. the `importdescriptors` RPC call is easiest to use `h` as the marker: `'["desc": ".../0h/..."]'`. + With this change `listdescriptors` will use `h`, so you can copy-paste the result, + without having to add escape characters or switch `'` to 'h' manually. + Note that this changes the descriptor checksum. + For legacy wallets the `hdkeypath` field in `getaddressinfo` is unchanged, + nor is the serialization format of wallet dumps. (#26076) diff --git a/doc/release-notes-26094.md b/doc/release-notes-26094.md new file mode 100644 index 0000000000..ba73f2707e --- /dev/null +++ b/doc/release-notes-26094.md @@ -0,0 +1,6 @@ +- The `getbalances` RPC now returns a `lastprocessedblock` JSON object which contains the wallet's last processed block + hash and height at the time the balances were calculated. This result shouldn't be cached because importing new keys could invalidate it. +- The `gettransaction` RPC now returns a `lastprocessedblock` JSON object which contains the wallet's last processed block + hash and height at the time the transaction information was generated. +- The `getwalletinfo` RPC now returns a `lastprocessedblock` JSON object which contains the wallet's last processed block + hash and height at the time the wallet information was generated.
\ No newline at end of file diff --git a/doc/release-notes-26213.md b/doc/release-notes-26213.md deleted file mode 100644 index e78d718ca9..0000000000 --- a/doc/release-notes-26213.md +++ /dev/null @@ -1,8 +0,0 @@ -Low-level changes -================= - -- Previously `setban`, `addpeeraddress`, `walletcreatefundedpsbt`, methods - allowed non-boolean and non-null values to be passed as boolean parameters. - Any string, number, array, or object value that was passed would be treated - as false. After this change, passing any value except `true`, `false`, or - `null` now triggers a JSON value is not of expected type error. (#26213) diff --git a/doc/release-notes-26265.md b/doc/release-notes-26265.md deleted file mode 100644 index ca2313d956..0000000000 --- a/doc/release-notes-26265.md +++ /dev/null @@ -1,6 +0,0 @@ -P2P and network changes ---------- - -- Transactions of non-witness size 65 and above are now allowed by mempool - and relay policy. This is to better reflect the actual afforded protections - against CVE-2017-12842 and open up additional use-cases of smaller transaction sizes. (#26265) diff --git a/doc/release-notes-26471.md b/doc/release-notes-26471.md deleted file mode 100644 index 2cb74804ca..0000000000 --- a/doc/release-notes-26471.md +++ /dev/null @@ -1,13 +0,0 @@ -Updated settings ----------------- - -- Setting `-blocksonly` will now reduce the maximum mempool memory - to 5MB (users may still use `-maxmempool` to override). Previously, - the default 300MB would be used, leading to unexpected memory usage - for users running with `-blocksonly` expecting it to eliminate - mempool memory usage. - - As unused mempool memory is shared with dbcache, this also reduces - the dbcache size for users running with `-blocksonly`, potentially - impacting performance. - diff --git a/doc/release-notes-26485.md b/doc/release-notes-26485.md new file mode 100644 index 0000000000..c8df3d22fb --- /dev/null +++ b/doc/release-notes-26485.md @@ -0,0 +1,16 @@ +JSON-RPC +--- + +For RPC methods which accept `options` parameters ((`importmulti`, `listunspent`, `fundrawtransaction`, `bumpfee`, `send`, `sendall`, `walletcreatefundedpsbt`, `simulaterawtransaction`), it is now possible to pass the options as named parameters without the need for a nested object. (#26485) + +This means it is possible make calls like: + +```sh +src/bitcoin-cli -named bumpfee txid fee_rate=100 +``` + +instead of + +```sh +src/bitcoin-cli -named bumpfee txid options='{"fee_rate": 100}' +``` diff --git a/doc/release-notes-26618.md b/doc/release-notes-26618.md deleted file mode 100644 index 9d1ef3bd2e..0000000000 --- a/doc/release-notes-26618.md +++ /dev/null @@ -1,4 +0,0 @@ -RPC Wallet ----------- - -- RPC `unloadwallet` now fails if a rescan is in progress. (#26618) diff --git a/doc/release-notes-26628.md b/doc/release-notes-26628.md deleted file mode 100644 index 48a07c1e81..0000000000 --- a/doc/release-notes-26628.md +++ /dev/null @@ -1,4 +0,0 @@ -JSON-RPC ---- - -The JSON-RPC server now rejects requests where a parameter is specified multiple times with the same name, instead of silently overwriting earlier parameter values with later ones. (#26628) diff --git a/doc/release-notes-26646.md b/doc/release-notes-26646.md deleted file mode 100644 index 7f94505a01..0000000000 --- a/doc/release-notes-26646.md +++ /dev/null @@ -1,8 +0,0 @@ -JSON-RPC --------- - -The `testmempoolaccept` RPC now returns 2 additional results within the "fees" result: -"effective-feerate" is the feerate including fees and sizes of transactions validated together if -package validation was used, and also includes any modified fees from prioritisetransaction. The -"effective-includes" result lists the wtxids of transactions whose modified fees and sizes were used -in the effective-feerate (#26646). diff --git a/doc/release-notes-26896.md b/doc/release-notes-26896.md deleted file mode 100644 index ff4ab44e27..0000000000 --- a/doc/release-notes-26896.md +++ /dev/null @@ -1,7 +0,0 @@ -Build System ------------- - -The --enable-upnp-default and --enable-natpmp-default options -have been removed. If you want to use port mapping, you can -configure it using a .conf file, or by passing the relevant -options at runtime.
\ No newline at end of file diff --git a/doc/release-notes-27037.md b/doc/release-notes-27037.md deleted file mode 100644 index ee30e64010..0000000000 --- a/doc/release-notes-27037.md +++ /dev/null @@ -1,5 +0,0 @@ -RPC ---- - -- `decodescript` may now infer a Miniscript descriptor under P2WSH context if it is not lacking - information. diff --git a/doc/release-notes-27068.md b/doc/release-notes-27068.md deleted file mode 100644 index 3f5c5dba37..0000000000 --- a/doc/release-notes-27068.md +++ /dev/null @@ -1,6 +0,0 @@ -Wallet ------- - -- Wallet passphrases may now contain null characters. - Prior to this change, only characters up to the first - null character were recognized and accepted. (#27068)
\ No newline at end of file diff --git a/doc/release-notes-27302.md b/doc/release-notes-27302.md new file mode 100644 index 0000000000..e67a6c8b06 --- /dev/null +++ b/doc/release-notes-27302.md @@ -0,0 +1,4 @@ +Configuration +--- + +- `bitcoind` and `bitcoin-qt` will now raise an error on startup if a datadir that is being used contains a bitcoin.conf file that will be ignored, which can happen when a datadir= line is used in a bitcoin.conf file. The error message is just a diagnostic intended to prevent accidental misconfiguration, and it can be disabled to restore the previous behavior of using the datadir while ignoring the bitcoin.conf contained in it. diff --git a/doc/release-notes/release-notes-23.2.md b/doc/release-notes/release-notes-23.2.md new file mode 100644 index 0000000000..2d6354ae5d --- /dev/null +++ b/doc/release-notes/release-notes-23.2.md @@ -0,0 +1,72 @@ +23.2 Release Notes +================== + +Bitcoin Core version 23.2 is now available from: + + <https://bitcoincore.org/bin/bitcoin-core-23.2/> + +This release includes various bug fixes and performance +improvements, as well as updated translations. + +Please report bugs using the issue tracker at GitHub: + + <https://github.com/bitcoin/bitcoin/issues> + +To receive security and update notifications, please subscribe to: + + <https://bitcoincore.org/en/list/announcements/join/> + +How to Upgrade +============== + +If you are running an older version, shut it down. Wait until it has completely +shut down (which might take a few minutes in some cases), then run the +installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS) +or `bitcoind`/`bitcoin-qt` (on Linux). + +Upgrading directly from a version of Bitcoin Core that has reached its EOL is +possible, but it might take some time if the data directory needs to be migrated. Old +wallet versions of Bitcoin Core are generally supported. + +Compatibility +============== + +Bitcoin Core is supported and extensively tested on operating systems +using the Linux kernel, macOS 10.15+, and Windows 7 and newer. Bitcoin +Core should also work on most other Unix-like systems but is not as +frequently tested on them. It is not recommended to use Bitcoin Core on +unsupported systems. + +### P2P + +- #26909 net: prevent peers.dat corruptions by only serializing once +- #27608 p2p: Avoid prematurely clearing download state for other peers +- #27610 Improve performance of p2p inv to send queues + +### Build system + +- #25436 build: suppress array-bounds errors in libxkbcommon +- #25763 bdb: disable Werror for format-security +- #26944 depends: fix systemtap download URL +- #27462 depends: fix compiling bdb with clang-16 on aarch64 + +### Miscellaneous + +- #25444 ci: macOS task imrovements +- #26388 ci: Use macos-ventura-xcode:14.1 image for "macOS native" task +- #26924 refactor: Add missing includes to fix gcc-13 compile error + +Credits +======= + +Thanks to everyone who directly contributed to this release: + +- Anthony Towns +- Hennadii Stepanov +- MacroFake +- Martin Zumsande +- Michael Ford +- Suhas Daftuar + +As well as to everyone that helped with translations on +[Transifex](https://www.transifex.com/bitcoin/bitcoin/).
\ No newline at end of file diff --git a/doc/release-notes/release-notes-24.1.md b/doc/release-notes/release-notes-24.1.md new file mode 100644 index 0000000000..f46434cc43 --- /dev/null +++ b/doc/release-notes/release-notes-24.1.md @@ -0,0 +1,99 @@ +24.1 Release Notes +================== + +Bitcoin Core version 24.1 is now available from: + + <https://bitcoincore.org/bin/bitcoin-core-24.1/> + +This release includes various bug fixes and performance +improvements, as well as updated translations. + +Please report bugs using the issue tracker at GitHub: + + <https://github.com/bitcoin/bitcoin/issues> + +To receive security and update notifications, please subscribe to: + + <https://bitcoincore.org/en/list/announcements/join/> + +How to Upgrade +============== + +If you are running an older version, shut it down. Wait until it has completely +shut down (which might take a few minutes in some cases), then run the +installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS) +or `bitcoind`/`bitcoin-qt` (on Linux). + +Upgrading directly from a version of Bitcoin Core that has reached its EOL is +possible, but it might take some time if the data directory needs to be migrated. Old +wallet versions of Bitcoin Core are generally supported. + +Compatibility +============== + +Bitcoin Core is supported and extensively tested on operating systems +using the Linux kernel, macOS 10.15+, and Windows 7 and newer. Bitcoin +Core should also work on most other Unix-like systems but is not as +frequently tested on them. It is not recommended to use Bitcoin Core on +unsupported systems. + +### P2P + +- #26878 I2P network optimizations +- #26909 net: prevent peers.dat corruptions by only serializing once +- #27608 p2p: Avoid prematurely clearing download state for other peers +- #27610 Improve performance of p2p inv to send queues + +### RPC and other APIs + +- #26515 rpc: Require NodeStateStats object in getpeerinfo +- #27279 doc: fix/improve warning helps in {create,load,unload,restore}wallet +- #27468 rest: avoid segfault for invalid URI + +### Build System + +- #26944 depends: fix systemtap download URL +- #27462 depends: fix compiling bdb with clang-16 on aarch64 + +### Wallet + +- #26595 wallet: be able to specify a wallet name and passphrase to migratewallet +- #26675 wallet: For feebump, ignore abandoned descendant spends +- #26679 wallet: Skip rescanning if wallet is more recent than tip +- #26761 wallet: fully migrate address book entries for watchonly/solvable wallets +- #27053 wallet: reuse change dest when re-creating TX with avoidpartialspends +- #27080 wallet: Zero out wallet master key upon locking so it doesn't persist in memory +- #27473 wallet: Properly handle "unknown" Address Type + +### GUI changes + +- gui#687 Load PSBTs using istreambuf_iterator rather than istream_iterator +- gui#704 Correctly limit overview transaction list + +### Miscellaneous + +- #26880 ci: replace Intel macOS CI job +- #26924 refactor: Add missing includes to fix gcc-13 compile error + +Credits +======= + +Thanks to everyone who directly contributed to this release: + +- Andrew Chow +- Anthony Towns +- Hennadii Stepanov +- John Moffett +- Jon Atack +- Marco Falke +- Martin Zumsande +- Matthew Zipkin +- Michael Ford +- pablomartin4btc +- Sebastian Falbesoner +- Suhas Daftuar +- Thomas Nguyen +- Vasil Dimov + +As well as to everyone that helped with translations on +[Transifex](https://www.transifex.com/bitcoin/bitcoin/).
\ No newline at end of file diff --git a/doc/release-notes/release-notes-25.0.md b/doc/release-notes/release-notes-25.0.md new file mode 100644 index 0000000000..919cb3b2f3 --- /dev/null +++ b/doc/release-notes/release-notes-25.0.md @@ -0,0 +1,340 @@ +25.0 Release Notes +================== + +Bitcoin Core version 25.0 is now available from: + + <https://bitcoincore.org/bin/bitcoin-core-25.0/> + +This release includes new features, various bug fixes and performance +improvements, as well as updated translations. + +Please report bugs using the issue tracker at GitHub: + + <https://github.com/bitcoin/bitcoin/issues> + +To receive security and update notifications, please subscribe to: + + <https://bitcoincore.org/en/list/announcements/join/> + +How to Upgrade +============== + +If you are running an older version, shut it down. Wait until it has completely +shut down (which might take a few minutes in some cases), then run the +installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS) +or `bitcoind`/`bitcoin-qt` (on Linux). + +Upgrading directly from a version of Bitcoin Core that has reached its EOL is +possible, but it might take some time if the data directory needs to be migrated. Old +wallet versions of Bitcoin Core are generally supported. + +Compatibility +============== + +Bitcoin Core is supported and extensively tested on operating systems +using the Linux kernel, macOS 10.15+, and Windows 7 and newer. Bitcoin +Core should also work on most other Unix-like systems but is not as +frequently tested on them. It is not recommended to use Bitcoin Core on +unsupported systems. + +Notable changes +=============== + +P2P and network changes +----------------------- + +- Transactions of non-witness size 65 bytes and above are now allowed by mempool + and relay policy. This is to better reflect the actual afforded protections + against CVE-2017-12842 and open up additional use-cases of smaller transaction sizes. (#26265) + +New RPCs +-------- + +- The scanblocks RPC returns the relevant blockhashes from a set of descriptors by + scanning all blockfilters in the given range. It can be used in combination with + the getblockheader and rescanblockchain RPCs to achieve fast wallet rescans. Note + that this functionality can only be used if a compact block filter index + (-blockfilterindex=1) has been constructed by the node. (#23549) + +Updated RPCs +------------ + +- All JSON-RPC methods accept a new [named + parameter](https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md#parameter-passing) called `args` that can + contain positional parameter values. This is a convenience to allow some + parameter values to be passed by name without having to name every value. The + python test framework and `bitcoin-cli` tool both take advantage of this, so + for example: + +```sh +bitcoin-cli -named createwallet wallet_name=mywallet load_on_startup=1 +``` + +Can now be shortened to: + +```sh +bitcoin-cli -named createwallet mywallet load_on_startup=1 +``` + +- The `verifychain` RPC will now return `false` if the checks didn't fail, + but couldn't be completed at the desired depth and level. This could be due + to missing data while pruning, due to an insufficient dbcache or due to + the node being shutdown before the call could finish. (#25574) + +- `sendrawtransaction` has a new, optional argument, `maxburnamount` with a default value of `0`. + Any transaction containing an unspendable output with a value greater than `maxburnamount` will + not be submitted. At present, the outputs deemed unspendable are those with scripts that begin + with an `OP_RETURN` code (known as 'datacarriers'), scripts that exceed the maximum script size, + and scripts that contain invalid opcodes. + +- The `testmempoolaccept` RPC now returns 2 additional results within the "fees" result: + "effective-feerate" is the feerate including fees and sizes of transactions validated together if + package validation was used, and also includes any modified fees from prioritisetransaction. The + "effective-includes" result lists the wtxids of transactions whose modified fees and sizes were used + in the effective-feerate (#26646). + +- `decodescript` may now infer a Miniscript descriptor under P2WSH context if it is not lacking + information. (#27037) + +- `finalizepsbt` is now able to finalize a transaction with inputs spending Miniscript-compatible + P2WSH scripts. (#24149) + +Changes to wallet related RPCs can be found in the Wallet section below. + +Build System +------------ + +- The `--enable-upnp-default` and `--enable-natpmp-default` options + have been removed. If you want to use port mapping, you can + configure it using a .conf file, or by passing the relevant + options at runtime. (#26896) + +Updated settings +---------------- + +- If the `-checkblocks` or `-checklevel` options are explicitly provided by the +user, but the verification checks cannot be completed due to an insufficient +dbcache, Bitcoin Core will now return an error at startup. (#25574) + +- Ports specified in `-port` and `-rpcport` options are now validated at startup. + Values that previously worked and were considered valid can now result in errors. (#22087) + +- Setting `-blocksonly` will now reduce the maximum mempool memory + to 5MB (users may still use `-maxmempool` to override). Previously, + the default 300MB would be used, leading to unexpected memory usage + for users running with `-blocksonly` expecting it to eliminate + mempool memory usage. + + As unused mempool memory is shared with dbcache, this also reduces + the dbcache size for users running with `-blocksonly`, potentially + impacting performance. +- Setting `-maxconnections=0` will now disable `-dnsseed` + and `-listen` (users may still set them to override). + +Changes to GUI or wallet related settings can be found in the GUI or Wallet section below. + +New settings +------------ + +- The `shutdownnotify` option is used to specify a command to execute synchronously +before Bitcoin Core has begun its shutdown sequence. (#23395) + + +Wallet +------ + +- The `minconf` option, which allows a user to specify the minimum number +of confirmations a UTXO being spent has, and the `maxconf` option, +which allows specifying the maximum number of confirmations, have been +added to the following RPCs in #25375: + - `fundrawtransaction` + - `send` + - `walletcreatefundedpsbt` + - `sendall` + +- Added a new `next_index` field in the response in `listdescriptors` to + have the same format as `importdescriptors` (#26194) + +- RPC `listunspent` now has a new argument `include_immature_coinbase` + to include coinbase UTXOs that don't meet the minimum spendability + depth requirement (which before were silently skipped). (#25730) + +- Rescans for descriptor wallets are now significantly faster if compact + block filters (BIP158) are available. Since those are not constructed + by default, the configuration option "-blockfilterindex=1" has to be + provided to take advantage of the optimization. This improves the + performance of the RPC calls `rescanblockchain`, `importdescriptors` + and `restorewallet`. (#25957) + +- RPC `unloadwallet` now fails if a rescan is in progress. (#26618) + +- Wallet passphrases may now contain null characters. + Prior to this change, only characters up to the first + null character were recognized and accepted. (#27068) + +- Address Purposes strings are now restricted to the currently known values of "send", + "receive", and "refund". Wallets that have unrecognized purpose strings will have + loading warnings, and the `listlabels` RPC will raise an error if an unrecognized purpose + is requested. (#27217) + +- In the `createwallet`, `loadwallet`, `unloadwallet`, and `restorewallet` RPCs, the + "warning" string field is deprecated in favor of a "warnings" field that + returns a JSON array of strings to better handle multiple warning messages and + for consistency with other wallet RPCs. The "warning" field will be fully + removed from these RPCs in v26. It can be temporarily re-enabled during the + deprecation period by launching bitcoind with the configuration option + `-deprecatedrpc=walletwarningfield`. (#27279) + +- Descriptor wallets can now spend coins sent to P2WSH Miniscript descriptors. (#24149) + +GUI changes +----------- + +- The "Mask values" is a persistent option now. (gui#701) +- The "Mask values" option affects the "Transaction" view now, in addition to the + "Overview" one. (gui#708) + +REST +---- + +- A new `/rest/deploymentinfo` endpoint has been added for fetching various + state info regarding deployments of consensus changes. (#25412) + +Binary verification +---- + +- The binary verification script has been updated. In previous releases it + would verify that the binaries had been signed with a single "release key". + In this release and moving forward it will verify that the binaries are + signed by a _threshold of trusted keys_. For more details and + examples, see: + https://github.com/bitcoin/bitcoin/blob/master/contrib/verify-binaries/README.md + (#27358) + +Low-level changes +================= + +RPC +--- + +- The JSON-RPC server now rejects requests where a parameter is specified multiple + times with the same name, instead of silently overwriting earlier parameter values + with later ones. (#26628) +- RPC `listsinceblock` now accepts an optional `label` argument + to fetch incoming transactions having the specified label. (#25934) +- Previously `setban`, `addpeeraddress`, `walletcreatefundedpsbt`, methods + allowed non-boolean and non-null values to be passed as boolean parameters. + Any string, number, array, or object value that was passed would be treated + as false. After this change, passing any value except `true`, `false`, or + `null` now triggers a JSON value is not of expected type error. (#26213) + +Credits +======= + +Thanks to everyone who directly contributed to this release: + +- 0xb10c +- 721217.xyz +- @RandyMcMillan +- amadeuszpawlik +- Amiti Uttarwar +- Andrew Chow +- Andrew Toth +- Anthony Towns +- Antoine Poinsot +- Aurèle Oulès +- Ben Woosley +- Bitcoin Hodler +- brunoerg +- Bushstar +- Carl Dong +- Chris Geihsler +- Cory Fields +- David Gumberg +- dergoegge +- Dhruv Mehta +- Dimitris Tsapakidis +- dougEfish +- Douglas Chimento +- ekzyis +- Elichai Turkel +- Ethan Heilman +- Fabian Jahr +- FractalEncrypt +- furszy +- Gleb Naumenko +- glozow +- Greg Sanders +- Hennadii Stepanov +- hernanmarino +- ishaanam +- ismaelsadeeq +- James O'Beirne +- jdjkelly@gmail.com +- Jeff Ruane +- Jeffrey Czyz +- Jeremy Rubin +- Jesse Barton +- João Barbosa +- JoaoAJMatos +- John Moffett +- Jon Atack +- Jonas Schnelli +- jonatack +- Joshua Kelly +- josibake +- Juan Pablo Civile +- kdmukai +- klementtan +- Kolby ML +- kouloumos +- Kristaps Kaupe +- laanwj +- Larry Ruane +- Leonardo Araujo +- Leonardo Lazzaro +- Luke Dashjr +- MacroFake +- MarcoFalke +- Martin Leitner-Ankerl +- Martin Zumsande +- Matt Whitlock +- Matthew Zipkin +- Michael Ford +- Miles Liu +- mruddy +- Murray Nesbitt +- muxator +- omahs +- pablomartin4btc +- Pasta +- Pieter Wuille +- Pttn +- Randall Naar +- Riahiamirreza +- roconnor-blockstream +- Russell O'Connor +- Ryan Ofsky +- S3RK +- Sebastian Falbesoner +- Seibart Nedor +- sinetek +- Sjors Provoost +- Skuli Dulfari +- SomberNight +- Stacie Waleyko +- stickies-v +- stratospher +- Suhas Daftuar +- Suriyaa Sundararuban +- TheCharlatan +- Vasil Dimov +- Vasil Stoyanov +- virtu +- w0xlt +- willcl-ark +- yancy +- Yusuf Sahin HAMZA + +As well as to everyone that helped with translations on +[Transifex](https://www.transifex.com/bitcoin/bitcoin/).
\ No newline at end of file diff --git a/doc/release-process.md b/doc/release-process.md index f1fd72f8ac..930110922c 100644 --- a/doc/release-process.md +++ b/doc/release-process.md @@ -29,7 +29,7 @@ Release Process #### Before branch-off * Update hardcoded [seeds](/contrib/seeds/README.md), see [this pull request](https://github.com/bitcoin/bitcoin/pull/7415) for an example. -* Update the following variables in [`src/chainparams.cpp`](/src/chainparams.cpp) for mainnet, testnet, and signet: +* Update the following variables in [`src/kernel/chainparams.cpp`](/src/kernel/chainparams.cpp) for mainnet, testnet, and signet: - `m_assumed_blockchain_size` and `m_assumed_chain_state_size` with the current size plus some overhead (see [this](#how-to-calculate-assumed-blockchain-and-chain-state-size) for information on how to calculate them). - The following updates should be reviewed with `reindex-chainstate` and `assumevalid=0` to catch any defect @@ -60,6 +60,8 @@ Release Process - Create a pinned meta-issue for testing the release candidate (see [this issue](https://github.com/bitcoin/bitcoin/issues/17079) for an example) and provide a link to it in the release announcements where useful. - Translations on Transifex - Change the auto-update URL for the new major version's resource away from `master` and to the branch, e.g. `https://raw.githubusercontent.com/bitcoin/bitcoin/<branch>/src/qt/locale/bitcoin_en.xlf`. Do not forget this or it will keep tracking the translations on master instead, drifting away from the specific major release. +- Prune inputs from the qa-assets repo (See [pruning + inputs](https://github.com/bitcoin-core/qa-assets#pruning-inputs)). #### Before final release @@ -98,7 +100,7 @@ Generate the change log. As this is a huge amount of work to do manually, there Generate list of authors: - git log --format='- %aN' v(current version, e.g. 0.20.0)..v(new version, e.g. 0.20.1) | sort -fiu + git log --format='- %aN' v(current version, e.g. 24.0)..v(new version, e.g. 24.1) | sort -fiu ### Setup and perform Guix builds @@ -107,7 +109,7 @@ Checkout the Bitcoin Core version you'd like to build: ```sh pushd ./bitcoin SIGNER='(your builder key, ie bluematt, sipa, etc)' -VERSION='(new version without v-prefix, e.g. 0.20.0)' +VERSION='(new version without v-prefix, e.g. 24.0)' git fetch origin "v${VERSION}" git checkout "v${VERSION}" popd @@ -282,7 +284,7 @@ cat "$VERSION"/*/all.SHA256SUMS.asc > SHA256SUMS.asc - Push the flatpak to flathub, e.g. https://github.com/flathub/org.bitcoincore.bitcoin-qt/pull/2 - - Push the snap, see https://github.com/bitcoin-core/packaging/blob/master/snap/build.md + - Push the snap, see https://github.com/bitcoin-core/packaging/blob/main/snap/local/build.md - This repo diff --git a/doc/tor.md b/doc/tor.md index 08d031d084..65aa3ece02 100644 --- a/doc/tor.md +++ b/doc/tor.md @@ -2,9 +2,7 @@ It is possible to run Bitcoin Core as a Tor onion service, and connect to such services. -The following directions assume you have a Tor proxy running on port 9050. Many distributions default to having a SOCKS proxy listening on port 9050, but others may not. In particular, the Tor Browser Bundle defaults to listening on port 9150. See [Tor Project FAQ:TBBSocksPort](https://www.torproject.org/docs/faq.html.en#TBBSocksPort) for how to properly -configure Tor. - +The following directions assume you have a Tor proxy running on port 9050. Many distributions default to having a SOCKS proxy listening on port 9050, but others may not. In particular, the Tor Browser Bundle defaults to listening on port 9150. ## Compatibility - Starting with version 22.0, Bitcoin Core only supports Tor version 3 hidden @@ -27,8 +25,7 @@ CLI `-addrinfo` returns the number of addresses known to your node per network. This can be useful to see how many onion peers your node knows, e.g. for `-onlynet=onion`. -To fetch a number of onion addresses that your node knows, for example seven -addresses, use the `getnodeaddresses 7 onion` RPC. +You can use the `getnodeaddresses` RPC to fetch a number of onion peers known to your node; run `bitcoin-cli help getnodeaddresses` for details. ## 1. Run Bitcoin Core behind a Tor proxy @@ -92,19 +89,13 @@ out by default (if not, add them): ControlPort 9051 CookieAuthentication 1 CookieAuthFileGroupReadable 1 +DataDirectoryGroupReadable 1 ``` Add or uncomment those, save, and restart Tor (usually `systemctl restart tor` or `sudo systemctl restart tor` on most systemd-based systems, including recent Debian and Ubuntu, or just restart the computer). -On some systems (such as Arch Linux), you may also need to add the following -line: - -``` -DataDirectoryGroupReadable 1 -``` - ### Authentication Connecting to Tor's control socket API requires one of two authentication diff --git a/doc/tracing.md b/doc/tracing.md index 6e60901496..d26cf52fc3 100644 --- a/doc/tracing.md +++ b/doc/tracing.md @@ -211,6 +211,58 @@ Arguments passed: 4. The expected transaction fee as an `int64` 5. The position of the change output as an `int32` +### Context `mempool` + +#### Tracepoint `mempool:added` + +Is called when a transaction is added to the node's mempool. Passes information +about the transaction. + +Arguments passed: +1. Transaction ID (hash) as `pointer to unsigned chars` (i.e. 32 bytes in little-endian) +2. Transaction virtual size as `uint64` +3. Transaction fee as `int64` + +#### Tracepoint `mempool:removed` + +Is called when a transaction is removed from the node's mempool. Passes information +about the transaction. + +Arguments passed: +1. Transaction ID (hash) as `pointer to unsigned chars` (i.e. 32 bytes in little-endian) +2. Removal reason as `pointer to C-style String` (max. length 9 characters) +3. Transaction virtual size as `uint64` +4. Transaction fee as `int64` +5. Transaction mempool entry time (epoch) as `uint64` + +#### Tracepoint `mempool:replaced` + +Is called when a transaction in the node's mempool is getting replaced by another. +Passes information about the replaced and replacement transactions. + +Arguments passed: +1. Replaced transaction ID (hash) as `pointer to unsigned chars` (i.e. 32 bytes in little-endian) +2. Replaced transaction virtual size as `uint64` +3. Replaced transaction fee as `int64` +4. Replaced transaction mempool entry time (epoch) as `uint64` +5. Replacement transaction ID (hash) as `pointer to unsigned chars` (i.e. 32 bytes in little-endian) +6. Replacement transaction virtual size as `uint64` +7. Replacement transaction fee as `int64` + +Note: In cases where a single replacement transaction replaces multiple +existing transactions in the mempool, the tracepoint is called once for each +replaced transaction, with data of the replacement transaction being the same +in each call. + +#### Tracepoint `mempool:rejected` + +Is called when a transaction is not permitted to enter the mempool. Passes +information about the rejected transaction. + +Arguments passed: +1. Transaction ID (hash) as `pointer to unsigned chars` (i.e. 32 bytes in little-endian) +2. Reject reason as `pointer to C-style String` (max. length 118 characters) + ## Adding tracepoints to Bitcoin Core To add a new tracepoint, `#include <util/trace.h>` in the compilation unit where |