doc: Merge release notes fragment, merge taproot description from wiki

Co-authored-by: David A. Harding <dave@dtrt.org>
Co-authored-by: Jon Atack <jon@atack.com>
Co-authored-by: Pieter Wuille <pieter@wuille.net>

Tree-SHA512: dd9ac416ff22276833111198445d76cf8417012a6faad0c3560276f1dcf24586ff41c65ac3430fbf1e840aaa563d3dd101671cff306b0fd92aa2ee03bb7f926b

2 files changed, 92 insertions, 16 deletions

diff --git a/doc/release-notes-20861.md b/doc/release-notes-20861.md
deleted file mode 100644
index 5c68e4ab0c..0000000000
--- a/doc/release-notes-20861.md
+++ /dev/null
@@ -1,13 +0,0 @@
-Updated RPCs
-------------
-
-- Due to [BIP 350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)
-  being implemented, behavior for all RPCs that accept addresses is changed when
-  a native witness version 1 (or higher) is passed. These now require a Bech32m
-  encoding instead of a Bech32 one, and Bech32m encoding will be used for such
-  addresses in RPC output as well. No version 1 addresses should be created
-  for mainnet until consensus rules are adopted that give them meaning
-  (e.g. through [BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)).
-  Once that happens, Bech32m is expected to be used for them, so this shouldn't
-  affect any production systems, but may be observed on other networks where such
-  addresses already have meaning (like signet).
diff --git a/doc/release-notes.md b/doc/release-notes.md
index 3dc18e0a79..d032fa8429 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -44,9 +44,98 @@ when macOS "dark mode" is activated.
 Notable changes
 ===============
 
-RPC
----
-
+## Taproot Soft Fork
+
+Included in this release are the mainnet and testnet activation
+parameters for the taproot soft fork (BIP341) which also adds support
+for schnorr signatures (BIP340) and tapscript (BIP342).
+
+If activated, these improvements will allow users of single-signature
+scripts, multisignature scripts, and complex contracts to all use
+identical-appearing commitments that enhance their privacy and the
+fungibility of all bitcoins. Spenders will enjoy lower fees and the
+ability to resolve many multisig scripts and complex contracts with the
+same efficiency, low fees, and large anonymity set as single-sig users.
+Taproot and schnorr also include efficiency improvements for full nodes
+such as the ability to batch signature verification.  Together, the
+improvements lay the groundwork for future potential
+upgrades that may improve efficiency, privacy, and fungibility further.
+
+Activation for taproot is being managed using a variation of BIP9
+versionbits called Speedy Trial (described in BIP341). Taproot's
+versionbit is bit 2, and nodes will begin tracking which blocks signal
+support for taproot at the beginning of the first retarget period after
+taproot’s start date of 24 April 2021.  If 90% of blocks within a
+2,016-block retarget period (about two weeks) signal support for taproot
+prior to the first retarget period beginning after the time of 11 August
+2021, the soft fork will be locked in, and taproot will then be active
+as of block 709632 (expected in early or mid November).
+
+Should taproot not be locked in via Speedy Trial activation, it is
+expected that a follow-up activation mechanism will be deployed, with
+changes to address the reasons the Speedy Trial method failed.
+
+This release includes the ability to pay taproot addresses, although
+payments to such addresses are not secure until taproot activates.
+It also includes the ability to relay and mine taproot transactions
+after activation.  Beyond those two basic capabilities, this release
+does not include any code that allows anyone to directly use taproot.
+The addition of taproot-related features to Bitcoin Core's wallet is
+expected in later releases once taproot activation is assured.
+
+All users, businesses, and miners are encouraged to upgrade to this
+release (or a subsequent compatible release) unless they object to
+activation of taproot.  If taproot is locked in, then upgrading before
+block 709632 is highly recommended to help enforce taproot's new rules
+and to avoid the unlikely case of seeing falsely confirmed transactions.
+
+Miners who want to activate Taproot should preferably use this release
+to control their signaling.  The `getblocktemplate` RPC results will
+automatically be updated to signal once the appropriate start has been
+reached and continue signaling until the timeout occurs or taproot
+activates.  Alternatively, miners may manually start signaling on bit 2
+at any time; if taproot activates, they will need to ensure they update
+their nodes before block 709632 or non-upgraded nodes could cause them to mine on
+an invalid chain.  See the [versionbits
+FAQ](https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/) for
+details.
+
+
+For more information about taproot, please see the following resources:
+
+- Technical specifications
+  - [BIP340 Schnorr signatures for secp256k1](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) 
+  - [BIP341 Taproot: SegWit version 1 spending rules](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)
+  - [BIP342 Validation of Taproot scripts](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki)
+
+- Popular articles;
+  - [Taproot Is Coming: What It Is, and How It Will Benefit Bitcoin](https://bitcoinmagazine.com/technical/taproot-coming-what-it-and-how-it-will-benefit-bitcoin)
+  - [What do Schnorr Signatures Mean for Bitcoin?](https://academy.binance.com/en/articles/what-do-schnorr-signatures-mean-for-bitcoin)
+  - [The Schnorr Signature & Taproot Softfork Proposal](https://blog.bitmex.com/the-schnorr-signature-taproot-softfork-proposal/)
+
+- Development history overview
+  - [Taproot](https://bitcoinops.org/en/topics/taproot/)
+  - [Schnorr signatures](https://bitcoinops.org/en/topics/schnorr-signatures/)
+  - [Tapscript](https://bitcoinops.org/en/topics/tapscript/)
+  - [Soft fork activation](https://bitcoinops.org/en/topics/soft-fork-activation/)
+
+- Other
+  - [Questions and answers related to taproot](https://bitcoin.stackexchange.com/questions/tagged/taproot)
+  - [Taproot review](https://github.com/ajtowns/taproot-review)
+
+Updated RPCs
+------------
+
+- Due to [BIP 350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)
+  being implemented, behavior for all RPCs that accept addresses is changed when
+  a native witness version 1 (or higher) is passed. These now require a Bech32m
+  encoding instead of a Bech32 one, and Bech32m encoding will be used for such
+  addresses in RPC output as well. No version 1 addresses should be created
+  for mainnet until consensus rules are adopted that give them meaning
+  (e.g. through [BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)).
+  Once that happens, Bech32m is expected to be used for them, so this shouldn't
+  affect any production systems, but may be observed on other networks where such
+  addresses already have meaning (like signet).
 
 0.21.1 change log
 =================