aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/benchmarking.md51
-rw-r--r--doc/bitcoin-conf.md15
-rw-r--r--doc/build-unix.md18
-rw-r--r--doc/dependencies.md11
-rw-r--r--doc/developer-notes.md155
-rw-r--r--doc/rapidcheck.md84
-rw-r--r--doc/release-notes-0.18.1-16257.md6
-rw-r--r--doc/release-notes-13756.md41
-rw-r--r--doc/release-notes-14054.md7
-rw-r--r--doc/release-notes-14802.md3
-rw-r--r--doc/release-notes-14954.md3
-rw-r--r--doc/release-notes-15006.md4
-rw-r--r--doc/release-notes-15427.md9
-rw-r--r--doc/release-notes-15566.md3
-rw-r--r--doc/release-notes-15620.md13
-rw-r--r--doc/release-notes-15637.md3
-rw-r--r--doc/release-notes-15730.md5
-rw-r--r--doc/release-notes-15849.md6
-rw-r--r--doc/release-notes.md286
-rw-r--r--doc/release-notes/release-notes-0.18.1.md136
-rw-r--r--doc/release-notes/release-notes-16152.md7
-rw-r--r--doc/translation_process.md6
-rw-r--r--doc/zmq.md4
23 files changed, 618 insertions, 258 deletions
diff --git a/doc/benchmarking.md b/doc/benchmarking.md
index 48f81cf6c1..8e3d88ab7a 100644
--- a/doc/benchmarking.md
+++ b/doc/benchmarking.md
@@ -2,10 +2,17 @@ Benchmarking
============
Bitcoin Core has an internal benchmarking framework, with benchmarks
-for cryptographic algorithms (e.g. SHA1, SHA256, SHA512, RIPEMD160), as well as the rolling bloom filter.
+for cryptographic algorithms (e.g. SHA1, SHA256, SHA512, RIPEMD160, Poly1305, ChaCha20), rolling bloom filter, coins selection,
+thread queue, wallet balance.
Running
---------------------
+
+For benchmarks purposes you only need to compile `bitcoin_bench`. Beware of configuring without `--enable-debug` as this would impact
+benchmarking by unlatching log printers and lock analysis.
+
+ make -C src bench_bitcoin
+
After compiling bitcoin-core, the benchmarks can be run with:
src/bench/bench_bitcoin
@@ -13,43 +20,29 @@ After compiling bitcoin-core, the benchmarks can be run with:
The output will look similar to:
```
# Benchmark, evals, iterations, total, min, max, median
-Base58CheckEncode, 5, 320000, 120.772, 7.49351e-05, 7.59374e-05, 7.54759e-05
-Base58Decode, 5, 800000, 122.833, 3.0467e-05, 3.11732e-05, 3.06304e-05
-Base58Encode, 5, 470000, 137.094, 5.81061e-05, 5.85109e-05, 5.84462e-05
-BenchLockedPool, 5, 530, 34.2023, 0.0128247, 0.0129613, 0.0129026
-CCheckQueueSpeedPrevectorJob, 5, 1400, 26.1762, 0.00365048, 0.00388629, 0.00367108
-CCoinsCaching, 5, 170000, 48.1074, 5.60229e-05, 5.72316e-05, 5.66214e-05
-CoinSelection, 5, 650, 34.6426, 0.0105801, 0.0107699, 0.010664
-DeserializeAndCheckBlockTest, 5, 160, 39.2084, 0.0483662, 0.0494199, 0.0490138
-DeserializeBlockTest, 5, 130, 23.8129, 0.0357731, 0.0373763, 0.0365858
-FastRandom_1bit, 5, 440000000, 38.1609, 1.72974e-08, 1.73882e-08, 1.73478e-08
-FastRandom_32bit, 5, 110000000, 72.8237, 1.29992e-07, 1.37014e-07, 1.30115e-07
-MempoolEviction, 5, 41000, 89.8883, 0.000432748, 0.000446857, 0.000438483
-PrevectorClear, 5, 5600, 47.9229, 0.00169952, 0.0017455, 0.00170315
-PrevectorDestructor, 5, 5700, 44.5498, 0.0015561, 0.00156977, 0.00156469
-RIPEMD160, 5, 440, 135.988, 0.0615496, 0.062268, 0.0617779
-RollingBloom, 5, 1500000, 36.5109, 4.80961e-06, 4.97463e-06, 4.85811e-06
-SHA1, 5, 570, 51.808, 0.018065, 0.0182623, 0.0181865
-SHA256, 5, 340, 8.31841, 0.00483231, 0.00499803, 0.00485486
-SHA256_32b, 5, 4700000, 10.469, 4.43441e-07, 4.47611e-07, 4.45223e-07
-SHA512, 5, 330, 33.3408, 0.02017, 0.0202554, 0.0201921
-SipHash_32b, 5, 40000000, 38.7088, 1.91103e-07, 1.96998e-07, 1.93792e-07
-Sleep100ms, 5, 10, 5.01062, 0.100131, 0.100368, 0.100147
-Trig, 5, 12000000, 5.95494, 9.78115e-08, 1.04354e-07, 9.80682e-08
-VerifyScriptBench, 5, 6300, 9.02493, 0.000285566, 0.000288433, 0.000286175
+AssembleBlock, 5, 700, 1.79954, 0.000510913, 0.000517018, 0.000514497
+...
```
Help
---------------------
-`-?` will print a list of options and exit:
- src/bench/bench_bitcoin -?
+ src/bench/bench_bitcoin --help
+
+To print options like scaling factor or per-benchmark filter.
Notes
---------------------
More benchmarks are needed for, in no particular order:
- Script Validation
-- CCoinDBView caching
- Coins database
- Memory pool
-- Wallet coin selection
+- Cuckoo Cache
+- P2P throughput
+
+Going Further
+--------------------
+
+To monitor Bitcoin Core performance more in depth (like reindex or IBD): https://github.com/chaincodelabs/bitcoinperf
+
+To generate Flame Graphs for Bitcoin Core: https://github.com/eklitzke/bitcoin/blob/flamegraphs/doc/flamegraphs.md
diff --git a/doc/bitcoin-conf.md b/doc/bitcoin-conf.md
index 88ecb8fe65..f8146b5d75 100644
--- a/doc/bitcoin-conf.md
+++ b/doc/bitcoin-conf.md
@@ -30,6 +30,21 @@ Network specific options can be:
- placed into sections with headers `[main]` (not `[mainnet]`), `[test]` (not `[testnet]`) or `[regtest]`;
- prefixed with a chain name; e.g., `regtest.maxmempool=100`.
+Network specific options take precedence over non-network specific options.
+If multiple values for the same option are found with the same precedence, the
+first one is generally chosen.
+
+This means that given the following configuration, `regtest.rpcport` is set to `3000`:
+
+```
+regtest=1
+rpcport=2000
+regtest.rpcport=3000
+
+[regtest]
+rpcport=4000
+```
+
## Configuration File Path
The configuration file is not automatically created; you can create it using your favorite text editor. By default, the configuration file name is `bitcoin.conf` and it is located in the Bitcoin data directory, but both the Bitcoin data directory and the configuration file path may be changed using the `-datadir` and `-conf` command-line options.
diff --git a/doc/build-unix.md b/doc/build-unix.md
index da65bc347a..eb88aca050 100644
--- a/doc/build-unix.md
+++ b/doc/build-unix.md
@@ -61,6 +61,14 @@ tuned to conserve memory with additional CXXFLAGS:
./configure CXXFLAGS="--param ggc-min-expand=1 --param ggc-min-heapsize=32768"
+Alternatively, or in addition, debugging information can be skipped for compilation. The default compile flags are
+`-g -O2`, and can be changed with:
+
+ ./configure CXXFLAGS="-O2"
+
+Finally, clang (often less resource hungry) can be used instead of gcc, which is used by default:
+
+ ./configure CXX=clang++ CC=clang
## Linux Distribution Specific Instructions
@@ -78,7 +86,7 @@ Now, you can either build from self-compiled [depends](/depends/README.md) or in
BerkeleyDB is required for the wallet.
-Ubuntu and Debian have their own libdb-dev and libdb++-dev packages, but these will install
+Ubuntu and Debian have their own `libdb-dev` and `libdb++-dev` packages, but these will install
BerkeleyDB 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.
@@ -88,7 +96,7 @@ Otherwise, you can build from self-compiled `depends` (see above).
To build Bitcoin Core without wallet, see [*Disable-wallet mode*](/doc/build-unix.md#disable-wallet-mode)
-Optional (see --with-miniupnpc and --enable-upnp-default):
+Optional (see `--with-miniupnpc` and `--enable-upnp-default`):
sudo apt-get install libminiupnpc-dev
@@ -122,10 +130,14 @@ Build requirements:
sudo dnf install gcc-c++ libtool make autoconf automake openssl-devel libevent-devel boost-devel libdb4-devel libdb4-cxx-devel python3
-Optional:
+Optional (see `--with-miniupnpc` and `--enable-upnp-default`):
sudo dnf install miniupnpc-devel
+ZMQ dependencies (provides ZMQ API):
+
+ sudo dnf install zeromq-devel
+
To build with Qt 5 you need the following:
sudo dnf install qt5-qttools-devel qt5-qtbase-devel protobuf-devel
diff --git a/doc/dependencies.md b/doc/dependencies.md
index c9c6a93c01..0b23ca0a2d 100644
--- a/doc/dependencies.md
+++ b/doc/dependencies.md
@@ -7,25 +7,24 @@ These are the dependencies currently used by Bitcoin Core. You can find instruct
| --- | --- | --- | --- | --- | --- |
| Berkeley DB | [4.8.30](https://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index.html) | 4.8.x | No | | |
| Boost | [1.70.0](https://www.boost.org/users/download/) | [1.47.0](https://github.com/bitcoin/bitcoin/pull/8920) | No | | |
-| Clang | | [3.3+](https://llvm.org/releases/download.html) (C++11 support) | | | |
+| Clang | | [3.3+](https://releases.llvm.org/download.html) (C++11 support) | | | |
| Expat | [2.2.7](https://libexpat.github.io/) | | No | Yes | |
| fontconfig | [2.12.1](https://www.freedesktop.org/software/fontconfig/release/) | | No | Yes | |
| FreeType | [2.7.1](https://download.savannah.gnu.org/releases/freetype) | | No | | |
| GCC | | [4.8+](https://gcc.gnu.org/) (C++11 support) | | | |
| HarfBuzz-NG | | | | | |
| libevent | [2.1.8-stable](https://github.com/libevent/libevent/releases) | 2.0.22 | No | | |
-| libjpeg | | | | | [Yes](https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk#L65) |
-| libpng | | | | | [Yes](https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk#L64) |
+| libpng | | | | | [Yes](https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk) |
| librsvg | | | | | |
| MiniUPnPc | [2.0.20180203](http://miniupnp.free.fr/files) | | No | | |
| OpenSSL | [1.0.1k](https://www.openssl.org/source) | | Yes | | |
-| PCRE | | | | | [Yes](https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk#L66) |
+| PCRE | | | | | [Yes](https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk) |
| protobuf | [2.6.1](https://github.com/google/protobuf/releases) | | No | | |
| Python (tests) | | [3.5](https://www.python.org/downloads) | | | |
| qrencode | [3.4.4](https://fukuchi.org/works/qrencode) | | No | | |
| Qt | [5.9.7](https://download.qt.io/official_releases/qt/) | [5.5.1](https://github.com/bitcoin/bitcoin/issues/13478) | No | | |
-| XCB | | | | | [Yes](https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk#L87) (Linux only) |
-| xkbcommon | | | | | [Yes](https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk#L86) (Linux only) |
+| XCB | | | | | [Yes](https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk) (Linux only) |
+| xkbcommon | | | | | [Yes](https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk) (Linux only) |
| ZeroMQ | [4.3.1](https://github.com/zeromq/libzmq/releases) | 4.0.0 | No | | |
| zlib | [1.2.11](https://zlib.net/) | | | | No |
diff --git a/doc/developer-notes.md b/doc/developer-notes.md
index 1ff5268218..561f623cd5 100644
--- a/doc/developer-notes.md
+++ b/doc/developer-notes.md
@@ -62,7 +62,7 @@ tool to clean up patches automatically before submission.
- Braces on the same line for everything else.
- 4 space indentation (no tabs) for every block except namespaces.
- No indentation for `public`/`protected`/`private` or for `namespace`.
- - No extra spaces inside parenthesis; don't do ( this )
+ - No extra spaces inside parenthesis; don't do ( this ).
- No space after function names; one space after `if`, `for` and `while`.
- If an `if` only has a single-statement `then`-clause, it can appear
on the same line as the `if`, without braces. In every other case,
@@ -72,12 +72,12 @@ tool to clean up patches automatically before submission.
- **Symbol naming conventions**. These are preferred in new code, but are not
required when doing so would need changes to significant pieces of existing
code.
- - Variable (including function arguments) and namespace names are all lowercase, and may use `_` to
+ - Variable (including function arguments) and namespace names are all lowercase and may use `_` to
separate words (snake_case).
- Class member variables have a `m_` prefix.
- Global variables have a `g_` prefix.
- Constant names are all uppercase, and use `_` to separate words.
- - Class names, function names and method names are UpperCamelCase
+ - Class names, function names, and method names are UpperCamelCase
(PascalCase). Do not prefix class names with `C`.
- Test suite naming convention: The Boost test suite in file
`src/test/foo_tests.cpp` should be named `foo_tests`. Test suite names
@@ -134,6 +134,7 @@ Bitcoin Core uses [Doxygen](http://www.doxygen.nl/) to generate its official doc
Use Doxygen-compatible comment blocks for functions, methods, and fields.
For example, to describe a function use:
+
```c++
/**
* ... text ...
@@ -143,11 +144,12 @@ For example, to describe a function use:
*/
bool function(int arg1, const char *arg2)
```
+
A complete list of `@xxx` commands can be found at http://www.doxygen.nl/manual/commands.html.
As Doxygen recognizes the comments by the delimiters (`/**` and `*/` in this case), you don't
*need* to provide any commands for a comment to be valid; just a description text is fine.
-To describe a class use the same construct above the class definition:
+To describe a class, use the same construct above the class definition:
```c++
/**
* Alerts are for notifying old versions if they become too obsolete and
@@ -189,7 +191,7 @@ but the above styles are favored.
Documentation can be generated with `make docs` and cleaned up with `make clean-docs`. The resulting files are located in `doc/doxygen/html`; open `index.html` to view the homepage.
-Before running `make docs`, you will need to install dependencies `doxygen` and `dot`. For example, on MacOS via Homebrew:
+Before running `make docs`, you will need to install dependencies `doxygen` and `dot`. For example, on macOS via Homebrew:
```
brew install doxygen --with-graphviz
```
@@ -231,7 +233,7 @@ that run in `-regtest` mode.
Bitcoin Core is a multi-threaded application, and deadlocks or other
multi-threading bugs can be very difficult to track down. The `--enable-debug`
configure option adds `-DDEBUG_LOCKORDER` to the compiler flags. This inserts
-run-time checks to keep track of which locks are held, and adds warnings to the
+run-time checks to keep track of which locks are held and adds warnings to the
debug.log file if inconsistencies are detected.
### Valgrind suppressions file
@@ -299,7 +301,7 @@ $ perf record \
-p `pgrep bitcoind` -- sleep 60
```
-You could then analyze the results by running
+You could then analyze the results by running:
```sh
perf report --stdio | c++filt | less
@@ -364,7 +366,7 @@ Additional resources:
Locking/mutex usage notes
-------------------------
-The code is multi-threaded, and uses mutexes and the
+The code is multi-threaded and uses mutexes and the
`LOCK` and `TRY_LOCK` macros to protect data structures.
Deadlocks due to inconsistent lock ordering (thread 1 locks `cs_main` and then
@@ -389,7 +391,7 @@ Threads
- ThreadDNSAddressSeed : Loads addresses of peers from the DNS.
-- ThreadMapPort : Universal plug-and-play startup/shutdown
+- ThreadMapPort : Universal plug-and-play startup/shutdown.
- ThreadSocketHandler : Sends/Receives data from peers on port 8333.
@@ -408,7 +410,7 @@ Threads
Ignoring IDE/editor files
--------------------------
-In closed-source environments in which everyone uses the same IDE it is common
+In closed-source environments in which everyone uses the same IDE, it is common
to add temporary files it produces to the project-wide `.gitignore` file.
However, in open source software such as Bitcoin Core, where everyone uses
@@ -446,19 +448,19 @@ pay attention to for reviewers of Bitcoin Core code.
General Bitcoin Core
----------------------
-- New features should be exposed on RPC first, then can be made available in the GUI
+- New features should be exposed on RPC first, then can be made available in the GUI.
- *Rationale*: RPC allows for better automatic testing. The test suite for
- the GUI is very limited
+ the GUI is very limited.
-- Make sure pull requests pass Travis CI before merging
+- Make sure pull requests pass Travis CI before merging.
- *Rationale*: Makes sure that they pass thorough testing, and that the tester will keep passing
- on the master branch. Otherwise all new pull requests will start failing the tests, resulting in
- confusion and mayhem
+ on the master branch. Otherwise, all new pull requests will start failing the tests, resulting in
+ confusion and mayhem.
- *Explanation*: If the test suite is to be updated for a change, this has to
- be done first
+ be done first.
Wallet
-------
@@ -466,13 +468,13 @@ Wallet
- Make sure that no crashes happen with run-time option `-disablewallet`.
- *Rationale*: In RPC code that conditionally uses the wallet (such as
- `validateaddress`) it is easy to forget that global pointer `pwalletMain`
+ `validateaddress`), it is easy to forget that global pointer `pwalletMain`
can be nullptr. See `test/functional/disablewallet.py` for functional tests
- exercising the API with `-disablewallet`
+ exercising the API with `-disablewallet`.
-- Include `db_cxx.h` (BerkeleyDB header) only when `ENABLE_WALLET` is set
+- Include `db_cxx.h` (BerkeleyDB header) only when `ENABLE_WALLET` is set.
- - *Rationale*: Otherwise compilation of the disable-wallet build will fail in environments without BerkeleyDB
+ - *Rationale*: Otherwise compilation of the disable-wallet build will fail in environments without BerkeleyDB.
General C++
-------------
@@ -483,26 +485,26 @@ Guidelines](https://isocpp.github.io/CppCoreGuidelines/).
Common misconceptions are clarified in those sections:
- Passing (non-)fundamental types in the [C++ Core
- Guideline](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-conventional)
+ Guideline](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-conventional).
-- Assertions should not have side-effects
+- Assertions should not have side-effects.
- *Rationale*: Even though the source code is set to refuse to compile
with assertions disabled, having side-effects in assertions is unexpected and
- makes the code harder to understand
+ makes the code harder to understand.
-- If you use the `.h`, you must link the `.cpp`
+- If you use the `.h`, you must link the `.cpp`.
- *Rationale*: Include files define the interface for the code in implementation files. Including one but
not linking the other is confusing. Please avoid that. Moving functions from
- the `.h` to the `.cpp` should not result in build errors
+ the `.h` to the `.cpp` should not result in build errors.
-- Use the RAII (Resource Acquisition Is Initialization) paradigm where possible. For example by using
+- Use the RAII (Resource Acquisition Is Initialization) paradigm where possible. For example, by using
`unique_ptr` for allocations in a function.
- - *Rationale*: This avoids memory and resource leaks, and ensures exception safety
+ - *Rationale*: This avoids memory and resource leaks, and ensures exception safety.
-- Use `MakeUnique()` to construct objects owned by `unique_ptr`s
+- Use `MakeUnique()` to construct objects owned by `unique_ptr`s.
- *Rationale*: `MakeUnique` is concise and ensures exception safety in complex expressions.
`MakeUnique` is a temporary project local implementation of `std::make_unique` (C++14).
@@ -510,27 +512,27 @@ Common misconceptions are clarified in those sections:
C++ data structures
--------------------
-- Never use the `std::map []` syntax when reading from a map, but instead use `.find()`
+- Never use the `std::map []` syntax when reading from a map, but instead use `.find()`.
- *Rationale*: `[]` does an insert (of the default element) if the item doesn't
exist in the map yet. This has resulted in memory leaks in the past, as well as
- race conditions (expecting read-read behavior). Using `[]` is fine for *writing* to a map
+ race conditions (expecting read-read behavior). Using `[]` is fine for *writing* to a map.
- Do not compare an iterator from one data structure with an iterator of
- another data structure (even if of the same type)
+ another data structure (even if of the same type).
- *Rationale*: Behavior is undefined. In C++ parlor this means "may reformat
- the universe", in practice this has resulted in at least one hard-to-debug crash bug
+ the universe", in practice this has resulted in at least one hard-to-debug crash bug.
- Watch out for out-of-bounds vector access. `&vch[vch.size()]` is illegal,
including `&vch[0]` for an empty vector. Use `vch.data()` and `vch.data() +
vch.size()` instead.
-- Vector bounds checking is only enabled in debug mode. Do not rely on it
+- Vector bounds checking is only enabled in debug mode. Do not rely on it.
- Initialize all non-static class members where they are defined.
If this is skipped for a good reason (i.e., optimization on the critical
- path), add an explicit comment about this
+ path), add an explicit comment about this.
- *Rationale*: Ensure determinism by avoiding accidental use of uninitialized
values. Also, static analyzers balk about this.
@@ -554,12 +556,12 @@ class A
`int8_t`. Do not use bare `char` unless it is to pass to a third-party API.
This type can be signed or unsigned depending on the architecture, which can
lead to interoperability problems or dangerous conditions such as
- out-of-bounds array accesses
+ out-of-bounds array accesses.
-- Prefer explicit constructions over implicit ones that rely on 'magical' C++ behavior
+- Prefer explicit constructions over implicit ones that rely on 'magical' C++ behavior.
- *Rationale*: Easier to understand what is happening, thus easier to spot mistakes, even for those
- that are not language lawyers
+ that are not language lawyers.
Strings and formatting
------------------------
@@ -567,17 +569,17 @@ Strings and formatting
- Be careful of `LogPrint` versus `LogPrintf`. `LogPrint` takes a `category` argument, `LogPrintf` does not.
- *Rationale*: Confusion of these can result in runtime exceptions due to
- formatting mismatch, and it is easy to get wrong because of subtly similar naming
+ formatting mismatch, and it is easy to get wrong because of subtly similar naming.
-- Use `std::string`, avoid C string manipulation functions
+- Use `std::string`, avoid C string manipulation functions.
- *Rationale*: C++ string handling is marginally safer, less scope for
- buffer overflows and surprises with `\0` characters. Also some C string manipulations
- tend to act differently depending on platform, or even the user locale
+ 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 `ParseInt32`, `ParseInt64`, `ParseUInt32`, `ParseUInt64`, `ParseDouble` from `utilstrencodings.h` for number parsing.
- - *Rationale*: These functions do overflow checking, and avoid pesky locale issues.
+ - *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)
@@ -607,34 +609,32 @@ Strings and formatting
`wcstoll`, `wcstombs`, `wcstoul`, `wcstoull`, `wcstoumax`, `wcswidth`,
`wcsxfrm`, `wctob`, `wctomb`, `wctrans`, `wctype`, `wcwidth`, `wprintf`
-- For `strprintf`, `LogPrint`, `LogPrintf` formatting characters don't need size specifiers
+- For `strprintf`, `LogPrint`, `LogPrintf` formatting characters don't need size specifiers.
- - *Rationale*: Bitcoin Core uses tinyformat, which is type safe. Leave them out to avoid confusion
+ - *Rationale*: Bitcoin Core uses tinyformat, which is type safe. Leave them out to avoid confusion.
Shadowing
--------------
-Although the shadowing warning (`-Wshadow`) is not enabled by default (it prevents issues rising
+Although the shadowing warning (`-Wshadow`) is not enabled by default (it prevents issues arising
from using a different variable with the same name),
please name variables so that their names do not shadow variables defined in the source code.
When using nested cycles, do not name the inner cycle variable the same as in
-upper cycle etc.
-
+the upper cycle, etc.
Threads and synchronization
----------------------------
- Build and run tests with `-DDEBUG_LOCKORDER` to verify that no potential
deadlocks are introduced. As of 0.12, this is defined by default when
- configuring with `--enable-debug`
+ configuring with `--enable-debug`.
- When using `LOCK`/`TRY_LOCK` be aware that the lock exists in the context of
the current scope, so surround the statement and the code that needs the lock
- with braces
+ with braces.
OK:
-
```c++
{
TRY_LOCK(cs_vNodes, lockNodes);
@@ -643,7 +643,6 @@ Threads and synchronization
```
Wrong:
-
```c++
TRY_LOCK(cs_vNodes, lockNodes);
{
@@ -665,13 +664,11 @@ Scripts
`#!/usr/bin/env bash` searches the user's PATH to find the bash binary.
OK:
-
```bash
#!/usr/bin/env bash
```
Wrong:
-
```bash
#!/bin/bash
```
@@ -680,9 +677,9 @@ Source code organization
--------------------------
- Implementation code should go into the `.cpp` file and not the `.h`, unless necessary due to template usage or
- when performance due to inlining is critical
+ when performance due to inlining is critical.
- - *Rationale*: Shorter and simpler header files are easier to read, and reduce compile time
+ - *Rationale*: Shorter and simpler header files are easier to read and reduce compile time.
- Use only the lowercase alphanumerics (`a-z0-9`), underscore (`_`) and hyphen (`-`) in source code filenames.
@@ -700,7 +697,7 @@ Source code organization
- Don't import anything into the global namespace (`using namespace ...`). Use
fully specified types such as `std::string`.
- - *Rationale*: Avoids symbol conflicts
+ - *Rationale*: Avoids symbol conflicts.
- Terminate namespaces with a comment (`// namespace mynamespace`). The comment
should be placed on the same line as the brace closing the namespace, e.g.
@@ -715,7 +712,7 @@ namespace {
} // namespace
```
- - *Rationale*: Avoids confusion about the namespace context
+ - *Rationale*: Avoids confusion about the namespace context.
- Use `#include <primitives/transaction.h>` bracket syntax instead of
`#include "primitives/transactions.h"` quote syntax.
@@ -738,13 +735,13 @@ namespace {
GUI
-----
-- Do not display or manipulate dialogs in model code (classes `*Model`)
+- Do not display or manipulate dialogs in model code (classes `*Model`).
- *Rationale*: Model classes pass through events and data from the core, they
should not interact with the user. That's where View classes come in. The converse also
holds: try to not directly access core data structures from Views.
-- Avoid adding slow or blocking code in the GUI thread. In particular do not
+- Avoid adding slow or blocking code in the GUI thread. In particular, do not
add new `interfaces::Node` and `interfaces::Wallet` method calls, even if they
may be fast now, in case they are changed to lock or communicate across
processes in the future.
@@ -763,12 +760,12 @@ Subtrees
Several parts of the repository are subtrees of software maintained elsewhere.
Some of these are maintained by active developers of Bitcoin Core, in which case changes should probably go
-directly upstream without being PRed directly against the project. They will be merged back in the next
+directly upstream without being PRed directly against the project. They will be merged back in the next
subtree merge.
-Others are external projects without a tight relationship with our project. Changes to these should also
-be sent upstream but bugfixes may also be prudent to PR against Bitcoin Core so that they can be integrated
-quickly. Cosmetic changes should be purely taken upstream.
+Others are external projects without a tight relationship with our project. Changes to these should also
+be sent upstream, but bugfixes may also be prudent to PR against Bitcoin Core so that they can be integrated
+quickly. Cosmetic changes should be purely taken upstream.
There is a tool in `test/lint/git-subtree-check.sh` to check a subtree directory for consistency with
its upstream repository.
@@ -798,11 +795,11 @@ you must be aware of.
### File Descriptor Counts
-In most configurations we use the default LevelDB value for `max_open_files`,
+In most configurations, we use the default LevelDB value for `max_open_files`,
which is 1000 at the time of this writing. If LevelDB actually uses this many
-file descriptors it will cause problems with Bitcoin's `select()` loop, because
+file descriptors, it will cause problems with Bitcoin's `select()` loop, because
it may cause new sockets to be created where the fd value is >= 1024. For this
-reason, on 64-bit Unix systems we rely on an internal LevelDB optimization that
+reason, on 64-bit Unix systems, we rely on an internal LevelDB optimization that
uses `mmap()` + `close()` to open table files without actually retaining
references to the table file descriptors. If you are upgrading LevelDB, you must
sanity check the changes to make sure that this assumption remains valid.
@@ -827,14 +824,14 @@ details.
It is possible for LevelDB changes to inadvertently change consensus
compatibility between nodes. This happened in Bitcoin 0.8 (when LevelDB was
-first introduced). When upgrading LevelDB you should review the upstream changes
+first introduced). When upgrading LevelDB, you should review the upstream changes
to check for issues affecting consensus compatibility.
For example, if LevelDB had a bug that accidentally prevented a key from being
returned in an edge case, and that bug was fixed upstream, the bug "fix" would
-be an incompatible consensus change. In this situation the correct behavior
+be an incompatible consensus change. In this situation, the correct behavior
would be to revert the upstream fix before applying the updates to Bitcoin's
-copy of LevelDB. In general you should be wary of any upstream changes affecting
+copy of LevelDB. In general, you should be wary of any upstream changes affecting
what data is returned from LevelDB queries.
Scripted diffs
@@ -853,7 +850,7 @@ To create a scripted-diff:
- `-BEGIN VERIFY SCRIPT-`
- `-END VERIFY SCRIPT-`
-The scripted-diff is verified by the tool `test/lint/commit-script-check.sh`. The tool's default behavior when supplied
+The scripted-diff is verified by the tool `test/lint/commit-script-check.sh`. The tool's default behavior, when supplied
with a commit is to verify all scripted-diffs from the beginning of time up to said commit. Internally, the tool passes
the first supplied argument to `git rev-list --reverse` to determine which commits to verify script-diffs for, ignoring
commits that don't conform to the commit message format described above.
@@ -886,23 +883,23 @@ RPC interface guidelines
A few guidelines for introducing and reviewing new RPC interfaces:
-- Method naming: use consecutive lower-case names such as `getrawtransaction` and `submitblock`
+- Method naming: use consecutive lower-case names such as `getrawtransaction` and `submitblock`.
- - *Rationale*: Consistency with existing interface.
+ - *Rationale*: Consistency with the existing interface.
- Argument naming: use snake case `fee_delta` (and not, e.g. camel case `feeDelta`)
- - *Rationale*: Consistency with existing interface.
+ - *Rationale*: Consistency with the existing interface.
- Use the JSON parser for parsing, don't manually parse integers or strings from
arguments unless absolutely necessary.
- *Rationale*: Introduces hand-rolled string manipulation code at both the caller and callee sites,
- which is error prone, and it is easy to get things such as escaping wrong.
+ which is error-prone, and it is easy to get things such as escaping wrong.
JSON already supports nested data structures, no need to re-invent the wheel.
- *Exception*: AmountFromValue can parse amounts as string. This was introduced because many JSON
- parsers and formatters hard-code handling decimal numbers as floating point
+ parsers and formatters hard-code handling decimal numbers as floating-point
values, resulting in potential loss of precision. This is unacceptable for
monetary values. **Always** use `AmountFromValue` and `ValueFromAmount` when
inputting or outputting monetary values. The only exceptions to this are
@@ -911,7 +908,7 @@ A few guidelines for introducing and reviewing new RPC interfaces:
- Missing arguments and 'null' should be treated the same: as default values. If there is no
default value, both cases should fail in the same way. The easiest way to follow this
- guideline is detect unspecified arguments with `params[x].isNull()` instead of
+ guideline is to detect unspecified arguments with `params[x].isNull()` instead of
`params.size() <= x`. The former returns true if the argument is either null or missing,
while the latter returns true if is missing, and false if it is null.
@@ -945,7 +942,7 @@ A few guidelines for introducing and reviewing new RPC interfaces:
from there.
- A RPC method must either be a wallet method or a non-wallet method. Do not
- introduce new methods that differ in behavior based on presence of a wallet.
+ introduce new methods that differ in behavior based on the presence of a wallet.
- *Rationale*: as well as complicating the implementation and interfering
with the introduction of multi-wallet, wallet and non-wallet code should be
@@ -953,7 +950,7 @@ A few guidelines for introducing and reviewing new RPC interfaces:
- Try to make the RPC response a JSON object.
- - *Rationale*: If a RPC response is not a JSON object then it is harder to avoid API breakage if
+ - *Rationale*: If a RPC response is not a JSON object, then it is harder to avoid API breakage if
new data in the response is needed.
- Wallet RPCs call BlockUntilSyncedToCurrentChain to maintain consistency with
diff --git a/doc/rapidcheck.md b/doc/rapidcheck.md
new file mode 100644
index 0000000000..397a907f17
--- /dev/null
+++ b/doc/rapidcheck.md
@@ -0,0 +1,84 @@
+# RapidCheck property-based testing for Bitcoin Core
+
+## Concept
+
+Property-based testing is experimentally being added to Bitcoin Core with
+[RapidCheck](https://github.com/emil-e/rapidcheck), a C++ framework for
+property-based testing inspired by the Haskell library
+[QuickCheck](https://hackage.haskell.org/package/QuickCheck).
+
+RapidCheck performs random testing of program properties. A specification of the
+program is given in the form of properties which functions should satisfy, and
+RapidCheck tests that the properties hold in a large number of randomly
+generated cases.
+
+If an exception is found, RapidCheck tries to find the smallest case, for some
+definition of smallest, for which the property is still false and displays it as
+a counter-example. For example, if the input is an integer, RapidCheck tries to
+find the smallest integer for which the property is false.
+
+## Running
+
+If RapidCheck is installed, Bitcoin Core will automatically run the
+property-based tests with the unit tests during `make check`, unless the
+`--without-rapidcheck` flag is passed when configuring.
+
+For more information, run `./configure --help` and see `--with-rapidcheck` under
+Optional Packages.
+
+## Setup
+
+The following instructions have been tested with Linux Debian and macOS.
+
+1. Clone the RapidCheck source code and cd into the repository.
+
+ ```shell
+ git clone https://github.com/emil-e/rapidcheck.git
+ cd rapidcheck
+ ```
+
+2. Build RapidCheck (requires CMake to be installed).
+
+ ```shell
+ cmake -DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=true -DRC_ENABLE_BOOST_TEST=ON $(pwd)
+ make && make install
+ ```
+
+3. Configure Bitcoin Core with RapidCheck.
+
+ `cd` to the directory of your local bitcoin repository and run
+ `./configure`. In the output you should see:
+
+ ```shell
+ checking rapidcheck.h usability... yes
+ checking rapidcheck.h presence... yes
+ checking for rapidcheck.h... yes
+ [...]
+ Options used to compile and link:
+ [...]
+ with test = yes
+ with prop = yes
+ ```
+
+4. Build Bitcoin Core with RapidCheck.
+
+ Now you can run `make` and should see the property-based tests compiled with
+ the unit tests:
+
+ ```shell
+ Making all in src
+ [...]
+ CXX test/gen/test_bitcoin-crypto_gen.o
+ CXX test/test_bitcoin-key_properties.o
+ ```
+
+5. Run the unit tests with `make check`. The property-based tests will be run
+ with the unit tests.
+
+ ```shell
+ Running tests: crypto_tests from test/crypto_tests.cpp
+ [...]
+ Running tests: key_properties from test/key_properties.cpp
+ ```
+
+That's it! You are now running property-based tests in Bitcoin Core.
diff --git a/doc/release-notes-0.18.1-16257.md b/doc/release-notes-0.18.1-16257.md
deleted file mode 100644
index 21867b7fb2..0000000000
--- a/doc/release-notes-0.18.1-16257.md
+++ /dev/null
@@ -1,6 +0,0 @@
-Wallet changes
---------------
-When creating a transaction with a fee above `-maxtxfee` (default 0.1 BTC),
-the RPC commands `walletcreatefundedpsbt` and `fundrawtransaction` will now fail
-instead of rounding down the fee. Beware that the `feeRate` argument is specified
-in BTC per kilobyte, not satoshi per byte.
diff --git a/doc/release-notes-13756.md b/doc/release-notes-13756.md
deleted file mode 100644
index a500aceb0f..0000000000
--- a/doc/release-notes-13756.md
+++ /dev/null
@@ -1,41 +0,0 @@
-Coin selection
---------------
-
-### Reuse Avoidance
-
-A new wallet flag `avoid_reuse` has been added (default off). When enabled,
-a wallet will distinguish between used and unused addresses, and default to not
-use the former in coin selection.
-
-Rescanning the blockchain is required, to correctly mark previously
-used destinations.
-
-Together with "avoid partial spends" (present as of Bitcoin v0.17), this
-addresses a serious privacy issue where a malicious user can track spends by
-peppering a previously paid to address with near-dust outputs, which would then
-be inadvertently included in future payments.
-
-New RPCs
---------
-
-- A new `setwalletflag` RPC sets/unsets flags for an existing wallet.
-
-
-Updated RPCs
-------------
-
-Several RPCs have been updated to include an "avoid_reuse" flag, used to control
-whether already used addresses should be left out or included in the operation.
-These include:
-
-- createwallet
-- getbalance
-- getbalances
-- sendtoaddress
-
-In addition, `sendtoaddress` has been changed to avoid partial spends when `avoid_reuse`
-is enabled (if not already enabled via the `-avoidpartialspends` command line flag),
-as it would otherwise risk using up the "wrong" UTXO for an address reuse case.
-
-The listunspent RPC has also been updated to now include a "reused" bool, for nodes
-with "avoid_reuse" enabled.
diff --git a/doc/release-notes-14054.md b/doc/release-notes-14054.md
deleted file mode 100644
index d8cad369c5..0000000000
--- a/doc/release-notes-14054.md
+++ /dev/null
@@ -1,7 +0,0 @@
-P2P changes
------------
-
-BIP 61 reject messages were deprecated in v0.18. They are now disabled by
-default, but can be enabled by setting the `-enablebip61` command line option.
-BIP 61 reject messages will be removed entirely in a future version of
-Bitcoin Core.
diff --git a/doc/release-notes-14802.md b/doc/release-notes-14802.md
deleted file mode 100644
index 1fcc38866a..0000000000
--- a/doc/release-notes-14802.md
+++ /dev/null
@@ -1,3 +0,0 @@
-RPC changes
------------
-The `getblockstats` RPC is faster for fee calculation by using BlockUndo data. Also, `-txindex` is no longer required and `getblockstats` works for all non-pruned blocks.
diff --git a/doc/release-notes-14954.md b/doc/release-notes-14954.md
deleted file mode 100644
index 4bb0fcca74..0000000000
--- a/doc/release-notes-14954.md
+++ /dev/null
@@ -1,3 +0,0 @@
-Build system changes
---------------------
-Python >=3.5 is now required by all aspects of the project. This includes the build systems, test framework and linters. The previously supported minimum (3.4), was EOL in March 2019. See #14954 for more details. \ No newline at end of file
diff --git a/doc/release-notes-15006.md b/doc/release-notes-15006.md
deleted file mode 100644
index 76ed3247a6..0000000000
--- a/doc/release-notes-15006.md
+++ /dev/null
@@ -1,4 +0,0 @@
-Miscellaneous RPC changes
-------------
-
-- `createwallet` can now create encrypted wallets if a non-empty passphrase is specified.
diff --git a/doc/release-notes-15427.md b/doc/release-notes-15427.md
deleted file mode 100644
index 25edfd4402..0000000000
--- a/doc/release-notes-15427.md
+++ /dev/null
@@ -1,9 +0,0 @@
-Updated RPCs
-------------
-
-The `utxoupdatepsbt` RPC method has been updated to take a `descriptors`
-argument. When provided, input and output scripts and keys will be filled in
-when known, and P2SH-witness inputs will be filled in from the UTXO set when a
-descriptor is provided that shows they're spending segwit outputs.
-
-See the RPC help text for full details.
diff --git a/doc/release-notes-15566.md b/doc/release-notes-15566.md
deleted file mode 100644
index 49964d7550..0000000000
--- a/doc/release-notes-15566.md
+++ /dev/null
@@ -1,3 +0,0 @@
-Miscellaneous CLI Changes
--------------------------
-- The `testnet` field in `bitcoin-cli -getinfo` has been renamed to `chain` and now returns the current network name as defined in BIP70 (main, test, regtest). \ No newline at end of file
diff --git a/doc/release-notes-15620.md b/doc/release-notes-15620.md
deleted file mode 100644
index bf89a70a4e..0000000000
--- a/doc/release-notes-15620.md
+++ /dev/null
@@ -1,13 +0,0 @@
-Updated RPCs
-------------
-
-* The -maxtxfee setting no longer has any effect on non-wallet RPCs.
-
- The `sendrawtransaction` and `testmempoolaccept` RPC methods previously
- accepted an `allowhighfees` parameter to fail the mempool acceptance in case
- the transaction's fee would exceed the value of the command line argument
- `-maxtxfee`. To uncouple the RPCs from the global option, they now have a
- hardcoded default for the maximum transaction fee, that can be changed for
- both RPCs on a per-call basis with the `maxfeerate` parameter. The
- `allowhighfees` boolean option has been removed and replaced by the
- `maxfeerate` numeric option.
diff --git a/doc/release-notes-15637.md b/doc/release-notes-15637.md
deleted file mode 100644
index 048d5e7218..0000000000
--- a/doc/release-notes-15637.md
+++ /dev/null
@@ -1,3 +0,0 @@
-RPC changes
------------
-In getmempoolancestors, getmempooldescendants, getmempoolentry and getrawmempool RPCs, to be consistent with the returned value and other RPCs such as getrawtransaction, vsize has been added and size is now deprecated. size will only be returned if bitcoind is started with `-deprecatedrpc=size`. \ No newline at end of file
diff --git a/doc/release-notes-15730.md b/doc/release-notes-15730.md
deleted file mode 100644
index 7a4a60b1ee..0000000000
--- a/doc/release-notes-15730.md
+++ /dev/null
@@ -1,5 +0,0 @@
-RPC changes
------------
-The RPC `getwalletinfo` response now includes the `scanning` key with an object
-if there is a scanning in progress or `false` otherwise. Currently the object
-has the scanning duration and progress.
diff --git a/doc/release-notes-15849.md b/doc/release-notes-15849.md
deleted file mode 100644
index a1df31f250..0000000000
--- a/doc/release-notes-15849.md
+++ /dev/null
@@ -1,6 +0,0 @@
-Thread names in logs
---------------------
-
-On platforms supporting `thread_local`, log lines can be prefixed with the name
-of the thread that caused the log. To enable this behavior, use
-`-logthreadnames=1`.
diff --git a/doc/release-notes.md b/doc/release-notes.md
index afb0469291..04aab56a72 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -64,14 +64,51 @@ platform.
Notable changes
===============
+New user documentation
+----------------------
+
+- [Reduce memory](https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-memory.md)
+ suggests configuration tweaks for running Bitcoin Core on systems with
+ limited memory. (#16339)
+
New RPCs
--------
- `getbalances` returns an object with all balances (`mine`,
`untrusted_pending` and `immature`). Please refer to the RPC help of
`getbalances` for details. The new RPC is intended to replace
- `getunconfirmedbalance` and the balance fields in `getwalletinfo`, as well as
- `getbalance`. The old calls may be removed in a future version.
+ `getbalance`, `getunconfirmedbalance`, and the balance fields in
+ `getwalletinfo`. These old calls and fields may be removed in a
+ future version. (#15930, #16239)
+
+- `setwalletflag` sets and unsets wallet flags that enable or disable
+ features specific to that existing wallet, such as the new
+ `avoid_reuse` feature documented elsewhere in these release notes.
+ (#13756)
+
+- `getblockfilter` gets the BIP158 filter for the specified block. This
+ RPC is only enabled if block filters have been created using the
+ `-blockfilterindex` configuration option. (#14121)
+
+New settings
+------------
+
+- `-blockfilterindex` enables the creation of BIP158 block filters for
+ the entire blockchain. Filters will be created in the background and
+ currently use about 4 GiB of space. Note: this version of Bitcoin
+ Core does not serve block filters over the P2P network, although the
+ local user may obtain block filters using the `getblockfilter` RPC.
+ (#14121)
+
+Updated settings
+----------------
+
+- `whitebind` and `whitelist` now accept a list of permissions to
+ provide peers connecting using the indicated interfaces or IP
+ addresses. If no permissions are specified with an address or CIDR
+ network, the implicit default permissions are the same as previous
+ releases. See the `bitcoind -help` output for these two options for
+ details about the available permissions. (#16248)
Updated RPCs
------------
@@ -79,15 +116,128 @@ Updated RPCs
Note: some low-level RPC changes mainly useful for testing are described in the
Low-level Changes section below.
-- The `sendmany` RPC had an argument `minconf` that was not well specified and
- would lead to RPC errors even when the wallet's coin selection would succeed.
- The `sendtoaddress` RPC never had this check, so to normalize the behavior,
- `minconf` is now ignored in `sendmany`. If the coin selection does not
- succeed due to missing coins, it will still throw an RPC error. Be reminded
- that coin selection is influenced by the `-spendzeroconfchange`,
- `-limitancestorcount`, `-limitdescendantcount` and `-walletrejectlongchains`
- command line arguments.
-
+- `sendmany` no longer has a `minconf` argument. This argument was not
+ well specified and would lead to RPC errors even when the wallet's
+ coin selection succeeded. Users who want to influence coin selection
+ can use the existing `-spendzeroconfchange`, `-limitancestorcount`,
+ `-limitdescendantcount` and `-walletrejectlongchains` configuration
+ arguments. (#15596)
+
+- `getbalance` and `sendtoaddress`, plus the new RPCs `getbalances` and
+ `createwallet`, now accept an "avoid_reuse" parameter that controls
+ whether already used addresses should be included in the operation.
+ Additionally, `sendtoaddress` will avoid partial spends when
+ `avoid_reuse` is enabled even if this feature is not already enabled
+ via the `-avoidpartialspends` command line flag because not doing so
+ would risk using up the "wrong" UTXO for an address reuse case.
+ (#13756)
+
+- `listunspent` now returns a "reused" bool for each output if the
+ wallet flag "avoid_reuse" is enabled. (#13756)
+
+- `getblockstats` now uses BlockUndo data instead of the transaction
+ index, making it much faster, no longer dependent on the `-txindex`
+ configuration option, and functional for all non-pruned blocks.
+ (#14802)
+
+- `utxoupdatepsbt` now accepts a `descriptors` parameter that will fill
+ out input and output scripts and keys when known. P2SH-witness inputs
+ will be filled in from the UTXO set when a descriptor is provided that
+ shows they're spending segwit outputs. See the RPC help text for full
+ details. (#15427)
+
+- `sendrawtransaction` and `testmempoolaccept` no longer accept a
+ `allowhighfees` parameter to fail mempool acceptance if the
+ transaction fee exceedes the value of the configuration option
+ `-maxtxfee`. Now there is a hardcoded default maximum feerate that
+ can be changed when calling either RPC using a `maxfeerate` parameter.
+ (#15620)
+
+- `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry`, and
+ `getrawmempool` no longer return a `size` field unless the
+ configuration option `-deprecatedrpc=size` is used. Instead a new
+ `vsize` field is returned with the transaction's virtual size
+ (consistent with other RPCs such as `getrawtransaction`). (#15637)
+
+- `getwalletinfo` now includes a `scanning` field that is either `false`
+ (no scanning) or an object with information about the duration and
+ progress of the wallet's scanning historical blocks for transactions
+ affecting its balances. (#15730)
+
+- `createwallet` accepts a new `passphrase` parameter. If set, this
+ will create the new wallet encrypted with the given passphrase. If
+ unset (the default) or set to an empty string, no encryption will be
+ used. (#16394)
+
+- `getmempoolentry` now provides a `weight` field containing the
+ transaction weight as defined in BIP141. (#16647)
+
+- `getdescriptorinfo` now returns an additional `checksum` field
+ containing the checksum for the unmodified descriptor provided by the
+ user (that is, before the descriptor is normalized for the
+ `descriptor` field). (#15986)
+
+- `walletcreatefundedpsbt` now signals BIP125 Replace-by-Fee if the
+ `-walletrbf` configuration option is set to true. (#15911)
+
+GUI changes
+-----------
+
+- Provides bech32 addresses by default. The user may change the address
+ during invoice generation using a GUI toggle, or the default address
+ type may be changed by the `-addresstype` configuration option.
+ (#15711, #16497)
+
+Deprecated or removed configuration options
+-------------------------------------------
+
+- `-mempoolreplacement` is removed, although default node behavior
+ remains the same. This option previously allowed the user to prevent
+ the node from accepting or relaying BIP125 transaction replacements.
+ This is different from the remaining configuration option
+ `-walletrbf`. (#16171)
+
+Deprecated or removed RPCs
+--------------------------
+
+- `bumpfee` no longer accepts a `totalFee` option unless the
+ configuration parameter `deprecatedrpc=totalFee` is specified. This
+ parameter will be fully removed in a subsequent release. (#15996)
+
+- `generate` is now removed after being deprecated in Bitcoin Core 0.18.
+ Use the `generatetoaddress` RPC instead. (#15492)
+
+P2P changes
+-----------
+
+- BIP 61 reject messages were deprecated in v0.18. They are now disabled
+ by default, but can be enabled by setting the `-enablebip61` command
+ line option. BIP 61 reject messages will be removed entirely in a
+ future version of Bitcoin Core. (#14054)
+
+- To eliminate well-known denial-of-service vectors in Bitcoin Core,
+ especially for nodes with spinning disks, the default value for the
+ `-peerbloomfilters` configuration option has been changed to false.
+ This prevents Bitcoin Core from sending the BIP111 NODE_BLOOM service
+ flag, accepting BIP37 bloom filters, or serving merkle blocks or
+ transactions matching a bloom filter. Users who still want to provide
+ bloom filter support may either set the configuration option to true
+ to re-enable both BIP111 and BIP37 support or enable just BIP37
+ support for specific peers using the updated `-whitelist` and
+ `-whitebind` configuration options described elsewhere in these
+ release notes. For the near future, lightweight clients using public
+ BIP111/BIP37 nodes should still be able to connect to older versions
+ of Bitcoin Core and nodes that have manually enabled BIP37 support,
+ but developers of such software should consider migrating to either
+ using specific BIP37 nodes or an alternative transaction filtering
+ system. (#16152)
+
+Miscellaneous CLI Changes
+-------------------------
+
+- The `testnet` field in `bitcoin-cli -getinfo` has been renamed to
+ `chain` and now returns the current network name as defined in BIP70
+ (main, test, regtest). (#15566)
Low-level changes
=================
@@ -95,24 +245,42 @@ Low-level changes
RPC
---
+- `getblockchaininfo` no longer returns a `bip9_softforks` object.
+ Instead, information has been moved into the `softforks` object and
+ an additional `type` field describes how Bitcoin Core determines
+ whether that soft fork is active (e.g. BIP9 or BIP90). See the RPC
+ help for details. (#16060)
+
+- `getblocktemplate` no longer returns a `rules` array containing `CSV`
+ and `segwit` (the BIP9 deployments that are currently in active
+ state). (#16060)
+
+- `getrpcinfo` now returns a `logpath` field with the path to
+ `debug.log`. (#15483)
Tests
-----
-- The regression test chain, that can be enabled by the `-regtest` command line
- flag, now requires transactions to not violate standard policy by default.
- Making the default the same as for mainnet, makes it easier to test mainnet
- behavior on regtest. Be reminded that the testnet still allows non-standard
- txs by default and that the policy can be locally adjusted with the
- `-acceptnonstdtxn` command line flag for both test chains.
+- The regression test chain enabled by the `-regtest` command line flag
+ now requires transactions to not violate standard policy by default.
+ This is the same default used for mainnet and makes it easier to test
+ mainnet behavior on regtest. Note that the testnet still allows
+ non-standard txs by default and that the policy can be locally
+ adjusted with the `-acceptnonstdtxn` command line flag for both test
+ chains. (#15891)
Configuration
------------
-- An error is issued where previously a warning was issued when a setting in
- the config file was specified in the default section, but not overridden for
- the selected network. This change takes only effect if the selected network
- is not mainnet.
+- A setting specified in the default section but not also specified in a
+ network-specific section (e.g. testnet) will now produce a error
+ preventing startup instead of just a warning unless the network is
+ mainnet. This prevents settings intended for mainnet from being
+ applied to testnet or regtest. (#15629)
+
+- On platforms supporting `thread_local`, log lines can be prefixed with
+ the name of the thread that caused the log. To enable this behavior,
+ use `-logthreadnames=1`. (#15849)
Network
-------
@@ -123,17 +291,81 @@ Network
peers' announcements were received. In this release, the download logic has
changed to randomize the fetch order across peers and to prefer sending
download requests to outbound peers over inbound peers. This fixes an issue
- where inbound peers can prevent a node from getting a transaction.
+ where inbound peers could prevent a node from getting a transaction.
+ (#14897, #15834)
+
+- If a Tor hidden service is being used, Bitcoin Core will be bound to
+ the standard port 8333 even if a different port is configured for
+ clearnet connections. This prevents leaking node identity through use
+ of identical non-default port numbers. (#15651)
+
+Mempool and transaction relay
+-----------------------------
+
+- Allows one extra single-ancestor transaction per package. Previously,
+ if a transaction in the mempool had 25 descendants, or it and all of
+ its descendants were over 101,000 vbytes, any newly-received
+ transaction that was also a descendant would be ignored. Now, one
+ extra descendant will be allowed provided it is an immediate
+ descendant (child) and the child's size is 10,000 vbytes or less.
+ This makes it possible for two-party contract protocols such as
+ Lightning Network to give each participant an output they can spend
+ immediately for Child-Pays-For-Parent (CPFP) fee bumping without
+ allowing one malicious participant to fill the entire package and thus
+ prevent the other participant from spending their output. (#15681)
+
+- Transactions with outputs paying v1 to v16 witness versions (future
+ segwit versions) are now accepted into the mempool, relayed, and
+ mined. Attempting to spend those outputs remains forbidden by policy
+ ("non-standard"). When this change has been widely deployed, wallets
+ and services can accept any valid bech32 Bitcoin address without
+ concern that transactions paying future segwit versions will become
+ stuck in an unconfirmed state. (#15846)
+
+- Legacy transactions (transactions with no segwit inputs) must now be
+ sent using the legacy encoding format, enforcing the rule specified in
+ BIP144. (#14039)
Wallet
------
- When in pruned mode, a rescan that was triggered by an `importwallet`,
- `importpubkey`, `importaddress`, or `importprivkey` RPC will only fail when
- blocks have been pruned. Previously it would fail when `-prune` has been set.
- This change allows to set `-prune` to a high value (e.g. the disk size) and
- the calls to any of the import RPCs would fail when the first block is
- pruned.
+ `importpubkey`, `importaddress`, or `importprivkey` RPC will only fail
+ when blocks have been pruned. Previously it would fail when `-prune`
+ has been set. This change allows setting `-prune` to a high value
+ (e.g. the disk size) without the calls to any of the import RPCs
+ failing until the first block is pruned. (#15870)
+
+- When creating a transaction with a fee above `-maxtxfee` (default 0.1
+ BTC), the RPC commands `walletcreatefundedpsbt` and
+ `fundrawtransaction` will now fail instead of rounding down the fee.
+ Be aware that the `feeRate` argument is specified in BTC per 1,000
+ vbytes, not satoshi per vbyte. (#16257)
+
+- A new wallet flag `avoid_reuse` has been added (default off). When
+ enabled, a wallet will distinguish between used and unused addresses,
+ and default to not use the former in coin selection. When setting
+ this flag on an existing wallet, rescanning the blockchain is required
+ to correctly mark previously used destinations. Together with "avoid
+ partial spends" (added in Bitcoin Core v0.17.0), this can eliminate a
+ serious privacy issue where a malicious user can track spends by
+ sending small payments to a previously-paid address that would then
+ be included with unrelated inputs in future payments. (#13756)
+
+Build system changes
+--------------------
+
+- Python >=3.5 is now required by all aspects of the project. This
+ includes the build systems, test framework and linters. The previously
+ supported minimum (3.4), was EOL in March 2019. (#14954)
+
+- The minimum supported miniUPnPc API version is set to 10. This keeps
+ compatibility with Ubuntu 16.04 LTS and Debian 8 `libminiupnpc-dev`
+ packages. Please note, on Debian this package is still vulnerable to
+ [CVE-2017-8798](https://security-tracker.debian.org/tracker/CVE-2017-8798)
+ (in jessie only) and
+ [CVE-2017-1000494](https://security-tracker.debian.org/tracker/CVE-2017-1000494)
+ (both in jessie and in stretch). (#15993)
Credits
=======
diff --git a/doc/release-notes/release-notes-0.18.1.md b/doc/release-notes/release-notes-0.18.1.md
new file mode 100644
index 0000000000..483cc5075e
--- /dev/null
+++ b/doc/release-notes/release-notes-0.18.1.md
@@ -0,0 +1,136 @@
+Bitcoin Core version 0.18.1 is now available from:
+
+ <https://bitcoincore.org/bin/bitcoin-core-0.18.1/>
+
+This is a new minor version release, including 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 for older
+versions), then run the installer (on Windows) or just copy over
+`/Applications/Bitcoin-Qt` (on Mac) or `bitcoind`/`bitcoin-qt` (on
+Linux).
+
+The first time you run version 0.15.0 or newer, your chainstate database
+will be converted to a new format, which will take anywhere from a few
+minutes to half an hour, depending on the speed of your machine.
+
+Note that the block database format also changed in version 0.8.0 and
+there is no automatic upgrade code from before version 0.8 to version
+0.15.0 or later. Upgrading directly from 0.7.x and earlier without
+redownloading the blockchain is not supported. However, as usual, old
+wallet versions are still supported.
+
+Compatibility
+==============
+
+Bitcoin Core is supported and extensively tested on operating systems
+using the Linux kernel, macOS 10.10+, and Windows 7 and newer. It is not
+recommended to use Bitcoin Core on unsupported systems.
+
+Bitcoin Core should also work on most other Unix-like systems but is not
+as frequently tested on them.
+
+From 0.17.0 onwards, macOS <10.10 is no longer supported. 0.17.0 is
+built using Qt 5.9.x, which doesn't support versions of macOS older than
+10.10. Additionally, Bitcoin Core does not yet change appearance when
+macOS "dark mode" is activated.
+
+Known issues
+============
+
+Wallet GUI
+----------
+
+For advanced users who have both (1) enabled coin control features, and
+(2) are using multiple wallets loaded at the same time: The coin control
+input selection dialog can erroneously retain wrong-wallet state when
+switching wallets using the dropdown menu. For now, it is recommended
+not to use coin control features with multiple wallets loaded.
+
+0.18.1 change log
+=================
+
+### P2P protocol and network code
+- #15990 Add tests and documentation for blocksonly (MarcoFalke)
+- #16021 Avoid logging transaction decode errors to stderr (MarcoFalke)
+- #16405 fix: tor: Call `event_base_loopbreak` from the event's callback (promag)
+- #16412 Make poll in InterruptibleRecv only filter for POLLIN events (tecnovert)
+
+### Wallet
+- #15913 Add -ignorepartialspends to list of ignored wallet options (luke-jr)
+
+### RPC and other APIs
+- #15991 Bugfix: fix pruneblockchain returned prune height (jonasschnelli)
+- #15899 Document iswitness flag and fix bug in converttopsbt (MarcoFalke)
+- #16026 Ensure that uncompressed public keys in a multisig always returns a legacy address (achow101)
+- #14039 Disallow extended encoding for non-witness transactions (sipa)
+- #16210 add 2nd arg to signrawtransactionwithkey examples (dooglus)
+- #16250 signrawtransactionwithkey: report error when missing redeemScript/witnessScript (ajtowns)
+
+### GUI
+- #16044 fix the bug of OPEN CONFIGURATION FILE on Mac (shannon1916)
+- #15957 Show "No wallets available" in open menu instead of nothing (meshcollider)
+- #16118 Enable open wallet menu on setWalletController (promag)
+- #16135 Set progressDialog to nullptr (promag)
+- #16231 Fix open wallet menu initialization order (promag)
+- #16254 Set `AA_EnableHighDpiScaling` attribute early (hebasto)
+- #16122 Enable console line edit on setClientModel (promag)
+- #16348 Assert QMetaObject::invokeMethod result (promag)
+
+### Build system
+- #15985 Add test for GCC bug 90348 (sipa)
+- #15947 Install bitcoin-wallet manpage (domob1812)
+- #15983 build with -fstack-reuse=none (MarcoFalke)
+
+### Tests and QA
+- #15826 Pure python EC (sipa)
+- #15893 Add test for superfluous witness record in deserialization (instagibbs)
+- #14818 Bugfix: test/functional/rpc_psbt: Remove check for specific error message that depends on uncertain assumptions (luke-jr)
+- #15831 Add test that addmultisigaddress fails for watchonly addresses (MarcoFalke)
+
+### Documentation
+- #15890 Remove text about txes always relayed from -whitelist (harding)
+
+### Miscellaneous
+- #16095 Catch by reference not value in wallettool (kristapsk)
+- #16205 Replace fprintf with tfm::format (MarcoFalke)
+
+Credits
+=======
+
+Thanks to everyone who directly contributed to this release:
+
+- Andrew Chow
+- Anthony Towns
+- Chris Moore
+- Daniel Kraft
+- David A. Harding
+- fanquake
+- Gregory Sanders
+- Hennadii Stepanov
+- John Newbery
+- Jonas Schnelli
+- João Barbosa
+- Kristaps Kaupe
+- Luke Dashjr
+- MarcoFalke
+- Michele Federici
+- Pieter Wuille
+- Samuel Dobson
+- shannon1916
+- tecnovert
+- Wladimir J. van der Laan
+
+As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
diff --git a/doc/release-notes/release-notes-16152.md b/doc/release-notes/release-notes-16152.md
deleted file mode 100644
index 9c77cb9ae5..0000000000
--- a/doc/release-notes/release-notes-16152.md
+++ /dev/null
@@ -1,7 +0,0 @@
-P2P Changes
------------
-- The default value for the -peerbloomfilters configuration option (and, thus, NODE_BLOOM support) has been changed to false.
- This resolves well-known DoS vectors in Bitcoin Core, especially for nodes with spinning disks. It is not anticipated that
- this will result in a significant lack of availability of NODE_BLOOM-enabled nodes in the coming years, however, clients
- which rely on the availability of NODE_BLOOM-supporting nodes on the P2P network should consider the process of migrating
- to a more modern (and less trustful and privacy-violating) alternative over the coming years.
diff --git a/doc/translation_process.md b/doc/translation_process.md
index b9a10b6527..0e9245250f 100644
--- a/doc/translation_process.md
+++ b/doc/translation_process.md
@@ -65,13 +65,13 @@ username = USERNAME
The Transifex Bitcoin project config file is included as part of the repo. It can be found at `.tx/config`, however you shouldn’t need to change anything.
### Synchronising translations
-To assist in updating translations, we have created a script to help.
+To assist in updating translations, a helper script is available in the [maintainer-tools repo](https://github.com/bitcoin-core/bitcoin-maintainer-tools).
-1. `python contrib/devtools/update-translations.py`
+1. `python3 ../bitcoin-maintainer-tools/update-translations.py`
2. `git add` new translations from `src/qt/locale/`
3. Update `src/qt/bitcoin_locale.qrc` manually or via
```bash
-git ls-files src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/<file alias="\2">locale\/\1.qm<\/file>/'
+git ls-files src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/ <file alias="\2">locale\/\1.qm<\/file>/'
```
4. Update `src/Makefile.qt.include` manually or via
```bash
diff --git a/doc/zmq.md b/doc/zmq.md
index 7ffc5623b6..a309abd0cc 100644
--- a/doc/zmq.md
+++ b/doc/zmq.md
@@ -111,7 +111,9 @@ using other means such as firewalling.
Note that when the block chain tip changes, a reorganisation may occur
and just the tip will be notified. It is up to the subscriber to
-retrieve the chain from the last known block to the new tip.
+retrieve the chain from the last known block to the new tip. Also note
+that no notification occurs if the tip was in the active chain - this
+is the case after calling invalidateblock RPC.
There are several possibilities that ZMQ notification can get lost
during transmission depending on the communication type you are