rust-lightning

Emit SpliceFailed event during channel shutdown

When a channel has a pending splice and is shutdown, generate a
SpliceFailed event when necessary. This allows users to reclaim any
contributed UTXOs.

Emit SpliceFailed event when tx_abort is received

When a tx_abort message is successfully processed for a funded channel
with an active splice negotiation, emit Event::SpliceFailed to notify
users that the splice operation was aborted by the counterparty.

Emit SpliceFailed event for interactive-tx failures

When interactive transaction construction fails during splice funding
negotiation, emit Event::SpliceFailed to notify users of the failure
such that they can reclaim any contributed UTXOs.

Add SpliceFailed event

Once a splice has been successfully initiated, but prior to signing any
negotiated funding transaction, it may fail. Add an event used to
indicate this and which UTXOs can be reused.

Emit SplicePending event when splice funding is negotiated

Once a splice has been negotiated and its funding transaction has been
broadcast, emit a SplicePending event. Once this occurs, the inputs
contributed to the splice cannot be reused except by an RBF attempt.

Add SplicePending event

Once a splice has been negotiated and its funding transaction has been
broadcast, it is considered pending until both parties have seen enough
confirmations to consider the funding locked. Add an event used to
indicate this.

Add support for deriving and signing a new static remote key

The `remote_key` derived by default in `KeysManager` depends on the
chanel's `channel_keys_id`, which generally has sufficient entropy
that without it the `remote_key` cannot be re-derived. In disaster
case where there is no remaining state except the `KeysManager`'s
`seed`, this results in lost funds, even if the counterparty
force-closes the channel.

Luckily, because of the `static_remote_key` feature, there's no
need for this. If the `remote_key` we derive is one of a countable
set, we can simply scan the chain for outputs to our `remote_key`s.

Here we set up such new derivation, adding logic to derive one of
1000 possible `remote_key`s (which translates to 2000 potential
`script_pubkey`s on chain). We also update the spending code to
check which of the two derivation formats where used and sign with
the correct key.

Convert `ChannelSigner::pubkeys` to only fetch *new* pubkeys

The `remote_key` derived by default in `KeysManager` depends on the
chanel's `channel_keys_id`, which generally has sufficient entropy
that without it the `remote_key` cannot be re-derived. In disaster
case where there is no remaining state except the `KeysManager`'s
`seed`, this results in lost funds, even if the counterparty
force-closes the channel.

Luckily, because of the `static_remote_key` feature, there's no
need for this. If the `remote_key` we derive is one of a countable
set, we can simply scan the chain for outputs to our `remote_key`s.

In the next commit, we'll start using different `remote_key`s based
on a config knob the user sets, but with the current
`ChannelSigner::pubkeys` API this would be invalid - we can't
return a different set of keys for a re-derived `ChannelSigner`.
Luckily, this isn't actually how LDK uses `ChannelSigner::pubkeys`,
it actually only calls it when it wants a new set of pubkeys,
either for a new channel or a splice.

Thus, here, we rename `ChannelSigner::pubkeys` to
`ChannelSigner::new_pubkeys` and update documentation to match.

Allow `KeysManager` to opt-into the new `remote_key` derivation

The `remote_key` derived by default in `KeysManager` depends on the
chanel's `channel_keys_id`, which generally has sufficient entropy
that without it the `remote_key` cannot be re-derived. In disaster
case where there is no remaining state except the `KeysManager`'s
`seed`, this results in lost funds, even if the counterparty
force-closes the channel.

Luckily, because of the `static_remote_key` feature, there's no
need for this. If the `remote_key` we derive is one of a countable
set, we can simply scan the chain for outputs to our `remote_key`s.

Here we finally allow users to opt into the new derivation scheme,
using the new derivation scheme for `remote_key`s for new and
spliced channels if a new `KeysManager::new` argument is set to
`true`.

Add UserConfig::reject_inbound_splices

This option allows nodes to reject inbound channel splice requests to
ensure backwards compatibility is not broken with LDK versions < 0.2
while a splice is pending. Outbound channel splice requests (via
`ChannelManager::splice_channel`, an opt-in API) are still allowed as
users should be aware of the backwards compatibility risk prior to using
the functionality.

Allow stale `ChannelMonitor`s if we are sure they don't have funds

In 601bf4bd8fdc37d55e571b1b3b9011a1c107afd9 we started refusing to
load `ChannelMonitor`s which were created prior to LDK 0.0.110 and
which were last updated prior to LDK 0.0.119. While this is likely
fine for nearly all of our users, there's some risk that some (like
me) have ancient un-archived `ChannelMonitor`s.

We do need to start auto-archiving `ChannelMonitor`s but for now we
need some way for such users to at least not fail on startup.
Sadly, ancient `ChannelMonitor`s often don't contain some of the
data we need to accurately calculate `Balance`s, but in cases where
they do, and where there are no claimable `Balance`s, we can be
confident we don't need the `ChannelMonitor`s.

Thus, here, we adapt the `ChannelMonitor` `Readable` implementation
used in the persistence wrappers to detect this case and simply
skip loading such `ChannelMonitor`s. Its not clear if this is
sufficient, but its at least better than the current state of
affairs after 601bf4bd8fdc37d55e571b1b3b9011a1c107afd9.

Test trampoline fwd payload encoded as receive

This re-adds test coverage for a case that was removed in the previous commit.

Add failure case on test unblided receive

Previously this commit, test only check for succesfully claimed case. Now tests
that successfully fail the HTLC and sender can read the error.

Fix trampoline error packet encryption using trampoline shared secret

When handling HTLC failures in trampoline routing, error packets were not
being properly encrypted with the trampoline shared secret. This caused
error messages to be unreadable by the original sender when failures
occurred within trampoline hops.

