From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_A38682E3-D2A1-42A2-82F5-096C24AF5825";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Thu, 5 Aug 2021 16:27:12 +0200
References: <1eb7b635-094c-a583-7dc0-21cea58ed1fb@achow101.com>
To: Andrew Chow <achow101-lists@achow101.com>,
 Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <1eb7b635-094c-a583-7dc0-21cea58ed1fb@achow101.com>
Message-Id: <38AE919F-7EA2-4CF4-9AF8-7E38C7542C59@sprovoost.nl>
Subject: Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors
Precedence: list


--Apple-Mail=_A38682E3-D2A1-42A2-82F5-096C24AF5825
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Thanks for writing this up!

I think your modular BIP approach makes sense. (the abstract should =
mention this too)

Contents look good to me, modulo missing test vectors. I also suggest =
dropping combo(), see below.


Regarding the use of h vs ', especially since they result in a different =
checksum, and equality is more tedious to verify, should we just pick =
one and recommend that software normalises to that?

For bip-descriptors-segwit, regardless of what Bitcoin Core does, is any =
hex encoded script allowed for wsh()? If so is it mandatory and/or =
allowed to use raw() as a sub descriptor?

Conversely, its BIP says: "The <tt>raw(HEX)</tt> expression can only be =
used as a top level descriptor". That answers the above, but not the =
why.

In the backwards compatibility section it may be worth pointing out that =
descriptors are also used by:
* Specter since at least v1.2.2: =
https://github.com/cryptoadvance/specter-desktop/releases/tag/v1.2.2
* Coldcard since 2.0.1: =
https://github.com/Coldcard/firmware/commit/af00f8778947664f2d74f19879b98f=
7925feb327
* HWI since 1.0.3: =
https://github.com/bitcoin-core/HWI/releases/tag/1.0.3

None of these support the tr(), raw() and addr() descriptors afaik. HWI =
doesn't implement (sorted_)multi.

Does anyone actually use combo? It seems useless, because even with the =
help of BIP 88 there's no way to compress all three in a single =
descriptor, since BIP 44/49/84 each have a different derivation. Afaik =
Bitcoin Core doesn't really use them either. And for future wallet =
migration, we might as well make separate descriptors for each key type.

