bitbox02-firmware
bitbox02-firmware copied to clipboard
BIP85 support
It would be great if the firmware would support BIP85.
BIP85 basically allows to derive other seeds from the master seed, which would allow to create multiple seeds for other wallets (e.g. hot wallets) and have them all backed up automatically with the seed of the BitBox.
Interesting, I didn't know about this BIP.
Do you know of any projects already implementing it?
Should the derived key be shown on the bitbox02 in form of a bip39 phrase?
I would worry about backup confusions, e.g. one could accidentally backup a derived bip39 phrase instead of the "root" bip39 phrase, and other UX issues impacting security.
We will list in our list of possible features for consideration, but we can't commit to implementing this for now. Thank you.
Coldcard implemented this a few weeks ago: https://github.com/Coldcard/firmware/pull/39
Yes, I think it makes sense to show the key as a bip39 phrase so that it can be used to restore (or create from scratch in case there are no funds) the wallet easily in other apps.
I don't know how the coldcard presents this in the UI (especially if you derive multiple keys), but I think it should be possible to make this not too confusing by only allowing to 'backup' the root key and explicitly tell the user that the other keys should NOT be backed up (since it is unnecessary). It would be nice to label the individual derived keys (in case you have 10 derived keys so that you know where you used this key), but this might be out of scope?
I wonder, if you use a derived bip39 seed for something, you should probably make a note of it along with the backup of the root seed, otherwise it is not clear when recovering if and which derivation paths are used for other wallets/apps.
If that is the case, what is the advantage of this versus just creating a new bip39 seed and backing that up in the same location as the primary backup? It does not seem that much more convenient to me handle on root seed plus info on how to derive more bip39 seeds, than just backing them up in parallel.
This is a good point, it does not help you to backup the various derivation paths of other wallets.
However, if you could label the derived key as something like 'Electrum v4.0.1 hot wallet', then this usually should be sufficient, since in case of recovery you either:
- a) get the exact version of the client and recover there, or
- b) figure out the derivation path etc. for that client version, or
- c) use a tool that tries the various derivation paths of all wallets and scans for funds (I don't know if this tool exists, yet, but at least I've seen ideas about tools like this).
In the worst case, you only backed up your master seed and don't have any information about where you used the derived keys. In that case, probably the only viable option is to use a tool like c) to check all common derivation paths (either with individual seeds that you derive again from the master seed, or – if you are ok with entering your master seed in that tool, which is probably NOT a good idea – by using your master seed and the tool derives the seeds for you).
One thing to keep in mind is: most users do not store the derivation paths in their backups right now either, since wallets usually just tell you to back up the seed words, assuming you will restore in that exact same wallet application in the future.
point c) does not seem viable to me. In the worst case you don't even know you should be looking for something (inheritance), and if you do, the information might not be enough to scan successfully. The keypath space can be vast.
I guess it makes sense to hardcode fixed derivation paths for specific uses, and not let the user choose their own derivation path. Then it is kind of like a standard.
One thing to keep in mind is: most users do not store the derivation paths in their backups right now either
But the backup will say what it is, e.g. "Bitcoin & Ethereum". If subkeys are used for different wallets, the backup should have a note about it. In which case my original point applies, I am not sure if the additional complexity is better than just keeping multiple backups in the same place.
Interesting nonetheless, we will discuss it. Thanks again.