-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preferred BIP85 mnemonic derivation path for Breez SDK clients #785
Comments
@dangeross that might be relevant for BitBox |
Thanks for this issue. Using the regular BIP85-BIP39 path like 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 The BIP85 derivation would then be
for the first LN account (vary index if multiple accounts should be needed). How does that sound @alessandro-saglimbeni? |
Any new updates/consensus on this decision? |
@lamafab BitBox02 went ahead with derivation method I outlined above. Haven't heard any feedback from others yet. cc @alessandro-saglimbeni |
@roeierez @dangeross please review and weigh in |
Hi @alessandro-saglimbeni, do you have anymore updates from your side guarding this issue? |
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 usem/83696968'/39'/0'/12'/0'
: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.
The text was updated successfully, but these errors were encountered: