Skip to content

Conversation

tnull
Copy link
Collaborator

@tnull tnull commented Sep 25, 2025

Based on #650.

We fix two more minor API changes that have been merged on LDK.

tnull and others added 30 commits September 3, 2025 13:55
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.
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
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.
…fwd-inv-req

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.
…refactor

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.
…pawner

Bump LDK and account for `FutureSpawner` move
.. first step to make review easier.
.. as we're gonna reuse the `async` `_internal` methods shortly.
.. where the former holds the latter in an `Arc` that can be used in
async/`Future` contexts more easily.
We implement the async `KVStore` trait for `VssStore`.
.. to be easier reusable via `KVStore` also
.. where the former holds the latter in an `Arc` that can be used in
async/`Future` contexts more easily.
.. to be easier reusable via `KVStore` also
.. where the former holds the latter in an `Arc` that can be used in
async/`Future` contexts more easily.
As an intermediary step, we require any store to implement both
`KVStore` and `KVStoreSync`, allowing us to switch over step-by-step.

We already switch to the fully-async background processor variant here.
We recently implemented persistence for the `lightning-liquidity` service
state. Here we make corresponding changes in LDK Node to have our
service state persisted.
@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Sep 25, 2025

👋 Hi! This PR is now in draft status.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

@tnull tnull marked this pull request as draft September 25, 2025 14:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants