rust-lightning
rust-lightning copied to clipboard
lightningdevkit
A highly modular Bitcoin Lightning library written in Rust. It's rust-lightning, not Rusty's Lightning!
We should add `cargo doc --features no-std --no-default-features` to our CI.
Fix #2879 Refactored `payment_parameters_from_zero_amount_invoice` to `amount-less` as per the discussion in the issue
A Payjoin integration with `ldk-node` started here https://github.com/lightningdevkit/ldk-node/pull/257 and there are a couple of things I discussed with tnull and we thought it would be good to bring the discussion...
Closes #2490. Previously, we would require our users to handle all events successfully inline or panic will trying to do so. If they would exit the `EventHandler` any other way...
Async-receive: - [ ] Support being the async receiver’s channel counterparty (eg LSP) per the [spec](https://github.com/lightning/bolts/pull/989) PR - [ ] Support store-and-forward mailbox for onion messages #2950 - [ ]...
Currently, every block connection triggers the persistence of all ChannelMonitors with an updated best_block. This approach poses challenges for large node operators managing thousands of channels. Furthermore, it leads to...
During LDK startup we often get a flood of gossip for channels that haven't seen an update in two years. Peers really shouldn't be sending us this garbage, but currently...
The "joint" channel functionality would be to make all the funding/closing and payments operations to be jointly signed by a group of N entities. This assumes Schnorr support being specified...
If a channel isn't public, our "reduce max_value_in_flight to provide routed payments more privacy" thing doesn't make sense...cause the channel isn't routing payments. Thus, our default config should depend on...
Metadata
Owner
Metadata
A highly modular Bitcoin Lightning library written in Rust. It's rust-lightning, not Rusty's Lightning!