[RFC] Add partial BIP39 support (import only) #16393

Context: In 0.17.0 Bitcoin Core added sethdseed RPC command which allows users to set their own seed for the HD wallet.

However, because Core internally interprets the seed as a CKey, it can only hold 256 bits.

BIP39 defines a mnemonic code for generating wallet seeds. It is currently supported by some of the most popular wallets on the market. BIP39 uses 512-bit seeds.

Problem: Core does not currently support BIP39-style seeds.

Proposal: Add partial support for BIP39 to Core by letting sethdseed accept a seed whose length is up to 512 bits.

Thoughts? If people feel this is something useful to have, I can start working on an implementation.

Concept ACK.

I think it would be good for us to allow users of most other wallets to be able to import their full HD wallet into Core. However, even with a seed imported, there would still be issues with differing derivation paths. But I believe that combining this with descriptor wallets will solve that problem.

n.b. I am mentoring @hugohn for the Chaincode residency

It should be easily possible to convert a BIP39 seed into a descriptor. I don't think we should be adding support for this to the legacy ismine/watching logic.

Thanks @sipa . It is true that with importdescriptors coming and descriptors taking a more central role in the wallet, this would be less of an issue. Do you think exposing an RPC command that does the BIP39 seed -> descriptor conversion would still be helpful to the users? Or do you think that should be done completely outside of Core? @ariard just alerted me to the existence of aezeed, which suggests that BIP39 itself has a few weaknesses. So that's probably an argument for doing the conversion outside of Core.

@hugohn in general "pure utility" RPC calls are not accepted anymore into Core.

@instagibbs That's good to know. Thanks!

What do you guys think about extending sethdseed support to more than 256 bits, independent of BIP39?

Yes there exists a work-around as @sipa mentioned (convert the seed into a descriptor then import), but it seems weird to me that we have an artificial limit on the seed length primarily because we want to pigeonhole this seed into an internal data structure. Some users might desire stronger security than 256 bits. Perhaps it's not a high priority, but if we expect the sethdseed interface to stick around for the long term (pls correct me if that's not the case), it might make sense to increase the length at some point, no?

@hugohn sethdseed won't work on descriptor wallets, and descriptor wallets is where development should be focusing on.

@sipa That's fair, and I like the move towards descriptors!

So do you expect us to deprecate sethdseed at some point? Or keep it around but warn the users that they won't get any benefits of the new descriptor-based wallet if they use it?

@hugohn The current implementation of descriptor wallets simply disables sethdseed for descriptor wallets. If a user has a legacy wallet (which most will have initially and there's really no upgrade path from legacy to descriptor), they will be able to use sethdseed. However descriptor wallets will not allow this.

I think one thing that would be useful in the future is to allow users to use seeds and mnemonics within a descriptor itself instead of having to derive the master private key from it.

@achow101 that would be very interesting... Although I think there's a small problem that there's no one single standard for seeds/mnemonics?

E.g.: BIP39 is one, aezeed is another. And even for BIP39 there're different implementations (different word lists etc.). This is unlike the current descriptor language where the elements are much more well-defined: SCRIPT, KEY, ADDR.

@hugohn There could be a tool that converts various types of seeds/mnemonics to descriptors.

@sipa yes, I think a tool like that will be necessary once descriptor wallets become more popular.

IMHO it is also consistent with efforts like PSBT in terms of making various wallets on the market more compatible with each other, and helping users avoid vendor lock-in.

See also https://bitcoin.stackexchange.com/questions/88237/is-there-a-reason-to-why-bitcoin-core-does-not-implement-bip39

Although I think there's a small problem that there's no one single standard for seeds/mnemonics?

Of course there's a problem. I've seen some users who were apparently scared off by this problem, and then they just turned to hold a single "precious" WIF private key (which would obviously be reused over and over again) instead.

There could be a tool that converts various types of seeds/mnemonics to descriptors.

"A tool outside Bitcoin Core" seems to require the user to be a bit tech-savvy.

just alerted me to the existence of aezeed, which suggests that BIP39 itself has a few weaknesses. So that's probably an argument for doing the conversion outside of Core.

I don't understand exactly what weaknesses BIP39 has.

To my understanding, the key stretching strength issue is meaningful only to the extra passphrase part. Even if this issue was considered unacceptable, it doesn't seem to be unfixable. (although an improved BIP39 could not be called "BIP39" anymore probably) @gmaxwell once mentioned that BIP39 doesn't really have plausible deniability, but to be frank, I didn't get his point.

I wonder if the "mnemonic" strategy is currently considered a correct way of backup at all? If not, why?

Personally I don't think BIP39 is ideal either, because:

1. BIP39 hashes the mnemonic words to generate the seed, which makes conversion among different languages impossible. This is quite awkward, especially for users who make cryptosteel backups.

2. BIP39 has a very weak checksum. Misread words could cause seemingly (it's actually not that tragic, because a recovery program traversing through all possible similar words should be possible) "tragic fund loss" problems potentially.

However, just like what the OP said in the beginning:

It is currently supported by some of the most popular wallets on the market. BIP39 uses 512-bit seeds.

To me, BIP39 still seems to be most hopeful to be the de-facto standard.

See also #19151 - support BIP39 mnemonic in descriptors