impl ser for the now-changed htlc failure packet

Avoid accessing `legacy` TLV fields after the TLV-stream read

`legacy` fields in TLV stream reads may be used to read fields
which are later moved into some other field using either
`default_value` or `static_value` "reads". This works fine if the
field supports copy semantics, however if it does not, the
accessing of the field in `_decode_and_build` after the TLV stream
read completes but before the struct is built results in a "use
after move" error.

Instead, here, we drop the attempt to hide unused variable warnings
entirely, dropping the post-TLV-stream access to legacy variables,
allowing their use in move semantics for later fields.

Make attribution_data optional

we need this for deserializing various old objects, eg if we decided
to fail an htlc on a previous version, stored that that htlc is
pending-failure and then shut down and upgraded.

simplify test method

mutation test for attr errs

integrated code test pass

rewrite to separate field wip

attr data len const

extend fail htlc msg

test all mutations

decrypt and verify failure

wip4

wiwp3

wip2

wip

Merge pull request #3616 from TheBlueMatt/2025-02-scoring-overflow

Fix overflow in historical scoring model point count summation

Merge pull request #3614 from TheBlueMatt/2025-02-rustfmt-wire-types

Fix overflow in historical scoring model point count summation

In adb0afc523f9fea44cd42e02a1022510a9c83a52 we started raising
bucket weights to the power four in the historical model. This
improved our model's accuracy greatly, but resulted in a much
larger `total_valid_points_tracked`. In the same commit we
converted `total_valid_points_tracked` to a float, but retained the
64-bit integer math to build it out of integer bucket values.

Sadly, 64 bits are not enough to sum 1024 bucket pairs of 16-bit
integers multiplied together and then squared (we need 16*4 + 10 =
74 bits to avoid overflow). Thus, here we replace the summation
with 128-bit integers.

Use a rustdoc link for URL in public `features` documentation

...addressing a warning that rustc always prints when generating
docs.

Remove `lightning/src/ln/types.rs` from rustfmt exclusions

Run rustfmt on `lightning/src/ln/types.rs`

Clean up `types.rs` hex deser to use more intermediate variables

...preventing rustfmt from making a mockery of our code.

Remove `lightning/src/ln/wire.rs` from rustfmt exclusions

Run rustfmt on `lightning/src/ln/wire.rs`

Reduce overuse of `where` clauses in `wire.rs`

rustfmt blows up `where` clauses even for trivial lines, so we
should generally avoid them where possible. Here we remove some
extra ones from `wire.rs`.

Merge pull request #3487 from wvanlint/anchor_channel_reserves

Define anchor channel reserve requirements

Merge pull request #3572 from tankyleo/25-01-htlc-dust-exposure

Tweak htlc dust exposure due to excess fees

Merge pull request #3588 from wpaulino/quiescence

Implement quiescence protocol

Test the accounting of dust exposure due to excess fees

This test checks to a 1msat precision the accounting of dust exposure
due to excess fees on counterparty commmitment and htlc transactions,
for both inbound and outbound htlcs.

Assert dust exposure exhaustion in the excess fees are dust test

The payments in this test previously failed for reasons other
than exhausting the dust exposure limit with excess fees. Upon payment
failures, we now check the logs to assert failures due to dust
exposure exhaustion.

For the candidate outbound htlc, sum weights, then sum fees

Previously, we calculated the fee of the commitment transaction with n
htlcs, and the fee due to the candidate htlc, rounded the two fees to
the lower satoshi, and then summed the fees. This is not equal to how
fees of commitment transactions are calculated, which is to add up the
total weight of the (n+1) htlc commitment transaction, convert to fee,
then round to the lower satoshi.

This commit corrects this delta by running the full fee calculation
twice, once for the n htlc, and once for the (n+1) htlc counterparty
commitment transactions.

Remove extra sum of tx fee dust on the counterparty tx dust exposure

