Integrate with LDK

[notmandatory]

BDK should be able to provide blockchain and key services for the Lightning Development Kit (LDK). The LDK traits that need to be implemented by BDK are:

• lightning::chain::keysinterface::KeysInterface
• lightning::chain::chaininterface::BroadcasterInterface
• lightning::chain::chaininterface::FeeEstimator
• lightning::chain::Filter
• lightning::chain::Confirm
• lightning::chain::Access
• lightning::chain::Watch

[moneyball]

@johncantrell97 how much of this is already done?

[johncantrell97]

The bdk-ldk library https://github.com/johncantrell97/bdk-ldk has implemented:

lightning::chain::chaininterface::BroadcasterInterface
lightning::chain::chaininterface::FeeEstimator
lightning::chain::Filter
lightning::chain::Confirm

I've looked at KeysInterface and I'm not entirely sure it's useful to implement with BDK. The only benefit that is sort of achievable is that you'd be able to use keys from your BDK wallet to sign for the outputs of a closed channel without sweeping them into your BDK wallet first. So you could potentially save a transaction.

After talking with Matt about it I decided it wasn't worth it, at least for now, because those outputs need to be spent in a very specific way. They can't just be added to bdk's utxo database and be spent like normal utxos the way bdk normally does.

It would need some kind of flag in bdk or a separate bucket of utxos that when included in a transaction could use different logic.
It's definitely something to continue to investigate because saving a transaction can potentially be a huge benefit.

I am not familiar with ChannelKeys interface (I think it's been renamed maybe?) but regardless it refers to something internal to ldk channel operations where I don't think there'd be any benefit in implementing it using BDK -- it's not currently something required to build a node.

As for Access/Watch I think those are no longer the appropriate interfaces for chain data. I implemented Confirm using ElectrumBlockchain and EsploraBlockchain for BDK. This interface is one where are able to query for specific chain data.

I need to still implement BlockSource interface to support bitcoind rpc polling similar to the ldk-sample node and Listen interface for compact block filter implementation.

There has also been talk in BDK of exposing block_connected/disconnected (and other) events as part of the sync() method. If a feature like that landed in BDK it might unify CBF + bitcoind backends and enable them both to just use Listen interface for ldk.

[moneyball]

Do you think the work you've done best serves as
a) an example other wallet devs can learn from
b) a reusable library other wallet devs can use
?

And if (b) do you think it should "become" (packaged as?) part of the LDK (or some future merged BDK+LDK)?

[johncantrell97]

It's definitely intended to be and currently usable as a library. The example bdk/ldk node I have and the more production ready node I'm working on are both using the bdk-ldk library I linked to above as a dependency. It allows you to take a bdk::Wallet instance and use it in the constructor of my "LightningWallet" struct to enhance it with lightning required functionality.

I have plans to make sure all the bdk backends are supported in the bdk-ldk library so that an end-user can choose freely between electrum/esplora/bitcoind/cbf. It currently supports both electrum and esplora.

As for where the bdk-ldk library should live I'm not sure, that's more up to the maintainers of ldk and/or bdk. I know ldk already has the concept of sub-crates that act as 'batteries' users can use. It probably would do well as one of those but I guess I'd like to hear the ldk's team thoughts on that.

Since it basically wraps a bdk::Wallet and extends it with more functionality it might actually make sense to live in the bdk org, again im not entirely sure though.

[moneyball]

Thoughts on language bindings for this shared library? Let's say a developer wants to build a wallet on Android using Kotlin and wanted to use this library.

[johncantrell97]

Yeah that's a good question. Well it starts with needing to instantiate a bdk wallet which can definitely already be done in Kotlin. I haven't been closely following the language bindings work so I'm not sure the best way to expose this library but my intiial thoughts are that it seems like it should be easy.

You would just need to expose this LightningWallet struct's constructor and methods. The returned object can then be used in the constructor of the relevant LDK objects that require an object with certain traits to be implemented.

Would need some input from ldk folks for the best way to achieve that.

[danielnordh]

I'm trying to do something similar for iOS/Swift, and at the moment it seems the status is:

• BDK and LDK on Swift don't share a workable API
• BDK on Swift does not expose enough functionality to supply the LDK blocksource
• A package to bridge BDK and LDK is required (like @johncantrell97 has done in Rust)
• A separate package may be needed to connect to Explore/Electrum to provide the blocksource to LDK

[notmandatory]

I am not familiar with ChannelKeys interface (I think it's been renamed maybe?) but regardless it refers to something internal to ldk channel operations where I don't think there'd be any benefit in implementing it using BDK -- it's not currently something required to build a node.

Removed ChannelKeys from this issue description.

And added lightning::chain::Confirm

[ConorOkus]

A few notes for BDK/LDK integration - https://docs.google.com/document/d/19atFfyV8FLyUdapgHlg2agzWykbprlgkASHHPoKgsjU