The fix prioritizes trampoline_shared_secret over phantom_shared_secret
when both are available, ensuring error packets can be properly decrypted
by trampoline senders.

Simplify test_trampoline_single_hop_receive

Previously, this test purported to test for a successful and a failing payment
to a single-hop blinded path containing one trampoline node. However, to induce
the failure the test was manually reconstructing the trampoline onion in a
complicated way that encoded the final onion payload as a receive, when for its
purposes it would be simplier for the recipient to just fail the payment
backwards.

In order to not regress in test coverage, the failure method the test was
previously using is re-added in the next commit as a dedicated test.

Test channel reestablish during splice lifecycle

This test captures all the new spec requirements introduced for a splice
to the channel reestablish flow.

Capture announcement signatures resend in reconnection tests

We'll use this in the next commit to test the resend logic for
`announcement_signatures` when reestablishing a channel that had a
pending splice become locked.

Avoid resetting splice state on FundingNegotiation::AwaitingSignatures

Otherwise, we won't ever be able to resume a pending negotiation after a
reconnection via `channel_reestablish`.

Along the way, we also merge `should_reset_pending_splice_state` into
`PendingFunding::can_abandon_state` to simplify the logic around when
we're able to reset specific parts of the pending splice state.

Avoid initial commitment channel_ready retransmission while splicing

If nodes have started a splice, this means they have both sent and
received `channel_ready` already: in that case, it's unnecessary to
retransmit `channel_ready` on reconnection.

Wait for inbound commitment_signed before producing tx_signatures

We only want to produce `tx_signatures` once we know that the monitor
update (either the initial one for a dual-funded channel, or a
`RenegotiatedFunding` one for a splice) has been persisted. If we
haven't received the counterparty's `commitment_signed` yet, then the
monitor update hasn't been created, leading us to pass the
`!awaiting_monitor_update` condition and produce a holder
`tx_signatures` message.

Return early on duplicate calls to `funding_transaction_signed`

We may produce duplicate `FundingTransactionReadyForSigning` events if
the user has processed an initial event but has not yet called back with
`funding_transaction_signed` and a peer reconnection occurs. If the user
also handles the duplicate events, any duplicate calls to
`funding_transaction_signed` after an initial successful one would
return an error. This doesn't make sense, as the API should remain
idempotent, so we return early on any duplicate calls.

Only claim HTLCs with matching payment hash upon preimage monitor update

Previously, we'd attempt to claim all HTLCs that have expired or that we
have the preimage for on each preimage monitor update. This happened due
to reusing the code path (`get_counterparty_output_claim_info`) used
when producing all claims for a newly confirmed counterparty commitment.
Unfortunately, this can result in invalid claim transactions and
ultimately in loss of funds (if the HTLC expires and the counterparty
claims it via the timeout), as it didn't consider that some of those
HTLCs may have already been claimed by a separate transaction.

This commit changes the behavior when handling preimage monitor updates
only. We will now only attempt to claim HTLCs for the specific preimage
that we learned via the monitor update. This is safe to do, as even if a
preimage HTLC claim transaction is reorged out, the `OnchainTxHandler`
is responsible for continuous claiming attempts until we see a reorg of
the corresponding commitment transaction.

Rustfmt get_counterparty_output_claim_info

We plan to rework this method in the following commit, so we start by
formatting it first.

Correctly handle new `ChannelMonitorUpdate`s to old post-FC chans

In 0.1 (1481216793169ae83c87ae26fddda8a1971e35f9) we started
setting `ChannelMonitorUpdate::update_id` to a non-`u64::MAX` value
for updates generated after a channel has been closed.

This is great, but in 71a364c13345396fd75b22877e03b6a7b1d2bca1 we
then started calculating the next `update_id` by incrementing the
last `update_id` we saw when we started and were looking at the
`ChannelMonitor`. However, the last-applied `update_id` may well be
`u64::MAX` for old `ChannelMonitor`s which were closed prior to
0.1. In that case the increment would overflow.

Here we fix this naively by simply replacing the increment with a
`saturating_add`. While its possible this will result in a
`ChannelMonitorUpdate` being tracked as in-flight (only for the
`ReleasePaymentComplete` updates added in 71a364c13345396fd75b2287)
at the same `update_id` as other updates already in-flight and
handling post-`ChannelMonitorUpdate` actions too early, this should
only apply to releasing payment complete updates, which have no
post-`ChannelMonitorUpdate` action.

Its also possible that this leads to a regression in the future,
where we have some new post-closure update that does have a
post-`ChannelMonitorUpdate` action and we run it too early, but by
then presumably its fairly rare to have a `ChannelMonitor` for a
channel closed pre-0.1 that still needs multiple updates.

Correctly track reloaded update_id in `chanmon_consistency` fuzzer

In the `chanmon_consistency` fuzzer, when reloading a node, we
take a pending monitor update (or the latest persisted one) and put
it in `persisted_monitor` as it is implicitly the latest persisted
monitor on restart. However, we failed to update
`persisted_monitor_id`. As a result, we may restart and write the
loaded monitor to `persisted_monitor` (eg at ID 2) but have a
later `persisted_monitor_id` (eg ID 3). Then, when we complete
the monitor update for the `persisted_monitor_id` (here, 3) we will
think that its not a new update and neglect to update
`persisted_monitor`/`persisted_monitor_id`. As a result, later
updates (e.g. ID 4) will fail as we're trying to apply them to the
original persisted monitor (at ID 2).

The fix is simply to ensure `persisted_monitor_id` is always
updated in lock-step with `persisted_monitor` on reload.