The path to a unified wallet

[ConorOkus]

BDK allows us to create descriptor-based wallets, it would be good if we can use a subkey or child key to seed our LDK KeysManager and make backup/recovery easier by only using one 12 word mnemonic.

The descriptors in a BDK wallet look something like this:
Receive addresses - wpkh(${xprv}/84'/1'/0'/0/*)
Change addresses - wpkh(${xprv}/84'/1'/0'/1/*)

I believe we want a separate derivation path for LDK keys. We'll then be able to use the child key pair derived from that master key with LDK as long as it's a 32-byte seed.

We'll need to pick a constant LDK KeysManager Seed Path, this should be a hardened key.

Does this PR look like it will have what we need to generate the sub-key pair with a different path and feed to LDK KeysManager?

[ConorOkus]

Another option as outlined in the Discord server:

1. Generate 32 random bytes then feed into PBKDF2 from bip39 to get a 64-byte seed.
2. Initialize LDK KeysManager with those first 32 bytes directly e.g master private key.
3. Use those bytes as seed for bip32 extended priv key generation => to native segwit descriptor for BDK wallet

https://discord.com/channels/753336465005608961/824249944810192956/1008914615255695381

[tnull]

I think partly in reference to the sample node and/or @johncantrell97's bdk-ldk, the initial version of LdkLite currently implements this approach very similar as:

let seed = read_or_generate_seed_file(&config)?;
let xprv = bitcoin::util::bip32::ExtendedPrivKey::new_master(network, &seed)?;
let bdk_wallet = bdk::Wallet::new(
	bdk::template::Bip84(xprv.clone(), bdk::KeychainKind::External),
	Some(bdk::template::Bip84(xprv.clone(), bdk::KeychainKind::Internal)),
	network,
	MemoryDatabase::default(),
)?;

fn read_or_generate_seed_file(config: &LdkLiteConfig) -> Result<[u8; 32], LdkLiteError> {
	let keys_seed_path = format!("{}/keys_seed", config.storage_dir_path);
	let keys_seed = if let Ok(seed) = fs::read(keys_seed_path.clone()) {
		assert_eq!(seed.len(), 32);
		let mut key = [0; 32];
		key.copy_from_slice(&seed);
		key
	} else {
		let mut key = [0; 32];
		thread_rng().fill_bytes(&mut key);

		let mut f = fs::File::create(keys_seed_path.clone()).map_err(|e| LdkLiteError::Io(e))?;
		f.write_all(&key).expect("Failed to write node keys seed to disk");
		f.sync_all().expect("Failed to sync node keys seed to disk");
		key
	};

	Ok(keys_seed)
}

[ConorOkus]

I still think we need a way to fit in the BIP39 Mnemonic with an optional passphrase though as the simplest backup/recovery mechanism.

[ConorOkus]

See point 3 below

[ConorOkus]

Tradeoffs:

1. If your mnemonic phrase can back up your entropy for your BDK on-chain wallet (through the typical BIP39 process + potential passphrase & descriptor) and the entropy part that needs to be given to LDK, that's a win for everyone; it's better than just giving random bytes to LDK and a different set of unrelated random bytes to BDK.
2. In the case above you can use BIP39 to back up that entropy, and because you're using a mapping 1-to-1 words-to-entropy you need 24 words because LDK requires 256 bits of entropy (a 12-word mnemonic only gives you 128 bits). In this hypothetical, the backup works like this: LDK uses the "raw" entropy implied by your 24 words, and BDK uses your 24 words to derive a full BIP32-compatible wallet with a descriptor.
3. If instead for the LDK entropy you use the BIP39 words to derive a BIP32 seed and you use that as your entropy, then that means you can use a 12 words backup, and that entropy will also be able to incorporate a passphrase (not required but if your on-chain wallet has one but your LDK doesn't then you're on 2 different sort of mnemonic backup structures (on-chain with passphrase LDK without).

https://discord.com/channels/753336465005608961/824249944810192956/1008916290909511741

[ConorOkus]

lightningdevkit/ldk-node#12

[ConorOkus]

This was added to the main website site here - https://lightningdevkit.org/key_management/#creating-a-unified-wallet