Make wallet entropy source configurable

[tnull]

Closes #12, based on #8, #9, #10, #11.

This PR makes the wallet entropy source configurable. We do this by first sourcing [u8; 64] bytes in different ways to setup a bip32::ExtendedPrivKey, whose secret key we then use to source LDK's seed bytes.

[tnull]

Unfortunately this is currently blocked on dependent projects, since Bip39 doesn't compile vs my BDK due to rust-bitcoin/rust-bip39#28.

[tnull]

That said, BDK seems to work on its own Bip39 implementation (bitcoindevkit/bdk#644), so let's see what unblocks this first.

[thunderbiscuit]

A small comment: because you're using 64 bytes when taking the SeedFile(String) or the SeedBytes([u8; 64]) route, this length of entropy will not be compatible with a BIP39 mnemonic. Presumably it might not a big deal because those users would have a backup that is different (simply backing up the file or the bytes in some way), but it makes the three approaches not interoperable when they could be. If all 3 approaches were interoperable, a user could have a backup as a file, but also as words. When recovering, either of them would lead to the same wallet.

You'd get this interop if instead of 64 bytes for the SeedFile and SeedBytes you use a 32 bytes requirement. You could then also provide the user a 24 word BIP39 backup if they wish to have one, and that would back up their entropy (the 32 bytes and the 24 words being different representations of the same thing). From there you could create the Mnemonic using Mnemonic::from_entropy_in(), and the code would be maybe something like

let mnemonic_from_bytes = Mnemonic::from_entropy_in(Language::English, &seed_bytes).unwrap();
let xprv = mnemonic_from_bytes.into_extended_key().unwrap().into_xprv(Network::Testnet).unwrap();
let ldk_seed: [u8; 32] = xprv.private_key.secret_bytes();

Other small comment: this LdkLite idea is awesome! Really looking forward to play around with it and build a small node!

[tnull]

A small comment: because you're using 64 bytes when taking the SeedFile(String) or the SeedBytes([u8; 64]) route, this length of entropy will not be compatible with a BIP39 mnemonic. Presumably it might not a big deal because those users would have a backup that is different (simply backing up the file or the bytes in some way), but it makes the three approaches not interoperable when they could be. If all 3 approaches were interoperable, a user could have a backup as a file, but also as words. When recovering, either of them would lead to the same wallet.

Ah, good point. I actually switched to 64 bytes since that is what Mnemonic::to_seed returns. As I currently only looked at the wallet import, this is probably fine. But you're right, the export to Mnemonic would just capture 256 bits. Will account for that!

Other small comment: this LdkLite idea is awesome! Really looking forward to play around with it and build a small node!

Love to hear it! :)

[danielnordh]

The specifics here are out of my depth, but the objective seems essential to a v1, and there has been no progress on the blocking issue for 6 months. May have to look into alternative routes forward.

Using BDK in Swift I had no issues creating the seed for LDK with descriptorSecretKey.secretBytes(), but apologies if I'm just ignorant.

[tnull]

The specifics here are out of my depth, but the objective seems essential to a v1, and there has been no progress on the blocking issue for 6 months. May have to look into alternative routes forward.

Sure, in particular if there is no movement, I'll probably just add a builder method allowing to specify the seed, e.g., Builder::from_seed(seed: [u8; 32]) or similar.

Using BDK in Swift I had no issues creating the seed for LDK with descriptorSecretKey.secretBytes(), but apologies if I'm just ignorant.

I mean the current version already creates a random seed that is persisted to disk. This PR is just meant to give additional options regarding how to generate that seed.

[tnull]

While reading from a Bip39 mnemonic is still pending due to above mentioned pinning issue, specifying the seed or seed file directly has now been included in #11 already. Closing as "mostly done".