BIP32 Derivation of FROST Keys

[MatthewLM]

I've created this discussion for the potential of BIP32 derivation of FROST keys as I raised here: #584 (comment)

Because the private key is unknown, it is not possible to do hardened derivation in accordance with the BIP32 scheme. However it is possible to do unhardened derivation which could still be useful for deriving new keys without requiring DKG each time. This could be as simple as applying BIP32 tweaks to the group key and the private and public shares.

The chain code could be determined from the public shares without requiring any extension to the DKG protocol. However it has been pointed out that if the public shares are revealed, this would also reveal the chain code, and it would not be compatible with schemes that modify the set of public shares.

Therefore the master chain code might be best generated separately. This might be done by participants providing commitments to other participants first before sharing values that are combined into a chain code.

Perhaps it's not so important to have public commitments for the chain code as a malicious participant could leak the chain code in any event and does it matter if they could manipulate its value? Participants should always behave as if the chain code is public information and ultimately details about relationships between keys could be leaked. However BIP32 provides some advantages over only having a single key or having to generate many keys.

Are there any other considerations for, or implications of BIP32 derivation? Maybe there are potential improvements to be had over BIP32?

[conradoplg]

Hi! Thank you for opening this. This is something that we're interested in but we need to look more closely into it. I'll keep you posted.

[jesseposner]

A fixed chaincode could be used, similar to the MuSig2 Derivation BIP:

A synthetic xpub can be created from a BIP 327 MuSig2 plain aggregate public key by setting
the depth to 0, the child number to 0, and attaching a chaincode with the byte string
868087ca02a6f974c4598924c36b57762d32cb45717167e300622c7167e38965'''Where does this
constant chaincode come from?''' It is the SHA256 of the text MuSig2MuSig2MuSig2.
This fixed chaincode should be used by all such synthetic xpubs following this specification.
Unhardened child public keys can be derived from the synthetic xpub as with any other xpub.

[jesseposner]

The static chaincode only applies to the root xpub though. The signers retain the option of deriving a child xpub, which will have a random chaincode and not reveal the use of FROST.

[conduition]

You're correct, but it depends on how you want the final xpub to look. For best privacy, you might want it to look exactly like a normal taproot xpub (derived from a master key at m/86'/0'/0'), so you'd need it to have a child number of 0x80000000 and a depth number of 3. This would necessitate straying outside the BIP32 standard and modifying the child xpub's embedded index.

I suppose if that's acceptable then sure, it'd be fine to just use a static chain code. That approach would have basically the same security/privacy properties as my suggestion here

[jesseposner]

But we can't do hardened derivations anyway with FROST, right? So the xpub will always have to start at the first unhardened index.

