14 files changed, 255 insertions, 69 deletions
diff --git a/doc/descriptors.md b/doc/descriptors.md
index b25678e06a..de4d4e574f 100644
--- a/doc/descriptors.md
+++ b/doc/descriptors.md
@@ -59,19 +59,20 @@ Descriptors consist of several types of expressions. The top level expression is
   - Followed by zero or more `/NUM` or `/NUM'` path elements to indicate unhardened or hardened derivation steps between the fingerprint and the key or xpub/xprv root that follows
   - A closing bracket `]`
 - Followed by the actual key, which is either:
-  - Hex encoded public keys (66 characters starting with `02` or `03`, or 130 characters starting with `04`).
+  - Hex encoded public keys (either 66 characters starting with `02` or `03` for a compressed pubkey, or 130 characters starting with `04` for an uncompressed pubkey).
     - Inside `wpkh` and `wsh`, only compressed public keys are permitted.
   - [WIF](https://en.bitcoin.it/wiki/Wallet_import_format) encoded private keys may be specified instead of the corresponding public key, with the same meaning.
-  -`xpub` encoded extended public key or `xprv` encoded private key (as defined in [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)).
+  - `xpub` encoded extended public key or `xprv` encoded extended private key (as defined in [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)).
     - Followed by zero or more `/NUM` unhardened and `/NUM'` hardened BIP32 derivation steps.
     - Optionally followed by a single `/*` or `/*'` final step to denote all (direct) unhardened or hardened children.
     - The usage of hardened derivation steps requires providing the private key.
-- Anywhere a `'` suffix is permitted to denote hardened derivation, the suffix `h` can be used instead.
+
+(Anywhere a `'` suffix is permitted to denote hardened derivation, the suffix `h` can be used instead.)
 
 `ADDR` expressions are any type of supported address:
-- P2PKH addresses (base58, of the form `1...`). Note that P2PKH addresses in descriptors cannot be used for P2PK outputs (use the `pk` function instead).
-- P2SH addresses (base58, of the form `3...`, defined in [BIP 13](https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki)).
-- Segwit addresses (bech32, of the form `bc1...`, defined in [BIP 173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)).
+- P2PKH addresses (base58, of the form `1...` for mainnet or `[nm]...` for testnet). Note that P2PKH addresses in descriptors cannot be used for P2PK outputs (use the `pk` function instead).
+- P2SH addresses (base58, of the form `3...` for mainnet or `2...` for testnet, defined in [BIP 13](https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki)).
+- Segwit addresses (bech32, of the form `bc1...` for mainnet or `tb1...` for testnet, defined in [BIP 173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)).
 
 ## Explanation
 
@@ -83,10 +84,9 @@ imaginable, though they may not be optimal: P2SH-P2PK, P2SH-P2PKH,
 P2WSH-P2PK, P2WSH-P2PKH, P2SH-P2WSH-P2PK, P2SH-P2WSH-P2PKH.
 
 To describe these, we model these as functions. The functions `pk`
-(P2PK), `pkh` (P2PKH) and `wpkh` (P2WPKH) take as input a public key in
-hexadecimal notation (which will be extended later), and return the
+(P2PK), `pkh` (P2PKH) and `wpkh` (P2WPKH) take as input a `KEY` expression, and return the
 corresponding *scriptPubKey*. The functions `sh` (P2SH) and `wsh` (P2WSH)
-take as input a script, and return the script describing P2SH and P2WSH
+take as input a `SCRIPT` expression, and return the script describing P2SH and P2WSH
 outputs with the input as embedded script. The names of the functions do
 not contain "p2" for brevity.
 
@@ -95,7 +95,7 @@ not contain "p2" for brevity.
 Several pieces of software use multi-signature (multisig) scripts based
 on Bitcoin's OP_CHECKMULTISIG opcode. To support these, we introduce the
 `multi(k,key_1,key_2,...,key_n)` function. It represents a *k-of-n*
-multisig policy, where any *k* out of the *n* provided public keys must
+multisig policy, where any *k* out of the *n* provided `KEY` expressions must
 sign.
 
 Key order is significant. A `multi()` expression describes a multisig script
@@ -138,7 +138,7 @@ Instead, it should be written as `xpub.../1/*`, where xpub corresponds to
 `m/44'/0'/0'`.
 
 When interacting with a hardware device, it may be necessary to include
-the entire path from the master down. BIP174 standardizes this by
+the entire path from the master down. [BIP174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) standardizes this by
 providing the master key *fingerprint* (first 32 bit of the Hash160 of
 the master pubkey), plus all derivation steps. To support constructing
 these, we permit providing this key origin information inside the
@@ -150,6 +150,10 @@ fingerprint plus optional derivation steps (hardened and unhardened)
 surrounded by brackets, identifying the master and derivation path the key or xpub
 that follows was derived with.
 
+Note that the fingerprint of the parent only serves as a fast way to detect
+parent and child nodes in software, and software must be willing to deal with
+collisions.
+
 ### Including private keys
 
 Often it is useful to communicate a description of scripts along with the
diff --git a/doc/developer-notes.md b/doc/developer-notes.md
index fd5cc78297..a6df17ddd8 100644
--- a/doc/developer-notes.md
+++ b/doc/developer-notes.md
@@ -28,6 +28,8 @@ Developer Notes
     - [Strings and formatting](#strings-and-formatting)
     - [Variable names](#variable-names)
     - [Threads and synchronization](#threads-and-synchronization)
+    - [Scripts](#scripts)
+        - [Shebang](#shebang)
     - [Source code organization](#source-code-organization)
     - [GUI](#gui)
     - [Subtrees](#subtrees)
@@ -602,6 +604,31 @@ TRY_LOCK(cs_vNodes, lockNodes);
 }
 ```
 
+Scripts
+--------------------------
+
+### Shebang
+
+- Use `#!/usr/bin/env bash` instead of obsolete `#!/bin/bash`.
+
+  - [*Rationale*](https://github.com/dylanaraps/pure-bash-bible#shebang):
+
+    `#!/bin/bash` assumes it is always installed to /bin/ which can cause issues;
+
+    `#!/usr/bin/env bash` searches the user's PATH to find the bash binary.
+
+  OK:
+
+```bash
+#!/usr/bin/env bash
+```
+
+  Wrong:
+
+```bash
+#!/bin/bash
+```
+
 Source code organization
 --------------------------
 
@@ -714,7 +741,7 @@ Current subtrees include:
   - Upstream at https://github.com/bitcoin-core/ctaes ; actively maintained by Core contributors.
 
 - src/univalue
-  - Upstream at https://github.com/jgarzik/univalue ; report important PRs to Core to avoid delay.
+  - Upstream at https://github.com/bitcoin-core/univalue ; actively maintained by Core contributors, deviates from upstream https://github.com/jgarzik/univalue
 
 Upgrading LevelDB
 ---------------------
@@ -827,7 +854,16 @@ 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 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.
+
+For development, it might be more convenient to verify all scripted-diffs in a range `A..B`, for example:
+
+```bash
+test/lint/commit-script-check.sh origin/master..HEAD
+```
 
 Commit [`bb81e173`](https://github.com/bitcoin/bitcoin/commit/bb81e173) is an example of a scripted-diff.
 
diff --git a/doc/release-notes-13152.md b/doc/release-notes-13152.md
deleted file mode 100644
index ace56f4d1b..0000000000
--- a/doc/release-notes-13152.md
+++ /dev/null
@@ -1,5 +0,0 @@
-New RPC methods
-------------
-
-- `getnodeaddresses` returns peer addresses known to this node. It may be used to connect to nodes over TCP without using the DNS seeds.
-- `listwalletdir` returns a list of wallets in the wallet directory which is configured with `-walletdir` parameter.
diff --git a/doc/release-notes-14023.md b/doc/release-notes-14023.md
deleted file mode 100644
index 18ea6f26d0..0000000000
--- a/doc/release-notes-14023.md
+++ /dev/null
@@ -1,8 +0,0 @@
-Account API removed
--------------------
-
-The 'account' API was deprecated in v0.17 and has been fully removed in v0.18.
-The 'label' API was introduced in v0.17 as a replacement for accounts.
-
-See the release notes from v0.17 for a full description of the changes from the
-'account' API to the 'label' API.
diff --git a/doc/release-notes-14060.md b/doc/release-notes-14060.md
new file mode 100644
index 0000000000..2cc5ab49fb
--- /dev/null
+++ b/doc/release-notes-14060.md
@@ -0,0 +1,21 @@
+Configuration
+-------------
+
+The outbound message high water mark of the ZMQ PUB sockets are now
+configurable via the options:
+
+`-zmqpubhashtxhwm=n`
+
+`-zmqpubhashblockhwm=n`
+
+`-zmqpubrawblockhwm=n`
+
+`-zmqpubrawtxhwm=n`
+
+Each high water mark value must be an integer greater than or equal to 0.
+The high water mark limits the maximum number of messages that ZMQ will
+queue in memory for any single subscriber. A value of 0 means no limit.
+When not specified, the default value continues to be 1000.
+When a ZMQ PUB socket reaches its high water mark for a subscriber, then
+additional messages to the subscriber are dropped until the number of
+queued messages again falls below the high water mark value.
diff --git a/doc/release-notes-14282.md b/doc/release-notes-14282.md
deleted file mode 100644
index 900ca04324..0000000000
--- a/doc/release-notes-14282.md
+++ /dev/null
@@ -1,9 +0,0 @@
-Low-level RPC changes
-----------------------
-
-`-usehd` was removed in version 0.16. From that version onwards, all new
-wallets created are hierarchical deterministic wallets. Version 0.18 makes
-specifying `-usehd` invalid config.
-
-`ischange` field of boolean type that shows if an address was used for change
-output was added to `getaddressinfo` method response.
diff --git a/doc/release-notes-14296.md b/doc/release-notes-14296.md
deleted file mode 100644
index f7c52baace..0000000000
--- a/doc/release-notes-14296.md
+++ /dev/null
@@ -1,5 +0,0 @@
-addwitnessaddress RPC method removed
-------------------------------------
-
-The `addwitnessaddress` RPC was added for segwit testing in version 0.13.0. It
-was deprecated in version 0.16.0. This version fully removes the RPC method.
diff --git a/doc/release-notes-14454.md b/doc/release-notes-14454.md
deleted file mode 100644
index dd2c6c7ced..0000000000
--- a/doc/release-notes-14454.md
+++ /dev/null
@@ -1,6 +0,0 @@
-Low-level RPC changes
-----------------------
-
-The `importmulti` RPC has been updated to support P2WSH, P2WPKH, P2SH-P2WPKH,
-P2SH-P2WSH. Each request now accepts an additional `witnessscript` to be used
-for P2WSH or P2SH-P2WSH.
diff --git a/doc/release-notes-14468.md b/doc/release-notes-14468.md
deleted file mode 100644
index fb0243aba8..0000000000
--- a/doc/release-notes-14468.md
+++ /dev/null
@@ -1,15 +0,0 @@
-Wallet `generate` RPC method deprecated
----------------------------------------
-
-The wallet's `generate` RPC method has been deprecated and will be fully
-removed in v0.19.
-
-`generate` is only used for testing. The RPC call reaches across multiple
-subsystems (wallet and mining), so is deprecated to simplify the wallet-node
-interface. Projects that are using `generate` for testing purposes should
-transition to using the `generatetoaddress` call, which does not require or use
-the wallet component. Calling `generatetoaddress` with an address returned by
-`getnewaddress` gives the same functionality as the old `generate` method.
-
-To continue using `generate` in v0.18, restart bitcoind with the
-`-deprecatedrpc=generate` configuration.
diff --git a/doc/release-notes-14477.md b/doc/release-notes-14477.md
new file mode 100644
index 0000000000..bb8c0a623e
--- /dev/null
+++ b/doc/release-notes-14477.md
@@ -0,0 +1,5 @@
+Miscellaneous RPC changes
+------------
+
+- `getaddressinfo` now reports `solvable`, a boolean indicating whether all information necessary for signing is present in the wallet (ignoring private keys).
+- `getaddressinfo`, `listunspent`, and `scantxoutset` have a new output field `desc`, an output descriptor that encapsulates all signing information and key paths for the address (only available when `solvable` is true for `getaddressinfo` and `listunspent`).
diff --git a/doc/release-notes-pr13381.md b/doc/release-notes-pr13381.md
new file mode 100644
index 0000000000..75faad9906
--- /dev/null
+++ b/doc/release-notes-pr13381.md
@@ -0,0 +1,29 @@
+RPC importprivkey: new label behavior
+-------------------------------------
+
+Previously, `importprivkey` automatically added the default empty label
+("") to all addresses associated with the imported private key.  Now it
+defaults to using any existing label for those addresses.  For example:
+
+- Old behavior: you import a watch-only address with the label "cold
+  wallet".  Later, you import the corresponding private key using the
+  default settings.  The address's label is changed from "cold wallet"
+  to "".
+
+- New behavior: you import a watch-only address with the label "cold
+  wallet".  Later, you import the corresponding private key using the
+  default settings.  The address's label remains "cold wallet".
+
+In both the previous and current case, if you directly specify a label
+during the import, that label will override whatever previous label the
+addresses may have had.  Also in both cases, if none of the addresses
+previously had a label, they will still receive the default empty label
+("").  Examples:
+
+- You import a watch-only address with the label "temporary".  Later you
+  import the corresponding private key with the label "final".  The
+  address's label will be changed to "final".
+
+- You use the default settings to import a private key for an address that
+  was not previously in the wallet.  Its addresses will receive the default
+  empty label ("").
diff --git a/doc/release-notes.md b/doc/release-notes.md
index 2044a50098..f5c139e3f1 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -53,8 +53,14 @@ the Linux kernel, macOS 10.10+, and Windows 7 and newer (Windows XP is not suppo
 Bitcoin Core should also work on most other Unix-like systems but is not
 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.
+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.
+
+In addition to previously-supported CPU platforms, this release's
+pre-compiled distribution also provides binaries for the RISC-V
+platform.
 
 Notable changes
 ===============
@@ -69,9 +75,137 @@ nodes. The option will now by default be off for improved privacy and security
 as well as reduced upload usage. The option can explicitly be turned on for
 local-network debugging purposes.
 
-Example item
+Documentation
+-------------
+
+- A new short
+  [document](https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md)
+  about the JSON-RPC interface describes cases where the results of an
+  RPC might contain inconsistencies between data sourced from different
+  subsystems, such as wallet state and mempool state.  A note is added
+  to the [REST interface documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md)
+  indicating that the same rules apply.
+
+- A new [document](https://github.com/bitcoin/bitcoin/blob/master/doc/bitcoin-conf.md)
+  about the `bitcoin.conf` file describes how to use it to configure
+  Bitcoin Core.
+
+- A new document introduces Bitcoin Core's BIP174
+  [Partially-Signed Bitcoin Transactions (PSBT)](https://github.com/bitcoin/bitcoin/blob/master/doc/psbt.md)
+  interface, which is used to allow multiple programs to collaboratively
+  work to create, sign, and broadcast new transactions.  This is useful
+  for offline (cold storage) wallets, multisig wallets, coinjoin
+  implementations, and many other cases where two or more programs need
+  to interact to generate a complete transaction.
+
+- The [output script descriptor](https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md)
+  documentation has been updated with information about new features in
+  this still-developing language for describing the output scripts that
+  a wallet or other program wants to receive notifications for, such as
+  which addresses it wants to know received payments.  The language is
+  currently used in the `scantxoutset` RPC and is expected to be adapted
+  to other RPCs and to the underlying wallet structure.
+
+Build system changes
+--------------------
+
+- A new `--disable-bip70` option may be passed to `./configure` to
+  prevent Bitcoin-Qt from being built with support for the BIP70 payment
+  protocol or from linking libssl.  As the payment protocol has exposed
+  Bitcoin Core to libssl vulnerabilities in the past, builders who don't
+  need BIP70 support are encouraged to use this option to reduce their
+  exposure to future vulnerabilities.
+
+Deprecated or removed RPCs
+--------------------------
+
+- The `signrawtransaction` RPC is removed after being deprecated and
+  hidden behind a special configuration option in version 0.17.0.
+
+- The 'account' API is removed after being deprecated in v0.17.  The
+  'label' API was introduced in v0.17 as a replacement for accounts.
+  See the [release notes from v0.17](https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.md#label-and-account-apis-for-wallet)
+  for a full description of the changes from the 'account' API to the
+  'label' API.
+
+- The `addwitnessaddress` RPC is removed after being deprecated in
+  version 0.13.0.
+
+- The wallet's `generate` RPC method is deprecated and will be fully
+  removed in a subsequent major version.  This RPC is only used for
+  testing, but its implementation reached across multiple subsystems
+  (wallet and mining), so it is being deprecated to simplify the
+  wallet-node interface.  Projects that are using `generate` for testing
+  purposes should transition to using the `generatetoaddress` RPC, which
+  does not require or use the wallet component. Calling
+  `generatetoaddress` with an address returned by the `getnewaddress`
+  RPC gives the same functionality as the old `generate` RPC.  To
+  continue using `generate` in this version, restart bitcoind with the
+  `-deprecatedrpc=generate` configuration option.
+
+New RPCs
+--------
+
+- A new `getnodeaddresses` RPC returns peer addresses known to this
+  node. It may be used to find nodes to connect to without using a DNS
+  seeder.
+
+- A new `listwalletdir` RPC returns a list of wallets in the wallet
+  directory (either the default wallet directory or the directory
+  configured by the `-walletdir` parameter).
+
+Updated RPCs
 ------------
 
+Note: some low-level RPC changes mainly useful for testing are described
+in the Low-level Changes section below.
+
+- The `getpeerinfo` RPC now returns an additional "minfeefilter" field
+  set to the peer's BIP133 fee filter.  You can use this to detect that
+  you have peers that are willing to accept transactions below the
+  default minimum relay fee.
+
+- The mempool RPCs, such as `getrawmempool` with `verbose=true`, now
+  return an additional "bip125-replaceable" value indicating whether the
+  transaction (or its unconfirmed ancestors) opts-in to asking nodes and
+  miners to replace it with a higher-feerate transaction spending any of
+  the same inputs.
+
+- The `settxfee` RPC previously silently ignored attempts to set the fee
+  below the allowed minimums.  It now prints a warning.  The special
+  value of "0" may still be used to request the minimum value.
+
+- The `getaddressinfo` RPC now provides an `ischange` field indicating
+  whether the wallet used the address in a change output.
+
+- The `importmulti` RPC has been updated to support P2WSH, P2WPKH,
+  P2SH-P2WPKH, and P2SH-P2WSH. Requests for P2WSH and P2SH-P2WSH accept
+  an additional `witnessscript` parameter.
+
+Low-level changes
+=================
+
+RPC
+---
+
+- The `submitblock` RPC previously returned the reason a rejected block
+  was invalid the first time it processed that block but returned a
+  generic "duplicate" rejection message on subsequent occasions it
+  processed the same block.  It now always returns the fundamental
+  reason for rejecting an invalid block and only returns "duplicate" for
+  valid blocks it has already accepted.
+
+- A new `submitheader` RPC allows submitting block headers independently
+  from their block.  This is likely only useful for testing.
+
+Configuration
+-------------
+
+- The `-usehd` configuration option was removed in version 0.16. From
+  that version onwards, all new wallets created are hierarchical
+  deterministic wallets. This release makes specifying `-usehd` an
+  invalid configuration option.
+
 Credits
 =======
 
diff --git a/doc/release-process.md b/doc/release-process.md
index f2fe44c8bf..97fedb6e24 100644
--- a/doc/release-process.md
+++ b/doc/release-process.md
@@ -6,11 +6,12 @@ Before every release candidate:
 * Update translations (ping wumpus on IRC) see [translation_process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md#synchronising-translations).
 
 * Update manpages, see [gen-manpages.sh](https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/README.md#gen-manpagessh).
+* Update release candidate version in `configure.ac` (`CLIENT_VERSION_RC`)
 
 Before every minor and major release:
 
 * Update [bips.md](bips.md) to account for changes since the last release.
-* Update version in `configure.ac` (don't forget to set `CLIENT_VERSION_IS_RELEASE` to `true`)
+* Update version in `configure.ac` (don't forget to set `CLIENT_VERSION_IS_RELEASE` to `true`) (don't forget to set `CLIENT_VERSION_RC` to `0`)
 * Write release notes (see below)
 * Update `src/chainparams.cpp` nMinimumChainWork with information from the getblockchaininfo rpc.
 * Update `src/chainparams.cpp` defaultAssumeValid with information from the getblockhash rpc.
@@ -86,7 +87,7 @@ Ensure gitian-builder is up-to-date:
     pushd ./gitian-builder
     mkdir -p inputs
     wget -P inputs https://bitcoincore.org/cfields/osslsigncode-Backports-to-1.7.1.patch
-    wget -P inputs http://downloads.sourceforge.net/project/osslsigncode/osslsigncode/osslsigncode-1.7.1.tar.gz
+    wget -P inputs https://downloads.sourceforge.net/project/osslsigncode/osslsigncode/osslsigncode-1.7.1.tar.gz
     popd
 
 Create the macOS SDK tarball, see the [macOS readme](README_osx.md) for details, and copy it into the inputs directory.
diff --git a/doc/tor.md b/doc/tor.md
index dc0b88618a..c46b7e9f60 100644
--- a/doc/tor.md
+++ b/doc/tor.md
@@ -109,9 +109,13 @@ preconfigured and the creation of a hidden service is automatic. If permission p
 are seen with `-debug=tor` they can be resolved by adding both the user running Tor and
 the user running bitcoind to the same group and setting permissions appropriately. On
 Debian-based systems the user running bitcoind can be added to the debian-tor group,
-which has the appropriate permissions. An alternative authentication method is the use
-of the `-torpassword` flag and a `hash-password` which can be enabled and specified in
-Tor configuration.
+which has the appropriate permissions.
+
+An alternative authentication method is the use
+of the `-torpassword=password` option. The `password` is the clear text form that
+was used when generating the hashed password for the `HashedControlPassword` option
+in the tor configuration file. The hashed password can be obtained with the command
+`tor --hash-password password` (read the tor manual for more details).
 
 ## 4. Privacy recommendations