[RFC] Add partial BIP39 support (import only)

[hugohn]

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.

[achow101]

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

[sipa]

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.

[hugohn]

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.

[instagibbs]

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

[hugohn]

@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?

[sipa]

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

[hugohn]

@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?

[achow101]

@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.

[hugohn]

@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.