bitcoin-core / gui-qml

Bitcoin GUI (experimental QML-based fork)
MIT License
111 stars 40 forks source link

Hardened vs non-hardened key derivation #85

Closed Bosch-0 closed 1 week ago

Bosch-0 commented 2 years ago

Currently Bitcoin Core uses hardened private key generation for security reasons which comes with a major UX tradeoff (not possible to use BIP39 recovery phrases).

However, If we want to turn the Bitcoin Core app into a multisig cold-storage wallet (which should be the primary aim imo) it is likely non-hardened addresses need to be used for the below reason:

However, there is a trade-off to using hardened addresses. Regular addresses are derived from public keys, but hardened addresses are derived from private keys. So to generate new hardened addresses requires access to private keys. This means either that private keys would need to be kept on third-party servers or that the client’s hardware wallets would need to be accessed whenever they wanted to generate new addresses. Both of these options are unacceptable.

More details here.

If we use non-hardened addresses for multi-sig it would make sense to also offer this for single-sig. However, something to consider is still offering hardened derivation wallet creation for those more advanced users who do not want to make the trade-off of using non-hardened key derivation. With good design we can cater to a wide range of user risk tolerances and skill levels. We can also offer some kind of progressive security where we educate and move users towards more advanced practices over time.

Rspigler commented 2 years ago

This isn't really a concern any more with descriptors. With descriptors, users can create any type of derivation/path with any set of output scripts. The default for multisig will probably by BIP87 (I'm biased, I wrote it), but advanced users will probably be able to do custom ones under an advanced dialog.

jarolrod commented 1 week ago

We just abstract details to the internal wallet, so not exactly a consideration at the gui level, but can revisit if a specific use case is needed in the future