rust-lightning

Retransmit announcement_signatures if requested

The previous commit allowed requesting retransmission of
announcement_signatures during channel reestablishment. This commit
handles such requests.

Request announcement_signatures retransmission

During channel reestablishment, announcement_signatures may need to be
retransmitted. The splicing spec allows doing so without retransmitting
splice_locked first, which could normally trigger retransmitting
announcement_signatures. Instead, my_current_funding_locked lets the
sender request retransmitting it.

Update next_funding_txid logic for channel_reestablish

The splicing spec updates the logic pertaining to next_funding_txid when
handling a channel_reestablish message. Specifically:

A receiving node:
- if `next_funding_txid` is set:
- if `next_funding_txid` matches the latest interactive funding transaction
or the current channel funding transaction:
- if `next_commitment_number` is equal to the commitment number of the
`commitment_signed` message it sent for this funding transaction:
- MUST retransmit its `commitment_signed` for that funding transaction.
- if it has already received `commitment_signed` and it should sign first,
as specified in the [`tx_signatures` requirements](#the-tx_signatures-message):
- MUST send its `tx_signatures` for that funding transaction.
- if it has already received `tx_signatures` for that funding transaction:
- MUST send its `tx_signatures` for that funding transaction.
- if it also sets `next_funding_txid` in its own `channel_reestablish`, but the
values don't match:
- MUST send an `error` and fail the channel.
- otherwise:
- MUST send `tx_abort` to let the sending node know that they can forget
this funding transaction.

Note that the spec is in flux. Instead, next_funding_txid is replaced
with next_funding, which contains both a txid and retransmit_flags. The
latter is used instead of next_commitment_number to determine whether
commitment_signed should be retransmitted.

This commit updates FundedChannel::channel_reestablish accordingly.

Co-authored-by: Wilmer Paulino <wilmer@wilmerpaulino.com>
Co-authored-by: Jeffrey Czyz <jkczyz@gmail.com>

Clear announcement_sigs on FundingScope promotion

When a splice transaction is promoted (i.e., when splice_locked has been
exchanged), announcement_signatures must be sent. However, if we try to
send a channel_announcement before they are received, then the
signatures will be incorrect. To avoid this, clear the counterparty's
announcement_signatures upon promoting a FundingScope.

Remove unnecessary next_funding check

During channel_reestablish handling, next_local_commitment_number can
never be zero. Remove the unnecessary check conditioning on next_funding
not being set. Additionally, remove the spec requirement in the comment
that follows since it does not exist.

Handle implicit splice_locked during channel_reestablish

When handling a counterparties channel_reestablish, the spec dictates
that a splice_locked may be implied by my_current_funding_locked.
Compare that against any pending splices and handle an implicit
splice_locked message when applicable.

Don't retransmit tx_signatures pending monitor update

The ChannelMonitor must be successfully persisted before transmitting
any messages.

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.

DRY HTLCPreviousHopData creation

In upcoming commits, we will be adding several more conversions from
PendingAddHTLCInfo into HTLCPreviousHopData. This conversion gets repeated all
over the ChannelManager already, so lay some groundwork by DRYing it up.

DRY PendingAddHTLCInfo creation in forward_htlcs

Without this DRYing, we would be repeating the same code to instantiate the
PendingAddHTLCInfo several more times in this method, in upcoming commits.

Add a method to avoid re-persisting monitors during startup

Prior to LDK 0.1, in rare cases we could replay payment claims to
`ChannelMonitor`s on startup, which we then expected to be
persisted prior to normal node operation. This required
re-persisting `ChannelMonitor`s after deserializing the
`ChannelManager`, delaying startup in some cases substantially.

In 0.1 we fixed this, moving claim replays to the background to run
after the `ChannelManager` starts operating (and only
updating/persisting changes to the `ChannelMonitor`s which need
it). However, we didn't actually enable this meaningfully in our
API - nearly all users use our `ChainMonitor` and the only way to
get a chanel into `ChainMonitor` is through the normal flow which
expects to persist.

Here we add a simple method to load `ChannelMonitor`s into the
`ChainMonitor` without persisting them.

Check v2 reserves after `funding_contribution_satoshis` is applied

We check this when validating `splice_init`, `splice_ack` messages, and
also when validating user-specified contributions.

From BOLT 2:
```
- If `funding_contribution_satoshis` is negative and its absolute value
is greater than the sending node's current channel balance:
- MUST send a `warning` and close the connection or send an `error`
and fail the channel.
```

and further down:
```
If a side does not meet the reserve requirements, that's OK: but if they
take funds out of the channel, they must ensure that they do meet them.
If your peer adds a massive amount to the channel, then you only have
to add more reserve if you want to contribute to the splice (and you
can use `tx_remove_output` and/or `tx_remove_input` part-way through if
this happens).
```

Therefore, we check the v2 reserve anytime
`funding_contribution_satoshis` is not equal to zero.

We allow parties to draw from their previous reserve, as long as they
satisfy their v2 reserve.

Add `NextCommitmentStats::get_balances_including_fee`

`NextCommitmentStats` provides the commitment transaction fee as a
separate value to assist with applying a multiplier on it in
`can_accept_incoming_htlc`.

Nonetheless in most cases, we want the balances to include the
commitment transaction fee, so here we add a helper that gives us these
balances.

Also make the style of `tx_builder::subtract_addl_outputs` consistent
with `get_balances_including_fee`.

Make `for_splice` infallible

Add `validate_splice_ack` helper function

As in `splice_init`, this helps clearly delineate `splice_ack` message
validation from the subsequent state mutations.

This is a code-move.

Correct the reserve minimums in `FundingScope::for_splice`

The reserve we should maintain on our own transaction should be greater
than our own dust limit.

Finish validation in `splice_ack` before taking a `&mut self`

As much as possible, we want to only mutate state once we are done with
input validation.

This also removes complaints when helper functions during validation
take a `&self`.

Enforce that the splice initiator set a non-zero funding contribution

Describe `ConfirmationTarget::MaximumFeeEstimate` more accurately

This isn't really just the maximum estimate that we want from our
fee estimator but rather the maximum estimate that we think is
reasonable to receive from our counterparty. Thus, we should really
describe it as such and suggest users add a fudge on top to
accomodate disagreements.

Add further additional documentation to `Listen`

`Listen` is somewhat quiet on high-level use and even requirements,
which we document further here.

Don't pass a latest-block-time to `Channel` unless we have one

When calling `Channel::best_block_updated` we pass it the timestamp
of the block we're connecting so that it can track the highest
timestamp it has seen.

However, in some cases, we don't actually have a timestamp to pass,
which `Channel::best_block_updated` will happily ignore as it
always takes the `max` of its existing value. Thus, we really
should pass a `None` to ensure the API is understandable, which we
do here.

Add more robust functional test of `Listen::blocks_disconnected`

Now that the `Listen` interface allows blocks to be disconnected in
batches rather than one at a time, we should test this. Here we add
a new `ConnectStyle` for the functional test framework which tests
doing so.

Drop the need for fork headers when calling `Listen`'s disconnect

The `Listen::block_disconnected` method is nice in that listeners
learn about each block disconnected in series. Further, it included
the header of the block that is being disconnected to allow the
listeners to do some checking that the interface is being used
correctly (namely, asserting that the header's block hash matches
their current understanding of the best chain).

However, this interface has some substantial drawbacks. Namely, the
requirement that fork headers be passed in means that restarting
with a new node that has no idea about a previous fork leaves us
unable to replay the chain at all. Further, while when various
listeners were initially written learning about each block
disconnected in series seemed useful, but now we no longer rely on
that anyway because the `Confirm` interface does not allow for it.

Thus, here, we replace `Listen::block_disconnected` with a new
`Listen::blocks_disconnected`, taking only information about the
fork point/new best chain tip (in the form of its block hash and
height) rather than information about previous fork blocks and only
requiring a single call to complete multiple block disconnections
during a reorg.

We also swap to using a single `BestBlock` to describe the new
chain tip, in anticipation of future extensions to `BestBlock`.

This requires removing some assertions on block disconnection
ordering, but because we now provide `lightning-block-sync` and
expect users to use it when using the `Listen` interface, these
assertions are much less critical.

Use similar `blocks_disconnected` semantics in `OnchainTxHandler`

`OnchainTxHandler` is an internal struct and doesn't implement
`Listen`, but its still nice to have its API mirror the `Listen`
API so that internal code all looks similar.