rust-lightning

Drop unused fields from `lightning-transaction-sync` test utils

Drop `AddSigned` trait

.. now that we can, addressing a TODO.

Add `rust-version` to all crates' `Cargo.toml`s

Bump MSRV to rustc 1.75.0

We generally align our MSRV with Debian's stable channel. Debian 13
'Trixie' was just released, shipping rustc 1.85. However, as 1.85.0 is
only about ~7months old at this point, we opt to bump to the more
conservative 1.75.0, which approaches two years of age.

Capture stfu send in reconnection tests

We'll use this in the next commit to test that we'll send a stfu message
for a splice we intend to initiate upon reconnecting.

Send 0conf splice_locked upon tx_signatures exchange

Splices negotiated with 0 confirmations require that we immediately lock
it after exchanging `tx_signatures`.

Replace docs.rs build `doc_auto_cfg` feature with `doc_cfg`

These have been merged, causing our docs.rs builds to fail. Sadly,
we saw our docs.rs build fail for the 0.1.6 upload because of this.

Emit SpliceFailed event upon reload

Similarly to when a peer is disconnected, when a node is reloaded any
splice that hasn't reaching FundingNegotiation::AwaitingSignatures will
be reset. This should produce a SpliceFailed event. However, since other
FundingNegotiation variants are not persisted, the data to produced the
SpliceFailed event upon reload is lost. Therefore, opportunistically
persist a SpliceFailed event for these cases such that it is available
upon reload.

Emit SpliceFailed upon disconnect while quiescent

Since quiescence is terminated upon disconnection, any outstanding
splice negotiation should result in emitting a SpliceFailed event as
long as we haven't reached FundingNegotiation::AwaitingSignatures. This
may occur if we explicitly disconnect the peer (e.g., when failing to
process splice_ack) or if the connection is lost.

Correct name of `get_counterparty_payment_script` method

`get_counterparty_payment_script` fetches the countersigner's (i.e.
non-broadcaster) payment script, but that could be ours or or
counterparty's. Thus, it should read
`get_countersigner_payment_script`, which we fix here.

Add a method to fetch all possible remote-closure `script_pubkey`s

In the previous commit we (finally) allowed users to opt into a
static `remote_key` derivation scheme, enabling them to scan the
chain for funds on counterparty commitment transactions without any
state at all.

This is only possible, however, of course, if they have the full
list of scripts to scan the chain for, which we expose here.

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.

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`.

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.

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.

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.

Correct EOF handling in stream read in `ChaChaDualPolyReadAdapter`

When `ChaChaDualPolyReadAdapter` encounters an EOF (`Read::read`
returns `Ok(0)`) while trying to drain the stream (even though the
`FixedLengthReader` thinks it has available space) we'll end up
infinite-looping trying to drain the stream looking for
`Read::read` to return an `Err` (which it won't).

The fix is, of course, simple, to detect the EOF signal.

Found by the `onion_message_target` fuzzer which @dergoegge ran.
Thanks to @morehouse for digging deeper on the specific fuzz test
case and thoroughly reporting the underlying causes.

Fixes #4139.

Wipe splice state upon failed interactive funding construction

An interactive funding construction can be considered failed upon a
disconnect or a `tx_abort` message. So far, we've consumed the
`InteractiveTxConstructor` in the latter case, but not the former.
Additionally, we may have splice-specific state that needs to be
consumed as well to allow us to negotiate another splice later on.

This commit ensures that we properly consume all splice and interactive
funding state whenever possible upon a disconnect or `tx_abort`.

The interactive funding state is safe to consume as long as we have
either yet to reach `AwaitingSignatures`, or we have but `tx_signatures`
has not been sent/received. In all of these cases, we also make sure to
clear the quiescent state flag such that we're able to resume processing
updates on the channel.

The splice state is safe to consume as long as we don't have a pending
`FundingNegotiation::AwaitingSignatures` with a `tx_signatures`
sent/received and we don't have any negotiated candidates. Note that
until splice RBF is supported, it is not currently possible to have any
negotiated candidates with a pending interactive funding transaction.

Give the `get_change_destination_script` future access to `self`

Its generally useful for trait methods to be able to access `self`,
sadly our definition of `get_change_destination_script` was screwed
up and couldn't. Luckily its an easy fix as none of the callsites
care about the extra `self` lifetime.