In a coming commit we'll expire HTLCs backwards even if we haven't
yet claimed them on-chain based on their inbound edge being close
to causing a channel force-closure.
Here we track the incoming edge's CLTV expiry in the
pending-routing state so that we can include it in the `HTLCSource`
in the next commit.
Co-authored-by: Matt Corallo <git@bluematt.me>
PR #3323 introduced some extra variables to avoid `rustfmt` making
a total mess of our code, but introduced a few that don't make
`rustfmt` do dumb things, which we remove here.
.. we pull out `Mutex` field initialization into dedicated variables as
they might otherwise land on the same line when formatting, which might
lead to lockorder violation false-positives when compiled with the
`backtrace` feature.
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.
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>
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`.
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 https://github.com/lightningdevkit/rust-lightning/issues/3537.
.. 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 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.
