rust-lightning

Make ClaimId optional in coin selection

CoinSelectionSource is used for anchor bumping where a ClaimId is passed
in to avoid double spending other claims. To re-use this trait for
funding a splice, the ClaimId must be optional. And, if None, then any
locked UTXOs may be considered ineligible by an implementation.

Use FundingTxInput instead of Utxo in CoinSelection

In order to reuse CoinSelectionSource for splicing, the previous
transaction of each UTXO is needed. Update CoinSelection to use
FundingTxInput (renamed to ConfirmedUtxo) so that it is available.

This requires adding a method to WalletSource to look up a previous
transaction for a UTXO. Otherwise, Wallet's implementation of
CoinSelectionSource would need WalletSource to include the previous
transactions when listing confirmed UTXOs to select from. But this would
be inefficient since only some UTXOs are selected.

Move shellcheck step from build job to linting job

Shellcheck is a static analysis tool for shell scripts and belongs with
the other linting checks rather than in the build matrix. This also
prepares for splitting the build job into parallel sub-jobs, where
running shellcheck in each sub-job would be redundant.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Add CI job to report main branch build failures via GitHub issues

Automatically creates or comments on a "build failed" issue when any CI
job fails on the main branch, and assigns it to the committer who
triggered the failure. Uses inline gh CLI commands to avoid a
third-party action dependency.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Move FundingTxInput::sequence to Utxo

A forthcoming commit will change CoinSelection to include FundingTxInput
instead of Utxo, though the former will probably be renamed. This is so
CoinSelectionSource can be used when funding a splice. Further updating
WalletSource to use FundingTxInput is not desirable, however, as it
would result in looking up each confirmed UTXOs previous transaction
even if it is not selected. See Wallet's implementation of
CoinSelectionSource, which delegates to WalletSource for listing all
confirmed UTXOs.

This commit moves FundingTxInput::sequence to Utxo, and thus the
responsibility for setting it to WalletSource implementations. Doing so
will allow Wallet's CoinSelectionSource implementation to delegate
looking up previous transactions to WalletSource without having to
explicitly set the sequence on any FundingTxInput.

Update RECONSTRUCT_HTLCS_FROM_CHANS_VERSION 5 -> 2

We previously had 5 due to wanting some flexibility to bump versions in
between, but eventually concluded that wasn't necessary.

Test restart-claim of two MPP holding cell HTLCs

Test that if we restart and had two inbound MPP-part HTLCs received over the
same channel in the holding cell prior to shutdown, and we lost the holding
cell prior to restart, those HTLCs will still be claimed backwards.

Test largely written by Claude

Fix missing user_channel_id in PaymentForwarded

Previously, if a forwarding node reloaded mid-HTLC-forward with a preimage in
the outbound edge monitor and the outbound edge channel still open, and
subsequently reclaimed the inbound HTLC backwards, the PaymentForwarded event
would be missing the next_user_channel_id field.

Fix PaymentForwarded fields on restart claim

Previously, we were spuriously using the upstream channel's info when we
should've been using the downstream channel's.

Persist outbound channel info in inbound HTLCs

We need these fields to generate a correct PaymentForwarded event if we need to
claim this inbound HTLC backwards after restart and it's already been claimed
and removed on the outbound edge.

Trivial: user_channel_id in pending_claims_to_replay

Adds support for passing user_channel_id into the pending_claims_to_replay vec,
which is used by the ChannelManager on startup.

For now user_channel_id is always set to None, but in upcoming commits we will
set it to Some when the downstream channel is still open (this is currently a
bug). Separated out here for reviewability.

Trivial: ChannelManager::read var rename prefactor

Makes an upcoming commit cleaner: when we add a next_hop variable we want to
distinguish it from the previous hop.

Select the channel with the highest balance for blinded paths

When building a compact blinded path we need to pick a channel for
an SCID that we think is mostl likely to stick around the longest.
We don't really have any great options cause we have no idea what
downstream code does, but "highest balance" seems marginally
better than the previous criteria of "oldest channel".

