rust-lightning

Correctly order channel_ready on channel_reestablish

When handling channel_reestablish, the order in which channel_ready is
sent depends on whether or not the initial commitment_signed /
tx_signatures are being retransmitted. When they are, then channel_ready
should come after them. Otherwise, channel_ready should come before any
commitment_signed.

Make BlindedMessagePath creation infallible

The LDK codebase in general is comfortable panicking if the entropy source
provided to it is dysfunctional. Up until now we made an exception for blinded
path creation, where we would handle an error that could occur on mul_tweak
that could only occur if the session_priv provided was not actually random.
In comparable cases in onion_utils, we would panic instead.

In upcoming commits, we will be including blinded paths in outbound
revoke_and_ack messages as part of implementing async payments, where it is
difficult to handle failing back an HTLC if blinded path creation fails. Thus
we now have an incentive to make the blinded path creation methods infallible,
so do so here.

Randomize order of inputs from `OutputSweeper`

For a marginal increase in privacy, we can randomize the inputs from the
`OutputSweeper`. Since we don't depend on `rand` to randomize the order
I just put the elements into a hashset, then back into a Vec. This
should give us enough randomness without having to introduce a new dep
or make the `OutputSweeper` depend on the `EntropySource`.

Retransmit commitment_signed before tx_signatures

During channel reestablishment, both commitment_signed and tx_signatures
messages may be retransmitted. However, commitment_signed must come
first, so re-arrange the ordering. This moves tx_abort as well to keep
the interactive tx messages together.

Split out remaining uses of `is_pre_funded_state` and rename it

`Channel::is_pre_funded_state` is used to mean several different
things. In the past few commits we stopped using it for a few
conflicting uses, but here we break out the remaining uses and
rename the remnants for clarity.

`is_funding_broadcast` was using `is_pre_funded_state` and was then
later used to decide if the `Channel` could be written to disk
(because it can be resumed on restart), if we should broadcast a
force-close transaction, and when to emit a `ChannelPending` event.

These were also somewhat divergent - we shouldn't generate a
`ChannelReady` event or broadcast a force-closing transaction until
we've actually broadcasted but want to write the `Channel` to disk
once we enter funding signature exchange for dual-funded open.

Thus, the ability to write a `Channel` to disk is provided by a new
`can_resume_on_restart` method. Then, `is_funding_broadcast` is
updated to only consider funding broadcasted after we provide our
funding signatures (i.e. the funding *could* have been
broadcasted). This is still a bit early to generate a
`ChannelPending` event (as the funding may not actually have been
broadcasted yet), but its better than it was.

Finally, the remaining `is_pre_funded_state` is renamed
`can_resume_on_reconnect`, which has slightly different semantics
than on-restart channels in batch opens.

Don't use `is_pre_funded_state` to provide an FC monitor update

`Channel::is_pre_funded_state` is used to mean several different
things. In this case its used to decide if we should provide a
`ChannelMonitorUpdate` marking a channel as closed when we go to
force-close it.

Here, we want to capture exactly when the original `ChannelMonitor`
is first created, but were doing so indirectly by looking at the
channel's state. Worse, `is_pre_funded_state` got updated to be
false whenever there is an interctive signing session, which isn't
correct for this use - we may have an interactive signing session
but have already persisted the original `ChannelMonitor` when we
received the first `commitment_signed`.

Instead, we just move to examining
`counterparty_next_commitment_transaction_number` which is
decrementing for the first time at exactly the time we create the
original `ChannelMonitor`, so it provides a much simpler test.

Fixes #3880

Dont use `is_pre_funded_state` to short-circuit `shutdown` handling

`Channel::is_pre_funded_state` is used to mean several different
things. In this case, its used to skip all the `shutdown` logic as
the funding transaction can't possibly have been broadcasted so
there's really no ned to try to sign a transaction spending it.

Here, we really want to capture any channel in `NegotiatingFunding`
or any V1 channel in `FundingNegotiated` or, finally, any V2
channel in `FundingNegotiated` where we haven't yet sent our
signatures (which is not captured in `is_pre_funded_state`).

Instead of a new helper, we just check the states directly in
`shutdown` handling.

Sign splice shared input when producing holder tx_signatures

We also remove the `Result` to make it clear that this method does not
support async operations yet and rename the method to clarify that it is
only intended to be used for the shared input of a splice.

Support splice shared input signing

This commit tracks all data related to the shared input of a splice,
such that a valid witness can be formed upon the splice transaction
finalization.

Rename get_inbound_payment_key to get_expanded_key

The use of ExpandedKey has grown beyond just encrypting inbound
payment data-it now also supports BOLT 12 Offers, spontaneous
payments, and authentication of various payment metadata.

To reflect this broader purpose, this commit renames the function
and updates its documentation accordingly.

Assume splicing input value from channel parameters

Remove reachable FundingTransactionReadyForSigning assertion

This is reachable if the event doesn't get handled and a channel
reestablish occurs.

Include witness weights in FundingNegotiationContext

ChannelManager::splice_channel takes witness weights with the funding
inputs. Storing these in FundingNegotiationContext allows us to use them
when calculating the change output and include them in a common struct
used for initiating a splice-in.

In preparation for having ChannelManager::splice_channel take
FundingTxContributions, add a weight to the
FundingTxContributions::InputsOnly, which supports the splice-in use
case.

Check splice contributions against SignedAmount::MAX_MONEY

Splice contributions should never exceed the total bitcoin supply. This
check prevents a potential overflow when converting the contribution
from sats to msats. The commit additionally begins to store the
contribution using SignedAmount.

Drop outdated async signing comment

Allow funding errors in `full_stack_target` fuzzer

