Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 09919C000E for ; Thu, 5 Aug 2021 14:36:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id D682960767 for ; Thu, 5 Aug 2021 14:36:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=sprovoost.nl header.b="XFrbWjBV"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="dy9GxCLx" Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swz_PUsNm48t for ; Thu, 5 Aug 2021 14:36:05 +0000 (UTC) X-Greylist: delayed 00:08:45 by SQLgrey-1.8.0 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by smtp3.osuosl.org (Postfix) with ESMTPS id 4A4C060758 for ; Thu, 5 Aug 2021 14:36:05 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id EBAF05C010F; Thu, 5 Aug 2021 10:27:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 05 Aug 2021 10:27:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h= from:content-type:mime-version:subject:date:references:to :in-reply-to:message-id; s=fm3; bh=NwbQjxzvkeLtlC1K8GqCAsMDtOIeP AzgKm59TNiYXEA=; b=XFrbWjBVIeWaLtVh+AghdJKHvlXCJS74VA2VvVuULLuv0 +rH48PSMk6Knd5knZlf45LFKXnUjO1LQbmJT6m/Y7PHg28wiu+K1Xd6hS8p7Io1n QfEg2/X9wmbrhzAddK5+7+W3UQBkHCIM8ZfQxtqQaTEinFm0hZ8mYfXTYGP5p6wu 7M/LhTuQTgAP4eXoPM5Z2YgCVTI3oi9sfJw5YHpqgJy3DEerQQf/5w8z2T0VnvWK x/b/Nc6mjcPZOJXW68VppmgZ2ogYO1y4modsmI/upqn8zwBlAYAN8Q/IoKXARjO1 Ym8QWrxoTHMAqWOewKg548xuYJZrn5UMIiw1Kl9Aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=NwbQjx zvkeLtlC1K8GqCAsMDtOIePAzgKm59TNiYXEA=; b=dy9GxCLxzGgHAwQZNXNbq8 ii9doCZgJjPmUyUXiSNaXD16zL2i4zAUvZCyB9nRTK2AnxwTfJYdnqnKjS/sq+NS ZyaXJ2vx6cDK5bBrR32PFtAIXdNXgRRzALCQHJUizcIeUrwHV8IFPYPXTXt3P3wq 1x2FcpOYIlYrfqYiaUOcnul5pMVw7WuY48gCNqWuv8MMAteKJWM5FFDteXqLwLWc 1an14tbiwp+OuuBTDdvSiiBf158QwD45uVcCeQqhqNBDu6FRplhMYJI3Y2/yMbCH CjCPCHG9OufeDENLKys55a09ZHibYu2qIkRhzQQFYYGI+QwWBvwAXybWUnGF5lCg == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrieelgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhtggguffffhfvjgfkofesghdtmherhhdtvdenucfhrhhomhepufhjohhrshcu rfhrohhvohhoshhtuceoshhjohhrshesshhprhhovhhoohhsthdrnhhlqeenucggtffrrg htthgvrhhnpefggefggeeufeevheeuheetleektdejvddvjedtteffgeeiffehudelieej leelueenucffohhmrghinhepghhithhhuhgsrdgtohhmpdgsihhttghoihhnrdhithdplh hinhhugihfohhunhgurghtihhonhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehsjhhorhhssehsphhrohhvohhoshhtrdhnlh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 5 Aug 2021 10:27:14 -0400 (EDT) From: Sjors Provoost 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 , Bitcoin Dev In-Reply-To: <1eb7b635-094c-a583-7dc0-21cea58ed1fb@achow101.com> Message-Id: <38AE919F-7EA2-4CF4-9AF8-7E38C7542C59@sprovoost.nl> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Mailman-Approved-At: Thu, 05 Aug 2021 15:06:42 +0000 Subject: Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 14:36:08 -0000 --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 raw(HEX) 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 = 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 >
>   BIP: bip-descriptors-general
>   Layer: Applications
>   Title: Output Script Descriptors General Operation
>   Author: Pieter Wuille 
>           Andrew Chow 
>   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
> 
>=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 SCRIPT. > This expression may be followed by #CHECKSUM, where > CHECKSUM is an 8 character alphanumeric descriptor checksum. >=20 > =3D=3D=3DScript Expressions=3D=3D=3D >=20 > Script Expressions (denoted SCRIPT) 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 KEY). > 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 [ > ** Exactly 8 hex characters for the fingerprint of the key where the > derivation starts (see BIP 32 for details) > ** Followed by zero or more /NUM or /NUM' path > elements to indicate the unhardened or hardened derivation steps = between > the fingerprint and the key that follows. > ** A closing bracket ] > * 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 02 or 03 > representing a compressed public key > *** 130 hex character string beginning with 04 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 > ** xpub encoded extended public key or xprv encoded > extended private key (as defined in BIP 32) > *** Followed by zero or more /NUM or /NUM' path > elements indicating BIP 32 derivation steps to be taken after the = given > extended key. > *** Optionally followed by a single /* or /*' final > step to denote all direct unhardened or hardened children. >=20 > If the KEY 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 /* or /*', 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 ' may be > replaced with alternative hardnened indicators of h or = H. >=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: >
> 0123456789()[],'/*abcdefgh@:$%{}
> IJKLMNOPQRSTUVWXYZ&+-.;<=3D>?!^_|~
> ijklmnopqrstuvwxyzABCDEFGH`#"\
> 
> Note that 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 > (#) 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 > 0123456789()[],'/*abcdefgh@:$%{} for another in that set = always > counts as 1 symbol error. > *** Note that hex encoded keys are covered by these characters. = Extended > keys (xpub and xprv) use other characters too, but > also have their own checksum mechansim. > *** SCRIPT 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 240 of being > undetected. >=20 > The checksum itself uses the same character set as bech32: > qpzry9x8gf2tvdw0s3jn54khce6mua7l >=20 > Valid descriptor strings with a checksum must pass the criteria for > validity specified by the Python3 code snippet below. > The function descsum_check must return true when its argument > s is a descriptor consisting in the form = SCRIPT#CHECKSUM. >=20 >
> 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
> 
>=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 >
> 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
> 
>=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 >
>   BIP: bip-descriptors-segwit
>   Layer: Applications
>   Title: segwit Output Script Descriptors
>   Author: Pieter Wuille 
>           Andrew Chow 
>   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
> 
>=20 > =3D=3DAbstract=3D=3D >=20 > This document specifies wpkh(), and wsh() output > script descriptors. > wpkh() descriptors take a key and produces a P2WPKH output = script. > wsh() 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: wpkh(), and = wsh(). >=20 > =3D=3D=3Dwpkh()=3D=3D=3D >=20 > The wpkh(KEY) expression can be used as a top level = expression, > or inside of a sh() 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 > wpkh() expression. >=20 > The output script produced is: >
> OP_0 
> 
>=20 > =3D=3D=3Dwsh()=3D=3D=3D >=20 > The wsh(SCRIPT) expression can be used as a top level > expression, or inside of a sh() descriptor. > It takes a single script expression as an argument and produces a = P2WSH > output script. > wsh() 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 SCRIPT > argument to wsh(). > Any key expression found in any script expression contained by a > wsh() expression must only produce compresed public keys. >=20 > The output script produced is: >
> OP_0 
> 
>=20 > =3D=3DTest Vectors=3D=3D >=20 > TBD >=20 > =3D=3DBackwards Compatibility=3D=3D >=20 > wpkh(), and wsh() 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 > wpkh(), and wsh() descriptors have been implemented = in > Bitcoin Core since version 0.17. >=20 > --- >=20 >
>   BIP: bip-descriptors-non-segwit
>   Layer: Applications
>   Title: Non-segwit Output Script Descriptors
>   Author: Pieter Wuille 
>           Andrew Chow 
>   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
> 
>=20 > =3D=3DAbstract=3D=3D >=20 > This document specifies pk(), pkh(), and = sh() > output script descriptors. > pk() descriptors take a key and produces a P2PK output = script. > pkh() descriptors take a key and produces a P2PKH output = script. > sh() 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: pk(), = pkh(), > and sh(). >=20 > =3D=3D=3Dpk()=3D=3D=3D >=20 > The pk(KEY) 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: >
>  OP_CHECKSIG
> 
>=20 > =3D=3D=3Dpkh()=3D=3D=3D >=20 > The pkh(KEY) expression can be used as a top level = expression, > or inside of either a sh() or wsh() 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: >
> OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG
> 
>=20 > =3D=3D=3Dsh()=3D=3D=3D >=20 > The sh(SCRIPT) 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. > sh() 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 SCRIPT > argument to sh(). >=20 > The output script produced is: >
> OP_HASH160  OP_EQUAL
> 
>=20 > =3D=3DTest Vectors=3D=3D >=20 > TBD >=20 > =3D=3DBackwards Compatibility=3D=3D >=20 > pk(), pkh(), and sh() 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 > pk(), pkh(), and sh() descriptors have been > implemented in Bitcoin Core since version 0.17. >=20 > --- >=20 >
>   BIP: bip-descriptors-tr
>   Layer: Applications
>   Title: tr() Output Script Descriptors
>   Author: Pieter Wuille 
>           Andrew Chow 
>   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
> 
>=20 > =3D=3DAbstract=3D=3D >=20 > This document specifies tr() output script descriptors. > tr() 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: tr(). > A new expression is defined: Tree Expressions >=20 > =3D=3D=3DTree Expression=3D=3D=3D >=20 > A Tree Expression (denoted TREE) 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 { > ** A Tree Expression > ** A comma , > ** A Tree Expression > ** A closing brance } >=20 > =3D=3D=3Dtr()=3D=3D=3D >=20 > The tr(KEY) or tr(KEY, TREE) expression can only be > used as a top level expression. > All key expressions under any tr() expression must create > x-only public keys. >=20 > tr(KEY 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(hashTapTweak(bytes(P)))G''." >=20 >
> internal_key:       lift_x(KEY)
> 32_byte_output_key: internal_key + =
int(HashTapTweak(bytes(internal_key)))G
> scriptPubKey:       OP_1 <32_byte_output_key>
> 
>=20 > tr(KEY, TREE) 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 >
> 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>
> 
>=20 > =3D=3DTest Vectors=3D=3D >=20 > TBD >=20 > =3D=3DBackwards Compatibility=3D=3D >=20 > tr() 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 pk(). > However there will be future BIPs that specify script expressions that > can be used in tree expressions. >=20 > =3D=3DReference Implemntation=3D=3D >=20 > tr() descriptors have been implemented in Bitcoin Core since > version 22.0. >=20 > --- >=20 >
>   BIP: bip-descriptors-multi
>   Layer: Applications
>   Title: Multisig Output Script Descriptors
>   Author: Pieter Wuille 
>           Andrew Chow 
>   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
> 
>=20 > =3D=3DAbstract=3D=3D >=20 > This document specifies multi(), and sortedmulti() > output script descriptors. > Both functions take a threshold and one or more public keys and = produce > a multisig output script. > multi() specifies the public keys in the output script in the > order given in the descriptor while sortedmulti() 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: multi(), and > sortedmulti(). > Both expressions produce the scripts of the same template and take the > same arguments. > They are written as multi(k,KEY_1,KEY_2,...,KEY_n). > k is the threshold - the number of keys that must sign the > input for the script to be valid. > KEY_1,KEY_2,...,KEY_n are the key expressions for the = multisig. > k must be less than or equal to n. >=20 > multi() and sortedmulti() expressions can be used as = a > top level expression, or inside of either a sh() or > wsh() 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 > n. > When used at the top level, there can only be at most 3 keys. > When used inside of a sh() 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 k. If > k is less than or equal to 16: >
> OP_k KEY_1 KEY_2 ... KEY_n OP_CHECKMULTISIG
> 
>=20 > if k is greater than 16: >
> k KEY_1 KEY_2 ... KEY_n OP_CHECKMULTISIG
> 
>=20 > =3D=3D=3Dsortedmulti()=3D=3D=3D >=20 > The only change for sortedmulti() 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
=3D=3D=3D >=20 > When one or more the key expressions in a multi() or > sortedmulti() 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 > multi(), and sortedmulti() 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 > multi(), and multi() descriptors have been = implemented > in Bitcoin Core since version 0.17. >=20 > --- >=20 >
>   BIP: bip-descriptors-combo
>   Layer: Applications
>   Title: combo() Output Script Descriptors
>   Author: Pieter Wuille 
>           Andrew Chow 
>   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
> 
>=20 > =3D=3DAbstract=3D=3D >=20 > This document specifies combo() 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: combo(KEY). > 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 combo() expression always produces a P2PK and P2PKH script, > the same as putting the key in both a pk() and a = pkh() > 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 > wpkh() and sh(wpkh()) expression. >=20 > =3D=3DTest Vectors=3D=3D >=20 > TBD >=20 > =3D=3DBackwards Compatibility=3D=3D >=20 > combo() 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 > combo descriptors have been implemented in Bitcoin Core since > version 0.17. >=20 > --- >=20 >
>   BIP: bip-descriptors-encap
>   Layer: Applications
>   Title: raw() and addr() Output Script Descriptors
>   Author: Andrew Chow 
>           Pieter Wuille 
>   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
> 
>=20 > =3D=3DAbstract=3D=3D >=20 > This document specifies raw() and addr() output = script > descriptors. > raw() encapsulates a raw script as a descriptor. > addr() 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: raw() and = addr(). >=20 > =3D=3D=3Draw()=3D=3D=3D >=20 > The raw(HEX) 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 HEX. >=20 > =3D=3D=3Daddr()=3D=3D=3D >=20 > The addr(ADDR) 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 ADDR. >=20 > =3D=3DTest Vectors=3D=3D >=20 > TBD >=20 > =3D=3DBackwards Compatibility=3D=3D >=20 > raw() and addr() 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 > raw() and addr 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--