Bump crate versions to 0.1.0/invoice 0.33.0/dns-resolver 0.2 #3543
Conversation
This file contains 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
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.
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.
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
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 <[email protected]> Co-authored-by: Jeffrey Czyz <[email protected]>
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.
Static invoices don't have an amount_msats field.
Sadly, dns-resolver got uploaded as 0.1.0 without a -beta1 tag (and yanked), and thus we release it here as 0.2.0.
TheBlueMatt
force-pushed
the
2025-01-0.1-version
branch
from
709c650 to
0241f6e
Compare
jkczyz
approved these changes
Jan 15, 2025
|
Landing since this is only version-bump/release name which doesn't really need a second reviewer. |
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.
Sadly, dns-resolver got uploaded as 0.1.0 without a -beta1 tag (and yanked), and thus we release it here as 0.2.0.