aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/Doxyfile.in2
-rw-r--r--doc/README.md1
-rw-r--r--doc/build-osx.md263
-rw-r--r--doc/dependencies.md5
-rw-r--r--doc/developer-notes.md5
-rw-r--r--doc/fuzzing.md4
-rw-r--r--doc/man/bitcoin-qt.13
-rw-r--r--doc/man/bitcoind.14
-rw-r--r--doc/reduce-memory.md49
-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-15427.md9
-rw-r--r--doc/release-notes.md29
-rw-r--r--doc/release-notes/release-notes-0.12.0.md2
-rw-r--r--doc/release-process.md3
15 files changed, 275 insertions, 151 deletions
diff --git a/doc/Doxyfile.in b/doc/Doxyfile.in
index 58c65fb7e2..399d54eb85 100644
--- a/doc/Doxyfile.in
+++ b/doc/Doxyfile.in
@@ -453,7 +453,7 @@ EXTRACT_PACKAGE = NO
# included in the documentation.
# The default value is: NO.
-EXTRACT_STATIC = NO
+EXTRACT_STATIC = YES
# If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined
# locally in source files will be included in the documentation. If set to NO,
diff --git a/doc/README.md b/doc/README.md
index b4fa933c8e..d3017de2ab 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -74,6 +74,7 @@ The Bitcoin repo's [root README](/README.md) contains relevant information on th
- [bitcoin.conf Configuration File](bitcoin-conf.md)
- [Files](files.md)
- [Fuzz-testing](fuzzing.md)
+- [Reduce Memory](reduce-memory.md)
- [Reduce Traffic](reduce-traffic.md)
- [Tor Support](tor.md)
- [Init Scripts (systemd/upstart/openrc)](init.md)
diff --git a/doc/build-osx.md b/doc/build-osx.md
index d28a3d97aa..65cfce6b15 100644
--- a/doc/build-osx.md
+++ b/doc/build-osx.md
@@ -1,33 +1,37 @@
-macOS Build Instructions and Notes
-====================================
+# macOS Build Instructions and Notes
+
The commands in this guide should be executed in a Terminal application.
-The built-in one is located in `/Applications/Utilities/Terminal.app`.
+The built-in one is located in
+```
+/Applications/Utilities/Terminal.app
+```
-Preparation
------------
+## Preparation
Install the macOS command line tools:
-`xcode-select --install`
+```shell
+xcode-select --install
+```
When the popup appears, click `Install`.
Then install [Homebrew](https://brew.sh).
-Dependencies
-----------------------
-
- brew install automake berkeley-db4 libtool boost miniupnpc openssl pkg-config protobuf python qt libevent qrencode
+## Dependencies
+```shell
+brew install automake berkeley-db4 libtool boost miniupnpc openssl pkg-config protobuf python qt libevent qrencode
+```
See [dependencies.md](dependencies.md) for a complete overview.
If you want to build the disk image with `make deploy` (.dmg / optional), you need RSVG:
+```shell
+brew install librsvg
+```
- brew install librsvg
-
-Berkeley DB
------------
+## Berkeley DB
It is recommended to use Berkeley DB 4.8. If you have to build it yourself,
-you can use [the installation script included in contrib/](/contrib/install_db4.sh)
+you can use [this](/contrib/install_db4.sh) script to install it
like so:
```shell
@@ -38,172 +42,167 @@ from the root of the repository.
**Note**: You only need Berkeley DB if the wallet is enabled (see [*Disable-wallet mode*](/doc/build-osx.md#disable-wallet-mode)).
-Build Bitcoin Core
-------------------------
+## Build Bitcoin Core
1. Clone the Bitcoin Core source code:
-
- git clone https://github.com/bitcoin/bitcoin
- cd bitcoin
+ ```shell
+ git clone https://github.com/bitcoin/bitcoin
+ cd bitcoin
+ ```
2. Build Bitcoin Core:
Configure and build the headless Bitcoin Core binaries as well as the GUI (if Qt is found).
You can disable the GUI build by passing `--without-gui` to configure.
-
- ./autogen.sh
- ./configure
- make
+ ```shell
+ ./autogen.sh
+ ./configure
+ make
+ ```
3. It is recommended to build and run the unit tests:
-
- make check
-
-4. You can also create a .dmg that contains the .app bundle (optional):
-
- make deploy
-
-Disable-wallet mode
---------------------
-When the intention is to run only a P2P node without a wallet, Bitcoin Core may be compiled in
-disable-wallet mode with:
-
- ./configure --disable-wallet
+ ```shell
+ make check
+ ```
+
+4. You can also create a `.dmg` that contains the `.app` bundle (optional):
+ ```shell
+ make deploy
+ ```
+
+## `disable-wallet` mode
+When the intention is to run only a P2P node without a wallet, Bitcoin Core may be
+compiled in `disable-wallet` mode with:
+```shell
+./configure --disable-wallet
+```
In this case there is no dependency on Berkeley DB 4.8.
Mining is also possible in disable-wallet mode using the `getblocktemplate` RPC call.
-Running
--------
-
+## Running
Bitcoin Core is now available at `./src/bitcoind`
Before running, you may create an empty configuration file:
+```shell
+mkdir -p "/Users/${USER}/Library/Application Support/Bitcoin"
- mkdir -p "/Users/${USER}/Library/Application Support/Bitcoin"
-
- touch "/Users/${USER}/Library/Application Support/Bitcoin/bitcoin.conf"
+touch "/Users/${USER}/Library/Application Support/Bitcoin/bitcoin.conf"
- chmod 600 "/Users/${USER}/Library/Application Support/Bitcoin/bitcoin.conf"
+chmod 600 "/Users/${USER}/Library/Application Support/Bitcoin/bitcoin.conf"
+```
-The first time you run bitcoind, it will start downloading the blockchain. This process could take many hours, or even days on slower than average systems.
+The first time you run bitcoind, it will start downloading the blockchain. This process could
+take many hours, or even days on slower than average systems.
You can monitor the download process by looking at the debug.log file:
+```shell
+tail -f $HOME/Library/Application\ Support/Bitcoin/debug.log
+```
- tail -f $HOME/Library/Application\ Support/Bitcoin/debug.log
-
-Other commands:
--------
-
- ./src/bitcoind -daemon # Starts the bitcoin daemon.
- ./src/bitcoin-cli --help # Outputs a list of command-line options.
- ./src/bitcoin-cli help # Outputs a list of RPC commands when the daemon is running.
-
-Notes
------
-
-* Tested on OS X 10.10 Yosemite through macOS 10.13 High Sierra on 64-bit Intel processors only.
-
-* Building with downloaded Qt binaries is not officially supported. See the notes in [#7714](https://github.com/bitcoin/bitcoin/issues/7714)
+## Other commands:
+```shell
+./src/bitcoind -daemon # Starts the bitcoin daemon.
+./src/bitcoin-cli --help # Outputs a list of command-line options.
+./src/bitcoin-cli help # Outputs a list of RPC commands when the daemon is running.
+```
-Deterministic macOS DMG Notes
------------------------------
+## Notes
+* Tested on OS X 10.10 Yosemite through macOS 10.14 Mojave on 64-bit Intel
+processors only.
+* Building with downloaded Qt binaries is not officially supported. See the notes in [#7714](https://github.com/bitcoin/bitcoin/issues/7714).
-Working macOS DMGs are created in Linux by combining a recent clang,
-the Apple binutils (ld, ar, etc) and DMG authoring tools.
+## Deterministic macOS DMG Notes
+Working macOS DMGs are created in Linux by combining a recent `clang`, the Apple
+`binutils` (`ld`, `ar`, etc) and DMG authoring tools.
-Apple uses clang extensively for development and has upstreamed the necessary
-functionality so that a vanilla clang can take advantage. It supports the use
-of -F, -target, -mmacosx-version-min, and --sysroot, which are all necessary
-when building for macOS.
+Apple uses `clang` extensively for development and has upstreamed the necessary
+functionality so that a vanilla clang can take advantage. It supports the use of `-F`,
+`-target`, `-mmacosx-version-min`, and `--sysroot`, which are all necessary when
+building for macOS.
-Apple's version of binutils (called cctools) contains lots of functionality
-missing in the FSF's binutils. In addition to extra linker options for
-frameworks and sysroots, several other tools are needed as well such as
-install_name_tool, lipo, and nmedit. These do not build under linux, so they
-have been patched to do so. The work here was used as a starting point:
-[mingwandroid/toolchain4](https://github.com/mingwandroid/toolchain4).
+Apple's version of `binutils` (called `cctools`) contains lots of functionality missing in the
+FSF's `binutils`. In addition to extra linker options for frameworks and sysroots, several
+other tools are needed as well such as `install_name_tool`, `lipo`, and `nmedit`. These
+do not build under Linux, so they have been patched to do so. The work here was used as
+a starting point: [mingwandroid/toolchain4](https://github.com/mingwandroid/toolchain4).
-In order to build a working toolchain, the following source packages are needed
-from Apple: cctools, dyld, and ld64.
+In order to build a working toolchain, the following source packages are needed from
+Apple: `cctools`, `dyld`, and `ld64`.
-These tools inject timestamps by default, which produce non-deterministic
-binaries. The ZERO_AR_DATE environment variable is used to disable that.
+These tools inject timestamps by default, which produce non-deterministic binaries. The
+`ZERO_AR_DATE` environment variable is used to disable that.
-This version of cctools has been patched to use the current version of clang's
-headers and its libLTO.so rather than those from llvmgcc, as it was
-originally done in toolchain4.
+This version of `cctools` has been patched to use the current version of `clang`'s headers
+and its `libLTO.so` rather than those from `llvmgcc`, as it was originally done in `toolchain4`.
-To complicate things further, all builds must target an Apple SDK. These SDKs
-are free to download, but not redistributable.
-To obtain it, register for a developer account, then download the [Xcode 7.3.1 dmg](https://developer.apple.com/devcenter/download.action?path=/Developer_Tools/Xcode_7.3.1/Xcode_7.3.1.dmg).
+To complicate things further, all builds must target an Apple SDK. These SDKs are free to
+download, but not redistributable. To obtain it, register for an Apple Developer Account,
+then download the [Xcode 7.3.1 dmg](https://developer.apple.com/devcenter/download.action?path=/Developer_Tools/Xcode_7.3.1/Xcode_7.3.1.dmg).
-This file is several gigabytes in size, but only a single directory inside is
-needed:
+This file is several gigabytes in size, but only a single directory inside is needed:
```
Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
```
-Unfortunately, the usual linux tools (7zip, hpmount, loopback mount) are incapable of opening this file.
-To create a tarball suitable for Gitian input, there are two options:
+Unfortunately, the usual Linux tools (7zip, hpmount, loopback mount) are incapable of
+opening this file. To create a tarball suitable for Gitian input, there are two options:
-Using macOS, you can mount the dmg, and then create it with:
-```
- $ hdiutil attach Xcode_7.3.1.dmg
- $ tar -C /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -czf MacOSX10.11.sdk.tar.gz MacOSX10.11.sdk
+Using macOS, you can mount the DMG, and then create it with:
+```shell
+hdiutil attach Xcode_7.3.1.dmg
+tar -C /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -czf MacOSX10.11.sdk.tar.gz MacOSX10.11.sdk
```
-Alternatively, you can use 7zip and SleuthKit to extract the files one by one.
-The script contrib/macdeploy/extract-osx-sdk.sh automates this. First ensure
-the dmg file is in the current directory, and then run the script. You may wish
-to delete the intermediate 5.hfs file and MacOSX10.11.sdk (the directory) when
-you've confirmed the extraction succeeded.
+Alternatively, you can use 7zip and SleuthKit to extract the files one by one. The script
+[`extract-osx-sdk.sh`](./../contrib/macdeploy/extract-osx-sdk.sh) automates this. First
+ensure the DMG file is in the current directory, and then run the script. You may wish to
+delete the `intermediate 5.hfs` file and `MacOSX10.11.sdk` (the directory) when you've
+confirmed the extraction succeeded.
-```bash
+```shell
apt-get install p7zip-full sleuthkit
contrib/macdeploy/extract-osx-sdk.sh
rm -rf 5.hfs MacOSX10.11.sdk
```
-The Gitian descriptors build 2 sets of files: Linux tools, then Apple binaries
-which are created using these tools. The build process has been designed to
-avoid including the SDK's files in Gitian's outputs. All interim tarballs are
-fully deterministic and may be freely redistributed.
+The Gitian descriptors build 2 sets of files: Linux tools, then Apple binaries which are
+created using these tools. The build process has been designed to avoid including the
+SDK's files in Gitian's outputs. All interim tarballs are fully deterministic and may be freely
+redistributed.
-genisoimage is used to create the initial DMG. It is not deterministic as-is,
-so it has been patched. A system genisoimage will work fine, but it will not
-be deterministic because the file-order will change between invocations.
-The patch can be seen here: [theuni/osx-cross-depends](https://raw.githubusercontent.com/theuni/osx-cross-depends/master/patches/cdrtools/genisoimage.diff).
-No effort was made to fix this cleanly, so it likely leaks memory badly. But
-it's only used for a single invocation, so that's no real concern.
+`genisoimage` is used to create the initial DMG. It is not deterministic as-is, so it has been
+patched. A system `genisoimage` will work fine, but it will not be deterministic because
+the file-order will change between invocations. The patch can be seen here: [theuni/osx-cross-depends](https://raw.githubusercontent.com/theuni/osx-cross-depends/master/patches/cdrtools/genisoimage.diff).
+No effort was made to fix this cleanly, so it likely leaks memory badly. But it's only used for
+a single invocation, so that's no real concern.
-genisoimage cannot compress DMGs, so afterwards, the 'dmg' tool from the
-libdmg-hfsplus project is used to compress it. There are several bugs in this
-tool and its maintainer has seemingly abandoned the project. It has been forked
-and is available (with fixes) here: [theuni/libdmg-hfsplus](https://github.com/theuni/libdmg-hfsplus).
+`genisoimage` cannot compress DMGs, so afterwards, the DMG tool from the
+`libdmg-hfsplus` project is used to compress it. There are several bugs in this tool and its
+maintainer has seemingly abandoned the project. It has been forked and is available
+(with fixes) here: [theuni/libdmg-hfsplus](https://github.com/theuni/libdmg-hfsplus).
-The 'dmg' tool has the ability to create DMGs from scratch as well, but this
-functionality is broken. Only the compression feature is currently used.
-Ideally, the creation could be fixed and genisoimage would no longer be necessary.
+The DMG tool has the ability to create DMGs from scratch as well, but this functionality is
+broken. Only the compression feature is currently used. Ideally, the creation could be fixed
+and `genisoimage` would no longer be necessary.
Background images and other features can be added to DMG files by inserting a
-.DS_Store before creation. This is generated by the script
-contrib/macdeploy/custom_dsstore.py.
-
-As of OS X 10.9 Mavericks, using an Apple-blessed key to sign binaries is a
-requirement in order to satisfy the new Gatekeeper requirements. Because this
-private key cannot be shared, we'll have to be a bit creative in order for the
-build process to remain somewhat deterministic. Here's how it works:
-
-- Builders use Gitian to create an unsigned release. This outputs an unsigned
- dmg which users may choose to bless and run. It also outputs an unsigned app
- structure in the form of a tarball, which also contains all of the tools
- that have been previously (deterministically) built in order to create a
- final dmg.
-- The Apple keyholder uses this unsigned app to create a detached signature,
- using the script that is also included there. Detached signatures are available from this [repository](https://github.com/bitcoin-core/bitcoin-detached-sigs).
-- Builders feed the unsigned app + detached signature back into Gitian. It
- uses the pre-built tools to recombine the pieces into a deterministic dmg.
+`.DS_Store` before creation. This is generated by the script
+`contrib/macdeploy/custom_dsstore.py`.
+
+As of OS X 10.9 Mavericks, using an Apple-blessed key to sign binaries is a requirement in
+order to satisfy the new Gatekeeper requirements. Because this private key cannot be
+shared, we'll have to be a bit creative in order for the build process to remain somewhat
+deterministic. Here's how it works:
+
+- Builders use Gitian to create an unsigned release. This outputs an unsigned DMG which
+ users may choose to bless and run. It also outputs an unsigned app structure in the form
+ of a tarball, which also contains all of the tools that have been previously (deterministically)
+ built in order to create a final DMG.
+- The Apple keyholder uses this unsigned app to create a detached signature, using the
+ script that is also included there. Detached signatures are available from this [repository](https://github.com/bitcoin-core/bitcoin-detached-sigs).
+- Builders feed the unsigned app + detached signature back into Gitian. It uses the
+ pre-built tools to recombine the pieces into a deterministic DMG.
diff --git a/doc/dependencies.md b/doc/dependencies.md
index 1b3df62867..c9c6a93c01 100644
--- a/doc/dependencies.md
+++ b/doc/dependencies.md
@@ -6,10 +6,9 @@ These are the dependencies currently used by Bitcoin Core. You can find instruct
| Dependency | Version used | Minimum required | CVEs | Shared | [Bundled Qt library](https://doc.qt.io/qt-5/configure-options.html#third-party-libraries) |
| --- | --- | --- | --- | --- | --- |
| Berkeley DB | [4.8.30](https://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index.html) | 4.8.x | No | | |
-| Boost | [1.64.0](https://www.boost.org/users/download/) | [1.47.0](https://github.com/bitcoin/bitcoin/pull/8920) | 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) | | | |
-| D-Bus | [1.10.18](https://cgit.freedesktop.org/dbus/dbus/tree/NEWS?h=dbus-1.10) | | No | Yes | |
-| Expat | [2.2.6](https://libexpat.github.io/) | | No | Yes | |
+| 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) | | | |
diff --git a/doc/developer-notes.md b/doc/developer-notes.md
index 45e55b7c40..39463dc6f8 100644
--- a/doc/developer-notes.md
+++ b/doc/developer-notes.md
@@ -34,7 +34,6 @@ Developer Notes
- [Source code organization](#source-code-organization)
- [GUI](#gui)
- [Subtrees](#subtrees)
- - [Git and GitHub tips](#git-and-github-tips)
- [Scripted diffs](#scripted-diffs)
- [Release notes](#release-notes)
- [RPC interface guidelines](#rpc-interface-guidelines)
@@ -280,7 +279,7 @@ thread](https://askubuntu.com/questions/50145/how-to-install-perf-monitoring-too
for specific instructions.
Certain kernel parameters may need to be set for perf to be able to inspect the
-running process' stack.
+running process's stack.
```sh
$ sudo sysctl -w kernel.perf_event_paranoid=-1
@@ -376,7 +375,7 @@ reported in the debug.log file.
Re-architecting the core code so there are better-defined interfaces
between the various components is a goal, with any necessary locking
-done by the components (e.g. see the self-contained `CBasicKeyStore` class
+done by the components (e.g. see the self-contained `FillableSigningProvider` class
and its `cs_KeyStore` lock for example).
Threads
diff --git a/doc/fuzzing.md b/doc/fuzzing.md
index f9221dde5b..3dc6be8b86 100644
--- a/doc/fuzzing.md
+++ b/doc/fuzzing.md
@@ -46,7 +46,7 @@ export AFLPATH=$PWD
To build Bitcoin Core using AFL instrumentation (this assumes that the
`AFLPATH` was set as above):
```
-./configure --disable-ccache --disable-shared --enable-tests --enable-fuzz --disable-wallet --disable-bench --with-utils=no --with-daemon=no --with-libs=no --with-gui=no CC=${AFLPATH}/afl-gcc CXX=${AFLPATH}/afl-g++
+./configure --disable-ccache --disable-shared --enable-tests --enable-fuzz CC=${AFLPATH}/afl-gcc CXX=${AFLPATH}/afl-g++
export AFL_HARDEN=1
cd src/
make
@@ -83,7 +83,7 @@ found in the `compiler-rt` runtime libraries package).
To build all fuzz targets with libFuzzer, run
```
-./configure --disable-ccache --disable-wallet --disable-bench --with-utils=no --with-daemon=no --with-libs=no --with-gui=no --enable-fuzz --with-sanitizers=fuzzer,address CC=clang CXX=clang++
+./configure --disable-ccache --enable-fuzz --with-sanitizers=fuzzer,address CC=clang CXX=clang++
make
```
diff --git a/doc/man/bitcoin-qt.1 b/doc/man/bitcoin-qt.1
index 052d420608..1e8443b1d3 100644
--- a/doc/man/bitcoin-qt.1
+++ b/doc/man/bitcoin-qt.1
@@ -488,9 +488,6 @@ Relay and mine data carrier transactions (default: 1)
Maximum size of data in data carrier transactions we relay and mine
(default: 83)
.HP
-\fB\-mempoolreplacement\fR
-.IP
-Enable transaction replacement in the memory pool (default: 1)
.HP
\fB\-minrelaytxfee=\fR<amt>
.IP
diff --git a/doc/man/bitcoind.1 b/doc/man/bitcoind.1
index 5e057d923f..2a79b6cb46 100644
--- a/doc/man/bitcoind.1
+++ b/doc/man/bitcoind.1
@@ -488,10 +488,6 @@ Relay and mine data carrier transactions (default: 1)
Maximum size of data in data carrier transactions we relay and mine
(default: 83)
.HP
-\fB\-mempoolreplacement\fR
-.IP
-Enable transaction replacement in the memory pool (default: 1)
-.HP
\fB\-minrelaytxfee=\fR<amt>
.IP
Fees (in BTC/kB) smaller than this are considered zero fee for relaying,
diff --git a/doc/reduce-memory.md b/doc/reduce-memory.md
new file mode 100644
index 0000000000..8d8ccdfedc
--- /dev/null
+++ b/doc/reduce-memory.md
@@ -0,0 +1,49 @@
+# Reduce Memory
+
+There are a few parameters that can be dialed down to reduce the memory usage of `bitcoind`. This can be useful on embedded systems or small VPSes.
+
+## In-memory caches
+
+The size of some in-memory caches can be reduced. As caches trade off memory usage for performance, reducing these will usually have a negative effect on performance.
+
+- `-dbcache=<n>` - the UTXO database cache size, this defaults to `450`. The unit is MiB (1024).
+ - The minimum value for `-dbcache` is 4.
+ - A lower `-dbcache` makes initial sync time much longer. After the initial sync, the effect is less pronounced for most use-cases, unless fast validation of blocks is important, such as for mining.
+
+## Memory pool
+
+- In Bitcoin Core there is a memory pool limiter which can be configured with `-maxmempool=<n>`, where `<n>` is the size in MB (1000). The default value is `300`.
+ - The minimum value for `-maxmempool` is 5.
+ - A lower maximum mempool size means that transactions will be evicted sooner. This will affect any uses of `bitcoind` that process unconfirmed transactions.
+
+- To completely disable mempool functionality there is the option `-blocksonly`. This will make the client opt out of receiving (and thus relaying) transactions completely, except as part of blocks.
+
+ - Do not use this when using the client to broadcast transactions as any transaction sent will stick out like a sore thumb, affecting privacy. When used with the wallet it should be combined with `-walletbroadcast=0` and `-spendzeroconfchange=0`. Another mechanism for broadcasting outgoing transactions (if any) should be used.
+
+- Since `0.14.0`, unused memory allocated to the mempool (default: 300MB) is shared with the UTXO cache, so when trying to reduce memory usage you should limit the mempool, with the `-maxmempool` command line argument.
+
+## Number of peers
+
+- `-maxconnections=<n>` - the maximum number of connections, this defaults to `125`. Each active connection takes up some memory. Only significant if incoming
+ connections are enabled, otherwise the number of connections will never be more than `8`.
+
+## Thread configuration
+
+For each thread a thread stack needs to be allocated. By default on Linux,
+threads take up 8MiB for the thread stack on a 64-bit system, and 4MiB in a
+32-bit system.
+
+- `-par=<n>` - the number of script verification threads, defaults to the number of cores in the system minus one.
+- `-rpcthreads=<n>` - the number of threads used for processing RPC requests, defaults to `4`.
+
+## 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:
+
+```bash
+#!/bin/bash
+export MALLOC_ARENA_MAX=1
+bitcoind
+```
+
+The behavior was introduced to increase CPU locality of allocated memory and performance with concurrent allocation, so this setting could in theory reduce performance. However, in Bitcoin Core very little parallel allocation happens, so the impact is expected to be small or absent.
diff --git a/doc/release-notes-0.18.1-16257.md b/doc/release-notes-0.18.1-16257.md
new file mode 100644
index 0000000000..21867b7fb2
--- /dev/null
+++ b/doc/release-notes-0.18.1-16257.md
@@ -0,0 +1,6 @@
+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
new file mode 100644
index 0000000000..a500aceb0f
--- /dev/null
+++ b/doc/release-notes-13756.md
@@ -0,0 +1,41 @@
+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-15427.md b/doc/release-notes-15427.md
new file mode 100644
index 0000000000..25edfd4402
--- /dev/null
+++ b/doc/release-notes-15427.md
@@ -0,0 +1,9 @@
+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.md b/doc/release-notes.md
index 4a86469ccf..83c84d34c9 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -90,7 +90,7 @@ 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
+- 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
@@ -103,14 +103,39 @@ Low-level Changes section below.
Low-level changes
=================
+RPC
+---
+
+
+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.
+
Configuration
------------
-* An error is issued where previously a warning was issued when a setting in
+- 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.
+Network
+-------
+
+- When fetching a transaction announced by multiple peers, previous versions of
+ Bitcoin Core would sequentially attempt to download the transaction from each
+ announcing peer until the transaction is received, in the order that those
+ 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.
+
Wallet
------
diff --git a/doc/release-notes/release-notes-0.12.0.md b/doc/release-notes/release-notes-0.12.0.md
index cf74a17975..bc0d5ea3b0 100644
--- a/doc/release-notes/release-notes-0.12.0.md
+++ b/doc/release-notes/release-notes-0.12.0.md
@@ -127,7 +127,7 @@ minimum relay feerate. The initial minimum relay feerate is set to
Bitcoin Core 0.12 also introduces new default policy limits on the length and
size of unconfirmed transaction chains that are allowed in the mempool
(generally limiting the length of unconfirmed chains to 25 transactions, with a
-total size of 101 KB). These limits can be overriden using command line
+total size of 101 KB). These limits can be overridden using command line
arguments; see the extended help (`--help -help-debug`) for more information.
Opt-in Replace-by-fee transactions
diff --git a/doc/release-process.md b/doc/release-process.md
index 2e712bf58e..480b09ee11 100644
--- a/doc/release-process.md
+++ b/doc/release-process.md
@@ -323,6 +323,9 @@ bitcoin.org (see below for bitcoin.org update instructions).
- bitcoincore.org blog post
+ - bitcoincore.org maintained versions update:
+ [table](https://github.com/bitcoin-core/bitcoincore.org/commits/master/_includes/posts/maintenance-table.md)
+
- bitcoincore.org RPC documentation update
- Update packaging repo