Backports for 0.1.0#3536
Merged
TheBlueMatt merged 12 commits intolightningdevkit:0.1from Jan 16, 2025
Merged
Conversation
Lack of bindings support was because the method used to return a slice of tuples, it seems. Now that it returns &[BlindedPaymentPath], bindings should be possible given that they can be generated for Bolt12Invoice::message_paths.
When either the amount or the `max_total_cltv_expiry_delta` are set to max-value, `set_max_path_length` can trigger overflows in `build_onion_payloads_callback`, leading to debug-panics.
With the `Confirm` interface, transaction confirmations can come in at any time, so asserting that a confirmation is more recent than the last time we broadcasted a transaction can lead to spurious assertion failures.
.. and bump its MSRV to 1.75. Recently, `rustls` bumped their MSRV to 1.71. As we depend on them and don't want to continuously pin this security-critical dependency back, we have no choice left but to bump the MSRV for `lightning-transaction-sync` to a version >= 1.71, too. Here, we hence move the `lightning-transaction-sync` tests to a dedicated script and propose to introduce a secondary MSRV of 1.75. We chose this particular version, because: a) it's > 1 year old b) it provides a buffer to 1.71, i.e., if some crate bumped to a version > 1.71, there is a chance we don't immediately have to react again c) it stabilized `async fn`s in traits (see https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html), which might become handy for related (BDK) crates, which hopefully will adopt the same target.
Contributor
|
Note that we also tagged #3531 for backport |
Collaborator
Author
|
Sure, but #3531 hasn't landed, and I'm not sure we need to hold 0.1.0 on it :). |
When scanning confirmed transactions for spends that conflict with our existing packages, we should continue scanning after detecting the first conflicting package since a transaction can conflict with multiple packages. This ensures that we remove *all* inputs from our packages that have already been spent by the counterparty so that valid claim transactions are generated. Fixes lightningdevkit#3537.
Contributor
|
Ah, CI failure reminded me we need to backport this: #3518. Just tagged it. |
Rust 1.84.0 was recently released along with some new clippy lints, one of which is `unnecessary_map_or`. Unfortunately this lint suggests using `Option::is_some_and` as a fix, but this is only available in Rust version >= 1.70, while we still have an MSRV of 1.63. So we silence that lint for now. We'd still like our lint CI to use stable Rust so that we can benefit from new lint checks which may be helpful and don't require an MSRV bump, but sometimes new lints (like in this case) do. See: https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_map_or https://doc.rust-lang.org/std/option/enum.Option.html#method.is_some_and
dunxen
approved these changes
Jan 15, 2025
To trigger message processing, we previously had the user set a callback to `PeerManager::process_events` via an `Fn()` callback. This is however not supported by `c_bindings`. Here, we therefore introduce as `ProcessMesssagesCallback` trait that can be used via `LiquidityManager::set_process_msgs_callback_fn`, which is exposed in `c_bindings`.
Add a check to ensure that the amount_msats in an invoice matches the amount_msats specified in the invoice_request or offer (or refund). Reject the invoice as invalid if there is a mismatch between these amounts. Otherwise, an invoice may be paid with an amount greater than the requested amount. Co-authored-by: Ian Slane <slaneian@gmail.com> Co-authored-by: Jeffrey Czyz <jkczyz@gmail.com>
When InvoiceRequest::amount_msats returns Some, it may have been inferred from the Offer::amount and InvoiceRequest::quantity. Add a method to InvoiceRequest for determining if the amount was explicitly set.
Collaborator
Author
|
Okay, this should be good to land now (once #3530 lands). |
TheBlueMatt
force-pushed
the
2025-01-0.1-backports
branch
from
ea0c318 to
be1a3ab
Compare
This was referenced Jan 15, 2025
Merged
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 0.1 #3536 +/- ##
==========================================
+ Coverage 88.29% 88.33% +0.04%
==========================================
Files 149 149
Lines 112930 113281 +351
Branches 112930 113281 +351
==========================================
+ Hits 99707 100066 +359
- Misses 10732 10733 +1
+ Partials 2491 2482 -9 ☔ View full report in Codecov by Sentry. |
This was referenced Jan 15, 2025
Static invoices don't have an amount_msats field.
Collaborator
Author
|
Ugh, okay, now should be good. |
jkczyz
approved these changes
Jan 15, 2025
This was referenced Jan 15, 2025
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
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.
This includes backports for #3518, #3520, #3521, #3522, #3524, #3528, #3530, #3533, #3535, and #3538.