You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe the idea here is that the BDK wallet would be able to sync and spend UTXOs created when a LDK channel is closed. I'd also expect that UTXOs in a BDK wallet could be used to open an LDK channel. This should be enabled with #485 and bitcoindevkit/bdk_wallet#188. We also need to be able to use LDK as a custom signer for spending UTXOs from LN script template "Descriptors". And LDK would have to be able to use BDK as a input signer.
This should be doable by just creating a custom KeysInterface where you make get_shutdown_scriptpubkey and get_destination_script get addresses from LDK.
This should be doable by just creating a custom KeysInterface where you make get_shutdown_scriptpubkey and get_destination_script get addresses from LDK.
I can now confirm that by implementing a custom KeysInterface we can override the shutdown/destination scripts coming from a BDK wallet, so that the funds show up in the BDK wallet after closing/claiming on-chain. Will be included in LDKLite (see lightningdevkit/ldk-node#33).
However, it likely still would be nice to allow users the flexibility to go the other way, i.e., allow them to add arbitrary UTXOs to BDK's coin selection.
Reacted by Bullish Node
Reacted by Conor Okus, Steve Myers and Bullish Node
@tnull do we only need to expose the existing rust add_foreign_utxo function in the language bindings? That should allow you to create a transaction in BDK that spends a UTXO owned by LDK, though you'd still need LDK to sign for that input.
Otherwise your KeysInterface approach sounds like it already allows BDK to be used to manage the onchain transactions for LDK.
@tnull do we only need to expose the existing rust add_foreign_utxo function in the language bindings? That should allow you to create a transaction in BDK that spends a UTXO owned by LDK, though you'd still need LDK to sign for that input.
Otherwise your KeysInterface approach sounds like it already allows BDK to be used to manage the onchain transactions for LDK.
Yup, I agree that the KeysInterface approach (by now renamed though) seems to work as expected. I'd say it's fine to close this issue for now until we find a good reason why we'd need to 'go the other way'.
Activity
afilini commentedon Aug 12, 2022
That's a bit generic, what do you mean exactly? Which utxos should be spent (normal deposits or channel utxos) and where are those keys stored?
notmandatory commentedon Aug 26, 2022
I believe the idea here is that the BDK wallet would be able to sync and spend UTXOs created when a LDK channel is closed. I'd also expect that UTXOs in a BDK wallet could be used to open an LDK channel. This should be enabled with #485 and bitcoindevkit/bdk_wallet#188. We also need to be able to use LDK as a custom signer for spending UTXOs from LN script template "Descriptors". And LDK would have to be able to use BDK as a input signer.
benthecarman commentedon Dec 13, 2022
This should be doable by just creating a custom
KeysInterfacewhere you makeget_shutdown_scriptpubkeyandget_destination_scriptget addresses from LDK.tnull commentedon Dec 15, 2022
I can now confirm that by implementing a custom
KeysInterfacewe can override the shutdown/destination scripts coming from a BDK wallet, so that the funds show up in the BDK wallet after closing/claiming on-chain. Will be included in LDKLite (see lightningdevkit/ldk-node#33).However, it likely still would be nice to allow users the flexibility to go the other way, i.e., allow them to add arbitrary UTXOs to BDK's coin selection.
ConorOkus commentedon Feb 23, 2023
Added an issue to improve this at the bindings layer here
moneyball commentedon Oct 9, 2023
What's the status/priority/plan for this?
notmandatory commentedon Oct 10, 2023
@tnull do we only need to expose the existing rust
add_foreign_utxofunction in the language bindings? That should allow you to create a transaction in BDK that spends a UTXO owned by LDK, though you'd still need LDK to sign for that input.Otherwise your
KeysInterfaceapproach sounds like it already allows BDK to be used to manage the onchain transactions for LDK.ConorOkus commentedon Oct 11, 2023
I don't think that's needed, we already have the ability to forward any other descriptors to
KeysManager::spend_spendable_outputsand provide guidance here in the docs https://lightningdevkit.org/key_management/#spending-on-chain-fundstnull commentedon Oct 12, 2023
Yup, I agree that the
KeysInterfaceapproach (by now renamed though) seems to work as expected. I'd say it's fine to close this issue for now until we find a good reason why we'd need to 'go the other way'.notmandatory commentedon Oct 12, 2023
Thanks guys, closing for now. Happy to re-open if needed.