Descriptors #3
Descriptors #3
Conversation
Old repo is archived and links to the new repo are found in the old one's README file. This change updates the old repo's link to the new one.
Segwit version 1 is encoded by Bech32m given by BIP350
PSBT_OUT_SCRIPT should be 0x04, not 0x03.
This sentence should use a singular 'key' instead of 'keys'. Change 'knowing an extended public keys allows' to be 'knowing an extended public key allows'
psbt2: Fix field number counting
BIP155: extra-clarify the semantic of sendaddrv2
Replaces Bech32 by Bech32m in BIP341
Remove typo: plural
BIP 86: Key Derivation for Single Key P2TR Outputs
Updated URL of the JavaScript reference implementation
| 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. |
There was a problem hiding this comment.
does otherwise refer only to wsh()? since tapscript accounts for sigops differently, perhaps it makes sense to narrow that down
There was a problem hiding this comment.
Yes, but multi cannot be used in a tapscript (yet).
| 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. |
There was a problem hiding this comment.
maybe worth mentioning that when the final step /*h it's not just an extended key but a private one?
There was a problem hiding this comment.
/*h does not require that the derivation make private keys, however it does require that the xprv is available to do the derivation.
There was a problem hiding this comment.
yep, the latter is what I'm suggesting to clarify, something like this perhaps:
| 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. | |
| 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. | |
| When the final step is <tt>/*'</tt>, <tt>KEY</tt> must be a BIP 32 extended private key. |
There was a problem hiding this comment.
I'm not sure that it should require that implementations output a private key in this case. Obviously it isn't very useful to have hardened derivation with only an xpub, but I'm not sure about requiring it to be an xprv. Currently in Core we don't really handle this case, but there is a clear separation of when descriptors with private keys can be output.
There was a problem hiding this comment.
I think my comment can be disregarded.
Initially an xpub in that case seemed nonsensical to me, since on its own it can't actually be used to even verify that any child keys are related to it, and obviously it can't be used to derive them. However, it can still be used to refer to the set of child keys/scripts in a way that a wallet in possession of the xprv equivalent can interpret, as well to correlate descriptors with a fingerprint of the parent.
Is it fair to say that this is a description of the syntax, and that it is not strictly guaranteed that a syntactically valid descriptor can always be evaluated as some enumeration of concrete scripts?
There was a problem hiding this comment.
I think that's a fair assessment.
bip-descriptors-general.mediawiki
Outdated
| ** 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 |
There was a problem hiding this comment.
are x-only public keys supported for use outside of of tr?
There was a problem hiding this comment.
No. I've removed this line and added a section to bip-descriptor-tr.mediawiki to specify the key expression semantics for tr().
| ===<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. |
There was a problem hiding this comment.
does this include BIP-0086 derivation from an xpub? line 88 of bip-descriptors-general.mediawiki vaguely implies that maybe it doesn't, but the descriptions of tr's use of key expressions is consistent with other output types, implying that it does.
There was a problem hiding this comment.
I don't quite follow. Keys derived at any path within a tr() must be x-only pubkeys. There are no derivation path limitations.
There was a problem hiding this comment.
This is fully addressed by the updated version, I wasn't sure if only the 64 character literal was allowed, or if any sort of derivation (technically not necessarily BIP 86, just any descriptor ending in /* or e.g. /*h).
achow101
force-pushed
the
descriptors
branch
2 times, most recently
from
0f75c74
to
25b7ede
Compare
| 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. |
There was a problem hiding this comment.
I think my comment can be disregarded.
Initially an xpub in that case seemed nonsensical to me, since on its own it can't actually be used to even verify that any child keys are related to it, and obviously it can't be used to derive them. However, it can still be used to refer to the set of child keys/scripts in a way that a wallet in possession of the xprv equivalent can interpret, as well to correlate descriptors with a fingerprint of the parent.
Is it fair to say that this is a description of the syntax, and that it is not strictly guaranteed that a syntactically valid descriptor can always be evaluated as some enumeration of concrete scripts?
|
Concept ACK. It is great that descriptors are being fully standardized! Also support splitting off descriptors-general from the rest of the docs. |
|
Moving to the BIPs repo: bitcoin#1143 |
For review.