Here we bubble up the payment context into PendingHTLCRouting::ReceiveKeysend
and check it when receiving a spontaneous payment prior to generating a
claimable event. Prior to this patch, we would have accepted out-of-context
keysends sent over blinded paths taken from our BOLT 12 invoices.
As a side effect of this, our blinded keysend success test cases now fail, so
those tests are now removed. Their coverage is re-added in future commits when
we add support for async receive, meaning we're able to receive blinded
keysends in the correct payment context.
While we could avoid storing the payment context for the purposes of this
bugfix, we go ahead and store it now because it will be needed when support for
receiving async payments is added.
Prior to this patch, if we received an expired static invoice we would delay
surfacing the payment failure until after the recipient had come online and
sent the release_held_htlc OM, which could be a long time later. Now, we'll
detect that the invoice is expired as soon as it's received.
Needed to authenticate that the held_htlc_available message is being sent over
a reply path that we originally created and that isn't expired before we reply
with release_held_htlc. This context will be used in upcoming commits when we
add support for async receive.
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>
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.
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.
