Blinded HTLCs are always failed back with the same error, so DRY the test code
that fails them backwards. This util will also be used for async payments
testing in upcoming commits.
When an outbound payment fails while paying to a route, we need to remove the
session_privs for each failed path in the outbound payment.
Previously we were sometimes removing in pay_route_internal and sometimes in
handle_pay_route_err, so refactor this so we always remove in
handle_pay_route_err.
Previously, the `feerate_bump` method did not enforce the dust
threshold, which could result in us thinking we had raised the fee
rate without actually having done so. Instead,
`compute_package_output` blindly accepted the updated fee rate while
enforcing a non-dust output value, resulting in repeated broadcast
attempts of an identical transaction.
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.
This commit ensures all new incoming HTLCs going forward will have their
onion decoded when they become fully committed to decide how we should
proceed with each one. As a result, we'll obtain `HTLCHandlingFailed`
events for _any_ failed HTLC that comes across a channel.
Previously, we would evaluate the incoming HTLC within
`can_accept_incoming_htlc` upon receiving it, but not yet committed, so
we'd always have to account for it ourselves manually when checking
certain HTLC limits. With this change, we no longer need to do so as it
will already be accounted for within the pending HTLC stats computation.
We will now start writing channels with the new serialization version
(4), and we will still be able to downgrade back to the commit that
introduced it since reading version 4 is supported.
Note that existing pending inbound HTLCs may already have their
resolution if they were received in a previous version of LDK. We must
support those until we no longer allow downgrading beyond this commit.
Prior to this patch, if we attempted to send a payment or probe to a buggy
route, we would error but continue storing the pending outbound payment
forever. Attempts to retry would result in a “duplicate payment” error.
In the case of ChannelManager::send_payment, we would also fail to generate a
PaymentFailed event, even if the user manually called abandon_payment.
This bug is unlikely to have ever been hit in the wild as most users use LDK’s
router. Discovered in the course of adding a new send_to_route API.
Now, we’ll properly generate events and remove the outbound from storage.
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`.