Drop `ChannelHandshakeLimits::max_funding_satoshis`

Previously, LDK would by default limit channels pre-Wumbo sizes and
leave it to the user to bump
`ChannelHandshakeLimits::max_funding_satoshis`. This has mostly
historical reasons that aimed to allow limiting risk when Lightning and
LDK were not as matured as today. By now, we do however expect ~all
users to eventually want to bump this limit, and having them pick an
arbitrary value (or pick a default ourselves) is kinda odd. Users that
still want to limit risks have ample other means to do so, for example
manually rejecting inbound channels via the manual-acceptence flow (via
`Event::OpenChannelRequest`) or soon even limiting risk on a per-HTLC
basis via general purpose HTLC interception.

Furthermore, it turns out that our current implementation is wrong, as
we do always announce `Wumbo`/`option_supports_large_channels` support
via the `IN` feature in `ChannelManager` defaults, irrespective of what
limit is configured. This has us announcing support for Wumbo channels
to only then reject inbound requests in case a counterparty dares to
actually try to open one.

To address this, we here simply propose to drop the
`max_funding_satoshis` field and corresponding checks entirely, and do
what we've announced to the network for a long time: enable Wumbo by
default.

Rustfmt ChannelManager::internal_splice_init

Rustfmt ChannelManager::internal_commitment_signed

Rustfmt ChannelManager::internal_splice_ack

Rustfmt ChannelManager::internal_tx_abort

Rustfmt ChannelManager::internal_tx_signatures

Rustfmt ChannelManager::internal_tx_complete

Refactor missing peer/channel APIError from ChannelManager methods

We have the same error being returned from several `ChannelManager` API
methods, so we DRY it up. Doing so also lets us get rid of the inlined
`format!` call, which for some reason prevents `rustfmt` from formatting
code around it.

Refactor missing peer/channel error from ChannelManager message handlers

We have the same error being returned from several `ChannelManager`
message handlers, so we DRY it up. Doing so also lets us get rid of the
inlined `format!` call, which for some reason prevents `rustfmt` from
formatting code around it.

Accept blinded paths built by a phantom node participant

In the next commit we'll add support for building a BOLT 12 offer
which can be paid to any one of a number of participant nodes. Here
we add support for validating blinded paths as coming from one of
the participating nodes by deriving a new key as a part of the
`ExpandedKey`.

We keep this separate from the existing `ReceiveAuthKey` which is
node-specific to ensure that we only allow this key to be used for
blinded payment paths and contexts in `invoice_request` messages.
This ensures that normal onion messages are still tied to specific
nodes.

Note that we will not yet use the blinded payment path phantom
support which requires additional future work. However, allowing
them to be authenticated in a phantom configuration should allow
for compatibility across versions once the building logic lands.

Add methods to fetch an `OfferBuilder` for "phantom" node configs

In the BOLT 11 world, we have specific support for what we call
"phantom nodes" - creating invoices which can be paid to any one of
a number of nodes by adding route-hints which represent nodes that
do not exist.

In BOLT 12, blinded paths make a similar feature much simpler - we
can simply add blinded paths which terminate at different nodes.
The blinding means that the sender is none the wiser.

Here we add logic to fetch an `OfferBuilder` which can generate an
offer payable to any one of a set of nodes. We retain the "phantom"
terminology even though there are no longer any "phantom" nodes.

Note that the current logic only supports the `invoice_request`
message going to any of the participating nodes, it then replies
with a `Bolt12Invoice` which can only be paid to the responding
node. Future work may relax this restriction.

Add an `ExpandedKey` key for phantom blinded path authentication

In the coming commits we'll add support for building a blinded path
which can be received to any one of several nodes in a "phantom"
configuration (terminology we retain from BOLT 11 though there are
no longer any phantom nodes in the paths).

Here we adda new key in `ExpandedKey` which we can use to
authenticate blinded paths as coming from a phantom node
participant.