rust-lightning

Remove input value fields from ConstructedTransaction

The local and remote input values are used to determine which node sends
tx_signatures first. Instead of persisting these values, compute them
only when needed from the input metadata. The spec states that the
entire shared input value is to be included for the node sending the
corresponding tx_add_input, so it isn't necessary to know the local and
remote balances which the metadata does not contain.

Limit outbound gossip buffer by size, rather than length

In 686a586c96aae6901d533646fc135379f825eb0d we stopped punishing
peers for slowly draining the gossip forwarding buffer, delaying
responding to our ping message. While that change was nice on its
own, it also now allows us to be a bit more flexible with what
enters the `gossip_broadcast_buffer`.

Because we now do not count pending messages in
`gossip_broadcast_buffer` against the peer's ping-response timer,
there's no reason to continue to limit it based on
`messages_sent_since_pong`. Thus, we drop that restriction here.

However, in practice, the reason for the vast majority of gossip
forwarding drops on my node is the 24-message total queue limit,
rather than the `messages_sent_since_pong` limit. This limit was
set to bend over backwards trying to avoid counting message buffer
sizes while keeping peer message buffers small.

In practice, there is really no reason to do that - summing the
capacity of tens of buffers is negligible cost and allows us to be
much more flexible with how many messages we queue.

Here we do so, limiting the total outbound message buffer size
before gossip forwards are dropped to 128 KiB per peer, rather than
24 messages. In practice, this appears to almost entirely remove
gossip forward drops on my node.

Check dust exposure on receiving `commitment_signed`, not `update_fee`

We allow a peer to send an `update_fee` message that pushes the dust
exposure over our max as long as they send HTLC updates that bring the
dust exposure back down under the limit before they send
`commitment_signed`.

Add a test for the new async `ChainMonitor` operation

We already have pretty good coverage of the
`MonitorUpdatingPersister` itself as well as `ChainMonitor`'s
update-completion handling, so here we just focus on an end-to-end
test to make sure `ChainMonitor` behaves at all correctly in the
new async mode.

Correct gossip forwarding criteria while doing background sync

If we're doing gossip backfill to a peer, we first forward all our
`channel_announcement`s and `channel_update`s in SCID-order. While
doing so, we don't forward any fresh `channel_update` messages for
any channels which we haven't yet backfilled (as we'll eventually
send the new update anyway, and it might get rejected without the
corresponding `channel_announcement`).

Sadly, our comparison for this was the wrong way, so we actually
*only* forwarded updates which were for channels we haven't yet
backfilled, and dropped updates for channels we already had
backfilled.

Update commitment_signed retransmission for next_funding

The next_funding TLV is included in channel_reestablish when either
tx_signatures or commitment_signed is needed for an interactive-tx
session. This commit largely includes the spec requirements in the
comments, including when to retransmit commitment_signed. But it also
adds an additional check that tx_signatures has not yet been received.

Simplify test_trampoline_unblinded_receive

No need to construct unused blinded hop data or hardcode session privs/prng
seeds.

Stop enqueueing error messages for disconnected peers

If a channel is failed while a peer is disconnected, we'll still
have a `PeerState` for that peer. Historically, we haven't bothered
to check if a peer is actually connected before we push the `error`
message onto the `PeerState::pending_msg_events` queue, leaving us
sending messages into the void.

This is generally not an issue as
`ChannelManager::get_and_clear_pending_msg_events` should be called
very regularly, removing these messages and then dropping them as
`PeerManager` won't have anything to do with them. Further, when
the the message is an `error`, if a peer happens to connect between
when we push the message and when `get_and_clear_pending_msg_events`
is called the worst that happens is they get the `error` message
we'd end up sending them when they try to reestablish the channel
anyway.

Still, its awkward to leave the `error`s lying around in a message
queue for a disconnected peer, so we remove them here.

Stop enqueueing messages for disconnected peers

If a channel operation occurs while a peer is disconnected, we'll
still have a `PeerState` for that peer. Historically, we haven't
bothered to check if a peer is actually connected before we push
new messages onto the `PeerState::pending_msg_events` field,
leaving us sending messages into the void.

This is generally not an issue as
`ChannelManager::get_and_clear_pending_msg_events` should be called
very regularly, removing these messages and then dropping them as
`PeerManager` won't have anything to do with them.

Still, there is a race condition here - if a peer manages to
connect between the generation of one such message and when
`get_and_clear_pending_msg_events` is called, we may enqueue a
message to the peer which makes no sense and could lead to a
spurious channel closure (especially in the case of an async
`ChannelMonitorUpdate` completion or async signing operation, which
often lead to normal channel message generation).

Further, if a peer is slow to send their `channel_reestablish`
message after connection this race could be substantially more
likely, as such normal channel messages may be nonsense until we've
completed the reestablish dance (i.e. the later reestablish dance
may lead us to re-send the same messages again immediately).

Here we remove most of the cases where we enqueue messages for
disconnected peers.

Note that we differentiate between two different checks for
connected-ness - for cases where we're sending an `error` or gossip
messages, we allow the messages to be enqueued if the peer is
connected at all. For most other cases, we only allow messages to
be enqueued if the peer is connected *and* the channel has
completed its reestablish dance (if required, i.e. the channel is
"connected").

Add struct-level logging to OutboundPayments

Previously, OutboundPayments methods required borrowed logger
arguments since Logger lacked a Clone bound. This prevented
logging in all desired places, limiting trace statements for
debugging. This change initializes OutboundPayments with a
cloned Logger, simplifying method signatures and improving
logging flexibility.