Previously, `get_pending_htlc_stats` did not account for the inbound
htlc because `can_accept_incoming_htlc` was called before the htlc was
irrevocably committed. But after commit d8d9dc7,
`can_accept_incoming_htlc` is called only when the htlc is irrevocably
committed, hence `get_pending_htlc_stats` does account for the inbound
htlc.

Nonetheless, in the case of a non-dust htlc, our calculation of the
counterparty tx dust exposure still assumed that
`get_pending_htlc_stats` did not account for the inbound htlc, causing
us to add the dust exposure due to that inbound htlc twice. This commit
removes this extra sum.

Add fuzzing coverage for quiescence

Enforce disconnect timeout during quiescence

Since new updates are not allowed during quiescence (local updates enter
the holding cell), we want to ensure quiescence eventually terminates if
the handshake takes too long or our counterparty is uncooperative.
Disconnecting implicitly terminates quiescence, so the holding cell can
be freed upon re-establishing the channel (assuming quiescence is not
requested again).

Track message timeout ticks based on internal states

With the introduction of `has_pending_channel_update`, we can now
determine whether any messages are owed to irrevocably commit HTLC
updates based on the current channel state. We prefer using the channel
state, over manually tracking as previously done, to have a single
source of truth. We also gain the ability to expect to receive multiple
messages at once, which will become relevant with the quiescence
protocol, where we may be waiting on a counterparty `revoke_and_ack` and
`stfu`.

Consider quiescence state when freeing holding cells upon revoke_and_ack

We previously would avoid freeing our holding cells upon a
`revoke_and_ack` if a monitor update was in progress, which we checked
explicitly. With quiescence, if we've already sent `stfu`, we're not
allowed to make further commitment updates, so we must also avoid
freeing our holding cells in such cases.

Along the way, we also remove the special handling of in-progress
monitor updates now that it behaves the same as the handling of being
quiescent.

Implement quiescence protocol

Quiescence is a new protocol feature that allows for channels to undergo
"fundamental" changes (i.e., protocol upgrade) while there are no
pending updates on either side. Its first use case will be to carry out
channel splices, to ensure new HTLC/fee updates are not made while a
splice is being negotiated.

Each side of the channel is allowed to send a `stfu` message if any of
their outbound updates are not pending for either side (i.e.,
irrevocably committed on both commitment transactions). Once both sides
exchange `stfu`, the channel becomes quiescent. A message timeout is
enforced during the quiescence handshake to ensure we can eventually
re-establish the channel and propose new HTLC/fee updates again.

Several new state flags have been added to `ChannelState::ChannelReady`
to track the progress of the quiescence handshake. Once the channel
becomes quiescent, all flags related to the handshake are cleared, and
the `QUIESCENT` flag is enabled. While quiescence is not a persistent
protocol (it implicitly terminates upon peer disconnection), and updates
cannot be made, we still need to track `MONITOR_UPDATE_IN_PROGRESS` as
it may be required by the quiescence-dependent protocol, like in the
case of splicing.

Add ChannelError::WarnAndDisconnect variant

The existing `ChannelError::Warn` variant only sends the warning and
does not disconnect. There are certain cases where we want to just send
a warning, and other cases where we want to also disconnect, so we
keep both variants around.

Change Stfu::initiator to bool type

Merge pull request #3592 from jkczyz/2025-02-channel-funding-scope

Refactor `ChannelContext` value fields into `FundingScope`

Move next_*_commitment_tx_fee_info_cached to FundingScope

Move *_max_commitment_tx_output to FundingScope

Move *_selected_channel_reserve_satoshis to FundedScope

Move value_to_self_msat to FundingScope

Move channel_value_satoshis to FundingScope

Merge pull request #3607 from arik-so/arik/trampoline/inbound-prefactors-03

Move shared secret calculation into decode_next_payment_hop

Merge pull request #3596 from joostjager/inbound-channel-config-override

