rust-lightning

Replace FundingTemplate contribution methods with FundingBuilder

This results in a slight change of behavior: now these methods reuse and
amend the prior contribution, as opposed to always starting from a fresh
contribution, which would be the desired expected behavior by users.

Introduce FundingBuilder for splice requests

This lets callers easily amend a prior contribution in place and only
re-run coin selection when the new request cannot be satisfied with the
existing inputs.

Disallow net-negative contributions when adding value

When a user requests to add value via coin-selected inputs, we should
strive to fulfill their request. Allowing them to remove value from the
channel is undesired as it goes against their request. While we still
allow adding outputs to enabled mixed contributions, their funds must
now always come from the set of coin-selected inputs, and must never
draw from the channel balance resulting in a smaller added value.

Split fuzz runners by hash mode

Move shared fuzz logic into the root fuzz crate and generate
fake-hashes and real-hashes runner crates.

Keep `chanmon_consistency_target` on the real-hashes side, remove
the fuzz-local Cargo config, and update scripts, CI, coverage,
and docs to use explicit flags for each runner.

Generate the hash-mode compile checks in the wrapper bins
without a synthetic Cargo feature, while keeping the wrapper
template close to its original shape.

AI tools were used in preparing this commit.

Fix chanmon_consistency for real hashes

Store real payment preimages in `chanmon_consistency` and use
them when claiming funds, so the real-hashes runner does not
treat `payment_hash` bytes as a stand-in preimage.

AI tools were used in preparing this commit.

Derive FundingContribution::net_value implicitly

This commit removes `FundingContribution::value_added` as tracking it is
unnecessary -- it can just be derived from the total amount in minus
total amount out minus fees.

Make PriorContribution::holder_balance non-optional

The `holder_balance` is computed by
`FundedChannel::get_holder_counterparty_balances_floor_incl_fee`, which
may unexpectedly fail due to the balance either being too high or too
low. These cases are highly unlikely to happen given we have validation
to ensure we never enter such a state to begin with. If they were to
happen, something has gone wrong with the channel and it doesn't make
sense to allow splicing anyway. Therefore, we opt to make
`PriorContribution::holder_balance` non-optional and return an error
that the channel cannot be spliced at the moment.

Use floor division for the spec's 25/24 RBF feerate rule

The spec says the 25/24 multiplicative feerate is "rounded down", but
min_rbf_feerate used ceiling division. This made the computed minimum 1
sat/kwu too high when prev * 25 is not evenly divisible by 24, which
could reject valid counterparty feerates.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Enforce minimum RBF feerate from counterparty

The spec's tx_init_rbf recipient requirements now mandate rejecting a
feerate below max(prev + 25 sat/kwu, ceil(prev * 25/24)), matching the
sender requirement. Previously we only enforced the 25/24 rule on
counterparties. Reuse the existing min_rbf_feerate function for both
our own and counterparty validation.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Expose current dust exposure in ChannelDetails

Co-authored-by: Codex <codex@openai.com>

expose scorer

ln/test: add multi-purpose trampoline test helper

To create trampoline forwarding and single hop receiving tails.

blinded_path: add constructor for trampoline blinded path

blinded_path/refactor: make construction generic over forwarding type

To use helper functions for either trampoline or regular paths.
We only want to support trampoline and regular blinded paths, so we
don't want to support implementation outside of this crate. We need
the trait itself to be public as it's part of a public struct, so we
use a sealed trait to disallow external implementation.

ln/refactor: pass minimum delta into check_incoming_htlc_cltv

For trampoline payments, we don't want to enforce a minimum cltv delta
between our incoming and outer onion outgoing CLTV because we'll
calculate our delta from the inner trampoline onion's value. However,
we still want to check that we get at least the CLTV that the sending
node intended for us and we still want to validate our incoming value.
Refactor to allow setting a zero delta, for use for trampoline payments.

ln/refactor: introduce HasMppPart generic to share incoming mpp

To allow re-use with trampoline payments which won't use the
ClaimablePayment type, make handling generic for anything with MPP
parts.

Here we also move counterparty skimmed logic to claimable payments,
as this doesn't apply for trampoline.

ln/refactor: move checks on incoming mpp accumulation into method

We're going to use the same logic for trampoline and for incoming MPP
payments, so we pull this out into a separate function.

ln/refactor: remove claimable htlc from fail_htlc macro

In the commit that follows we're going to need to take ownership
of our htlc before this macro is used, so we pull out the information
we need in advance.

ln/refactor: move on chain timeout check into claimable htlc

We'll re-use this to check trampoline MPP timeout in future commits.

ln/refactor: move mpp timeout into helper function

We'll use this shared logic when we need to timeout trampoline HTLCs.

Note that there's a slight behavior change in this commit. Previously,
we'd do a first pass to check out total received value and return
early if we'd reached it without applying a MPP tick to any HTLC.
Now, we'll apply the MPP tick as we accumulate our total value received.

This does not make any difference, because we never MPP-timeout fully
accumulated MPP payments so it doesn't matter if we've applied the
tick when we've reached our full amount.

ln/refactor: move MPP information into separate struct to ClaimableHTLC

Pull out all fields that are common to incoming claimable and trampoline
MPP HTLCs. This will be used in future commits to accumulate MPP HTLCs
that are part of trampoline forwards - we can't claim these, but need
to accumulate them in the same way as receives before forwarding onwards.

ln/refactor: rename shared secret and populate in HTLCPreviousHopData

ln/refactor: add previous_hop_data helper for HTLCSource

fuzz: gate splice opcodes on cfg(splicing)

Keep the splice opcodes in chanmon_consistency available
only when the crate is built with cfg(splicing). When
splicing is disabled, return early from those opcode
handlers instead of calling splice helpers that are not
compiled in.

Add cfg(splicing) to fuzz/Cargo.toml check-cfg so the
guarded code builds cleanly in the fuzz crate.

AI tools were used in preparing this commit.

fuzz: handle BroadcastChannelUpdate in chanmon

The regression was introduced in d627ce14c. That change
switched fee update opcodes in chanmon_consistency from
maybe_update_chan_fees() to timer_tick_occurred(), which can
enqueue BroadcastChannelUpdate events while peers are
disconnected.

The harness already tolerated those events in one delivery
path, but still treated them as unreachable in
push_excess_b_events and disconnect draining. Accept
BroadcastChannelUpdate in those match arms so the fuzz target
no longer panics on valid timer tick driven message queues.

AI tools were used in preparing this commit.