One thing on my wish list - for this BIP, BIP 88 (Hierarchical =
Deterministic Path Templates) or yet another one - is to include a birth =
date (minimum block height). E.g. =
tr([m/86'/0'/0']xpub.../{0-1}/*)>709631

And then of course there's the gap limit. Perhaps we just need a =
"metadata" format to go along with descriptors to track the birth data, =
gap limit and anything else you need (nonce collection for musig2 =
setup?). E.g. a simple dictionary: =
tr([m/86'/0'/0']xpub.../{0-1}/*){dob:709631,gap:1000}

- Sjors


> Op 29 jun. 2021, om 23:14 heeft Andrew Chow via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>=20
> Hi All,
>=20
> I've been working on formalizing the Output Script Descriptors that =
have
> been available in Bitcoin Core for a while into BIPs. Since =
descriptors
> are modular and have optional components, I've decided to split it =
into
> 7 BIPs, rather than a single one. The first describes descriptors in
> general and does not specify any particular descriptor. However it =
does
> describe the general operation, key expressions (including derivation
> paths and key origin info), and the descriptor checksum. The following =
6
> BIPs specify the actual descriptors themselves. These are non-segwit
> descriptor (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig
> descriptors (multi, sortedmulti), the taproot descriptor (tr), the =
combo
> descriptor, and opaque descriptors (raw, addr). This separation is so
> that implementors can choose to not implement some descriptors and =
still
> say which descriptors they support without being too difficult to
> understand.
>=20
> The text of all of the documents are below, and they can also be found
> on github:https://github.com/achow101/bips/tree/descriptors/
>=20
> Thanks,
> Andrew Chow
>=20
> ---
>=20
> <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>
>=20
> =3D=3DAbstract=3D=3D
>=20
> Output Script Descriptors are a simple language which can be used to
> describe collections ofoutput scripts.
> There can be many different descriptor fragments and functions.
> This document describes the general syntax for descriptors, descriptor
> checksums, and common expressions.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> =3D=3DSpecification=3D=3D
>=20
> 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.
>=20
> =3D=3D=3DScript Expressions=3D=3D=3D
>=20
> 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.
>=20
> 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.
>=20
> =3D=3D=3DKey Expressions=3D=3D=3D
>=20
> 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.
>=20
> 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>/NUM'</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
> *** 64 hex character string representing an x-only 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>/NUM'</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>/*'</tt> final
> step to denote all direct unhardened or hardened children.
>=20
> 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 serialized as a compressed public key.
>=20
> In the above specification, the hardened indicator <tt>'</tt> may be
> replaced with alternative hardnened indicators of <tt>h</tt> or =
<tt>H</tt>.
>=20
> =3D=3D=3DCharacter Set=3D=3D=3D
>=20
> The expressions used in descriptors must only contain characters =
within
> this character set so that the descriptor checksum will work.
>=20
> The allowed characters are:
> <pre>
> 0123456789()[],'/*abcdefgh@:$%{}
> IJKLMNOPQRSTUVWXYZ&+-.;<=3D>?!^_|~
> ijklmnopqrstuvwxyzABCDEFGH`#"\<space>
> </pre>
> Note that <tt><space></tt> on the last line is a space character.
>=20
> 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.
>=20
> =3D=3D=3DChecksum=3D=3D=3D
>=20
> 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.
>=20
> 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.
>=20
> The checksum itself uses the same character set as bech32:
> <tt>qpzry9x8gf2tvdw0s3jn54khce6mua7l</tt>
>=20
> 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>.
>=20
> <pre>
> INPUT_CHARSET =3D
> =
"0123456789()[],'/*abcdefgh@:$%{}IJKLMNOPQRSTUVWXYZ&+-.;<=3D>?!^_|~ijklmno=
pqrstuvwxyzABCDEFGH`#\"\\
> "
> CHECKSUM_CHARSET =3D "qpzry9x8gf2tvdw0s3jn54khce6mua7l"
> GENERATOR =3D [0xf5dee51989, 0xa9fdca3312, 0x1bab10e32d, 0x3706b1677a,
> 0x644d626ffd]
>=20
> def descsum_polymod(symbols):
>     """Internal function that computes the descriptor checksum."""
>     chk =3D 1
>     for value in symbols:
>         top =3D chk >> 35
>         chk =3D (chk & 0x7ffffffff) << 5 ^ value
>         for i in range(5):
>             chk ^=3D GENERATOR[i] if ((top >> i) & 1) else 0
>     return chk
>=20
> def descsum_expand(s):
>     """Internal function that does the character to symbol =
expansion"""
>     groups =3D []
>     symbols =3D []
>     for c in s:
>         if not c in INPUT_CHARSET:
>             return None
>         v =3D INPUT_CHARSET.find(c)
>         symbols.append(v & 31)
>         groups.append(v >> 5)
>         if len(groups) =3D=3D 3:
>             symbols.append(groups[0] * 9 + groups[1] * 3 + groups[2])
>             groups =3D []
>     if len(groups) =3D=3D 1:
>         symbols.append(groups[0])
>     elif len(groups) =3D=3D 2:
>         symbols.append(groups[0] * 3 + groups[1])
>     return symbols
>=20
> def descsum_check(s):
>     """Verify that the checksum is correct in a descriptor"""
>     if s[-9] !=3D '#':
>         return False
>     if not all(x in CHECKSUM_CHARSET for x in s[-8:]):
>         return False
>     symbols =3D descsum_expand(s[:-9]) + [CHECKSUM_CHARSET.find(x) for =
x
> in s[-8:]]
>     return descsum_polymod(symbols) =3D=3D 1
> </pre>
>=20
> 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.
>=20
> To construct a valid checksum given a script expression, the code =
below
> can be used:
>=20
> <pre>
> def descsum_create(s):
>     """Add a checksum to a descriptor without"""
>     symbols =3D descsum_expand(s) + [0, 0, 0, 0, 0, 0, 0, 0]
>     checksum =3D descsum_polymod(symbols) ^ 1
>     return s + '#' + ''.join(CHECKSUM_CHARSET[(checksum >> (5 * (7 -
> i))) & 31] for i in range(8))
>=20
> </pre>
>=20
> =3D=3DBackwards Compatibility=3D=3D
>=20
> 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.
>=20
> Output script descriptors are designed for future extension with =
further
> fragment types and new script expressions.
> These will be specified in additional BIPs.
>=20
> =3D=3DReference Implemntation=3D=3D
>=20
> Descriptors have been implemented in Bitcoin Core since version 0.17.
>=20
> ---
>=20
> <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>
>=20
> =3D=3DAbstract=3D=3D
>=20
> 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.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> Segregated Witness added 2 additional standard output script formats:
> P2WPKH and P2WSH.
> These expressions allow specifying those formats as a descriptor.
>=20
> =3D=3DSpecification=3D=3D
>=20
> Two new script expressions are defined: <tt>wpkh()</tt>, and =
<tt>wsh()</tt>.
>=20
> =3D=3D=3D<tt>wpkh()</tt>=3D=3D=3D
>=20
> 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.
>=20
> The output script produced is:
> <pre>
> OP_0 <KEY_hash160>
> </pre>
>=20
> =3D=3D=3D<tt>wsh()</tt>=3D=3D=3D
>=20
> 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.
>=20
> The output script produced is:
> <pre>
> OP_0 <SCRIPT_sha256>
> </pre>
>=20
> =3D=3DTest Vectors=3D=3D
>=20
> TBD
>=20
> =3D=3DBackwards Compatibility=3D=3D
>=20
> <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.
>=20
> =3D=3DReference Implemntation=3D=3D
>=20
> <tt>wpkh()</tt>, and <tt>wsh()</tt> descriptors have been implemented =
in
> Bitcoin Core since version 0.17.
>=20
> ---
>=20
> <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>
>=20
> =3D=3DAbstract=3D=3D
>=20
> 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.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> 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.
>=20
> =3D=3DSpecification=3D=3D
>=20
> Three new script expressions are defined: <tt>pk()</tt>, =
<tt>pkh()</tt>,
> and <tt>sh()</tt>.
>=20
> =3D=3D=3D<tt>pk()</tt>=3D=3D=3D
>=20
> 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.
>=20
> The output script produced is:
> <pre>
> <KEY> OP_CHECKSIG
> </pre>
>=20
> =3D=3D=3D<tt>pkh()</tt>=3D=3D=3D
>=20
> 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.
>=20
> The output script produced is:
> <pre>
> OP_DUP OP_HASH160 <KEY_hash160> OP_EQUALVERIFY OP_CHECKSIG
> </pre>
>=20
> =3D=3D=3D<tt>sh()</tt>=3D=3D=3D
>=20
> 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>.
>=20
> The output script produced is:
> <pre>
> OP_HASH160 <SCRIPT_hash160> OP_EQUAL
> </pre>
>=20
> =3D=3DTest Vectors=3D=3D
>=20
> TBD
>=20
> =3D=3DBackwards Compatibility=3D=3D
>=20
> <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.
>=20
> =3D=3DReference Implemntation=3D=3D
>=20
> <tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt> descriptors have been
> implemented in Bitcoin Core since version 0.17.
>=20
> ---
>=20
> <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>
>=20
> =3D=3DAbstract=3D=3D
>=20
> 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.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> Taproot added one additional standard output script format: P2TR.
> These expressions allow specifying those formats as a descriptor.
>=20
> =3D=3DSpecification=3D=3D
>=20
> A new script expressions are defined: <tt>tr()</tt>.
> A new expression is defined: Tree Expressions
>=20
> =3D=3D=3DTree Expression=3D=3D=3D
>=20
> 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.
>=20
> 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>
>=20
> =3D=3D=3D<tt>tr()</tt>=3D=3D=3D
>=20
> 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.
>=20
> <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 =3D P +
> int(hash<sub>TapTweak</sub>(bytes(P)))G''."
>=20
> <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>
>=20
> <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.
>=20
> <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>
>=20
> =3D=3DTest Vectors=3D=3D
>=20
> TBD
>=20
> =3D=3DBackwards Compatibility=3D=3D
>=20
> <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.
>=20
> 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.
>=20
> =3D=3DReference Implemntation=3D=3D
>=20
> <tt>tr()</tt> descriptors have been implemented in Bitcoin Core since
> version 22.0.
>=20
> ---
>=20
> <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>
>=20
> =3D=3DAbstract=3D=3D
>=20
> 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.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> The most common complex script used in Bitcoin is a threshold =
multisig.
> These expressions allow specifying multisig scripts as a descriptor.
>=20
> =3D=3DSpecification=3D=3D
>=20
> 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>.
>=20
> <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.
>=20
> 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.
>=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>
>=20
> if <tt>k</tt> is greater than 16:
> <pre>
> k KEY_1 KEY_2 ... KEY_n OP_CHECKMULTISIG
> </pre>
>=20
> =3D=3D=3D<tt>sortedmulti()</tt>=3D=3D=3D
>=20
> 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.
>=20
> =3D=3D=3DMultiple Extended Keys</tt>=3D=3D=3D
>=20
> 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.
>=20
> =3D=3DTest Vectors=3D=3D
>=20
> TBD
>=20
> =3D=3DBackwards Compatibility=3D=3D
>=20
> <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.
>=20
> =3D=3DReference Implemntation=3D=3D
>=20
> <tt>multi()</tt>, and <tt>multi()</tt> descriptors have been =
implemented
> in Bitcoin Core since version 0.17.
>=20
> ---
>=20
> <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>
>=20
> =3D=3DAbstract=3D=3D
>=20
> 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.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> 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.
>=20
> =3D=3DSpecification=3D=3D
>=20
> 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.
>=20
> =3D=3DTest Vectors=3D=3D
>=20
> TBD
>=20
> =3D=3DBackwards Compatibility=3D=3D
>=20
> <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.
>=20
> =3D=3DReference Implemntation=3D=3D
>=20
> <tt>combo</tt> descriptors have been implemented in Bitcoin Core since
> version 0.17.
>=20
> ---
>=20
> <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>
>=20
> =3D=3DAbstract=3D=3D
>=20
> 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.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> 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.
>=20
> =3D=3DSpecification=3D=3D
>=20
> Two new script expressions are defined: <tt>raw()</tt> and =
<tt>addr()</tt>.
>=20
> =3D=3D=3D<tt>raw()</tt>=3D=3D=3D
>=20
> 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>.
>=20
> =3D=3D=3D<tt>addr()</tt>=3D=3D=3D
>=20
> 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>.
>=20
> =3D=3DTest Vectors=3D=3D
>=20
> TBD
>=20
> =3D=3DBackwards Compatibility=3D=3D
>=20
> <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.
>=20
> =3D=3DReference Implemntation=3D=3D
>=20
> <tt>raw()</tt> and <tt>addr</tt> descriptors have been implemented in
> Bitcoin Core since version 0.17.
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_A38682E3-D2A1-42A2-82F5-096C24AF5825
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAmEL9UAACgkQV/+b28ww
EAkTmRAApLV8uwXo8KPsa/xc7Wf9wokXSkznolSuFhxEj4I/lrzHq3tYUu/moOhY
t0ITj4V8AXJP5BVkLGMcQ4UpSuM0s7KeVy5EX46ZIVBnnkqPOxsCcHSSOzD7TJFC
2QM8iqN5ehKR+h7bklHcaUfPucACyZ7k6ICJ6X3G2hmQOqvJoWSJz/H3Z4UZ9T2N
5kr0eEusN2slqgH5/JuQ63GdIHnPozxKWEBJ1Y/XW8bDdKLc1kDF2aXDci8CVAQZ
1HgRyHsg1Ia7jyPmt3lSPOGvBIcQPWTrdxxXfKizmto7hx3SOHfs3O1qz9eSpIwe
iZjSk2YB9UkbaoVXNqAdWYVQhX19ys6I8mepHPSfyJYNOq2O/ldHajK3aZGwohjD
ynSb1TA1MeRmMHa5SpGOSUeOyGOP+jGJ8kqKbXBX+TrNKGpHn3G6n5E1lykFO2Ji
ZLCDsx/gC+trmOOwDMf9i6KOxi20E6GwE9ev5Z0KoipQpAJesHpFKm4i9kv5gZK4
OL9V/XlubmxsegwcPn+GQXrDZ3UmVe5htiORFEMHih4CAuhCKJkXU/EOqDVmEJf3
URUeaIhx1L+SrIhnsO+q54Q/rrCX6YeOKLpzckGnP/6x/H/CHxRFPIMRODBQr3oI
1xmQUluza/QBfuAlZQzPCs1ql8sgFijWZJfmNfp/cYFnCw9QptE=
=zXkj
-----END PGP SIGNATURE-----

--Apple-Mail=_A38682E3-D2A1-42A2-82F5-096C24AF5825--