Allow to override config defaults for inbound channels on a per-channel basis

Calculate shared secret within hop decode function

For Trampoline, we'll need to keep track of both the outer and inner
onion's shared secrets. To this end, we're moving the secret
calculation inside `decode_next_payment_hop` such that, when applicable,
it can return both.

Clean up `Hop` match arms

Essentially a follow-up to 38284a0d, deduplicating some additional code.

Allow config defaults override for inbound channels

This commit introduces a config override struct parameter to the
accept_inbound_channel methods. With manual channel acceptance enabled,
users can modify the default configuration as needed.

Allow channel update for accept_underpaying_htlcs

Extends partial channel updates to optionally include the
accept_underpaying_htlcs flag.

Define anchor channel reserve requirements

This change defines anchor reserve requirements by calculating weights
and fees for the transactions that need to be confirmed on-chain in the
event of a unilateral closure. The calculation is given a set of
parameters as input, including the expected fee rate and number of
in-flight HTLCs.

Introduce a channel FundingScope

When establishing a channel, the funding transaction may be replaced
either:
- after the funding transaction has confirmed using splicing,
- before the funding transaction has confirmed for v2 channel
  establishment using tx_init_rbf, or
- before the splice's funding transaction has confirmed using
  tx_init_rbf.

In each of these cases, fields in ChannelContext will need to be updated
once the funding transaction confirms. Additionally, the same fields for
a pending attempt may need to be considered instead of a previously
confirmed funding.

This commit introduces a FundingScope to hold the aforementioned fields.
It lives next to ChannelContext and will be needed whenever these fields
are accessed. The next few commits will move the relevant fields to
FundingScope and provide access to them whenever needed, allowing to
swap in another FundingScope when necessary.

Merge pull request #3605 from vincenzopalazzo/macros/fix-warnings

[RFC] remove the cfg test that it is not needed in a error code path

remove the cfg test that it is not needed

looking at the code, the #[cfg(not(test))] is not needed, so I remove it
because the CI is failing for some reason on the following code path
with rustc 1.63

     Running `rustc --crate-name lightning --edition=2021 lightning/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --emit=dep-info,link -C opt-level=1 -C lto=off -C embed-bitcode=no -C debuginfo=2 -C debug-assertions=on --test --cfg 'feature="default"' --cfg 'feature="grind_signatures"' --cfg 'feature="std"' -C metadata=7f2d308b97eed1fd -C extra-filename=-7f2d308b97eed1fd --out-dir /home/runner/work/rust-lightning/rust-lightning/target/debug/deps -C incremental=/home/runner/work/rust-lightning/rust-lightning/target/debug/incremental -L dependency=/home/runner/work/rust-lightning/rust-lightning/target/debug/deps --extern bech32=/home/runner/work/rust-lightning/rust-lightning/target/debug/deps/libbech32-16d69ba236ca57d8.rlib --extern bitcoin=/home/runner/work/rust-lightning/rust-lightning/target/debug/deps/libbitcoin-eca0fe041fbfc4dc.rlib --extern dnssec_prover=/home/runner/work/rust-lightning/rust-lightning/target/debug/deps/libdnssec_prover-1dd31ceabfa87dd5.rlib --extern hashbrown=/home/runner/work/rust-lightning/rust-lightning/target/debug/deps/libhashbrown-d9958110f8162c77.rlib --extern libm=/home/runner/work/rust-lightning/rust-lightning/target/debug/deps/liblibm-274dde3847e6cc8d.rlib --extern lightning_invoice=/home/runner/work/rust-lightning/rust-lightning/target/debug/deps/liblightning_invoice-56ed15b130ee9288.rlib --extern lightning_macros=/home/runner/work/rust-lightning/rust-lightning/target/debug/deps/liblightning_macros-528cdf9e072c4caf.so --extern lightning_types=/home/runner/work/rust-lightning/rust-lightning/target/debug/deps/liblightning_types-2a1be369ae37a72c.rlib --extern possiblyrandom=/home/runner/work/rust-lightning/rust-lightning/target/debug/deps/libpossiblyrandom-5fb85e240a23737f.rlib --extern regex=/home/runner/work/rust-lightning/rust-lightning/target/debug/deps/libregex-187d4eaedfe307ba.rlib -D warnings -L native=/home/runner/work/rust-lightning/rust-lightning/target/debug/build/bitcoinconsensus-9dfaf2ad2edfe5f6/out -L native=/home/runner/work/rust-lightning/rust-lightning/target/debug/build/bitcoinconsensus-9dfaf2ad2edfe5f6/out -L native=/home/runner/work/rust-lightning/rust-lightning/target/debug/build/secp256k1-sys-44754c91469ec6ec/out`
