-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow for wallet import #12
Comments
Hey @tnull! I work on the BDK language bindings and I'm looking to understand better what would be a recommended way/location to source the entropy we provide to the LDK library, potentially to expose that in the bindings if the users need it. I read what LdkLite is doing at the moment for the LDK entropy, and have questions regarding this approach (mainly because I want to enable mirroring this approach with the BDK bindings if users need to):
| | | 2048 rounds of | | On-chain |
| | --- BIP39 --> | HMAC-SHA512 | --- BIP32 Seed ---> | BDK |
| | | (mnemonic + passphrase) | | descriptor |
| entropy |
| | | |
| | --- BIP39- --> | LDK |
| | like | |
Overall, my question boils down to this: Cheers! |
Hey @thunderbiscuit! Thanks for outlining the different scenarios. I imagine LDK itself will keep relatively agnostic to any particular entropy source and just accept any I currently tend towards what you described under 3.: derive LDK's entropy from the same Bip32 seed as BDK, and offer a number of different ways in the API how to restore this Bip32 seed (e.g., simply providing the raw bytes, a String of Bip39 words, etc.). IIUC what you propose, wouldn't taking the first 32 bytes of the seed be the same as simply using the master secret key, i.e., |
@thunderbiscuit Just added a first draft of this over at #14. |
Hey that sounds great! I'll keep an eye on this, and we'll make sure that users of bdk-ffi are offered the ability to derive the same entropy LDK uses for As for the question: wouldn't taking the first 32 bytes of the seed be the same as simply using the master secret key, i.e., I'm not 100% percent sure on this, but also in my local testing the two do not equate each other (using your code in #14) let xprv = bitcoin::util::bip32::ExtendedPrivKey::new_master(config.network, &seed_bytes)?;
let ldk_seed: [u8; 32] = xprv.private_key.secret_bytes(); I think what is happening is that this impl ExtendedPrivKey {
/// Construct a new master key from a seed value
pub fn new_master(network: Network, seed: &[u8]) -> Result<ExtendedPrivKey, Error> {
let mut hmac_engine: HmacEngine<sha512::Hash> = HmacEngine::new(b"Bitcoin seed");
hmac_engine.input(seed);
let hmac_result: Hmac<sha512::Hash> = Hmac::from_engine(hmac_engine);
Ok(ExtendedPrivKey {
network,
depth: 0,
parent_fingerprint: Default::default(),
child_number: ChildNumber::from_normal_idx(0)?,
private_key: secp256k1::SecretKey::from_slice(&hmac_result[..32])?,
chain_code: ChainCode::from(&hmac_result[32..]),
})
} Sorry this is getting a bit long. In short, I think they are different, but I also think that using the private key is just as good, and it's easier to document than "take the first 32 bytes out of the seed bla bla bla". |
Great, thank you for the explanation! I agree they are different, but essentially only one HMAC away. 😆 |
Absolutely! They don't need to be the same at all, I was just curious because initially in my mind they were but I was wrong. |
Currently we setup the underlying BDK/LDK wallets from a single random seed file.
We should however allow to import pre-existing on-chain wallets, e.g., from a Bip39 mnemonic.
The text was updated successfully, but these errors were encountered: