.. 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>
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.
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, define a conversion from PendingV2Channel
to ChannelPhase (to be renamed Channel).
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, define a conversion from InboundV1Channel
to ChannelPhase (to be renamed Channel).
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, define a conversion from OutboundV1Channel
to ChannelPhase (to be renamed Channel).
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, define a conversion from Channel (to be
renamed FundedChannel) to ChannelPhase (to be renamed Channel).
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, update ChannelManager methods to use
methods on ChannelPhase for obtaining the appropriate V1 channel types.
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, update the convert_chan_phase_err macro to
use ChannelPhase::as_funded_mut instead.
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, update ChannelManager methods to use
ChannelPhase::as_unfunded_v2_mut and ChannelPhase::into_unfunded_v2
methods.
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, update ChannelManager::timer_tick_occurred
to use ChannelPhase::as_funded_mut and a new
ChannelPhase::unfunded_context_mut method.
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, update ChannelManager::handle_error to use
a new ChannelPhase::maybe_handle_error_without_close.
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, update ChannelManager::peer_connected to
use ChannelPhase::as_funded_mut and a new
ChannelPhase::maybe_get_open_channel method.
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, update ChannelManager::peer_disconnected to
use ChannelPhase::as_funded_mut and a new ChannelPhase::is_resumable
method.
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, update ChannelManager::signer_unblocked to
use ChannelPhase::as_funded and a new method on ChannelPhase dispatching
to each variant's signer_maybe_unblocked method.
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, update ChannelManager::internal_tx_abort to
use ChannelPhase::is_funded and a new ChannelPhase::as_unfunded_v2_mut
method.
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, rewrite ChannelManager's
unfunded_channel_count method to use ChannelPhase::as_funded and a new
ChannelPhase::as_unfunded_v2 method.
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, introduce ChannelPhase::is_funded for use
in ChannelManager when a Channel (to be later renamed FundedChannel)
needs to be tested for.
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.
Exposing ChannelPhase in ChannelManager has led to verbose match
statements, which need to be modified each time a ChannelPhase is added.
Making ChannelPhase an implementation detail of Channel would help avoid
this.
As a step in this direction, introduce ChannelPhase::as_funded and
ChannelPhase::as_funded_mut for use in ChannelManager when a Channel (to
be later renamed FundedChannel) is needed.
Pending v2 channels will need to be broken up into separate phases for
constructing and signing the funding transaction. To avoid increasing
the number of phases, combine the InboundV2Channel and OutboundV2Channel
types so that the can be used in one phase. Whether the channel is
inbound or outbound can be inferred from the ChannelContext.
We recently introduced `TRACE`-level logging for event handling.
However, in onion messenger we'd now log (twice, actually) every time
`process_events_async` is called, which is very very spammy. Here we fix
this by short-cutting to only proceed when we actualy have any event
futures to poll.
Previously, we would fail parsing `Offer`s if the HRP didn't match our
expected (lowercase) HRP. Here, we relax this check in accordance with
the spec to also allow all-uppercase HRPs.
Since adding support for creating static invoices from ChannelManager, it's
easier to test these failure cases that went untested when we added support for
paying static invoices.
We can't use our regular offer creation util for receiving async payments
because the recipient can't be relied on to be online to service
invoice_requests.
Therefore, add a new offer creation util that is parameterized by blinded
message paths to another node on the network that *is* always-online and can
serve static invoices on behalf of the often-offline recipient.
Also add a utility for creating static invoices corresponding to these offers.
See new utils' docs and BOLTs PR 1149 for more info.
