rust-lightning

Add missing documentation for sigs-ready event to `splice_channel`

`ChannelManager::splice_channel` initiates a splice which
ultimately generates a series of events. The most important of
which, `FundingTransactionReadyForSigning` (which must always be
handled, unlike the others), was not documented.

Here we mention the event generation.

Drop useless `vec!` macro calls

`clippy` now complains about more instances of useless `vec!`s, so
we drop them here.

Pin `proptest` again to fix CI

.. `proptest` 1.9.0 was just released, now requiring rustc 1.82.

Properly handle funding key rotation during splices

When splicing, we're required by protocol to retain all the
existing keys material except the funding key which we're allowed
to rotate. In the original implementation we acknowledged that but
figured we'd stick with a single `pubkey` method in the
`ChannelSigner` anyway cause adding a specific method for it is
annoying.

Sadly, this was ultimately broken - in `FundingScope::for_splice`,
we called the signer's `new_pubkeys` method (renamed from `pubkeys`
after splicing initially landed), replacing all of the public keys
the `Channel` would use rather than just the funding key. This can
result in commitment signature mismatches if the signer changes any
keys aside from the funding one.

`InMemorySigner` did not do so, however, so we didn't notice the
bug. Luckily-ish, in 189b8ac4a7674bbf623f903dcd144c9d1a24a128 we
started generating a fresh `remote_key` when splicing (at least
when upgrading from 0.1 to 0.2 or when setting `KeysManager` to use
v1 `remote_key` derivation). This breaks splicing cause we can't
communicate the new `remote_key` to the counterparty during the
splicing handshake.

Ultimately this bug is because the API we had didn't communicate to
the signer that we weren't allowed to change anything except the
funding key, and allowed returning a `ChannelPublicKeys` which
would break the channel.

Here we fix this by renaming `new_pubkeys` `pubkeys` again
(partially reverting 9d291e01f98417c2f6b2d4321bbf806464c424a6 but
keeping the changed requirements that `pubkeys` only be called
once) and adding a new `ChannelSigner:new_funding_pubkey` method
specifically for splicing.

We also update `channel.rs` to correctly fetch the new funding
pubkey before sending `splice_init`, storing it in the
`PendingFunding` untl we build a `FundingScope`.

Fix `generated_by_local` arg to build commmitment during splicing

`build_commitment_transaction`'s fifth argument is supposed to be
whether we're the one generating the commitment (i.e. because we're
signing rather than validating the commitment). During splicing,
this doesn't matter because there should be no async HTLC
addition/removal happening so the commitment generated wil be the
same in either case, but its still good to pass the correct bool.

Fix panic when deserializing `Duration`

`Duration::new` adds any nanoseconds in excess of a second to the
second part. This can overflow, however, panicking. In 0.2 we
introduced a few further cases where we store `Duration`s,
specifically some when handling network messages.

Sadly, that introduced a remotely-triggerable crash where someone
can send us, for example, a malicious blinded path context which
can cause us to panic.

Found by the `onion_message` fuzzer

Send 0conf splice_locked upon tx_signatures exchange

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

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.

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.

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

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.

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.

Introduce specific InvoiceBuilders in OffersMessageFlow

This change improves type safety and architectural clarity
by introducing dedicated `InvoiceBuilder` methods tied to
each variant of `VerifiedInvoiceRequestEnum`.

With this change, users are now required to match on the
enum variant before calling the corresponding builder method.
This pushes the responsibility of selecting the correct
builder to the user and ensures that invalid builder
usage is caught at compile time, rather than relying
on runtime checks.

The signing logic has also been moved from the builder
to the `ChannelManager`. This shift simplifies the
builder's role and aligns it with the rest of the API,
where builder methods return a configurable object that
can be extended before signing. The result is a more
consistent and predictable interface that separates
concerns cleanly and makes future maintenance easier.

Introduce VerifiedInvoiceRequest<S: SigningPubkeyStrategy>

This commit reintroduces `VerifiedInvoiceRequest`, now parameterized by
`SigningPubkeyStrategy`.

The key motivation is to restrict which functions can be called on a
`VerifiedInvoiceRequest` based on its strategy type. This enables
compile-time guarantees — ensuring that an incorrect `InvoiceBuilder`
cannot be constructed for a given request, and misuses are caught early.

Run `async_signer_tests::test_async_holder_signatures` with P2A anchors

Include HTLC signatures in initial commitment signed for splices

While we did consider the pending HTLCs when generating the signatures,
we did not include them in the resulting `commitment_signed` message
sent because we assumed it was only used within a dual-funding context
where there are no pending HTLCs.

Persist witnesses in InteractiveTxSigningSession

InteractiveTxSigningSession currently persists holder witnesses
directly, but persists counterparty witnesses as part of its unsigned
ConstructedTransaction. This makes the ConstructedTransaction actually
partially signed even though it is held in a field named unsigned_tx.
Instead, persists the counterparty witnesses alongside the holder
witnesses directly in InteractiveTxSigningSession, leaving the
transaction it holds unsigned.