10 files changed, 414 insertions, 238 deletions
diff --git a/doc/README.md b/doc/README.md
index 4dd21c4620..19d8204d83 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -30,7 +30,7 @@ Drag Bitcoin Core to your applications folder, and then run Bitcoin Core.
 
 * See the documentation at the [Bitcoin Wiki](https://en.bitcoin.it/wiki/Main_Page)
 for help and more information.
-* Ask for help on [#bitcoin](http://webchat.freenode.net?channels=bitcoin) on Freenode. If you don't have an IRC client, use [webchat here](http://webchat.freenode.net?channels=bitcoin).
+* Ask for help on [#bitcoin](https://webchat.freenode.net/#bitcoin) on Freenode. If you don't have an IRC client, use [webchat here](https://webchat.freenode.net/#bitcoin).
 * Ask for help on the [BitcoinTalk](https://bitcointalk.org/) forums, in the [Technical Support board](https://bitcointalk.org/index.php?board=4.0).
 
 Building
@@ -66,8 +66,8 @@ The Bitcoin repo's [root README](/README.md) contains relevant information on th
 
 ### Resources
 * Discuss on the [BitcoinTalk](https://bitcointalk.org/) forums, in the [Development & Technical Discussion board](https://bitcointalk.org/index.php?board=6.0).
-* Discuss project-specific development on #bitcoin-core-dev on Freenode. If you don't have an IRC client, use [webchat here](http://webchat.freenode.net/?channels=bitcoin-core-dev).
-* Discuss general Bitcoin development on #bitcoin-dev on Freenode. If you don't have an IRC client, use [webchat here](http://webchat.freenode.net/?channels=bitcoin-dev).
+* Discuss project-specific development on #bitcoin-core-dev on Freenode. If you don't have an IRC client, use [webchat here](https://webchat.freenode.net/#bitcoin-core-dev).
+* Discuss general Bitcoin development on #bitcoin-dev on Freenode. If you don't have an IRC client, use [webchat here](https://webchat.freenode.net/#bitcoin-dev).
 
 ### Miscellaneous
 - [Assets Attribution](assets-attribution.md)
diff --git a/doc/dependencies.md b/doc/dependencies.md
index 51a2240107..0cb5311e8b 100644
--- a/doc/dependencies.md
+++ b/doc/dependencies.md
@@ -13,7 +13,7 @@ These are the dependencies currently used by Bitcoin Core. You can find instruct
 | FreeType | [2.7.1](https://download.savannah.gnu.org/releases/freetype) |  | No |  | [Yes](https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk) (Android only) |
 | GCC |  | [4.8+](https://gcc.gnu.org/) (C++11 support) |  |  |  |
 | HarfBuzz-NG |  |  |  |  | [Yes](https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk) |
-| libevent | [2.1.11-stable](https://github.com/libevent/libevent/releases) | 2.0.22 | No |  |  |
+| libevent | [2.1.11-stable](https://github.com/libevent/libevent/releases) | [2.0.21](https://github.com/bitcoin/bitcoin/pull/18676) | No |  |  |
 | libpng |  |  |  |  | [Yes](https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk) |
 | librsvg | |  |  |  |  |
 | MiniUPnPc | [2.0.20180203](https://miniupnp.tuxfamily.org/files) |  | No |  |  |
diff --git a/doc/developer-notes.md b/doc/developer-notes.md
index 6e8bde47f8..b33b3ad18a 100644
--- a/doc/developer-notes.md
+++ b/doc/developer-notes.md
@@ -43,6 +43,7 @@ Developer Notes
         - [Suggestions and examples](#suggestions-and-examples)
     - [Release notes](#release-notes)
     - [RPC interface guidelines](#rpc-interface-guidelines)
+    - [Internal interface guidelines](#internal-interface-guidelines)
 
 <!-- markdown-toc end -->
 
@@ -422,27 +423,52 @@ and its `cs_KeyStore` lock for example).
 Threads
 -------
 
-- ThreadScriptCheck : Verifies block scripts.
+- [Main thread (`bitcoind`)](https://doxygen.bitcoincore.org/bitcoind_8cpp.html#a0ddf1224851353fc92bfbff6f499fa97)
+  : Started from `main()` in `bitcoind.cpp`. Responsible for starting up and
+  shutting down the application.
 
-- ThreadImport : Loads blocks from `blk*.dat` files or `-loadblock=<file>`.
+- [ThreadImport (`b-loadblk`)](https://doxygen.bitcoincore.org/init_8cpp.html#ae9e290a0e829ec0198518de2eda579d1)
+  : Loads blocks from `blk*.dat` files or `-loadblock=<file>` on startup.
 
-- ThreadDNSAddressSeed : Loads addresses of peers from the DNS.
+- [ThreadScriptCheck (`b-scriptch.x`)](https://doxygen.bitcoincore.org/validation_8cpp.html#a925a33e7952a157922b0bbb8dab29a20)
+  : Parallel script validation threads for transactions in blocks.
 
-- ThreadMapPort : Universal plug-and-play startup/shutdown.
+- [ThreadHTTP (`b-http`)](https://doxygen.bitcoincore.org/httpserver_8cpp.html#abb9f6ea8819672bd9a62d3695070709c)
+  : Libevent thread to listen for RPC and REST connections.
 
-- ThreadSocketHandler : Sends/Receives data from peers on port 8333.
+- [HTTP worker threads(`b-httpworker.x`)](https://doxygen.bitcoincore.org/httpserver_8cpp.html#aa6a7bc27265043bc0193220c5ae3a55f)
+  : Threads to service RPC and REST requests.
 
-- ThreadOpenAddedConnections : Opens network connections to added nodes.
+- [Indexer threads (`b-txindex`, etc)](https://doxygen.bitcoincore.org/class_base_index.html#a96a7407421fbf877509248bbe64f8d87)
+  : One thread per indexer.
 
-- ThreadOpenConnections : Initiates new connections to peers.
+- [SchedulerThread (`b-scheduler`)](https://doxygen.bitcoincore.org/class_c_scheduler.html#a14d2800815da93577858ea078aed1fba)
+  : Does asynchronous background tasks like dumping wallet contents, dumping
+  addrman and running asynchronous validationinterface callbacks.
 
-- ThreadMessageHandler : Higher-level message handling (sending and receiving).
+- [TorControlThread (`b-torcontrol`)](https://doxygen.bitcoincore.org/torcontrol_8cpp.html#a4faed3692d57a0d7bdbecf3b37f72de0)
+  : Libevent thread for tor connections.
 
-- DumpAddresses : Dumps IP addresses of nodes to `peers.dat`.
+- Net threads:
 
-- ThreadRPCServer : Remote procedure call handler, listens on port 8332 for connections and services them.
+  - [ThreadMessageHandler (`b-msghand`)](https://doxygen.bitcoincore.org/class_c_connman.html#aacdbb7148575a31bb33bc345e2bf22a9)
+    : Application level message handling (sending and receiving). Almost
+    all net_processing and validation logic runs on this thread.
 
-- Shutdown : Does an orderly shutdown of everything.
+  - [ThreadDNSAddressSeed (`b-dnsseed`)](https://doxygen.bitcoincore.org/class_c_connman.html#aa7c6970ed98a4a7bafbc071d24897d13)
+    : Loads addresses of peers from the DNS.
+
+  - [ThreadMapPort (`b-upnp`)](https://doxygen.bitcoincore.org/net_8cpp.html#a63f82a71c4169290c2db1651a9bbe249)
+    : Universal plug-and-play startup/shutdown.
+
+  - [ThreadSocketHandler (`b-net`)](https://doxygen.bitcoincore.org/class_c_connman.html#a765597cbfe99c083d8fa3d61bb464e34)
+    : Sends/Receives data from peers on port 8333.
+
+  - [ThreadOpenAddedConnections (`b-addcon`)](https://doxygen.bitcoincore.org/class_c_connman.html#a0b787caf95e52a346a2b31a580d60a62)
+    : Opens network connections to added nodes.
+
+  - [ThreadOpenConnections (`b-opencon`)](https://doxygen.bitcoincore.org/class_c_connman.html#a55e9feafc3bab78e5c9d408c207faa45)
+    : Initiates new connections to peers.
 
 Ignoring IDE/editor files
 --------------------------
@@ -964,7 +990,7 @@ Some good examples of scripted-diff:
 - [scripted-diff: Rename InitInterfaces to NodeContext](https://github.com/bitcoin/bitcoin/commit/301bd41a2e6765b185bd55f4c541f9e27aeea29d)
 uses an elegant script to replace occurrences of multiple terms in all source files.
 
-- [scripted-diff: Remove g_connman, g_banman globals](https://github.com/bitcoin/bitcoin/commit/301bd41a2e6765b185bd55f4c541f9e27aeea29d)
+- [scripted-diff: Remove g_connman, g_banman globals](https://github.com/bitcoin/bitcoin/commit/8922d7f6b751a3e6b3b9f6fb7961c442877fb65a)
 replaces specific terms in a list of specific source files.
 
 - [scripted-diff: Replace fprintf with tfm::format](https://github.com/bitcoin/bitcoin/commit/fac03ec43a15ad547161e37e53ea82482cc508f9)
@@ -1100,3 +1126,124 @@ A few guidelines for introducing and reviewing new RPC interfaces:
   timestamps in the documentation.
 
   - *Rationale*: User-facing consistency.
+
+Internal interface guidelines
+-----------------------------
+
+Internal interfaces between parts of the codebase that are meant to be
+independent (node, wallet, GUI), are defined in
+[`src/interfaces/`](../src/interfaces/). The main interface classes defined
+there are [`interfaces::Chain`](../src/interfaces/chain.h), used by wallet to
+access the node's latest chain state,
+[`interfaces::Node`](../src/interfaces/node.h), used by the GUI to control the
+node, and [`interfaces::Wallet`](../src/interfaces/wallet.h), used by the GUI
+to control an individual wallet. There are also more specialized interface
+types like [`interfaces::Handler`](../src/interfaces/handler.h)
+[`interfaces::ChainClient`](../src/interfaces/chain.h) passed to and from
+various interface methods.
+
+Interface classes are written in a particular style so node, wallet, and GUI
+code doesn't need to run in the same process, and so the class declarations
+work more easily with tools and libraries supporting interprocess
+communication:
+
+- Interface classes should be abstract and have methods that are [pure
+  virtual](https://en.cppreference.com/w/cpp/language/abstract_class). This
+  allows multiple implementations to inherit from the same interface class,
+  particularly so one implementation can execute functionality in the local
+  process, and other implementations can forward calls to remote processes.
+
+- Interface method definitions should wrap existing functionality instead of
+  implementing new functionality. Any substantial new node or wallet
+  functionality should be implemented in [`src/node/`](../src/node/) or
+  [`src/wallet/`](../src/wallet/) and just exposed in
+  [`src/interfaces/`](../src/interfaces/) instead of being implemented there,
+  so it can be more modular and accessible to unit tests.
+
+- Interface method parameter and return types should either be serializable or
+  be other interface classes. Interface methods shouldn't pass references to
+  objects that can't be serialized or accessed from another process.
+
+  Examples:
+
+  ```c++
+  // Good: takes string argument and returns interface class pointer
+  virtual unique_ptr<interfaces::Wallet> loadWallet(std::string filename) = 0;
+
+  // Bad: returns CWallet reference that can't be used from another process
+  virtual CWallet& loadWallet(std::string filename) = 0;
+  ```
+
+  ```c++
+  // Good: accepts and returns primitive types
+  virtual bool findBlock(const uint256& hash, int& out_height, int64_t& out_time) = 0;
+
+  // Bad: returns pointer to internal node in a linked list inaccessible to
+  // other processes
+  virtual const CBlockIndex* findBlock(const uint256& hash) = 0;
+  ```
+
+  ```c++
+  // Good: takes plain callback type and returns interface pointer
+  using TipChangedFn = std::function<void(int block_height, int64_t block_time)>;
+  virtual std::unique_ptr<interfaces::Handler> handleTipChanged(TipChangedFn fn) = 0;
+
+  // Bad: returns boost connection specific to local process
+  using TipChangedFn = std::function<void(int block_height, int64_t block_time)>;
+  virtual boost::signals2::scoped_connection connectTipChanged(TipChangedFn fn) = 0;
+  ```
+
+- For consistency and friendliness to code generation tools, interface method
+  input and inout parameters should be ordered first and output parameters
+  should come last.
+
+  Example:
+
+  ```c++
+  // Good: error output param is last
+  virtual bool broadcastTransaction(const CTransactionRef& tx, CAmount max_fee, std::string& error) = 0;
+
+  // Bad: error output param is between input params
+  virtual bool broadcastTransaction(const CTransactionRef& tx, std::string& error, CAmount max_fee) = 0;
+  ```
+
+- For friendliness to code generation tools, interface methods should not be
+  overloaded:
+
+  Example:
+
+  ```c++
+  // Good: method names are unique
+  virtual bool disconnectByAddress(const CNetAddr& net_addr) = 0;
+  virtual bool disconnectById(NodeId id) = 0;
+
+  // Bad: methods are overloaded by type
+  virtual bool disconnect(const CNetAddr& net_addr) = 0;
+  virtual bool disconnect(NodeId id) = 0;
+  ```
+
+- For consistency and friendliness to code generation tools, interface method
+  names should be `lowerCamelCase` and standalone function names should be
+  `UpperCamelCase`.
+
+  Examples:
+
+  ```c++
+  // Good: lowerCamelCase method name
+  virtual void blockConnected(const CBlock& block, int height) = 0;
+
+  // Bad: uppercase class method
+  virtual void BlockConnected(const CBlock& block, int height) = 0;
+  ```
+
+  ```c++
+  // Good: UpperCamelCase standalone function name
+  std::unique_ptr<Node> MakeNode(LocalInit& init);
+
+  // Bad: lowercase standalone function
+  std::unique_ptr<Node> makeNode(LocalInit& init);
+  ```
+
+  Note: This last convention isn't generally followed outside of
+  [`src/interfaces/`](../src/interfaces/), though it did come up for discussion
+  before in [#14635](https://github.com/bitcoin/bitcoin/pull/14635).
diff --git a/doc/fuzzing.md b/doc/fuzzing.md
index af82371d58..9642337821 100644
--- a/doc/fuzzing.md
+++ b/doc/fuzzing.md
@@ -1,125 +1,93 @@
-Fuzz-testing Bitcoin Core
-==========================
-
-A special test harness in `src/test/fuzz/` is provided for each fuzz target to
-provide an easy entry point for fuzzers and the like. In this document we'll
-describe how to use it with AFL and libFuzzer.
-
-## Preparing fuzzing
-
-The fuzzer needs some inputs to work on, but the inputs or seeds can be used
-interchangeably between libFuzzer and AFL.
-
-Extract the example seeds (or other starting inputs) into the inputs
-directory before starting fuzzing.
-
-```
-git clone https://github.com/bitcoin-core/qa-assets
-export DIR_FUZZ_IN=$PWD/qa-assets/fuzz_seed_corpus
-```
-
-AFL needs an input directory with examples, and an output directory where it
-will place examples that it found. These can be anywhere in the file system,
-we'll define environment variables to make it easy to reference them.
-
-So, only for AFL you need to configure the outputs path:
-
-```
-mkdir outputs
-export AFLOUT=$PWD/outputs
-```
-
-libFuzzer will use the input directory as output directory.
-
-## AFL
-
-### Building AFL
-
-It is recommended to always use the latest version of afl:
-```
-wget http://lcamtuf.coredump.cx/afl/releases/afl-latest.tgz
-tar -zxvf afl-latest.tgz
-cd afl-<version>
-make
-export AFLPATH=$PWD
-```
-
-For macOS you may need to ignore x86 compilation checks when running `make`:
-`AFL_NO_X86=1 make`.
-
-### Instrumentation
-
-To build Bitcoin Core using AFL instrumentation (this assumes that the
-`AFLPATH` was set as above):
-```
-./configure --disable-shared --enable-tests --enable-fuzz CC=${AFLPATH}/afl-gcc CXX=${AFLPATH}/afl-g++
-export AFL_HARDEN=1
-make
-```
-
-If you are using clang you will need to substitute `afl-gcc` with `afl-clang`
-and `afl-g++` with `afl-clang++`, so the first line above becomes:
-```
-./configure --disable-shared --enable-tests --enable-fuzz CC=${AFLPATH}/afl-clang CXX=${AFLPATH}/afl-clang++
-```
-
-We disable ccache because we don't want to pollute the ccache with instrumented
-objects, and similarly don't want to use non-instrumented cached objects linked
-in.
-
-The fuzzing can be sped up significantly (~200x) by using `afl-clang-fast` and
-`afl-clang-fast++` in place of `afl-gcc` and `afl-g++` when compiling. When
-compiling using `afl-clang-fast`/`afl-clang-fast++` the resulting
-binary will be instrumented in such a way that the AFL
-features "persistent mode" and "deferred forkserver" can be used. See
-https://github.com/google/AFL/tree/master/llvm_mode for details.
-
-### Fuzzing
-
-To start the actual fuzzing use:
-
-```
-export FUZZ_TARGET=bech32  # Pick a fuzz_target
-mkdir ${AFLOUT}/${FUZZ_TARGET}
-$AFLPATH/afl-fuzz -i ${DIR_FUZZ_IN}/${FUZZ_TARGET} -o ${AFLOUT}/${FUZZ_TARGET} -m52 -- src/test/fuzz/${FUZZ_TARGET}
-```
-
-You may have to change a few kernel parameters to test optimally - `afl-fuzz`
-will print an error and suggestion if so.
-
-On macOS you may need to set `AFL_NO_FORKSRV=1` to get the target to run.
-```
-export FUZZ_TARGET=bech32  # Pick a fuzz_target
-mkdir ${AFLOUT}/${FUZZ_TARGET}
-AFL_NO_FORKSRV=1 $AFLPATH/afl-fuzz -i ${DIR_FUZZ_IN}/${FUZZ_TARGET} -o ${AFLOUT}/${FUZZ_TARGET} -m52 -- src/test/fuzz/${FUZZ_TARGET}
-```
-
-## libFuzzer
-
-A recent version of `clang`, the address/undefined sanitizers (ASan/UBSan) and
-libFuzzer is needed (all found in the `compiler-rt` runtime libraries package).
-
-To build all fuzz targets with libFuzzer, run
-
-```
-./configure --enable-fuzz --with-sanitizers=fuzzer,address,undefined CC=clang CXX=clang++
-make
-```
-
-See https://llvm.org/docs/LibFuzzer.html#running on how to run the libFuzzer
-instrumented executable.
-
-Alternatively, you can run the script through the fuzzing test harness (only
-libFuzzer supported so far). You need to pass it the inputs directory and
-the specific test target you want to run.
-
-```
-./test/fuzz/test_runner.py ${DIR_FUZZ_IN} bech32
-```
-
-### macOS hints for libFuzzer
-
-The default clang/llvm version supplied by Apple on macOS does not include
+# Fuzzing Bitcoin Core using libFuzzer
+
+## Quickstart guide
+
+To quickly get started fuzzing Bitcoin Core using [libFuzzer](https://llvm.org/docs/LibFuzzer.html):
+
+```sh
+$ git clone https://github.com/bitcoin/bitcoin
+$ cd bitcoin/
+$ ./autogen.sh
+$ CC=clang CXX=clang++ ./configure --enable-fuzz --with-sanitizers=address,fuzzer,undefined
+# macOS users: If you have problem with this step then make sure to read "macOS hints for
+# libFuzzer" on https://github.com/bitcoin/bitcoin/blob/master/doc/fuzzing.md#macos-hints-for-libfuzzer
+$ make
+$ src/test/fuzz/process_message
+# abort fuzzing using ctrl-c
+```
+
+## Fuzzing harnesses, fuzzing output and fuzzing corpora
+
+[`process_message`](https://github.com/bitcoin/bitcoin/blob/master/src/test/fuzz/process_message.cpp) is a fuzzing harness for the [`ProcessMessage(...)` function (`net_processing`)](https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp). The available fuzzing harnesses are found in [`src/test/fuzz/`](https://github.com/bitcoin/bitcoin/tree/master/src/test/fuzz).
+
+The fuzzer will output `NEW` every time it has created a test input that covers new areas of the code under test. For more information on how to interpret the fuzzer output, see the [libFuzzer documentation](https://llvm.org/docs/LibFuzzer.html).
+
+If you specify a corpus directory then any new coverage increasing inputs will be saved there:
+
+```sh
+$ mkdir -p process_message-seeded-from-thin-air/
+$ src/test/fuzz/process_message process_message-seeded-from-thin-air/
+INFO: Seed: 840522292
+INFO: Loaded 1 modules   (424174 inline 8-bit counters): 424174 [0x55e121ef9ab8, 0x55e121f613a6),
+INFO: Loaded 1 PC tables (424174 PCs): 424174 [0x55e121f613a8,0x55e1225da288),
+INFO:        0 files found in process_message-seeded-from-thin-air/
+INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 94 ft: 95 corp: 1/1b exec/s: 0 rss: 150Mb
+#3      NEW    cov: 95 ft: 96 corp: 2/3b lim: 4 exec/s: 0 rss: 150Mb L: 2/2 MS: 1 InsertByte-
+#4      NEW    cov: 96 ft: 98 corp: 3/7b lim: 4 exec/s: 0 rss: 150Mb L: 4/4 MS: 1 CrossOver-
+#21     NEW    cov: 96 ft: 100 corp: 4/11b lim: 4 exec/s: 0 rss: 150Mb L: 4/4 MS: 2 ChangeBit-CrossOver-
+#324    NEW    cov: 101 ft: 105 corp: 5/12b lim: 6 exec/s: 0 rss: 150Mb L: 6/6 MS: 5 CrossOver-ChangeBit-CopyPart-ChangeBit-ChangeBinInt-
+#1239   REDUCE cov: 102 ft: 106 corp: 6/24b lim: 14 exec/s: 0 rss: 150Mb L: 13/13 MS: 5 ChangeBit-CrossOver-EraseBytes-ChangeBit-InsertRepeatedBytes-
+#1272   REDUCE cov: 102 ft: 106 corp: 6/23b lim: 14 exec/s: 0 rss: 150Mb L: 12/12 MS: 3 ChangeBinInt-ChangeBit-EraseBytes-
+        NEW_FUNC[1/677]: 0x55e11f456690 in std::_Function_base::~_Function_base() /usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/std_function.h:255
+        NEW_FUNC[2/677]: 0x55e11f465800 in CDataStream::CDataStream(std::vector<unsigned char, std::allocator<unsigned char> > const&, int, int) src/./streams.h:248
+#2125   REDUCE cov: 4820 ft: 4867 corp: 7/29b lim: 21 exec/s: 0 rss: 155Mb L: 6/12 MS: 2 CopyPart-CMP- DE: "block"-
+        NEW_FUNC[1/9]: 0x55e11f64d790 in std::_Rb_tree<uint256, std::pair<uint256 const, std::chrono::duration<long, std::ratio<1l, 1000000l> > >, std::_Select1st<std::pair<uint256 const, std::chrono::duration<long, std::ratio<1l, 1000000l> > > >, std::less<uint256>, std::allocator<std::pair<uint256 const, std::chrono::duration<long, std::ratio<1l, 1000000l> > > > >::~_Rb_tree() /usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_tree.h:972
+        NEW_FUNC[2/9]: 0x55e11f64d870 in std::_Rb_tree<uint256, std::pair<uint256 const, std::chrono::duration<long, std::ratio<1l, 1000000l> > >, std::_Select1st<std::pair<uint256 const, std::chrono::duration<long, std::ratio<1l, 1000000l> > > >, std::less<uint256>, std::allocator<std::pair<uint256 const, std::chrono::duration<long, std::ratio<1l, 1000000l> > > > >::_M_erase(std::_Rb_tree_node<std::pair<uint256 const, std::chrono::duration<long, std::ratio<1l, 1000000l> > > >*) /usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_tree.h:1875
+#2228   NEW    cov: 4898 ft: 4971 corp: 8/35b lim: 21 exec/s: 0 rss: 156Mb L: 6/12 MS: 3 EraseBytes-CopyPart-PersAutoDict- DE: "block"-
+        NEW_FUNC[1/5]: 0x55e11f46df70 in std::enable_if<__and_<std::allocator_traits<zero_after_free_allocator<char> >::__construct_helper<char, unsigned char const&>::type>::value, void>::type std::allocator_traits<zero_after_free_allocator<char> >::_S_construct<char, unsigned char const&>(zero_after_free_allocator<char>&, char*, unsigned char const&) /usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/alloc_traits.h:243
+        NEW_FUNC[2/5]: 0x55e11f477390 in std::vector<unsigned char, std::allocator<unsigned char> >::data() /usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_vector.h:1056
+#2456   NEW    cov: 4933 ft: 5042 corp: 9/55b lim: 21 exec/s: 0 rss: 160Mb L: 20/20 MS: 3 ChangeByte-InsertRepeatedBytes-PersAutoDict- DE: "block"-
+#2467   NEW    cov: 4933 ft: 5043 corp: 10/76b lim: 21 exec/s: 0 rss: 161Mb L: 21/21 MS: 1 InsertByte-
+#4215   NEW    cov: 4941 ft: 5129 corp: 17/205b lim: 29 exec/s: 4215 rss: 350Mb L: 29/29 MS: 5 InsertByte-ChangeBit-CopyPart-InsertRepeatedBytes-CrossOver-
+#4567   REDUCE cov: 4941 ft: 5129 corp: 17/204b lim: 29 exec/s: 4567 rss: 404Mb L: 24/29 MS: 2 ChangeByte-EraseBytes-
+#6642   NEW    cov: 4941 ft: 5138 corp: 18/244b lim: 43 exec/s: 2214 rss: 450Mb L: 43/43 MS: 3 CopyPart-CMP-CrossOver- DE: "verack"-
+# abort fuzzing using ctrl-c
+$ ls process_message-seeded-from-thin-air/
+349ac589fc66a09abc0b72bb4ae445a7a19e2cd8 4df479f1f421f2ea64b383cd4919a272604087a7
+a640312c98dcc55d6744730c33e41c5168c55f09 b135de16e4709558c0797c15f86046d31c5d86d7
+c000f7b41b05139de8b63f4cbf7d1ad4c6e2aa7f fc52cc00ec1eb1c08470e69f809ae4993fa70082
+$ cat --show-nonprinting process_message-seeded-from-thin-air/349ac589fc66a09abc0b72bb4ae445a7a19e2cd8
+block^@M-^?M-^?M-^?M-^?M-^?nM-^?M-^?
+```
+
+In this case the fuzzer managed to create a `block` message which when passed to `ProcessMessage(...)` increased coverage.
+
+The project's collection of seed corpora is found in the [`bitcoin-core/qa-assets`](https://github.com/bitcoin-core/qa-assets) repo.
+
+To fuzz `process_message` using the [`bitcoin-core/qa-assets`](https://github.com/bitcoin-core/qa-assets) seed corpus:
+
+```sh
+$ git clone https://github.com/bitcoin-core/qa-assets
+$ src/test/fuzz/process_message qa-assets/fuzz_seed_corpus/process_message/
+INFO: Seed: 1346407872
+INFO: Loaded 1 modules   (424174 inline 8-bit counters): 424174 [0x55d8a9004ab8, 0x55d8a906c3a6),
+INFO: Loaded 1 PC tables (424174 PCs): 424174 [0x55d8a906c3a8,0x55d8a96e5288),
+INFO:      991 files found in qa-assets/fuzz_seed_corpus/process_message/
+INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
+INFO: seed corpus: files: 991 min: 1b max: 1858b total: 288291b rss: 150Mb
+#993    INITED cov: 7063 ft: 8236 corp: 25/3821b exec/s: 0 rss: 181Mb
+…
+```
+
+If you find coverage increasing inputs when fuzzing you are highly encouraged to submit them for inclusion in the [`bitcoin-core/qa-assets`](https://github.com/bitcoin-core/qa-assets) repo.
+
+Every single pull request submitted against the Bitcoin Core repo is automatically tested against all inputs in the [`bitcoin-core/qa-assets`](https://github.com/bitcoin-core/qa-assets) repo. Contributing new coverage increasing inputs is an easy way to help make Bitcoin Core more robust.
+
+## macOS hints for libFuzzer
+
+The default Clang/LLVM version supplied by Apple on macOS does not include
 fuzzing libraries, so macOS users will need to install a full version, for
 example using `brew install llvm`.
 
@@ -128,11 +96,40 @@ may need to run `./configure` with `--disable-asm` to avoid errors
 with certain assembly code from Bitcoin Core's code. See [developer notes on sanitizers](https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#sanitizers)
 for more information.
 
-You may also need to take care of giving the correct path for clang and
-clang++, like `CC=/path/to/clang CXX=/path/to/clang++` if the non-systems
-clang does not come first in your path.
+You may also need to take care of giving the correct path for `clang` and
+`clang++`, like `CC=/path/to/clang CXX=/path/to/clang++` if the non-systems
+`clang` does not come first in your path.
 
 Full configure that was tested on macOS Catalina with `brew` installed `llvm`:
-```
+
+```sh
 ./configure --enable-fuzz --with-sanitizers=fuzzer,address,undefined CC=/usr/local/opt/llvm/bin/clang CXX=/usr/local/opt/llvm/bin/clang++ --disable-asm
 ```
+
+Read the [libFuzzer documentation](https://llvm.org/docs/LibFuzzer.html) for more information. This [libFuzzer tutorial](https://github.com/google/fuzzing/blob/master/tutorial/libFuzzerTutorial.md) might also be of interest.
+
+# Fuzzing Bitcoin Core using american fuzzy lop (`afl-fuzz`)
+
+## Quickstart guide
+
+To quickly get started fuzzing Bitcoin Core using [`afl-fuzz`](https://github.com/google/afl):
+
+```sh
+$ git clone https://github.com/bitcoin/bitcoin
+$ cd bitcoin/
+$ git clone https://github.com/google/afl
+$ make -C afl/
+$ make -C afl/llvm_mode/
+$ ./autogen.sh
+$ CC=$(pwd)/afl/afl-clang-fast CXX=$(pwd)/afl/afl-clang-fast++ ./configure --enable-fuzz
+$ make
+# For macOS you may need to ignore x86 compilation checks when running "make". If so,
+# try compiling using: AFL_NO_X86=1 make
+$ mkdir -p inputs/ outputs/
+$ echo A > inputs/thin-air-input
+$ afl/afl-fuzz -i inputs/ -o outputs/ -- src/test/fuzz/bech32
+# You may have to change a few kernel parameters to test optimally - afl-fuzz
+# will print an error and suggestion if so.
+```
+
+Read the [`afl-fuzz` documentation](https://github.com/google/afl) for more information.
diff --git a/doc/productivity.md b/doc/productivity.md
index b25ddc94e5..1bf3d9afb5 100644
--- a/doc/productivity.md
+++ b/doc/productivity.md
@@ -172,11 +172,11 @@ When looking at other's pull requests, it may make sense to add the following se
 
 ```
 [remote "upstream-pull"]
-        fetch = +refs/pull/*:refs/remotes/upstream-pull/*
+        fetch = +refs/pull/*/head:refs/remotes/upstream-pull/*
         url = git@github.com:bitcoin/bitcoin.git
 ```
 
-This will add an `upstream-pull` remote to your git repository, which can be fetched using `git fetch --all` or `git fetch upstream-pull`. Afterwards, you can use `upstream-pull/NUMBER/head` in arguments to `git show`, `git checkout` and anywhere a commit id would be acceptable to see the changes from pull request NUMBER.
+This will add an `upstream-pull` remote to your git repository, which can be fetched using `git fetch --all` or `git fetch upstream-pull`. It will download and store on disk quite a lot of data (all PRs, including merged and closed ones). Afterwards, you can use `upstream-pull/NUMBER/head` in arguments to `git show`, `git checkout` and anywhere a commit id would be acceptable to see the changes from pull request NUMBER.
 
 ### Diff the diffs with `git range-diff`
 
diff --git a/doc/rapidcheck.md b/doc/rapidcheck.md
deleted file mode 100644
index 397a907f17..0000000000
--- a/doc/rapidcheck.md
+++ /dev/null
@@ -1,84 +0,0 @@
-# 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/reduce-memory.md b/doc/reduce-memory.md
index b0faf0825a..6e7a578ecc 100644
--- a/doc/reduce-memory.md
+++ b/doc/reduce-memory.md
@@ -24,8 +24,9 @@ The size of some in-memory caches can be reduced. As caches trade off memory usa
 
 ## 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`.
+- `-maxconnections=<n>` - the maximum number of connections, this defaults to 125. Each active connection takes up some
+  memory. This option applies only if incoming connections are enabled, otherwise the number of connections will never
+  be more than 10. Of the 10 outbound peers, there can be 8 full-relay connections and 2 block-relay-only ones.
 
 ## Thread configuration
 
diff --git a/doc/reduce-traffic.md b/doc/reduce-traffic.md
index 5a71f62e0f..e39e43df7a 100644
--- a/doc/reduce-traffic.md
+++ b/doc/reduce-traffic.md
@@ -3,8 +3,10 @@ Reduce Traffic
 
 Some node operators need to deal with bandwidth caps imposed by their ISPs.
 
-By default, Bitcoin Core allows up to 125 connections to different peers, 8 of
-which are outbound. You can therefore, have at most 117 inbound connections.
+By default, Bitcoin Core allows up to 125 connections to different peers, 10 of
+which are outbound. You can therefore, have at most 115 inbound connections.
+Of the 10 outbound peers, there can be 8 full-relay connections and 2
+block-relay-only ones.
 
 The default settings can result in relatively significant traffic consumption.
 
@@ -26,7 +28,7 @@ calculating the target.
 
 ## 2. Disable "listening" (`-listen=0`)
 
-Disabling listening will result in fewer nodes connected (remember the maximum of 8
+Disabling listening will result in fewer nodes connected (remember the maximum of 10
 outbound peers). Fewer nodes will result in less traffic usage as you are relaying
 blocks and transactions to fewer nodes.
 
@@ -44,7 +46,11 @@ with other peers, you can disable transaction relay.
 Be reminded of the effects of this setting.
 
 - Fee estimation will no longer work.
-- Not relaying other's transactions could hurt your privacy if used while a
-  wallet is loaded or if you use the node to broadcast transactions.
+- It sets the flag "-walletbroadcast" to be "0", only if it is currently unset.
+  Doing so disables the automatic broadcasting of transactions from wallet. Not
+  relaying other's transactions could hurt your privacy if used while a wallet
+  is loaded or if you use the node to broadcast transactions.
+- If a peer is whitelisted and "-whitelistforcerelay" is set to "1" (which will
+  also set "whitelistrelay" to "1"), we will still receive and relay their transactions.
 - It makes block propagation slower because compact block relay can only be
   used when transaction relay is enabled.
diff --git a/doc/release-notes.md b/doc/release-notes.md
index cd6a4d6b59..0d668a6302 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -1,5 +1,114 @@
-Please edit the release notes here:
+*After branching off for a major version release of Bitcoin Core, use this
+template to create the initial release notes draft.*
 
-https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.20.0-Release-Notes-Draft
+*The release notes draft is a temporary file that can be added to by anyone. See
+[/doc/developer-notes.md#release-notes](/doc/developer-notes.md#release-notes)
+for the process.*
+
+*Create the draft, named* "*version* Release Notes Draft"
+*(e.g. "0.20.0 Release Notes Draft"), as a collaborative wiki in:*
+
+https://github.com/bitcoin-core/bitcoin-devwiki/wiki/
 
 *Before the final release, move the notes back to this git repository.*
+
+*version* Release Notes Draft
+===============================
+
+Bitcoin Core version *version* is now available from:
+
+  <https://bitcoincore.org/bin/bitcoin-core-*version*/>
+
+This release includes new features, various bug fixes and performance
+improvements, as well as updated translations.
+
+Please report bugs using the issue tracker at GitHub:
+
+  <https://github.com/bitcoin/bitcoin/issues>
+
+To receive security and update notifications, please subscribe to:
+
+  <https://bitcoincore.org/en/list/announcements/join/>
+
+How to Upgrade
+==============
+
+If you are running an older version, shut it down. Wait until it has completely
+shut down (which might take a few minutes for older versions), then run the
+installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
+or `bitcoind`/`bitcoin-qt` (on Linux).
+
+Upgrading directly from a version of Bitcoin Core that has reached its EOL is
+possible, but it might take some time if the datadir needs to be migrated. Old
+wallet versions of Bitcoin Core are generally supported.
+
+Compatibility
+==============
+
+Bitcoin Core is supported and extensively tested on operating systems using
+the Linux kernel, macOS 10.12+, 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 Bitcoin Core 0.20.0 onwards, macOS versions earlier than 10.12 are no
+longer supported. 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 provides binaries for the RISC-V platform.
+
+Notable changes
+===============
+
+P2P and network changes
+-----------------------
+
+Updated RPCs
+------------
+
+Changes to Wallet or GUI related RPCs can be found in the GUI or Wallet section below.
+
+New RPCs
+--------
+
+Build System
+------------
+
+Updated settings
+----------------
+
+Changes to Wallet or GUI related settings can be found in the GUI or Wallet  section below.
+
+New settings
+------------
+
+Wallet
+------
+
+#### Wallet RPC changes
+
+- The `upgradewallet` RPC replaces the `-upgradewallet` command line option.
+  (#15761)
+- The `settxfee` RPC will fail if the fee was set higher than the `-maxtxfee`
+  command line setting. The wallet will already fail to create transactions
+  with fees higher than `-maxtxfee`. (#18467)
+
+GUI changes
+-----------
+
+Low-level changes
+=================
+
+Tests
+-----
+
+Credits
+=======
+
+Thanks to everyone who directly contributed to this release:
+
+
+As well as to everyone that helped with translations on
+[Transifex](https://www.transifex.com/bitcoin/bitcoin/).
diff --git a/doc/release-process.md b/doc/release-process.md
index e0f29f6ad7..a61b67c35f 100644
--- a/doc/release-process.md
+++ b/doc/release-process.md
@@ -219,7 +219,7 @@ Codesigner only: Commit the detached codesign payloads:
     rm -rf *
     tar xf signature-osx.tar.gz
     tar xf signature-win.tar.gz
-    git add -a
+    git add -A
     git commit -m "point to ${VERSION}"
     git tag -s v${VERSION} HEAD
     git push the current branch and new tag