390: clarifications on KEY expression restrictions #1871

achow101 commented at 10:06 PM on June 18, 2025: member

Clarifies the restrictions on KEY expressions around when child derivation is allowed.

Also added a Requires header to all of the descriptor BIPs since they require reading 380 first.

descriptors: Require BIP 380

All of BIPs describing new descriptors require BIP 380

bc66fdb166

achow101 force-pushed on Jun 18, 2025

murchandamus commented at 10:58 PM on June 18, 2025: contributor

Thanks, looks good to me.

jonatack added the label Proposed BIP modification on Jun 18, 2025

in bip-0390.mediawiki:64 in 23e78b68df outdated

  69 | +described above, with the keys also being sorted after all derivation and prior to aggregation.
  70 | +Then further BIP 32 derivation will be performed on the aggregate public key as described in
  71 | +[[bip-0328.mediawiki|BIP 328]]. The <tt>/NUM/.../*</tt> following the <tt>musig()</tt> specifies
  72 | +the derivation path to be used when deriving from the aggregate public key. <tt>/*</tt> is also
  73 | +optional. As there is no aggregate private key, only unhardened derivation from the aggregate public
  74 | +key is allowed. Thus these derivation steps cannot contain be <tt>/NUMh</tt> or <tt>/NUM'</tt>

jonatack commented at 11:54 PM on June 18, 2025:

s/contain be/contain/ ?

achow101 commented at 12:13 AM on June 19, 2025:

Done

in bip-0390.mediawiki:61 in 23e78b68df outdated

  66 | +contains child derivation as specified by <tt>/*</tt> or multipath as specified with
  67 | +<tt>/<NUM;NUM;...></tt>, in addition to the same usage restrictions as in the previous section. The KEY expressions
  68 | +additionally must be xpubs or derived from xpubs. The aggregate public key is first computed as
  69 | +described above, with the keys also being sorted after all derivation and prior to aggregation.
  70 | +Then further BIP 32 derivation will be performed on the aggregate public key as described in
  71 | +[[bip-0328.mediawiki|BIP 328]]. The <tt>/NUM/.../*</tt> following the <tt>musig()</tt> specifies

jonatack commented at 11:55 PM on June 18, 2025:

(in passing, should 390 require 328?)

achow101 commented at 12:14 AM on June 19, 2025:

I guess so. added

390: Additional clarifications on KEY expression restrictions c754a4d095

in bip-0389.mediawiki:12 in 23e78b68df outdated

   8 | @@ -9,6 +9,7 @@
   9 |    Type: Informational
  10 |    Created: 2022-07-26
  11 |    License: BSD-2-Clause
  12 | +  Requires: 380

jonatack commented at 11:59 PM on June 18, 2025:

Checked that 388 (omitted from this change) does not also require 380

achow101 force-pushed on Jun 19, 2025

in bip-0390.mediawiki:63 in c754a4d095

  68 | +additionally must be xpubs or derived from xpubs. The aggregate public key is first computed as
  69 | +described above, with the keys also being sorted after all derivation and prior to aggregation.
  70 | +Then further BIP 32 derivation will be performed on the aggregate public key as described in
  71 | +[[bip-0328.mediawiki|BIP 328]]. The <tt>/NUM/.../*</tt> following the <tt>musig()</tt> specifies
  72 | +the derivation path to be used when deriving from the aggregate public key. <tt>/*</tt> is also
  73 | +optional. As there is no aggregate private key, only unhardened derivation from the aggregate public

rkrux commented at 11:49 AM on June 19, 2025:

<tt>/*</tt> is also optional.

So musig(xpub.../1,xpub.../2)/3/4 will be treated as musig(xpub.../1,xpub.../2)/3/4/*? If yes, I understand it's being provided to reduce verbosity but one with an explicit /* at the end would get rid of any possibility of a doubt in the mind of a reader imho.

rkrux commented at 1:35 PM on June 19, 2025:

So musig(xpub.../1,xpub.../2)/3/4 will be treated as musig(xpub.../1,xpub.../2)/3/4/*?

On second thought, I think this is not what this means, they both will be treated separately. Sorry I didn't mean to add more confusion.

rkrux commented at 11:51 AM on June 19, 2025: contributor

The new verbiage is better and mostly not confusing - asked one question.

jonatack commented at 2:19 AM on June 20, 2025: member

ACK c754a4d095704228de928deb817cda47a6499e3e

jonatack merged this on Jun 20, 2025

jonatack closed this on Jun 20, 2025