Descriptors by achow101 · Pull Request #3 · achow101/bips

achow101 · 2021-07-02T20:04:25Z

For review.

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

bip-descriptors-general.mediawiki

bip-descriptors-multi.mediawiki

nothingmuch

could use some clarification of how bip 32 key expressions interact with contexts that require compressed vs. x-only pubkeys

bip-descriptors-tr.mediawiki

bip-descriptors-general.mediawiki

nothingmuch · 2021-07-04T03:02:05Z

bip-descriptors-multi.mediawiki

+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.


does otherwise refer only to wsh()? since tapscript accounts for sigops differently, perhaps it makes sense to narrow that down

Yes, but multi cannot be used in a tapscript (yet).

nothingmuch · 2021-07-04T03:25:45Z

bip-descriptors-general.mediawiki

+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.


maybe worth mentioning that when the final step /*h it's not just an extended key but a private one?

/*h does not require that the derivation make private keys, however it does require that the xprv is available to do the derivation.

yep, the latter is what I'm suggesting to clarify, something like this perhaps:

Suggested change

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.

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.

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?

I think that's a fair assessment.

nothingmuch · 2021-07-04T03:38:37Z

bip-descriptors-general.mediawiki

+** 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


are x-only public keys supported for use outside of of tr?

No. I've removed this line and added a section to bip-descriptor-tr.mediawiki to specify the key expression semantics for tr().

nothingmuch · 2021-07-04T03:45:52Z

bip-descriptors-tr.mediawiki

+===<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.


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.

I don't quite follow. Keys derived at any path within a tr() must be x-only pubkeys. There are no derivation path limitations.

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).

nothingmuch · 2021-07-06T18:54:06Z

bip-descriptors-general.mediawiki

+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.


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?

bip-descriptors-general.mediawiki

Rspigler · 2021-07-08T20:38:16Z

Concept ACK. It is great that descriptors are being fully standardized! Also support splitting off descriptors-general from the rest of the docs.

achow101 · 2021-07-14T22:09:41Z

Moving to the BIPs repo: bitcoin#1143

Update OP_CAT implementation code

chirag64 and others added 12 commits June 6, 2021 17:34

Updated URL of the JavaScript reference implementation

cdbe675

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.

Replaces Bech32 by Bech32m in BIP341

5919ade

Segwit version 1 is encoded by Bech32m given by BIP350

BIP155: extra-clarify the semantic of sendaddrv2

337114b

psbt2: Fix field number counting

70e37e0

PSBT_OUT_SCRIPT should be 0x04, not 0x03.

Remove typo: plural

c8d0e63

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'

Merge pull request bitcoin#1135 from achow101/psbt2-fieldnum-typo

3cc3c96

psbt2: Fix field number counting

Merge pull request bitcoin#1134 from vasild/bip155_clarify_sendaddrv2

ee0f1c3

BIP155: extra-clarify the semantic of sendaddrv2

Merge pull request bitcoin#1133 from Raulo/bip341bech32mfix

cdd8dfd

Replaces Bech32 by Bech32m in BIP341

Specify BIP 86: Key Derivation for Single Key P2TR Outputs

330b56b

Merge pull request bitcoin#1136 from tcharding/bip-32

8659829

Remove typo: plural

Merge pull request bitcoin#1137 from achow101/taproot-bip44

07228b6

BIP 86: Key Derivation for Single Key P2TR Outputs

Merge pull request bitcoin#1127 from chirag64/patch-1

ad745f2

Updated URL of the JavaScript reference implementation

achow101 force-pushed the descriptors branch from 8f851d3 to 195e1d2 Compare July 3, 2021 05:07

nothingmuch reviewed Jul 3, 2021

View reviewed changes

bip-descriptors-general.mediawiki Outdated Show resolved Hide resolved

bip-descriptors-multi.mediawiki Outdated Show resolved Hide resolved

nothingmuch reviewed Jul 4, 2021

View reviewed changes

achow101 force-pushed the descriptors branch 2 times, most recently from 0f75c74 to 25b7ede Compare July 6, 2021 18:48

nothingmuch reviewed Jul 6, 2021

View reviewed changes

achow101 added 7 commits July 6, 2021 15:11

Specify BIP-descriptors-general

f964dea

Specify bip-descriptors-non-segwit

38157a5

Specify bip-descriptors-segwit

148b0ba

Specify bip-descriptors-multi

cc4f085

Specify bip-descriptors-combo

0df4822

Specify bip-descriptors-raw-addr

9f64478

Specify bip-descriptors-tr

a4c0b26

achow101 force-pushed the descriptors branch from 25b7ede to a4c0b26 Compare July 6, 2021 19:11

achow101 closed this Jul 14, 2021

Rspigler mentioned this pull request Jul 27, 2021

[BIPs 380-386] Output Script Descriptors bitcoin/bips#1143

Merged

achow101 pushed a commit that referenced this pull request Jun 6, 2024

Merge pull request #3 from 0xBEEFCAF3/cat

35641a8

Update OP_CAT implementation code

		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.

Conversation

achow101 commented Jul 2, 2021

Uh oh!

Uh oh!

Uh oh!

nothingmuch left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

achow101 Jul 6, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Rspigler commented Jul 8, 2021

Uh oh!

achow101 commented Jul 14, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

achow101 Jul 6, 2021 •

edited

Loading