To not reveal this, the participants could create a random fingerprint for m and submit a descriptor like tr([12345678/86'/0'/0'/0]xpub6CUGRUonZSQ4TWtTMmzXdrXDtypWKiKv2qjeZP8L2RF2CFZVGPyv6xqvUl7BC7F4tRFJio7F2eN3v6ZMBgW9Qsac2fnBi764jLxsjZh2wwBHV3) where 12345678 is a random fingerprint that doesn't actually represent a key and the unhardened derivation paths aren't actually used.

[jesseposner]

If we treat the root frost public key as m, then instead of a random fingerprint, we can hash the root frost public key, with the static chain code, and use that as the fingerprint in the descriptor. Then we can disregard the hardened paths and begin derivation at the first unhardened path /0. Then the xpub that follows in the descriptor will be the child key at /0 with a random chaincode.

[conduition]

I like this approach. My only question is, could the unusual key path m/86'/0'/0'/0 (or the xpub's embedded depth of 4) be associated with FROST? AFAIK most clients only give out xpubs derived from hardened indexes, right? FROST xpubs would stick out because they're derived from an unhardened index at a weird depth (4 instead of 3).

I suppose we want the best anonymity set, which depends on what other modern wallets are doing. Since most wallets with taproot support use generic keyspending at path m/86'/0'/0', i think hiding FROST xpubs amongst those would be a good place to start.

But we can't do hardened derivations anyway with FROST, right? So the xpub will always have to start at the first unhardened index.

Yes, but you can create an xpub synthetically (in which case you can pick whatever fake 'hardened' child index you want), or you can modify an existing unhardened xpub's child index field to look hardened.

[conduition]

A few points:

• Since the group's master public key has no known private key, any child derivations from it would have to be done through unhardened indexes only.
• The top-level group xpub's chain code could be a fixed global value, but this could negatively affect privacy for some use cases by exposing it as a FROST xpub.
  • Deriving the chain code from public shares could be both secure & private, but if the set of verifying shares could be changed via RTS or VSR, this approach breaks down. Deriving the chain code from the master public key itself would be secure but not private, as it exposes the xpub as a FROST key.
  • We could execute some kind of provable-randomness protocol to generate a unique and random chain code, but then participants must store the chain code permanently, alongside their public key package, or else it will be lost. This would also add a lot of code complexity.

I have a suggestion which should address these issues.

Procedure

The group runs the DKG as normal to generate the group's master public key $M$.

Each participant computes two namespaced hashes of $M$:

• $b=H_{\text{tweak}}(M)$
• $c=H_{\text{chaincode}}(M)$.

$b$ is interpreted as a scalar, used to additively tweak $M$.

$$M^{\prime }=M+bG$$

$c$ will be used as the chain code.

The participants can build a depth-3 xpub (imagine it as an xpub at m/86'/0'/0'), constructed with the following fields:

Field	Value
Version	network-specific
Depth	3
Fingerprint	rmd160(sha256(M))[:4] (this is part of BIP32 standard)
Child Number	0x80000000 (i.e. /0')
Chain Code	$c$
Public Key	$M^{\prime }$

Observations

• The process of computing $b$ and $c$ is conceptually similar to BIP32 master key derivation used to expand a small piece of entropy (the seed) into the master node (key + chaincode), except using two distinct tagged hashes instead of HMAC-SHA512, and instead of a secret seed we're using a public key $M$ which we assume the group keeps private to within their own group.
• To observers who don't know $M$, the resulting BIP32 extended pubkey will look like any other standard taproot xpub, derived from some unknown master key at path m/86'/0'/0'. They will only see the 'obscured' (tweaked) master key $M^{\prime }=M+bG$.
• The participants must keep the true un-tweaked public key $M$ private. Revealing it would also reveal their xpub, and would reveal the fact that their group key is a FROST group.
• When signing, the participants need only tweak their secret signing shares correctly, which could easily be done using the effective_secret_key method on Ciphersuite added here in my and zebra-lucky's taproot PR.
• We could further parameterize the hashes of $M$ with some index $i$ (e.g. $b=H_{\text{tweak}}(M,i)$ ). This might be useful if the group needs different xpubs for different blockchains (e.g. testnet, altcoins).
• To encourage code reuse, we might have chosen to use $M$ as a depth-2 xpub public key directly, with an empty (32 zeros) chain code, and then simply derive a child xpub from that to get a depth-3 xpub. However this child xpub will by default have an unhardened child index 0, instead of the hardened child index 0x80000000. To improve privacy, we'd have to manually modify the child xpub and set the child index number to +0x80000000. To avoid that footgun, i'd recommend not to reuse the BIP32 CKD algorithm exactly.
• The value of this procedure is predicated on the assumption that some FROST groups don't want to expose the fact that they're using FROST, and so we might as well engineer a universal solution that works equally well for everybody. If that is not a concern, a static fixed chain code would suffice.

[conduition]

I'm working on a prototype of this approach on my fork of the FROST repo. Some features and tests are missing/unfinished so don't depend on this yet, but existing tests are passing. Bear in mind it depends on #584