-
Notifications
You must be signed in to change notification settings - Fork 115
Account for Arc
s and lazy
being dropped
#651
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
tnull
wants to merge
36
commits into
lightningdevkit:main
Choose a base branch
from
tnull:2025-09-fix-lazy-remove
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
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.
…-server 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
…sole-log 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.
…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.
👋 Hi! This PR is now in draft status. |
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.
Based on #650.
We fix two more minor API changes that have been merged on LDK.