Drop `RevokedOutput::is_counterparty_balance_on_anchors`

When we added anchors support we declined to aggregate claims
across different types of outputs for anchor channels, requiring
that we track whether a `RevokedOutput` claim came from an anchor
channel or not. This was only ever used to decide whether the claim
was aggregable or not.

In 0fe90c6f7c3325935b18dbc809be14afd8fe067f we started aggregating
by determining whether a claim is pinnable or not, rather than the
much-too-coarse aggregable flag, leaving
`is_counterparty_balance_on_anchors` unused.

Here we remove it entirely (as it would become ambiguous with
zero-commitment-fee anchor channels).

We always write `Some(())`, marking the claim as an anchor claim
and resulting in LDK prior to 0.1 refusing to aggregate the claim
(which is the more conservative stance). This breaks downgrade to
LDK 0.0.115 and earlier.

Generate new `ReleasePaymentComplete` monitor updates

`MonitorEvent`s aren't delivered to the `ChannelManager` in a
durable fasion - if the `ChannelManager` fetches the pending
`MonitorEvent`s, then the `ChannelMonitor` gets persisted (i.e. due
to a block update) then the node crashes, prior to persisting the
`ChannelManager` again, the `MonitorEvent` and its effects on the
`ChannelManger` will be lost. This isn't likely in a sync persist
environment, but in an async one this could be an issue.

Note that this is only an issue for closed channels -
`MonitorEvent`s only inform the `ChannelManager` that a channel is
closed (which the `ChannelManager` will learn on startup or when it
next tries to advance the channel state), that
`ChannelMonitorUpdate` writes completed (which the `ChannelManager`
will detect on startup), or that HTLCs resolved on-chain post
closure. Of the three, only the last is problematic to lose prior
to a reload.

In previous commits we ensured that HTLC resolutions which came to
`ChannelManager` via a `MonitorEvent` were replayed on startup if
the `MonitorEvent` was lost. However, in cases where the
`ChannelManager` was so stale that it didn't have the payment state
for an HTLC at all, we only re-add it in cases where
`ChannelMonitor::get_pending_or_resolved_outbound_htlcs` includes
it.

Because constantly re-adding a payment state and then failing it
would generate lots of noise for users on startup (not to mention
risk of confusing stale payment events for the latest state of a
payment when the `PaymentId` has been reused to retry a payment).
Thus, `get_pending_or_resolved_outbound_htlcs` does not include
state for HTLCs which were resolved on chain with a preimage or
HTLCs which were resolved on chain with a timeout after
`ANTI_REORG_DELAY` confirmations.

This critera matches the critera for generating a `MonitorEvent`,
and works great under the assumption that `MonitorEvent`s are
reliably delivered. However, if they are not, and our
`ChannelManager` is lost or substantially old (or, in a future
where we do not persist `ChannelManager` at all), we will not end
up seeing payment resolution events for an HTLC.

Instead, we really want to tell our `ChannelMonitor`s when the
resolution of an HTLC is complete. Note that we don't particularly
care about non-payment HTLCs, as there is no re-hydration of state
to do there - `ChannelManager` load ignores forwarded HTLCs coming
back from `get_pending_or_resolved_outbound_htlcs` as there's
nothing to do - we always attempt to replay the success/failure and
figure out if it mattered based on whether there was still an HTLC
to claim/fail.

Here we begin generating the new
`ChannelMonitorUpdateStep::ReleasePaymentComplete` updates,
updating functional tests for the new `ChannelMonitorUpdate`s where
required.

Remove tx_signatures flags for interactive signing ChannelState

This commit addresses an overlap of state between
`InteractiveTxSigningSession` and `ChannelState::FundingNegotiated`. The
signing session already tracks whether both holder and counterparty
`tx_signatures` have been produced, so tracking the state duplicatively
at the `ChannelState` level is unnecessary.

Move interactive signing session into ChannelContext

Since the `InteractiveTxSigningSession` already tracks everything we
need, we can remove the duplicate interactive signing state tracking
within `ChannelState`.

test(invoice): add new BOLT11 test vector to test public-key recovery high-S signature

refactor(invoice): align signature checks with BOLT11 semantics

Simplify `check_signature` logic to follow the BOLT11 rules discussed:

- If an `n` field is present, verify the signature against the included
pubkey using `secp256k1_ecdsa_verify`, which enforces normalized
low-S form.

- If no `n` field is present, rely on `secp256k1_ecdsa_recover` to
extract the pubkey. Recovery accepts both high-S and low-S signatures,
matching existing implementations (lnd, c-lightning).

This avoids redundant recovery+verify checks while preserving
interoperability.

Persist FundedChannel::pending_splice

Once a splice funding transaction has been constructed, the
corresponding state must be persisted so that the process can be
continued across restarts. This includes exchanging signatures, waiting
for enough confirmations, and RBF'ing.

Update OnchainTxHandler channel parameters on renegotiated funding locked

The `ChannelMonitor` now tracks its own set of channel parameters, but
in the event they change after a splice, we want to ensure they are
updated accordingly at the `OnchainTxHandler` level as well in case the
user downgrades after a locked splice has already occurred.

Set version 3 on transactions for HTLC signatures in 0FC channels

Co-authored-by: Matt Corallo <git@bluematt.me>

Use `SINGLE|ACP` sighash on signatures from peer in 0FC channels

Co-authored-by: Matt Corallo <git@bluematt.me>

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.

Don't retransmit tx_signatures pending monitor update

The ChannelMonitor must be successfully persisted before transmitting
any messages.