diff --git a/README.mediawiki b/README.mediawiki
index d8bcae62a5..a3a7406f51 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -434,6 +434,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Ethan Kosakovsky
 | Informational
 | Draft
+|-
+| [[bip-0086.mediawiki|86]]
+| Applications
+| Key Derivation for Single Key P2TR Outputs
+| Andrew Chow
+| Standard
+| Draft
 |- style="background-color: #ffffcf"
 | [[bip-0087.mediawiki|87]]
 | Applications
@@ -1029,6 +1036,55 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Andrew Chow
 | Standard
 | Draft
+|-
+| [[bip-descriptors-general.mediawiki|bip-descriptors-general]]
+| Applications
+| Output Script Descriptors General Operation
+| Pieter Wuille, Andrew Chow
+| Informational
+| Draft
+|-
+| [[bip-descriptors-non-segwit.mediawiki|bip-descriptors-non-segwit]]
+| Applications
+| Non-Segwit Output Script Descriptors
+| Pieter Wuille, Andrew Chow
+| Informational
+| Draft
+|-
+| [[bip-descriptors-segwit.mediawiki|bip-descriptors-segwit]]
+| Applications
+| Segwit Output Script Descriptors
+| Pieter Wuille, Andrew Chow
+| Informational
+| Draft
+|-
+| [[bip-descriptors-multi.mediawiki|bip-descriptors-multi]]
+| Applications
+| Multisig Output Script Descriptors
+| Pieter Wuille, Andrew Chow
+| Informational
+| Draft
+|-
+| [[bip-descriptors-combo.mediawiki|bip-descriptors-combo]]
+| Applications
+| combo() Output Script Descriptors
+| Pieter Wuille, Andrew Chow
+| Informational
+| Draft
+|-
+| [[bip-descriptors-raw-addr.mediawiki|bip-descriptors-raw-addr]]
+| Applications
+| raw() and addr() Output Script Descriptors
+| Pieter Wuille, Andrew Chow
+| Informational
+| Draft
+|-
+| [[bip-descriptors-tr.mediawiki|bip-descriptors-tr]]
+| Applications
+| tr() Output Script Descriptors
+| Pieter Wuille, Andrew Chow
+| Informational
+| Draft
 |}
 
 <!-- IMPORTANT!  See the instructions at the top of this page, do NOT JUST add BIPs here! -->
diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index b8152e7663..88c2dbbcd9 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -119,7 +119,7 @@ To shorten notation, we will write CKDpriv(CKDpriv(CKDpriv(m,3<sub>H</sub>),2),5
 * N(m/a<sub>H</sub>/b/c) = N(m/a<sub>H</sub>/b)/c = N(m/a<sub>H</sub>)/b/c.
 However, N(m/a<sub>H</sub>) cannot be rewritten as N(m)/a<sub>H</sub>, as the latter is not possible.
 
-Each leaf node in the tree corresponds to an actual key, while the internal nodes correspond to the collections of keys that descend from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is relevant. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public keys allows reconstruction of all descendant non-hardened public keys.
+Each leaf node in the tree corresponds to an actual key, while the internal nodes correspond to the collections of keys that descend from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is relevant. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public key allows reconstruction of all descendant non-hardened public keys.
 
 ===Key identifiers===
 
diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index 498694c3ce..4ac3c556d9 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -163,7 +163,7 @@ Haskell:
 * https://github.com/NicolasDorier/NBitcoin
 
 JavaScript:
-* https://github.com/bitpay/bitcore-mnemonic
+* https://github.com/bitpay/bitcore/tree/master/packages/bitcore-mnemonic
 * https://github.com/bitcoinjs/bip39 (used by [[https://github.com/blockchain/My-Wallet-V3/blob/v3.8.0/src/hd-wallet.js#L121-L146|blockchain.info]])
 
 Java:
diff --git a/bip-0086.mediawiki b/bip-0086.mediawiki
new file mode 100644
index 0000000000..f724884e8a
--- /dev/null
+++ b/bip-0086.mediawiki
@@ -0,0 +1,128 @@
+<pre>
+  BIP: 86
+  Layer: Applications
+  Title: Key Derivation for Single Key P2TR Outputs
+  Author: Andrew Chow <andrew@achow101.com>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0086
+  Status: Draft
+  Type: Standards Track
+  Created: 2021-06-22
+  License: BSD-2-Clause
+</pre>
+
+==Abstract==
+
+This document suggests a derivation scheme for HD wallets whose keys are involved in single key
+P2TR ([[bip-0341.mediawiki|BIP 341]]) outputs as the Taproot internal key.
+
+===Copyright===
+
+This BIP is licensed under the 2-clause BSD license.
+
+==Motivation==
+
+With the usage of single key P2TR transactions, it is useful to have a common derivation scheme so
+that HD wallets that only have a backup of the HD seed can be likely to recover single key Taproot
+outputs. Although there are now solutions which obviate the need for fixed derivation paths for
+specific script types, many software wallets and hardware signers still use seed backups which
+lack derivation path and script information. Thus we largely use the same approach used in BIPs
+[[bip-0049.mediawiki|49]] and [[bip-0084.mediawiki|84]] for ease of implementation.
+
+==Specifications==
+
+This BIP defines the two needed steps to derive multiple deterministic addresses based on a
+[[bip-0032.mediawiki|BIP 32]] master private key.
+
+===Public key derivation===
+
+To derive a public key from the root account, this BIP uses the same account-structure as
+defined in BIPs [[bip-0044.mediawiki|44]], [[bip-0049.mediawiki|49]], and [[bip-0084.mediawiki|84]],
+but with a different purpose value for the script type.
+
+<pre>
+m / purpose' / coin_type' / account' / change / address_index
+</pre>
+
+For the <tt>purpose</tt>-path level it uses <tt>86'</tt>.
+The rest of the levels are used as defined in BIPs 44, 49, and 84.
+
+A key derived with this derivation path pattern will be referred to as <tt>derived_key</tt> further
+in this document.
+
+===Address derivation===
+
+
+[[bip-0341.mediawiki#cite_ref-22-0|BIP 341]] states: "If the spending conditions do not require a
+script path, the output key should commit to an unspendable script path instead of having no
+script path. This can be achieved by computing the output key point as
+''Q = P + int(hash<sub>TapTweak</sub>(bytes(P)))G''." Thus:
+
+<pre>
+internal_key:       lift_x(derived_key)
+32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G
+</pre>
+
+In a transaction, the scripts and witnesses are as defined in
+[[bip-0341.mediawiki#specification|BIP 341]]:
+
+<pre>
+witness:      <signature>
+scriptSig:    (empty)
+scriptPubKey: 1 <32_byte_output_key>
+              (0x5120{32_byte_output_key})
+</pre>
+
+==Backwards Compatibility==
+
+This BIP is not backwards compatible by design.
+An incompatible wallet will not discover these accounts at all and the user will notice that
+something is wrong.
+
+However this BIP uses the same method used in BIPs 44, 49, and 84, so it should not be difficult
+to implement.
+
+==Test vectors==
+
+<pre>
+mnemonic = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
+rootpriv = xprv9s21ZrQH143K3GJpoapnV8SFfukcVBSfeCficPSGfubmSFDxo1kuHnLisriDvSnRRuL2Qrg5ggqHKNVpxR86QEC8w35uxmGoggxtQTPvfUu
+rootpub  = xpub661MyMwAqRbcFkPHucMnrGNzDwb6teAX1RbKQmqtEF8kK3Z7LZ59qafCjB9eCRLiTVG3uxBxgKvRgbubRhqSKXnGGb1aoaqLrpMBDrVxga8
+
+// Account 0, root = m/86'/0'/0'
+xprv = xprv9xgqHN7yz9MwCkxsBPN5qetuNdQSUttZNKw1dcYTV4mkaAFiBVGQziHs3NRSWMkCzvgjEe3n9xV8oYywvM8at9yRqyaZVz6TYYhX98VjsUk
+xpub = xpub6BgBgsespWvERF3LHQu6CnqdvfEvtMcQjYrcRzx53QJjSxarj2afYWcLteoGVky7D3UKDP9QyrLprQ3VCECoY49yfdDEHGCtMMj92pReUsQ
+
+// Account 0, first receiving address = m/86'/0'/0'/0/0
+xprv         = xprvA449goEeU9okwCzzZaxiy475EQGQzBkc65su82nXEvcwzfSskb2hAt2WymrjyRL6kpbVTGL3cKtp9herYXSjjQ1j4stsXXiRF7kXkCacK3T
+xpub         = xpub6H3W6JmYJXN49h5TfcVjLC3onS6uPeUTTJoVvRC8oG9vsTn2J8LwigLzq5tHbrwAzH9DGo6ThGUdWsqce8dGfwHVBxSbixjDADGGdzF7t2B
+internal_key = cc8a4bc64d897bddc5fbc2f670f7a8ba0b386779106cf1223c6fc5d7cd6fc115
+output_key   = a60869f0dbcf1dc659c9cecbaf8050135ea9e8cdc487053f1dc6880949dc684c
+scriptPubKey = 5120a60869f0dbcf1dc659c9cecbaf8050135ea9e8cdc487053f1dc6880949dc684c
+address      = bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr
+
+// Account 0, second receiving address = m/86'/0'/0'/0/1
+xprv         = xprvA449goEeU9okyiF1LmKiDaTgeXvmh87DVyRd35VPbsSop8n8uALpbtrUhUXByPFKK7C2yuqrB1FrhiDkEMC4RGmA5KTwsE1aB5jRu9zHsuQ
+xpub         = xpub6H3W6JmYJXN4CCKUSnriaiQRCZmG6aq4sCMDqTu1ACyngw7HShf59hAxYjXgKDuuHThVEUzdHrc3aXCr9kfvQvZPit5dnD3K9xVRBzjK3rX
+internal_key = 83dfe85a3151d2517290da461fe2815591ef69f2b18a2ce63f01697a8b313145
+output_key   = a82f29944d65b86ae6b5e5cc75e294ead6c59391a1edc5e016e3498c67fc7bbb
+scriptPubKey = 5120a82f29944d65b86ae6b5e5cc75e294ead6c59391a1edc5e016e3498c67fc7bbb
+address      = bc1p4qhjn9zdvkux4e44uhx8tc55attvtyu358kutcqkudyccelu0was9fqzwh
+
+// Account 0, first change address = m/86'/0'/0'/1/0
+xprv         = xprvA3Ln3Gt3aphvUgzgEDT8vE2cYqb4PjFfpmbiFKphxLg1FjXQpkAk5M1ZKDY15bmCAHA35jTiawbFuwGtbDZogKF1WfjwxML4gK7WfYW5JRP
+xpub         = xpub6GL8SnQwRCGDhB59LEz9HMyM6sRYoByXBzXK3iEKWgCz8XrZNHUzd9L3AUBELW5NzA7dEFvMas1F84TuPH3xqdUA5tumaGWFgihJzWytXe3
+internal_key = 399f1b2f4393f29a18c937859c5dd8a77350103157eb880f02e8c08214277cef
+output_key   = 882d74e5d0572d5a816cef0041a96b6c1de832f6f9676d9605c44d5e9a97d3dc
+scriptPubKey = 5120882d74e5d0572d5a816cef0041a96b6c1de832f6f9676d9605c44d5e9a97d3dc
+address      = bc1p3qkhfews2uk44qtvauqyr2ttdsw7svhkl9nkm9s9c3x4ax5h60wqwruhk7
+</pre>
+
+==Reference==
+
+* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
+* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
+* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
+* [[bip-0049.mediawiki|BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts]]
+* [[bip-0084.mediawiki|BIP84 - Derivation scheme for P2WPKH based accounts]]
+* [[bip-0341.mediawiki|BIP341 - Taproot: SegWit version 1 spending rules]]
diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki
index 19f92f24e5..3e7b0d829d 100644
--- a/bip-0155.mediawiki
+++ b/bip-0155.mediawiki
@@ -131,7 +131,7 @@ See the appendices for the address encodings to be used for the various networks
 
 ==Signaling support and compatibility==
 
-Introduce a new message type <code>sendaddrv2</code>. Sending such a message indicates that a node can understand and prefers to receive <code>addrv2</code> messages instead of <code>addr</code> messages. I.e. "Send me addrv2".
+Introduce a new message type <code>sendaddrv2</code>. Sending such a message indicates that a node can understand and prefers to receive <code>addrv2</code> messages instead of <code>addr</code> messages. I.e. "Send me addrv2". Sending or not sending this message does not imply any preference with respect to receiving unrequested address messages.
 
 The <code>sendaddrv2</code> message MUST only be sent in response to the <code>version</code> message from a peer and prior to sending the <code>verack</code> message.
 
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index b211434699..f3de964f97 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -501,7 +501,7 @@ determine which outputs are change outputs and verify that the change is returni
 | [[bip-psb2.mediawiki|psbt2]]
 |-
 | Output Script
-| <tt>PSBT_OUT_SCRIPT = 0x03</tt>
+| <tt>PSBT_OUT_SCRIPT = 0x04</tt>
 | None
 | No key data
 | <tt><script></tt>
diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki
index fb6e222471..5e47bfc4f7 100644
--- a/bip-0341.mediawiki
+++ b/bip-0341.mediawiki
@@ -336,7 +336,7 @@ Non-upgraded nodes, however, will consider all SegWit version 1 witness programs
 They are strongly encouraged to upgrade in order to fully validate the new programs.
 
 Non-upgraded wallets can receive and send bitcoin from non-upgraded and upgraded wallets using SegWit version 0 programs, traditional pay-to-pubkey-hash, etc.
-Depending on the implementation non-upgraded wallets may be able to send to Segwit version 1 programs if they support sending to [[bip-0173.mediawiki|BIP173]] Bech32 addresses.
+Depending on the implementation non-upgraded wallets may be able to send to Segwit version 1 programs if they support sending to [[bip-0350.mediawiki|BIP350]] Bech32m addresses.
 
 == Acknowledgements ==
 
diff --git a/bip-0370.mediawiki b/bip-0370.mediawiki
index 8dd557a3af..d906a40f24 100644
--- a/bip-0370.mediawiki
+++ b/bip-0370.mediawiki
@@ -197,7 +197,7 @@ The new per-output types for PSBT Version 2 are defined as follows:
 | 2
 |-
 | Output Script
-| <tt>PSBT_OUT_SCRIPT = 0x03</tt>
+| <tt>PSBT_OUT_SCRIPT = 0x04</tt>
 | None
 | No key data
 | <tt><script></tt>
diff --git a/bip-descriptors-combo.mediawiki b/bip-descriptors-combo.mediawiki
new file mode 100644
index 0000000000..ffbdaad08d
--- /dev/null
+++ b/bip-descriptors-combo.mediawiki
@@ -0,0 +1,48 @@
+<pre>
+  BIP: bip-descriptors-combo
+  Layer: Applications
+  Title: combo() Output Script Descriptors
+  Author: Pieter Wuille <pieter@wuille.net>
+          Andrew Chow <andrew@achow101.com>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-combo
+  Status: Draft
+  Type: Informational
+  Created: 2021-06-27
+  License: BSD-2-Clause
+</pre>
+
+==Abstract==
+
+This document specifies <tt>combo()</tt> output script descriptors.
+These take a key and produce P2PK, P2PKH, P2WPKH, and P2SH-P2WPKH output scripts if applicable to the key.
+
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
+==Motivation==
+
+In order to make the transition from traditional key based wallets to descriptor based wallets easier, it is useful to be able to take a key and produce the scripts which have traditionally been produced by wallet software.
+
+==Specification==
+
+A new top level script expression is defined: <tt>combo(KEY)</tt>.
+This expression can only be used as a top level expression.
+It takes a single key expression as an argument and produces either 2 or 4 output scripts, depending on the key.
+A <tt>combo()</tt> expression always produces a P2PK and P2PKH script, the same as putting the key in both a <tt>pk()</tt> and a <tt>pkh()</tt> expression.
+If the key is/has a compressed public key, then P2WPKH and P2SH-P2WPKH scripts are also produced, the same as putting the key in both a <tt>wpkh()</tt> and <tt>sh(wpkh())</tt> expression.
+
+==Test Vectors==
+
+TBD
+
+==Backwards Compatibility==
+
+<tt>combo()</tt> descriptors use the format and general operation specified in [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
+As this is a wholly new descriptor, it is not compatible with any implementation.
+However the scripts produced are standard scripts so existing software are likely to be familiar with them.
+
+==Reference Implemntation==
+
+<tt>combo</tt> descriptors have been implemented in Bitcoin Core since version 0.17.
diff --git a/bip-descriptors-general.mediawiki b/bip-descriptors-general.mediawiki
new file mode 100644
index 0000000000..424f11d4be
--- /dev/null
+++ b/bip-descriptors-general.mediawiki
@@ -0,0 +1,211 @@
+<pre>
+  BIP: bip-descriptors-general
+  Layer: Applications
+  Title: Output Script Descriptors General Operation
+  Author: Pieter Wuille <pieter@wuille.net>
+          Andrew Chow <andrew@achow101.com>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-general
+  Status: Draft
+  Type: Informational
+  Created: 2021-06-27
+  License: BSD-2-Clause
+</pre>
+
+==Abstract==
+
+Output Script Descriptors are a simple language which can be used to describe collections of output scripts.
+There can be many different descriptor fragments and functions.
+This document describes the general syntax for descriptors, descriptor checksums, and common expressions.
+
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
+==Motivation==
+
+Bitcoin wallets traditionally have stored a set of keys which are later serialized and mutated to produce the output scripts that the wallet watches and the addresses it provides to users.
+Typically backups have consisted of solely the private keys, nowadays primarily in the form of BIP 39 mnemonics.
+However this backup solution is insuffient, especially since the introduction of Segregated Witness which added new output types.
+Given just the private keys, it is not possible for restored wallets to know which kinds of output scripts and addresses to produce.
+This has lead to incompatibilities between wallets when restoring a backup or exporting data for a watch only wallet.
+
+Further complicating matters are BIP 32 derivation paths.
+Although BIPs 44, 49, and 84 have specified standard BIP 32 derivation paths for different output scripts and addresses, not all wallets support them nor use those derivation paths.
+The lack of derivation path information in these backups and exports leads to further incompatibilities between wallets.
+
+Current solutions to these issues have not been generic and can be viewed as being layer violations.
+Solutions such as introducing different version bytes for extended key serialization both are a layer violation (key derivation should be separate from script type meaning) and specific only to a particular derivation path and script type.
+
+Output Script Descriptors introduces a generic solution to these issues.
+Script types are specified explicitly through the use of Script Expressions.
+Key derivation paths are specified explicitly in Key Expressions.
+These allow for creating wallet backups and exports which specify the exact scripts, subscripts (redeemScript, witnessScript, etc.), and keys to produce.
+With the general structure specified in this BIP, new Script Expressions can be introduced as new script types are added.
+Lastly, the use of common terminology and existing standards allow for Output Script Descriptors to be engineer readable so that the results can be understood at a glance.
+
+==Specification==
+
+Descriptors consist of several types of expressions.
+The top level expression is a <tt>SCRIPT</tt>.
+This expression may be followed by <tt>#CHECKSUM</tt>, where <tt>CHECKSUM</tt> is an 8 character alphanumeric descriptor checksum.
+
+===Script Expressions===
+
+Script Expressions (denoted <tt>SCRIPT</tt>) are expressions which correspond directly with a Bitcoin script.
+These expressions are written as functions and take arguments.
+Such expressions have a script template which is filled with the arguments correspondingly.
+Expressions are written with a human readable identifier string with the arguments enclosed with parentheses.
+The identifier string should be alphanumeric and may include underscores.
+
+The arguments to a script expression are defined by that expression itself.
+They could be a script expression, a key expression, or some other expression entirely.
+
+===Key Expressions===
+
+A common expression used as an argument to script expressions are key expressions (denoted <tt>KEY</tt>).
+These represent a public or private key and, optionally, information about the origin of that key.
+Key expressions can only be used as arguments to script expressions.
+
+Key expressions consist of:
+* Optionally, key origin information, consisting of:
+** An open bracket <tt>[</tt>
+** Exactly 8 hex characters for the fingerprint of the key where the derivation starts (see BIP 32 for details)
+** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt>  path elements to indicate the unhardened or hardened derivation steps between the fingerprint and the key that follows.
+** A closing bracket <tt>]</tt>
+* Followed by the actual key, which is either:
+** A hex encoded public key, which depending the script expression, may be either:
+*** 66 hex character string beginning with <tt>02</tt> or <tt>03</tt> representing a compressed public key
+*** 130 hex character string beginning with <tt>04</tt> representing an uncompressed public key
+** A [[https://en.bitcoin.it/wiki/Wallet_import_format|WIF]] encoded private key
+** <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded extended private key (as defined in BIP 32)
+*** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path elements indicating BIP 32 derivation steps to be taken after the given extended key.
+*** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final step to denote all direct unhardened or hardened children.
+
+If the <tt>KEY</tt> is a BIP 32 extended key, before output scripts can be created, child keys must be derived using the derivation information that follows the extended key.
+When the final step is <tt>/*</tt> or <tt>/*'</tt>, an output script will be produced for every child key index.
+The derived key must be not be serialized as an uncompressed public key.
+Script Expressions may have further requirements on how derived public keys are serialized for script creation.
+
+In the above specification, the hardened indicator <tt>h</tt> may be replaced with alternative hardnened indicators of <tt>H</tt> or <tt>'</tt>.
+
+====Normalization of Key Expressions with Hardened Derivation====
+
+When a descriptor is exported without private keys, it is necessary to do additional derivation to remove any intermediate hardened derivation steps for the exported descriptor to be useful.
+The exporter should derive the extended public key at the last hardened derivation step and use that extended public key as the key in the descriptor.
+The derivation steps that were taken to get to that key must be added to the previous key origin information.
+If there is no key origin information, then one must be added for the newly derived extended public key.
+If the final derivation is hardened, then it is not necessary to do additional derivation.
+
+===Character Set===
+
+The expressions used in descriptors must only contain characters within this character set so that the descriptor checksum will work.
+
+The allowed characters are:
+<pre>
+0123456789()[],'/*abcdefgh@:$%{}
+IJKLMNOPQRSTUVWXYZ&+-.;<=>?!^_|~
+ijklmnopqrstuvwxyzABCDEFGH`#"\<space>
+</pre>
+Note that <tt><space></tt> on the last line is a space character.
+
+This character set is written as 3 groups of 32 characters in this specific order so that the checksum below can identify more errors.
+The first group are the most common "unprotected" characters (i.e. things such as hex and keypaths that do not already have their own checksums).
+Case errors cause an offset that is a multiple of 32 while as many alphabetic characters are in the same group while following the previous restrictions.
+
+===Checksum===
+
+Follwing the top level script expression is a single octothorpe (<tt>#</tt>) followed by the 8 character checksum.
+The checksum is an error correcting checksum similar to bech32.
+
+The checksum has the following properties:
+* Mistakes in a descriptor string are measured in "symbol errors". The higher the number of symbol errors, the harder it is to detect:
+** An error substituting a character from <tt>0123456789()[],'/*abcdefgh@:$%{}</tt> for another in that set always counts as 1 symbol error.
+*** Note that hex encoded keys are covered by these characters. Extended keys (<tt>xpub</tt> and <tt>xprv</tt>) use other characters too, but also have their own checksum mechansim.
+*** <tt>SCRIPT</tt> expression function names use other characters, but mistakes in these would generally result in an unparsable descriptor.
+** A case error always counts as 1 symbol error.
+** Any other 1 character substitution error counts as 1 or 2 symbol errors.
+* Any 1 symbol error is always detected.
+* Any 2 or 3 symbol error in a descriptor of up to 49154 characters is always detected.
+* Any 4 symbol error in a descriptor of up to 507 characters is always detected.
+* Any 5 symbol error in a descriptor of up to 77 characters is always detected.
+* Is optimized to minimize the chance of a 5 symbol error in a descriptor up to 387 characters is undetected
+* Random errors have a chance of 1 in 2<super>40</super> of being undetected.
+
+The checksum itself uses the same character set as bech32: <tt>qpzry9x8gf2tvdw0s3jn54khce6mua7l</tt>
+
+Valid descriptor strings with a checksum must pass the criteria for validity specified by the Python3 code snippet below.
+The function <tt>descsum_check</tt> must return true when its argument <tt>s</tt> is a descriptor consisting in the form <tt>SCRIPT#CHECKSUM</tt>.
+
+<pre>
+INPUT_CHARSET = "0123456789()[],'/*abcdefgh@:$%{}IJKLMNOPQRSTUVWXYZ&+-.;<=>?!^_|~ijklmnopqrstuvwxyzABCDEFGH`#\"\\ "
+CHECKSUM_CHARSET = "qpzry9x8gf2tvdw0s3jn54khce6mua7l"
+GENERATOR = [0xf5dee51989, 0xa9fdca3312, 0x1bab10e32d, 0x3706b1677a, 0x644d626ffd]
+
+def descsum_polymod(symbols):
+    """Internal function that computes the descriptor checksum."""
+    chk = 1
+    for value in symbols:
+        top = chk >> 35
+        chk = (chk & 0x7ffffffff) << 5 ^ value
+        for i in range(5):
+            chk ^= GENERATOR[i] if ((top >> i) & 1) else 0
+    return chk
+
+def descsum_expand(s):
+    """Internal function that does the character to symbol expansion"""
+    groups = []
+    symbols = []
+    for c in s:
+        if not c in INPUT_CHARSET:
+            return None
+        v = INPUT_CHARSET.find(c)
+        symbols.append(v & 31)
+        groups.append(v >> 5)
+        if len(groups) == 3:
+            symbols.append(groups[0] * 9 + groups[1] * 3 + groups[2])
+            groups = []
+    if len(groups) == 1:
+        symbols.append(groups[0])
+    elif len(groups) == 2:
+        symbols.append(groups[0] * 3 + groups[1])
+    return symbols
+
+def descsum_check(s):
+    """Verify that the checksum is correct in a descriptor"""
+    if s[-9] != '#':
+        return False
+    if not all(x in CHECKSUM_CHARSET for x in s[-8:]):
+        return False
+    symbols = descsum_expand(s[:-9]) + [CHECKSUM_CHARSET.find(x) for x in s[-8:]]
+    return descsum_polymod(symbols) == 1
+</pre>
+
+This implements a BCH code that has the properties described above.
+The entire descriptor string is first processed into an array of symbols.
+The symbol for each character is its position within its group.
+After every 3rd symbol, a 4th symbol is inserted which represents the group numbers combined together.
+This means that a change that only affects the position within a group, or only a group number change, will only affect a single symbol.
+
+To construct a valid checksum given a script expression, the code below can be used:
+
+<pre>
+def descsum_create(s):
+    """Add a checksum to a descriptor without"""
+    symbols = descsum_expand(s) + [0, 0, 0, 0, 0, 0, 0, 0]
+    checksum = descsum_polymod(symbols) ^ 1
+    return s + '#' + ''.join(CHECKSUM_CHARSET[(checksum >> (5 * (7 - i))) & 31] for i in range(8))
+
+</pre>
+
+==Backwards Compatibility==
+
+Output script descriptors are an entirely new language which is not compatible with any existing software.
+However many components of the expressions reuse encodings and serializations defined by previous BIPs.
+
+Output script descriptors are designed for future extension with further fragment types and new script expressions.
+These will be specified in additional BIPs.
+
+==Reference Implemntation==
+
+Descriptors have been implemented in Bitcoin Core since version 0.17.
diff --git a/bip-descriptors-multi.mediawiki b/bip-descriptors-multi.mediawiki
new file mode 100644
index 0000000000..ed1929aae7
--- /dev/null
+++ b/bip-descriptors-multi.mediawiki
@@ -0,0 +1,78 @@
+<pre>
+  BIP: bip-descriptors-multi
+  Layer: Applications
+  Title: Multisig Output Script Descriptors
+  Author: Pieter Wuille <pieter@wuille.net>
+          Andrew Chow <andrew@achow101.com>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-multi
+  Status: Draft
+  Type: Informational
+  Created: 2021-06-27
+  License: BSD-2-Clause
+</pre>
+
+==Abstract==
+
+This document specifies <tt>multi()</tt>, and <tt>sortedmulti()</tt> output script descriptors.
+Both functions take a threshold and one or more public keys and produce a multisig output script.
+<tt>multi()</tt> specifies the public keys in the output script in the order given in the descriptor while <tt>sortedmulti()</tt> sorts the public keys lexicographically when the output script is produced.
+
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
+==Motivation==
+
+The most common complex script used in Bitcoin is a threshold multisig.
+These expressions allow specifying multisig scripts as a descriptor.
+
+==Specification==
+
+Two new script expressions are defined: <tt>multi()</tt>, and <tt>sortedmulti()</tt>.
+Both expressions produce the scripts of the same template and take the same arguments.
+They are written as <tt>multi(k,KEY_1,KEY_2,...,KEY_n)</tt>.
+<tt>k</tt> is the threshold - the number of keys that must sign the input for the script to be valid.
+<tt>KEY_1,KEY_2,...,KEY_n</tt> are the key expressions for the multisig. <tt>k</tt> must be less than or equal to <tt>n</tt>.
+
+<tt>multi()</tt> and <tt>sortedmulti()</tt> expressions can be used as a top level expression, or inside of either a <tt>sh()</tt> or <tt>wsh()</tt> descriptor.
+Depending on the higher level descriptors, there may be restrictions on the type of public keys that can be included.
+
+Depending on the higher level descriptors, there are also restrictions on the number of keys that can be present, i.e. the maximum value of <tt>n</tt>.
+When used at the top level, there can only be at most 3 keys.
+When used inside of a <tt>sh()</tt> expression, there can only be most 15 compressed public keys (this is limited by the P2SH script limit).
+Otherwise the maximum number of keys is 20.
+
+The output script produced also depends on the value of <tt>k</tt>. If <tt>k</tt> is less than or equal to 16:
+<pre>
+OP_k KEY_1 KEY_2 ... KEY_n OP_CHECKMULTISIG
+</pre>
+
+if <tt>k</tt> is greater than 16:
+<pre>
+k KEY_1 KEY_2 ... KEY_n OP_CHECKMULTISIG
+</pre>
+
+===<tt>sortedmulti()</tt>===
+
+The only change for <tt>sortedmulti()</tt> is that the keys are sorted lexicographically prior to the creation of the output script.
+This sorting is on the keys that are to be put into the output script, i.e. after all extended keys are derived.
+
+===Multiple Extended Keys</tt>===
+
+When one or more the key expressions in a <tt>multi()</tt> or <tt>sortedmulti()</tt> expression are extended keys, the derived keys use the same child index.
+This changes the keys in lockstep and allows for output scripts to be indexed in the same way that the derived keys are indexed.
+
+==Test Vectors==
+
+TBD
+
+==Backwards Compatibility==
+
+<tt>multi()</tt>, and <tt>sortedmulti()</tt> descriptors use the format and general operation specified in [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
+As these are a wholly new descriptors, they are not compatible with any implementation.
+However the scripts produced are standard scripts so existing software are likely to be familiar with them.
+
+==Reference Implemntation==
+
+<tt>multi()</tt>, and <tt>multi()</tt> descriptors have been implemented in Bitcoin Core since version 0.17.
diff --git a/bip-descriptors-non-segwit.mediawiki b/bip-descriptors-non-segwit.mediawiki
new file mode 100644
index 0000000000..f10a27c3db
--- /dev/null
+++ b/bip-descriptors-non-segwit.mediawiki
@@ -0,0 +1,83 @@
+<pre>
+  BIP: bip-descriptors-non-segwit
+  Layer: Applications
+  Title: Non-segwit Output Script Descriptors
+  Author: Pieter Wuille <pieter@wuille.net>
+          Andrew Chow <andrew@achow101.com>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-non-segwit
+  Status: Draft
+  Type: Informational
+  Created: 2021-06-27
+  License: BSD-2-Clause
+</pre>
+
+==Abstract==
+
+This document specifies <tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt> output script descriptors.
+<tt>pk()</tt> descriptors take a key and produces a P2PK output script.
+<tt>pkh()</tt> descriptors take a key and produces a P2PKH output script.
+<tt>sh()</tt> descriptors take a script and produces a P2SH output script.
+
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
+==Motivation==
+
+Prior to the activation of Segregated Witness, there were 3 main standard output script formats: P2PK, P2PKH, and P2SH.
+These expressions allow specifying those formats as a descriptor.
+
+==Specification==
+
+Three new script expressions are defined: <tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt>.
+
+===<tt>pk()</tt>===
+
+The <tt>pk(KEY)</tt> expression can be used in any context or level of a descriptor.
+It takes a single key expression as an argument and produces a P2PK output script.
+Depending on the higher level descriptors, there may be restrictions on the type of public keys that can be included.
+Such restrictions will be specified by those descriptors.
+
+The output script produced is:
+<pre>
+<KEY> OP_CHECKSIG
+</pre>
+
+===<tt>pkh()</tt>===
+
+The <tt>pkh(KEY)</tt> expression can be used as a top level expression, or inside of either a <tt>sh()</tt> or <tt>wsh()</tt> descriptor.
+It takes a single key expression as an argument and produces a P2PKH output script.
+Depending on the higher level descriptors, there may be restrictions on the type of public keys that can be included.
+Such restrictions will be specified by those descriptors.
+
+The output script produced is:
+<pre>
+OP_DUP OP_HASH160 <KEY_hash160> OP_EQUALVERIFY OP_CHECKSIG
+</pre>
+
+===<tt>sh()</tt>===
+
+The <tt>sh(SCRIPT)</tt> expression can only be used as a top level expression.
+It takes a single script expression as an argument and produces a P2SH output script.
+<tt>sh()</tt> expressions also create a redeemScript which is required in order to spend outputs which use its output script.
+This redeemScript is the output script produced by the <tt>SCRIPT</tt> argument to <tt>sh()</tt>.
+
+The output script produced is:
+<pre>
+OP_HASH160 <SCRIPT_hash160> OP_EQUAL
+</pre>
+
+==Test Vectors==
+
+TBD
+
+==Backwards Compatibility==
+
+<tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt> descriptors use the format and general operation specified in [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
+As these are a wholly new descriptors, they are not compatible with any implementation.
+However the scripts produced are standard scripts so existing software are likely to be familiar with them.
+
+==Reference Implemntation==
+
+<tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt> descriptors have been implemented in Bitcoin Core since version 0.17.
diff --git a/bip-descriptors-raw-addr.mediawiki b/bip-descriptors-raw-addr.mediawiki
new file mode 100644
index 0000000000..16df1446cd
--- /dev/null
+++ b/bip-descriptors-raw-addr.mediawiki
@@ -0,0 +1,57 @@
+<pre>
+  BIP: bip-descriptors-encap
+  Layer: Applications
+  Title: raw() and addr() Output Script Descriptors
+  Author: Andrew Chow <andrew@achow101.com>
+          Pieter Wuille <pieter@wuille.net>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-raw
+  Status: Draft
+  Type: Informational
+  Created: 2021-06-27
+  License: BSD-2-Clause
+</pre>
+
+==Abstract==
+
+This document specifies <tt>raw()</tt> and <tt>addr()</tt> output script descriptors.
+<tt>raw()</tt> encapsulates a raw script as a descriptor.
+<tt>addr()</tt> encapsulates an address as a descriptor.
+
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
+==Motivation==
+
+In order to make descriptors maximally compatible with scripts in use today, it is useful to be able to wrap any arbitrary output script or an address into a descriptor.
+
+==Specification==
+
+Two new script expressions are defined: <tt>raw()</tt> and <tt>addr()</tt>.
+
+===<tt>raw()</tt>===
+
+The <tt>raw(HEX)</tt> expression can only be used as a top level descriptor.
+As the argument, it takes a hex string representing a Bitcoin script.
+The output script produced by this descriptor is the script represented by <tt>HEX</tt>.
+
+===<tt>addr()</tt>===
+
+The <tt>addr(ADDR)</tt> expression can only be used as a top level descriptor.
+It takes an address as its single argument.
+The output script produced by this descriptor is the output script produced by the address <tt>ADDR</tt>.
+
+==Test Vectors==
+
+TBD
+
+==Backwards Compatibility==
+
+<tt>raw()</tt> and <tt>addr()</tt> descriptors use the format and general operation specified in [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
+As this is a wholly new descriptor, it is not compatible with any implementation.
+The reuse of existing Bitcoin addresses allows for this to be more easily implemented.
+
+==Reference Implemntation==
+
+<tt>raw()</tt> and <tt>addr</tt> descriptors have been implemented in Bitcoin Core since version 0.17.
diff --git a/bip-descriptors-segwit.mediawiki b/bip-descriptors-segwit.mediawiki
new file mode 100644
index 0000000000..438ef6a55c
--- /dev/null
+++ b/bip-descriptors-segwit.mediawiki
@@ -0,0 +1,70 @@
+<pre>
+  BIP: bip-descriptors-segwit
+  Layer: Applications
+  Title: segwit Output Script Descriptors
+  Author: Pieter Wuille <pieter@wuille.net>
+          Andrew Chow <andrew@achow101.com>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-segwit
+  Status: Draft
+  Type: Informational
+  Created: 2021-06-27
+  License: BSD-2-Clause
+</pre>
+
+==Abstract==
+
+This document specifies <tt>wpkh()</tt>, and <tt>wsh()</tt> output script descriptors.
+<tt>wpkh()</tt> descriptors take a key and produces a P2WPKH output script.
+<tt>wsh()</tt> descriptors take a script and produces a P2WSH output script.
+
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
+==Motivation==
+
+Segregated Witness added 2 additional standard output script formats: P2WPKH and P2WSH.
+These expressions allow specifying those formats as a descriptor.
+
+==Specification==
+
+Two new script expressions are defined: <tt>wpkh()</tt>, and <tt>wsh()</tt>.
+
+===<tt>wpkh()</tt>===
+
+The <tt>wpkh(KEY)</tt> expression can be used as a top level expression, or inside of a <tt>sh()</tt> descriptor.
+It takes a single key expression as an argument and produces a P2WPKH output script.
+Only keys which are/has compressed public keys can be contained in a <tt>wpkh()</tt> expression.
+
+The output script produced is:
+<pre>
+OP_0 <KEY_hash160>
+</pre>
+
+===<tt>wsh()</tt>===
+
+The <tt>wsh(SCRIPT)</tt> expression can be used as a top level expression, or inside of a <tt>sh()</tt> descriptor.
+It takes a single script expression as an argument and produces a P2WSH output script.
+<tt>wsh()</tt> expressions also create a witnessScript which is required in order to spend outputs which use its output script.
+This redeemScript is the output script produced by the <tt>SCRIPT</tt> argument to <tt>wsh()</tt>.
+Any key expression found in any script expression contained by a <tt>wsh()</tt> expression must only produce compresed public keys.
+
+The output script produced is:
+<pre>
+OP_0 <SCRIPT_sha256>
+</pre>
+
+==Test Vectors==
+
+TBD
+
+==Backwards Compatibility==
+
+<tt>wpkh()</tt>, and <tt>wsh()</tt> descriptors use the format and general operation specified in [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
+As these are a wholly new descriptors, they are not compatible with any implementation.
+However the scripts produced are standard scripts so existing software are likely to be familiar with them.
+
+==Reference Implemntation==
+
+<tt>wpkh()</tt>, and <tt>wsh()</tt> descriptors have been implemented in Bitcoin Core since version 0.17.
diff --git a/bip-descriptors-tr.mediawiki b/bip-descriptors-tr.mediawiki
new file mode 100644
index 0000000000..e9c39d842b
--- /dev/null
+++ b/bip-descriptors-tr.mediawiki
@@ -0,0 +1,101 @@
+<pre>
+  BIP: bip-descriptors-tr
+  Layer: Applications
+  Title: tr() Output Script Descriptors
+  Author: Pieter Wuille <pieter@wuille.net>
+          Andrew Chow <andrew@achow101.com>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-tr
+  Status: Draft
+  Type: Informational
+  Created: 2021-06-27
+  License: BSD-2-Clause
+</pre>
+
+==Abstract==
+
+This document specifies <tt>tr()</tt> output script descriptors.
+<tt>tr()</tt> descriptors take a key and optionally a tree of scripts and produces a P2TR output script.
+
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
+==Motivation==
+
+Taproot added one additional standard output script format: P2TR.
+These expressions allow specifying those formats as a descriptor.
+
+==Specification==
+
+A new script expressions are defined: <tt>tr()</tt>.
+A new expression is defined: Tree Expressions
+
+===Tree Expression===
+
+A Tree Expression (denoted <tt>TREE</tt>) is an expression which represents a tree of scripts.
+The way the tree is represented in an output script is dependent on the higher level expressions.
+
+A Tree Expression is:
+* Any Script Expression that is allowed at the level this Tree Expression is in.
+* A pair of Tree Expressions consisting of:
+** An open brace <tt>{</tt>
+** A Tree Expression
+** A comma <tt>,</tt>
+** A Tree Expression
+** A closing brance <tt>}</tt>
+
+===<tt>tr()</tt>===
+
+The <tt>tr(KEY)</tt> or <tt>tr(KEY, TREE)</tt> expression can only be used as a top level expression.
+All key expressions under any <tt>tr()</tt> expression must create x-only public keys.
+
+<tt>tr(KEY)</tt> takes a single key expression as an argument and produces a P2TR output script which does not have a script path.
+The keys produced by the key expression are used as the internal key as specified by [[bip-0341.mediawiki#cite_ref-22-0|BIP 341]].
+Specifically, "If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path.
+This can be achieved by computing the output key point as ''Q = P + int(hash<sub>TapTweak</sub>(bytes(P)))G''."
+
+<pre>
+internal_key:       lift_x(KEY)
+32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G
+scriptPubKey:       OP_1 <32_byte_output_key>
+</pre>
+
+<tt>tr(KEY, TREE)</tt> takes a key expression as the first argument, and a tree expression as the second argument and produces a P2TR output script which has a script path.
+The keys produced by the first key expression are used as the internal key as specified by [[bip-0341.mediawiki#Constructing_and_spending_Taproot_outputs|BIP 341]].
+The Tree expression becomes the Taproot script tree as described in BIP 341.
+A merkle root is computed from this tree and combined with the internal key to create the Taproot output key.
+
+<pre>
+internal_key:       lift_x(KEY)
+merkle_root:        HashTapBranch(TREE)
+32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key) || merkle_root))G
+scriptPubKey:       OP_1 <32_byte_output_key>
+</pre>
+
+===Modified Key Expression===
+
+Key Expressions within a <tt>tr()</tt> expression must only create x-only public keys.
+Uncompressed public keys are not allowed, but compressed public keys may be implicitly converted to x-only public keys.
+The keys derived from extended keys must be serialized as x-only public keys.
+An additional key expression is defined only for use within a <tt>tr()</tt> descriptor:
+
+* A 64 hex character string representing an x-only public key
+
+==Test Vectors==
+
+TBD
+
+==Backwards Compatibility==
+
+<tt>tr()</tt> descriptors use the format and general operation specified in [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
+As these are a wholly new descriptors, they are not compatible with any implementation.
+However the scripts produced are standard scripts so existing software are likely to be familiar with them.
+
+Tree Expressions are largely incompatible with existing script expressions due to the restrictions in those expressions.
+As of 2021-06-27, the only allowed script expression that can be used in a tree expression is <tt>pk()</tt>.
+However there will be future BIPs that specify script expressions that can be used in tree expressions.
+
+==Reference Implementation==
+
+<tt>tr()</tt> descriptors have been implemented in Bitcoin Core since version 22.0.