Eclair

Use helpers for feerates conversions (#3156)

It saves tedious double parentheses: `FeeratePerKw(FeeratePerByte(1 sat))` -> `FeeratePerByte(1 sat).perKw`.

Re-encode channel data using v5 codecs (#3149)

We force a re-encoding of all channel data using v5 codecs when updating
eclair. This will allow us to remove support for previous codecs in a
later release. If users try to directly upgrade to a release that does
not contain the legacy codecs, we'll fail at start-up and tell them to
first update to the release that contains this migration code as an
intermediate step.

We plan to remove support for channels that aren't using anchor outputs,
so we add a warning in the logs and a command to help users close such
existing channels.

Use balance estimates from past payments in path-finding (#2308)

We estimate the probability that a given route can relay a given payment as part of route selection.
Until now this estimate was naively assuming the channel balances to be uniformly distributed.
We will now use data from past payment attempts (both successes and failures) to provide a better estimate, hopefully improving route selection.

Allow non-initiator RBF for dual funding (#3021)

We previously only allowed the opener to RBF a dual-funded channel.
This is not consistent with splicing, where both peers can initiate
RBF. There is no technical reason to restrict the channel creation,
we can allow the non-initiator to RBF if they wish to do so.

The only subtlety is in the case where there is a liquidity purchase.
In that case we want the opener to be the only one allowed to RBF to
guarantee that we keep the liquidity purchase (since the initiator is
the only one that can purchase liquidity).

Allow overriding `max-closing-feerate` with `forceclose` API (#3142)

We introduced a mechanism to limit the feerate used for non-urgent
force-close transactions in #3097. We now provide a way to update
this feerate on a per-channel basis, without restarting the eclair
node, by using the `forceclose` API.

Fixes #3108.

Fix `LocalFundingStatus.ConfirmedFundingTx` migration (#3151)

We cannot rely on the `shortChannelId` to choose which output of the
funding transaction is the channel output, because in some cases the
`shortChannelId` isn't properly filled (e.g. private channels).

We instead use the commit tx input which should always be correctly
set.

Add `GossipTimestampFilter` buffer during gossip queries to fix flaky tests (#3152)

In a network Alice -- Bob - Carol, we could have
- Alice creates a channel update, Bob and Carol do not know it yet.
- Carol syncs with Bob and sends a `GossipTimestampFilter` with the current timestamp
- Bob receives the channel update from Alice but does not propagate it to Carol because it is too old for the `GossipTimestampFilter`

To prevent this from happening, we add a buffer of one minute to allow gossip to propagate.

This is unlikely to happen in real life but was making some tests flaky.

Adjust `batch_size` on `commit_sig` retransmission (#3147)

If we send a batch of `commit_sig` while our peer is sending their
`splice_locked` and we disconnect before receiving `revoke_and_ack`,
we will have less `commit_sig` messages to send on reconnection. But
we were still sending the old `batch_size`, so our peer was expecting
more `commit_sig` messages and waiting indefinitely.

This shows how hacky the `batch_size` mechanism is: fortunately, it was
removed from the official splice spec and replaced by the funding txid
matching the commitment, which gets rid of this edge case entirely.
But for existing phoenix users, while the splice spec isn't finalized,
we need to fix this scenario.

Fix minor incompatibilities with feature branches (#3148)

* Fix conflict with custom TLVs for `prevtxout`

We already use TLV types 1107 and 1109 for our experimental
swap-in-potentiam implementation.

* Store spent outpoints for confirmed funding txs

This can be used in feature branches to catch double-spending issues
across interactive-tx sessions early in the flow.

Split commit nonces from funding nonce in `tx_complete` (#3145)

The commit nonces and funding nonce provided in `tx_complete` are
actually completely orthogonal:

- the commit nonces must be provided whenever the *next* commitment
format is using taproot
- the funding nonce must be provided whenever the *previous* commitment
format is using taproot

It thus makes more sense to split them into separate TLVs.

Allow omitting `previousTx` for taproot splices (#3143)

When splicing a taproot channel, both participants will provide a
signature for a segwit v1 input: this signature will cover every
spent `txOut`, including their amount and script. This ensures
that attackers cannot reuse a signature while replacing a segwit
input with a non-segwit input, which could be used to steal funds.

A side-effect of this change in signature behavior is that we don't
need to provide the entire previous transaction when both channel
participants sign a taproot input. For simplicity, we only allow
this simplification when splicing taproot channels for now. We can
also allow channel creation based on swap-in-potentiam, which also
uses musig2 and has the same non-malleability guarantee (on feature
branches for phoenix users).

Simple taproot channels (#3103)

Implement simple taproot channels

We add new commitment formats and TLV extensions to include musig2 nonces. This includes a specific commitment format for phoenix
taproot channels.

The old v1 channel establishment protocol is updated to include nonces and partial signatures.

The v2 channel estalishment protocol, based on the interactive tx constuction protocol, is also updated, and the
interactive tx session now includes:
- an optional funding nonce for the shared input (i.e. the funding tx that is being spent)
- a nonce for the commit tx that is being created, and another nonce that will become the channel's "next remote nonce" once the session completes
The funding nonce is random and its lifecycle is bound to the interactive session.

Side note: the new v2 protocol is both simpler to extend and gives us support for dual-funding and splices.

Since there can be several different commitment transactions that valid at the same time while splices are pending, revoke_and_ack
and channel_restablish are extended to include a list of funding_tx_id -> nonce tuples (one for each active commitment).

channel_restablish also includes as an optional "current commit nonce": if we got disconnected while a splice was in progress
before both nodes exchanged their commit signatures: if that is the case, we need to re-send our peer's current signature
and will use this nonce to compute it.

We also update the simple close protocol to include closing nonces.

We allow upgrading channels to taproot during splices, with an optional channel_type TLV added to splice_init/splice_ack.
This is not part of the BOLT proposal, and upgrading is currently limited to phoenix taproot channels from phoenix anchor channels.

Extract `CommitParams` to individual commitments (#3118)

We introduce a new channel codec version where:

- we extract per-commitment parameters (commitment format and params
such as `dust_limit` which we may want to dynamically update in the
future)
- we clean-up the splice iterations on the `Commitments` structure
- we remove the funding transaction from the confirmed local funding
status (once confirmed, we don't need it anymore: it is wasting DB
space for no good reason, we can get it from the blockchain)
- we add a `maxClosingFeerate_opt` to the closing state, to allow
limiting the feerate used in RBF attempts for safe transactions
- we add the commitment format to interactive-tx parameters
- we make channel type feature non permanent

We add a mechanism to prevent the node from starting-up, unless an
override is provided. This provides an opportunity to iterate on codecs
while knowing that node operators won't be affected if we make changes
that are backwards-incompatible. This is meant to be temporary.

Offers with currency must set amount. (#3140)

Adds check and corresponding test from lightning/bolts#1279

Use actual CLTV delta for reputation (#3134)

When computing reputation, instead of using a fixed multiplier for pending HTLCs, we now use the CLTV expiry of the HTLC (assuming a new block is mined every 10 minutes).
The reason for the fixed multiplier was that a HTLC with the maximum CLTV delta could stay pending for several orders of magnitude longer than a regular HTLC and would have an oversized impact on the reputation. We mitigate this by increasing the expected settlement time (from a few seconds to a few minutes), using more historical data (increasing the half-life), and counting on the fact that most HTLCs will have a CLTV expiry a lot lower than the maximum.

Add recent invoice spec test vectors (#3137)

Add test vectors from https://github.com/lightning/bolts/pull/1276
and https://github.com/lightning/bolts/pull/1264