error: constant `MAX_PEER_STORAGE_SIZE` is never used
    --> lightning/src/ln/channelmanager.rs:2882:1
     |
2882 | const MAX_PEER_STORAGE_SIZE: usize = 1024;
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: `-D dead-code` implied by `-D warnings`

error: could not compile `lightning` due to previous error

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Merge pull request #3575 from adi2011/peer-storage/channel-manager

PeerStorage: Add feature and store peer storage in ChannelManager

Merge pull request #3602 from jkczyz/2025-02-unset-funding-info

Fix debug panic in `full_stack` fuzz test

Merge pull request #3598 from arik-so/arik/trampoline/inbound-prefactors-02

Eliminate invalid Hop/InboundOnionPayload combinations

Add test for peer storage handling

This test ensures that PeerStorage & PeerStorageRetrieval handling behaves as expected. It simulates
receiving a dummy peer storage message, disconnecting and reconnecting peers, and
validates that the correct messages are exchanged during reestablishment.

- Added a test case `test_peer_storage` to verify the handling of `PeerStorageMessage`
  and the validation of warning messages in the event of invalid peer storage retrieval.

- Simulated peer storage retrieval upon reconnection between nodes.

- Validated that a warning message is generated when `PeerStorageRetrievalMessage`
  is received.

- Ensured the warning message contains the expected error description.

Handle PeerStorage Message and its Persistence

This commit introduces the handling and persistence of PeerStorage messages on a per-peer basis.
The peer storage is stored within the PeerState to simplify management, ensuring we do not need to remove it
when there are no active channels with the peer.

Key changes include:

 - Add PeerStorage to PeerState for persistent storage.
 - Implement internal_peer_storage to manage PeerStorage and its updates.
 - Add resend logic in peer_connected() to resend PeerStorage before sending the channel reestablish message upon reconnection.
 - Update PeerState's write() and read() methods to support PeerStorage persistence.

Add Message Handlers for Peer Storage

Introduce message types and handlers to enable the exchange of peer storage data between nodes.
PeerStorageMessage: Used to send encrypted backups to peers.
PeerStorageRetrievalMessage: Used to return a peer's stored data upon reconnection.

- Define two new message types: PeerStorageMessage and PeerStorageRetrievalMessage.
- Implement handlers for these messages in ChannelMessageHandler.
- Add SendPeerStorageMessage and SendPeerStorageRetrievalMessage to MessageSendEvent.

Add 'ProvideStorage' to 'InitContext' and 'NodeContext'

Introduce the 'ProvideStorage' feature to enable nodes to distribute
and store peer storage backups for channel partners. This functionality enhances
resilience by ensuring critical peer data is backed up and can be retrieved if needed.

- Added 'ProvideStorage' to the 'InitContext' & 'NodeContext'.
- Set feature bit for this feature inside 'provide_init_features()'

Add debug assertion in Channel::funding_signed

This is a sanity check that ChannelPhase and ChannelState do not go out
of sync.

Remove invalid state options from Hop

