Merge develop into main
#655
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As part of the version v0.3 release we switched to the upstreamed `OutputSweeper` which slightly changed our serialization format, having us run a migration step on startup for backwards compatibility ever since. Here we drop the migration code running on startup, for simplicity's sake, but also because it's going to be async going forward and we currently don't have a runtime available on startup (which might change soon, but still). As the v0.3 release now well over a year ago, it's very unlikely that there are any v0.2 (or even v0.3) users left. If there are any affected users left, they'll first have to upgrade to any version pre-v0.7, startup, and then upgrade to v0.7 or later.
We bump our LDK dependency to 0.2-devel, up to commit `4e32d85249359d8ef8ece97d89848e40154363ab`.
We switch to use `rustls-ring` everywhere, which is necessary for Swift builds, but also generally makes our lives easier.
Helpful to correlate multiple log files throughout time
This commit adds support for using ldk-node as a static invoice server. When configured as such, the node persists and retrieves invoices from the configured kv store. Access is guarded by a rate limiter to prevent overload and mitigate potential DoS attacks. In this mode, ldk-node also exposes blinded paths that can be shared with async recipients, allowing them to contact the static invoice server. When ldk-node functions as a recipient, it can communicate with the static invoice server to set up async payments.
Static invoice server
With splicing now implemented, a channel may have multiple holder commitment transactions and corresponding balance candidates. ldk-node now reports the confirmed balance candidate rather than a single static balance, ensuring the exposed value matches the channel's onchain state. Other candidate balances remain internal for now.
Adapt channel balance reporting to use confirmed candidate
Multi node console log
With the merge of lightningdevkit/rust-lightning#4049, it is now possible for a static invoice server to forward the invoice request to the recipient if they are online.
To better align with the expected real life setup.
Update static invoice store for invoice requests
Backoff wasn't actually working and polling would happen without any delay at all.
Updated `pay_for_offer` call with `OptionalOfferPaymentParams` and delegate to `pay_for_offer_with_quantity` when needed.
Adapt to new pay_for_offer call
We attempt to log a status code when `reqwest` returns a `Request` error kind. It might not be the case that the status code would always/ever be set for this error kind.
Fix wait_for_tx/outpoint exponential backoff
Try to log status code for `reqwest`'s `Request` error kind
The `FutureSpawner` trait moved to `lightning::util::native_async` now.
Bump LDK and account for `FutureSpawner` move
This introduces an in-memory mailbox to hold onion messages until the receiver comes online. This is required for async payment `held_htlc_available` messages. The mailbox is bounded by a maximum number of peers and a maximum number of messages per peer.
Add onion mailbox for async recipients
Nightly `rustfmt` allows to auto-group imports on the module level. While we're not quite convinced to switch to the nightly channel for this yet (mostly because not all contributors would have the right nightly version installed on their machines), we here make use of `cargo +nightly fmt` with some addtional import grouping options as a one-off. This cleans up our imports for the whole crate and gets us to a consistent state everywhere.
Re-format all imports
So that we'll cleanly signal and wait for termination.
Previously ldk-node would start binding after the first successful bind to an address.
To avoid conflicts ("port in use") with ports that were used for
outgoing connections and are now in the TIME_WAIT state.
Listen on all provided addresses
|
👋 Thanks for assigning @joostjager as a reviewer! |
joostjager
approved these changes
Oct 7, 2025
Contributor
joostjager
left a comment
joostjager
left a comment
There was a problem hiding this comment.
Blind ack, everything has been reviewed already.
This was referenced Oct 7, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We recently introduced a
developbranch that tracks more recent commits on LDK'smainbranch. This proved to be a good idea for more seamless development that require more recent LDK features. It however also increased complexity/confusion around what branch contributors should base new PR off.Here, we simply merge the new
developonto main, and will delete it eventually.From now on, all PRs should be based off
main, and we'll simply backport changes/cherry-pick commits for minor releases, just as we already do for patch releases.