Upon creating a channel monitor, it is provided with the initial
counterparty commitment transaction info directly before the very first
time it is persisted. Because of this, the very first counterparty
commitment is not seen as an update in the persistence pipeline, and so
our previous changes to the monitor and updates cannot be used to
reconstruct this commitment.
To be able to expose the counterparty's transaction for the very first
commitment, we add a thin wrapper around
`provide_latest_counterparty_commitment_tx`, that stores the necessary
data needed to reconstruct the initial commitment transaction in the
monitor.
Currently, when we receive an HTLC claim from a peer, we first hash
the preimage they gave us before removing the HTLC, then
immediately pass the preimage to the inbound channel and hash the
preimage again before removing the HTLC and sending our peer an
`update_fulfill_htlc`. This second hash is actually only asserted
on, never used in any meaningful way as we have the htlc data
present in the same code.
Here we simply drop this second hash and move it into a
`debug_assert`.
If a user has issues with a payment, the most obvious thing they'll
do is check logs for the payment hash. Thus, we should ensure our
logs that show a payment's lifecycle include the payment hash and
are emitted (a) as soon as LDK learns of the payment, (b) once the
payment goes out to the peer (which is already reasonably covered
in the commitment transaction building logs) and (c) when the
payment ultimately is fulfilled or fails.
Here we improve our logs for both (a) and (c).
This adds the feerate and local and remote output values to this channel
monitor update step so that a monitor can reconstruct the counterparty's
commitment transaction from an update. These commitment transactions
will be exposed to users in the following commits to support third-party
watchtowers in the persistence pipeline.
With only the HTLC outputs currently available in the monitor update, we
can tell how much of the channel balance is in-flight and towards which
side, however it doesn't tell us the amount that resides on either side.
Because of dust, we can't reliably derive the remote value from the
local value and visa versa. Thus, it seems these are the minimum fields
that need to be added.
Rather than using a holder_signer of a specific
signer type in Channel and ChannelContext, this
allows us to hold an enum such that depending on
the type of channel, the appropriate signer could
be held in its respective variant.
Doing so required the reparametrization of Channel
from using a Signer to using the SignerProvider
trait. This percolated down to the ChannelManager
and multiple tests.
Now, when accessign various signer methods, there
is a distinction between accessing methods defined
for all signers on ChannelSigner, and accessing
type-specific methods using accessors such as
`as_ecdsa`.
LND hasn't properly handled shutdown messages ever, and
force-closes any time we send one while HTLCs are still present.
The issue is tracked at
https://github.com/lightningnetwork/lnd/issues/6039 and has had
multiple patches to fix it but none so far have managed to land
upstream. The issue appears to be very low priority for the LND
team despite being marked "P1".
We're not going to bother handling this in a sensible way, instead
simply repeated the Shutdown message on repeat until morale
improves.
In 0ad1f4c943 we fixed a nasty bug
where a failure to persist a `ChannelManager` faster than a
`ChannelMonitor` could result in the loss of a `PaymentSent` event,
eventually resulting in a `PaymentFailed` instead!
As noted in that commit, there's still some risk, though its been
substantially reduced - if we receive an `update_fulfill_htlc`
message for an outbound payment, and persist the initial removal
`ChannelMonitorUpdate`, then respond with our own
`commitment_signed` + `revoke_and_ack`, followed by receiving our
peer's final `revoke_and_ack`, and then persist the
`ChannelMonitorUpdate` generated from that, all prior to completing
a `ChannelManager` persistence, we'll still forget the HTLC and
eventually trigger a `PaymentFailed` rather than the correct
`PaymentSent`.
Here we fully fix the issue by delaying the final
`ChannelMonitorUpdate` persistence until the `PaymentSent` event
has been processed and document the fact that a spurious
`PaymentFailed` event can still be generated for a sent payment.
The original fix in 0ad1f4c943 is
still incredibly useful here, allowing us to avoid blocking the
first `ChannelMonitorUpdate` until the event processing completes,
as this would cause us to add event-processing delay in our general
commitment update latency. Instead, we ultimately race the user
handling the `PaymentSent` event with how long it takes our
`revoke_and_ack` + `commitment_signed` to make it to our
counterparty and receive the response `revoke_and_ack`. This should
give the user plenty of time to handle the event before we need to
make progress.
Sadly, because we change our `ChannelMonitorUpdate` semantics, this
change requires a number of test changes, avoiding checking for a
post-RAA `ChannelMonitorUpdate` until after we process a
`PaymentSent` event. Note that this does not apply to payments we
learned the preimage for on-chain - ensuring `PaymentSent` events
from such resolutions will be addressed in a future PR. Thus, tests
which resolve payments on-chain switch to a direct call to the
`expect_payment_sent` function with the claim-expected flag unset.
01847277b9 switched around the logic
for inbound channel construction to assign the outbound SCID alias
after constructing the `InboundV1Channel` object. Thus, the SCID
alias argument is now unused, and we remove it here.
The ChannelMonitor::get_claimable_balances method provides a more
straightforward approach to the balance of a channel, which satisfies
most use cases. The computation of AvailableBalances::balance_msat is
complex and originally had a different purpose that is not applicable
anymore.
Create a new table in 'peer_state' to maintain unaccepted inbound
channels; i.e., a channel for which we've received an 'open_channel'
message but that user code has not yet confirmed for acceptance. When
user code accepts the channel (e.g. via 'accept_inbound_channel'),
create the channel object and as before.
Currently, the 'open_channel' message eagerly creates an
InboundV1Channel object before determining if the channel should be
accepted. Because this happens /before/ the channel has been assigned
a user identity (which happens in the handler for OpenChannelRequest),
the channel is assigned a random user identity. As part of the
creation process, the channel's cryptographic material is initialized,
which then uses this randomly generated value for the user's channel
identity e.g. in SignerProvider::generate_channel_keys_id.
By delaying the creation of the InboundV1Channel until /after/ the
channel has been accepted, we ensure that we defer cryptographic
initialization until we have given the user the opportunity to assign
an identity to the channel.
A channel's `short_channel_id` is currently only set when the funding
transaction is confirmed via `transactions_confirmed`, which might be
well after the channel initally becomes usable, e.g., in the 0conf case.
Previously we would panic due to a reachable `unwrap` when receiving a
counterparty's `announcement_signatures` message for a 0conf channel
pending confirmation on-chain.
Here we fix this bug by avoiding unsafe `unwrap`s and just erroring out
and ignoring the announcement_signatures message if the `short_channel_id`
hasn't been set yet.
We introduce a `UnfundedChannelContext` which contains a counter for the
current age of an unfunded channel in timer ticks. This age is incremented
for every `ChannelManager::timer_tick_ocurred` and the unfunded channel
is removed if it exceeds `UNFUNDED_CHANNEL_AGE_LIMIT_TICKS`.
The value will not be persisted as unfunded channels themselves are not
persisted.
As done with inbound feerate updates, we can afford to commit less in
fees, as long as we still may the minimum mempool feerate. This enables
users to spend a bit more of their balance, as less funds are being
committed to transaction fees.
Channels supporting anchors outputs no longer require their feerate
updates to target a prompt confirmation since commitment transactions
can be bumped when broadcasting. Commitment transactions must now at
least meet the minimum mempool feerate, until package relay is deployed,
such that they can propagate across node mempools in the network by
themselves.
The existing higher bound no longer applies to channels supporting
anchor outputs since their HTLC transactions don't have any fees
committed, which directly impact the available balance users can send.
* `PhantomRouteHints::channels` has been written since the struct
was added in 410eb05365.
* `HTLCSource::path_hops` has been written since the struct was
converted to TLVs in 66784e32fe.
This commit makes use of the added enum to calculate the dust
exposure threshold based on the current fee rate. This also updates
tests to ensure it works as intended.
With fee rates rising dramatically in mid-April 2023, thresholds for
what is considered dust have risen, often exceeding our previous dust
exposure threshold of 5k sats. This causes all payments and HTLC
forwards between 5k sats and new dust thresholds to fail.
This commit changes our max dust exposure config knob from a fixed
upper limit to a `MaxDustHTLCExposure` enum with an additional variant
to allow setting our max dust exposure to a multiplier on the current
high priority feerate.
To remain backwards compatible we'll always write the fixed limit if
it's set, or its default value in its currently reserved TLV.
We also now write an odd TLV for the new enum, so that previous
versions can safely ignore it upon downgrading, while allowing us to
make use of the new type when it's written.
In 1ce2beb774,
`Channel::blocked_monitor_updates` was moved to an even TLV to
ensure downgrades with vec entries are forbidden. However, the
serialized type remained `vec_type`, which is always written.
Instead, `optional_vec` must be used.
In 9dfe42cf86,
`ChannelMonitorUpdate`s were stored in `Channel` while they were
being processed. Because it was possible (though highly unlikely,
due to various locking likely blocking persistence) an update was
in-flight (even synchronously) when a `ChannelManager` was
persisted, the new updates were persisted via an odd TLV.
However, in 4041f0899f these pending
monitor updates were moved to `ChannelManager`, with appropriate
handling there. Now the only `ChannelMonitorUpdate`s which are
stored in `Channel` are those which are explicitly blocked, which
requires the async pipeline.
Because we don't support async monitor update users downgrading to
0.0.115 or lower, we move to persisting them via an even TLV. As
the odd TLV storage has not yet been released, we can do so
trivially.
Fixes#2317.
Now that all of the core functionality for anchor outputs has landed,
we're ready to remove the config flag that was temporarily hiding it
from our API.
`Channel::get_latest_complete_monitor_update_id` no longer refers
to complete updates, but rather ones which were passed to the
`ChannelManager` and which the `CHannel` no longer knows about.
Thus, we rename it `get_latest_unblocked_monitor_update_id`.
Because `ChannelMonitorUpdate`s can be generated for a
channel which is already closed, and must still be tracked
through their completion, storing them in a `Channel`
doesn't make sense - we'd have to have a redundant place to
put them post-closure and handle both storage locations
equivalently.
Instead, here, we move to storing in-flight
`ChannelMonitorUpdate`s to the `ChannelManager`, leaving
blocked `ChannelMonitorUpdate`s in the `Channel` as they
were.
