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!
This adds an `OnionMessenger::process_pending_events_async` mirroring the same in `ChannelManager`. However, unlike the one in `ChannelManager`, this processes the events in parallel by spawning all futures and using the new `MultiFuturePoller`....
We have a lot of users who use LDK with a counterparty who is their LSP and they trust to not play games with dust limit/feerates and maybe even accept...
I think we were a little too conservative on our scoring params and we end up too strongly preferring to avoid fees, when most lightning users actually expect to pay...
- [x] dynamic signer factory - [x] `DynSigner` - [x] apply `xtest` macros - [x] PoC external usage
After we upgraded to `rust-bitcoin` 0.30 in #2740, we should look into upgrading to 0.31.0 soon to keep up with the most-recent version. However, this time we should try to...
For quite some time, LDK has force-closed channels if the peer sends us a feerate update which is below our `FeeEstimator`'s concept of a channel lower-bound. This is intended to...
Users keep running into fee rate related interoperability issues on `Testnet` as we try to dynamically estimate fees while CLN/LND hard-code certain fee rates due to fee estimation being broken...
There is no way to tell whether a `Balance` is for a coop close or an HTLC or a force-close. We should expose that info.
Once we have a finalized coop close transaction we should consider rebroadcasting it via the channelmonitor, I think.
re: #2261 we should also ideally expose what our current dust exposure in a channel *is*
Metadata
Owner
Metadata
A highly modular Bitcoin Lightning library written in Rust. It's rust-lightning, not Rusty's Lightning!