What questions do you have about the Lightning Development Kit?

[ConorOkus]

Please post each question in a dedicated comment. Then we can use replies to each comment to discuss and answer.

[ConorOkus]

What's the recommended way to serialize/deserialize the channel manager?

[ConorOkus]

In general, you should deserialize by just loading the bytes into the ChannelManagerConstructor, and serialize by writing the bytes given to you in persist_manager

cc @TheBlueMatt

[jochasinga]

I was trying to ramp up on the Building a Node in Rust and creating a ChainMonitor was more involved than the guide.

// Here, Rust won't allow `Filter` which is a `Sized` trait object. It must be wrapped inside `Box<dyn Filter>` perhaps
let filter: Option<Filter> = None;

// Rust needs an explicit type annotation for `chain_monitor` here.
let chain_monitor = ChainMonitor::new(
        filter,
        &broadcaster,
        &logger,
        &fee_estimator,
        &persister
);

rust version 1.53.0
lightning version 0.0.99

[ConorOkus]

Attempted to fix here - lightningdevkit/lightningdevkit.org#64

[jochasinga]

I don't think you can simply do that because ChainMonitor mandates Option<Box<dyn Filter>> to implement Deref.

Here is the error:

the trait bound `Option<Box<(dyn lightning::chain::Filter + 'static)>>: lightning::chain::Filter` is not satisfied
the trait `lightning::chain::Filter` is not implemented for `Option<Box<(dyn lightning::chain::Filter + 'static)>>` rustcE0277

However, Arc<dyn Filter> will pass because Arc<T> implements Deref.

[ConorOkus]

Yeah didn't realize Matt is creating a patch here - lightningdevkit/lightningdevkit.org#63

[TheBlueMatt]

I don't think you can simply do that because ChainMonitor mandates Option<Box> to implement Deref.

It shouldn't - the constructor for ChainMonitor requires an Option of a Deref, not a Deref itself. Arc, Box, etc all implement Deref so any should work just the same, as long as its in an Option when passed to ChainMonitor::new().

[jochasinga]

My bad. Yes, you're right.

[jochasinga]

Referring to the home page's section that says Mobile First:

Mobile First
As lightweight as you need it to be and with language bindings suitable for iOS or Android -- it may be written in secure Rust, but you'll never have to touch Rust code.

Is it implying that the Java and Swift binding can run the lightning node on the mobile device?

[TheBlueMatt]

Yep! You can do nearly everything in Java/Swift as you can in Rust, and never need to write a single line of Rust.

[jochasinga]

Missing Generics for Struct ChannelManager

I'm reimplementing the LDK node sample, and at this line:

https://github.com/lightningdevkit/ldk-sample/blob/d3112a612f8f830520ad01e533e3aac3a701c55e/src/main.rs#L374

I got the following error, which basically ask for generic parameters for ChannelManager:

error[E0107]: missing generics for struct `ChannelManager`
   --> src/main.rs:195:22
    |
195 |         <(BlockHash, ChannelManager)>::read(&mut channel_manager_file, read_args)
    |                      ^^^^^^^^^^^^^^ expected 6 type arguments
    |
note: struct defined here, with 6 type parameters: `Signer`, `M`, `T`, `K`, `F`, `L`
   --> /home/pancy/.cargo/git/checkouts/rust-lightning-6850882c83c110d8/7dfa886/lightning/src/ln/channelmanager.rs:424:12
    |
424 | pub struct ChannelManager<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref>
    |            ^^^^^^^^^^^^^^ ------        -         -         -         -         -
help: use angle brackets to add missing type arguments
    |
195 |         <(BlockHash, ChannelManager<Signer, M, T, K, F, L>)>::read(&mut channel_manager_file, read_args)
    |                                    ^^^^^^^^^^^^^^^^^^^^^^^

Is this due to a more updated implementation that doesn't get reflected in the sample? Please kindly advice.

[TheBlueMatt]

That simply means that rustc wasn't able to figure out the required generic types. In the case of the sample, because we eventually assign the read value to a variable with defined generic types, it can deduce what we meant without us having to write it. If you aren't assigning the result in a variable with known type, you'll have to provide the list of generic types explicitly as it recommends.

Note that the sample uses SimpleArcChannelManager which hides a few of the generic types for you to avoid overload. https://github.com/lightningdevkit/ldk-sample/blob/d3112a612f8f830520ad01e533e3aac3a701c55e/src/main.rs#L97

[johnsBeharry]

What is the relationship with this repo and rust-lightning? Where does rust lightning stop and ldk begin?

[moneyball]

In most ways they're one and the same. LDK = rust-lightning. LDK is the preferred name to refer to the development kit for people to use. The implementation of the LN spec is in the rust-lightning repo. The code in the LDK repo(s) are bindings, samples, batteries, etc. to make it more usable. There has been some discussion about possibly moving/"linking" the repos to reduce confusion, and I'm not really sure where that discussion stands at this point.

[johnsBeharry]

Thats clear thanks!

[johnsBeharry]

What is the strategy for writing new language bindings? Is the goal to have them auto generated from rust, or is there cases where things would need to be partially / fully re-implemented in the new language?

[moneyball]

Auto-generated from rust.

[TheBlueMatt]

Note that generally generating straight from Rust has a huge amount of complexity. Thus, or Swift and Java bindings are currently generated from the C bindings (which are the only bindings generated directly from Rust).