Now that each `InboundOnionPayload` variant corresponds to its own
struct, we can reference these same types inside `Hop` and thereby
avoid nesting that allowed invalid combinations, and instead store
supplemental data as each variant calls for.

Merge pull request #3599 from tnull/2025-02-track-amount-in-payment-sent

Track `amount_msat` field in `Event::PaymentSent`

Track `amount_msat` field in `Event::PaymentSent`

Previously, we would only track the fees paid, but not the actual amount
that was sent.

Create structs for InboundOnionPayload variants

In an upcoming commit, we will eliminate various invalid state
combinations between `Hop` and `InboundOnionPayload` enums. To do so,
rather than nesting one within the other, we will instead have them
both referring to the same structs, with variant-dependent supplemental
data. This requires pulling each variant's data into its own type.

Merge pull request #3595 from arik-so/arik/trampoline/inbound-prefactors

Prefactor for inbound Trampoline parsing/decryption

Merge pull request #3558 from optout21/funding-fee-estimation

Include base input fee in fee, in calculate_our_funding_satoshis()

Fix debug panic in full_stack fuzz test

d4bd56fc41e8714574407ffcd064be21cb42e539 changed the logic for calling
unset_funding_info such that it may be called on a channel that was
already in ChannelPhase::Funded when handling funding_signed. This
caused a debug panic in the full_stack fuzz test when calling
FundedChannel::unset_funding_info. Fix this by only calling
unset_funding_info on watch_channel error, as was previously the case.

This also reverts moving the channel back into
ChannelPhase::UnfundedOutboundV1, which should be fine since the channel
is about to be removed.

Test trampoline-cfg in CI

Merge pull request #3586 from TheBlueMatt/2025-02-router-fixes

Fix router-backtrack cases in last-hop hints

Add TrampolineForward variant to PendingHTLCRouting

Forwarding Trampoline packets requires storing their shared secrets on
top of the outer onion's shared secrets, as well as referencing the
next hop by its node ID as opposed to by an SCID. We modify
PendingHTLCRouting to adequately represent this information.

Stop wrapping router errors in `LightningError`

`LightningError` is an error type for returning errors back to the
`PeerHandler` when handling P2P messages. However, it used to be
more broadly used, in a way that never made any sense.

Here we remove on vestige of this, using a `&'static str` for
router errors rather than `LightningError` with a constant
`action`.

More completely ignore route hints which are for our own channels

When we see a channel come into the router as a route-hint, but its
for a direct channel of ours, we'd like to ignore the route-hint as
we have more information in the first-hop channel info. We do this
by matching SCIDs, but only considered outbound SCID aliases.

Here we change to consider both outbound SCID aliases and the full
channel SCID, which some nodes may use in their invoices.

Replace a few router `expect`s with `debug_assert` + `Err`-returns

The router is a somewhat complicated beast, and though the last few
commits removed some code from it, a complicated beast it remains.
Thus, having `expect`s in it is somewhat risky, so we take this
opportunity to replace some of them with `debug_assert!(false)`s
and an `Err`-return.

Add `PathBuildingHop::best_path_from_hop_selected`

When we process a path backwards from a node during pathfinding, we
implicitly commit to the path up to that node. Any changes to the
preferred path up to that node will make the newly processed path's
state invalid.

In the previous few commits we fixed cases for this in last-hop
paths (both blinded and unblinded).

Here we add assertions to enforce this, tracked in a new bool in
`PathBuildingHop`.

Add direct hops to intros after all blinded paths in pathfinding

When we do pathfinding with blinded paths, we start each
pathfinding iteration by inserting all the blinded paths into our
nodes map as last-hops to the destination. As we do that, we check
if any of the introduction points happen to be nodes we have direct
chanels with, as we want to use the local info for such channels
and support finding a path even if that channel is not publicly
announced.

However, as we iterate the blinded paths, we may find a second
blinded path from the same introduction point which we prefer over
the first. If this happens, we would already have added info from
us over the local channel to that intro point and end up with
calculations for the first hop to a blinded path that we no longer
prefer.