When a channel gets replaced before we can fund it, its possible
now (due to RNG output repetition) to hit the "trying to fund
channel before its ready to be funded" error in the
`full_stack_target` fuzzer.

Thus, we now simply ignore errors when funding.

offer: fix path validation to only require non-empty paths when issuer_id is missing

When an offer has an issuer_id, empty paths should be allowed since the
issuer_id can be used for signing. Only when issuer_id is None should
we require non-empty paths to extract the blinded node ID for signing.

Detect commitment transaction confirmation in ChannelMonitor instead

Previously, the `ChannelManager` would assume a `Channel` was closed the
moment it saw a spend for its funding input. With splicing, this will no
longer be the case. Since the `ChannelMonitor` is already responsible
for reliably tracking each onchain transaction relevant to a channel, we
now produce a `MonitorEvent::CommitmentTxConfirmed` event to inform the
`ChannelManager` the channel can be considered closed and removed.

As a result of this change, many tests failed now that we rely on
handling the `MonitorEvent::CommitmentTxConfirmed` first before seeing
the `ChannelMonitorUpdateStep::ChannelForceClosed` go out.

Stop counting for RNG output in `full_stack_target`

The `full_stack` fuzzer ensures that RNG output is unique by
keeping a counter of the number of `get_secure_random_bytes` calls
and using it to determine the "random" value to return.

However, because LDK regularly changes when it requests RNG output
this causes the fuzz input required to reach a codepath to change
regularly, making any existing fuzz corpus stale.

Instead, here, we allow the fuzz input to set a new RNG output
value, but otherwise always return the same output. This allows the
fuzzer to still reach RNG-output-specifc paths, but fuzzing seeds
aren't invalidated when LDK changes.

Stop reading fee estimates directly in `full_stack_target`

The `full_stack` fuzzer tries to just expose much of the entire
library to the fuzzer, and as such when a request comes in from
LDK to estimate the current fee it tries to read two bytes of
fuzzing input and returns that as the fee to LDK.

However, because LDK regularly changes when it requests a fee
estimate from the user this causes the fuzz input required to reach
a codepath to change regularly, making any existing fuzz corpus
stale.

Instead, here, we allow the fuzz input to load a fee estimate
result into a buffer, and if its empty simply return 253. This
allows the fuzzer to still reach fee-estimate-triggered overflows,
but only invalidates fuzzing seeds that relied on fee estimate
inputs rather than all seeds whenever LDK changes fee estimate
calls.

Use `FundingScope` spent when signing watchtower justice transactions

Since there may be multiple counterparty commitment transactions for the
same commitment number due to splicing, we have to locate the matching
`FundingScope::channel_parameters` to provide the signer. Since this is
intended to be called during `Persist::update_persisted_channel`, the
monitor should have already had the update applied.

Verify the holder provided valid witnesses and uses SIGHASH_ALL

LDK checks the following:
* Each input spends an output that is one of P2WPKH, P2WSH, or P2TR.
These were already checked by LDK when the inputs to be contributed
were provided.
* All signatures use the `SIGHASH_ALL` sighash type.
* P2WPKH and P2TR key path spends are valid (verifies signatures)

NOTE:
* When checking P2WSH spends, LDK tries to decode 70-72 byte witness
elements as ECDSA signatures with a sighash flag. If the internal
DER-decoding fails, then LDK just assumes it wasn't a signature and
carries with checks. If the element can be decoded as an ECDSA
signature, the the sighash flag must be `SIGHASH_ALL`.
* When checking P2TR script-path spends, LDK assumes all elements of
exactly 65 bytes with the last byte matching any valid sighash flag
byte are schnorr signatures and checks that the sighash type is
`SIGHASH_ALL`. If the last byte is not any valid sighash flag, the
element is assumed not to be a signature and is ignored. Elements of
64 bytes are not checked because if they were schnorr signatures then
they would implicitly be `SIGHASH_DEFAULT` which is an alias of
`SIGHASH_ALL`.

Introduce `FundingTransactionReadyForSignatures` event

The `FundingTransactionReadyForSignatures` event requests witnesses
from the client for their contributed inputs to an interactively
constructed transaction.

The client calls `ChannelManager::funding_transaction_signed` to provide
the witnesses to LDK.

The `handle_channel_resumption` method handles resumption from both
a channel re-establish and a monitor update. When the corresponding
monitor update for the commitment_signed message completes, we will
push the event here.

We can thus only ever provide holder signatures after a monitor update
has completed.

We can also get rid of the reestablish code involved with
`monitor_pending_tx_signatures` and remove that field too.

Add `prev_ouput` to `NegotiatedTxInput` for SIGHASH_ALL & key-spend checks

In a following commit, We'll use the contained scriptPubKeys to validate
P2WPKH and P2TR key path spends and to assist in checking that signatures
in provided holder witnesses use SIGHASH_ALL to prevent funds being frozen
or held ransom.

Block RAA `ChannelMonitorUpdate`s on `PaymentClaimed` events

We added the ability to block `ChannelMonitorUpdate`s on receipt of
an RAA in order to avoid dropping a payment preimage from a channel
that created a `PaymentSent` event in
9ede794e8e8559f1b2b386c1c57372094fc92fd4. We did not at the time
use the same infrastructure for `PaymentClaimed` events, but really
should have. While a `PaymentClaimed` event may seem a bit less
critical than a `PaymentSent` event (it doesn't contain a payment
preimage that the user needs to make sure they store for proof of
payment), its still important for users to ensure their payment
tracking logic is always correct.

Here we take the (relatively straightforward) action of setting a
`EventCompletionAction` to block RAA monitor updates on channels
which created a `PaymentClaimed` event. Note that we only block one
random channel from an MPP paymnet, not all of them, as any single
channel should provide enough information for us to recreate the
`PaymentClaimed` event on restart.