Preferred BIP85 mnemonic derivation path for Breez SDK clients

[alessandro-saglimbeni]

Context

Services like Green or Bitbox might want to be able to segregate the security assumptions and threat model for protecting users' funds onchain versus on lightning.

For instance, hardware signing devices will be able to directly sign channel state updates some time in the future, but there are some usability issues that make such hardware signers a bad fit for retail users usage on lightning, e.g. the hardware signer must be unlocked and attached to some breez-sdk client within 1m30s when you receive a payment, not a great UX.

BIP85 mnemonic derivation allows to derive a child mnemonic that can be used by the Breez SDK (which will then be converted to a seed). Such child mnemonic could then be treated with different security assumptions, so that it could for instance be exported from a hardware signer and be delegated to a breez-sdk client (as Jade does).

Such BIP85 child mnemonic can then be exported also to other breez-sdk clients, solely for the purpose of accessing the funds on the associated Greenlight node, without interfering with the security of the app/device that originated it.

Early implementation

On Green and Jade, for this purpose we decided to start following the BIP85 derivation using the BIP39 app_no.

By the standard, the derivation path for a mnemonic should follow m/83696968'/{app_no}/{language}'/{words}'/{index}' specifically we chose to use m/83696968'/39'/0'/12'/0':

• Language english
• Words 12, compatible with Breez
• Index should start from 0, and then if one LN account needs to be revoked, we’d progressively use 1/2/… this avoids having to implement searching for an index. This information would be communicated in various places: (a) the app view where user can export mnemonic, (b) a Help Center doc, (c) in code

This child mnemonic is then used by the breez-sdk client, and is converted into a seed entropy which will then be used to connect with a Greenlight node.

Standardizing the derivation path

Colleagues in the space have different opinions regarding the BIP85 path to be used.

It would be nice if us as the Breez SDK users interested in using a BIP85 child key, for the above stated purpose of segregating it from other keys, would all converge to using the same BIP85 derivation path. So we're opening this issue for discussion.

[kingonly]

@dangeross that might be relevant for BitBox

[benma]

Thanks for this issue.

Using the regular BIP85-BIP39 path like m/83696968'/39'/0'/12'/0' for this is problematic as a user might use the same mnemonics for something else, e.g. another cold storage wallet. In such a case, the derived mnemonic of the user would become hot without the user realizing it.

For the purpose of generating a mnemonic for a lightning hot wallet using BIP85, we should instead use a different application number dedicated to this.

I propose to go with the app number 19534', which is unlikely to interfere with other uses. It's hex representation 0x4c4e spells LN in ASCII.

The BIP85 derivation would then be m/83696968'/{app_no}/{language}'/{words}'/ as in BIP85-BIP39, but use 19534' for the app_no instead of 39', and words fixed to 12 words, so:

m/83696968'/19534'/0'/12'/0'

for the first LN account (vary index if multiple accounts should be needed).

How does that sound @alessandro-saglimbeni?

[lamafab]

Any new updates/consensus on this decision?

[benma]

@lamafab BitBox02 went ahead with derivation method I outlined above. Haven't heard any feedback from others yet. cc @alessandro-saglimbeni

[kingonly]

@roeierez @dangeross please review and weigh in

[dangeross]

Hi @alessandro-saglimbeni, do you have anymore updates from your side guarding this issue?