This is ultimately fixed here in two ways:
(a) we process the first-hop channels to blinded path introduction
    points in a separate loop after we've processed all blinded
    paths, ensuring we only ever consider a channel to the blinded
    path we will ultimately prefer.
(b) In the next commit, we add we add a new tracking bool in
    `PathBuildingHop` called `best_path_from_hop_selected` which we
    set when we process a channel backwards from a node, indicating
    that we've committed to the best path to the node and check when
    we add a new path to a node. This would have resulted in a much
    earlier debug-assertion in fuzzing or several tests.

Move last-hop route handling to the common "normal" hop codepath

When we handle the unblinded last-hop route hints from an invoice,
we had a good bit of code dedicated to handling fee propagation
through the (potentially) multiple last-hops and connecting them to
potentially directly-connected first-hops.

This was a good bit of code that was almost never used, and it
turns out was also buggy - we could process a route hint with
multiple hops, committing to one path through nodes A, B, to C,
then process another route hint (or public channel) which changes
our best path from B to C, making the A entry invalid.

Here we remove the whole maze, utilizing the normal hop-processing
logic in `add_entries_to_cheapest_to_target_node` for last-hops as
well. It requires tracking which nodes connect to last-hop hints
similar to the way we do with `is_first_hop_target` in
`PathBuildingHop`, storing the `CandidateRouteHop`s in a new map,
and always calling `add_entries_to_cheapest_to_target_node` on the
payee node, whether its public or not.

Prefer higher-value, shorter equal-cost paths when routing

This likely only impacts very rare edge cases, but if we have two
equal-cost paths, we should likely prefer ones which contribute
more value (avoiding cases where we use paths which are
amount-limited but equal fee to higher-amount paths) and then paths
with fewer hops (which may complete faster).

It does make test behavior more robust against router changes,
which comes in handy over the coming commits.

Drop calculate_our_funding_satoshis(), keep only fee estimation

This method does not take into the intended funding amount, and it's
not currently used, therefore it's removed now. Its fee estimation
part is kept (estimate_v2_funding_transaction_fee).

Include base input fee in fee calculation

The base input fee was missing in calculate_our_funding_satoshis(),
it is added now; also add unit test.

Merge pull request #3577 from tnull/2025-01-rustfmt-offers

`rustfmt`: Run on `offers`

Merge pull request #3562 from joostjager/merge-scores

add scores getter on ProbabilisticScorer

Allows access to the scorer state. An example use case is an LSP
exposing the global network view in its scorer over http to light
clients.

add set_scores method on CombinedScorer to overwrite local data

This commit expands on the previously introduced merge method by
offering a way to simply replace the local scores by the liquidity
information that is obtained from an external source.

`rustfmt`: Drop `lightning/src/offers/mod.rs` from exclusion list

`rustfmt`: Drop `lightning/src/offers/test_utils.rs` from exclusion list

`rustfmt`: Run on `lightning/src/offers/test_utils.rs`

`rustfmt`: Drop `lightning/src/offers/signer.rs` from exclusion list

`rustfmt`: Run on `lightning/src/offers/signer.rs`

`rustfmt`: Drop `lightning/src/offers/refund.rs` from exclusion list

`rustfmt`: Run on `lightning/src/offers/refund.rs`

`rustfmt`: Drop `lightning/src/offers/payer.rs` from exclusion list

`rustfmt`: Drop `lightning/src/offers/parse.rs` from exclusion list

`rustfmt`: Run on `lightning/src/offers/parse.rs`

`rustfmt`: Drop `lightning/src/offers/offer.rs` from exclusion list

`rustfmt`: Run on `lightning/src/offers/offer.rs`

`rustfmt`: Drop `lightning/src/offers/merkle.rs` from exclusion list

`rustfmt`: Run on `lightning/src/offers/merkle.rs`