Eclair

Add `zero-conf` test tag for Phoenix taproot tests (#3181)

We ensure that tests using the Phoenix taproot commitment format
correctly pass on feature branches without conflicts.

Co-authored-by: pm47 <pm.padiou@gmail.com>

Add `DATA_CLOSED` class when active channel is closed (#3170)

We introduce a `DATA_CLOSED` class with minimal information about a
past channel that has been fully closed. This will let us deprecate
legacy channels without having backwards-compatibility issues with
very old closed channels inside our DB.

When channels have never been properly opened or used, we don't
bother storing them in our DB, as it would open the door to DoS
attacks.

We create a dedicated table to store `DATA_CLOSED`. We migrate the
existing DB and remove the foreign key constraint on `htlc_infos`.

Update `bitcoin-lib` (#3179)

And simplify musig2 nonce using Scala classes.

Deduplicate closing balance during mutual close (#3182)

When a mutual close transaction is published or recently confirmed, we
don't include the corresponding channel in our off-chain balance to
avoid counting it twice (which would resolve itself after confirmations
but is misleading).

There are degenerate cases where the channel will actually end up being
force-closed, even though we started with a mutual close, but that will
be very infrequent and will resolve itself after confirmations.

Smaller default value for `peer-connection.max-no-channels` (#3180)

We previously allowed 250 parallel incoming connections from nodes with
whom we don't have any channels yet. While this makes sense for wallet
providers, this is too large for standard routing nodes and exposes them
to more DoS risk. We reduce the default value to 64 instead, which can
of course be overridden by node operators in their `eclair.conf`.

Fix encoding of channel type TLV in splice_init/splice_ack (#3178)

Fix encoding of channel type TLV in splice_init/splice_ack

The channel type codec that we use is a "TLV field codec", wrapping it in a tlvField() codec was wrong
and messed up the encoding.

Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>

Add "phoenix zero reserve" feature bit (#3176)

* Add PhoenixZeroReserve feature bit

Add a feature bit for zero-reserve channel. It is used by phoenix wallets and different from the feature bit proposed in https://github.com/lightning/bolts/pull/1140.

* Simplify SimpleTaprootChannelsPhoenix channel type

It does not make sense to have versions with/without scid-alias and zero-conf.

Reject offers with some fields present but empty (#3175)

Offers or invoices where the fields `offer_chains`, `offer_paths`, `invoice_paths`, `invoice_blindedpay` are present but empty are considered invalid.
While the spec does not necessarily rejects them explicitly, they can't be paid.

Remove `PaymentWeightRatios` from the routing config (#3171)

The new weights based on success probability estimates have proven superior to the old `PaymentWeightRatios`. Removing `PaymentWeightRatios` makes the configuration simpler.

Kill the connection if a peer sends multiple ping requests in parallel (#3172)

We keep track of the number of pings that we have not yet sent a pong for. If there is more than 1, our peer is malicious and we close the connection.

Always count local CLTV delta in route finding (#3174)

When paying from our node, we don't pay the fee for the local channel but we still "pay" its CLTV delta.

Correctly fill PSBT for taproot `interactive-tx` (#3169)

When using tapoot for our inputs, our signatures will cover *all* inputs
of the transaction, even those that don't belong to us. If our peer adds
inputs, we must thus fill them in the PSBT we create, otherwise signing
will fail.

This was the reason why we were previously sharing the same dummy wallet
between Alice and Bob in our unit tests, otherwise we were seeing that
kind of failures in unit tests, but we never figured out why before.

Now that this is fixed, we can improve the unit tests by having separate
wallets for Alice and Bob, and remove the unused `NoOpOnChainWallet`.

Increase timeout for flaky onion message tests (#3167)

The previous timeout of 100ms was creating a lot of tests failures.
This fixes flaky tests in `PostmanSpec` and maybe some other places.

Resign next remote commit on reconnection (#3157)

We previously retransmitted our last `commit_sig` on reconnection if it
hadn't been received by our peer, without changing it. This can be an
issue for taproot channels when remote nodes don't use deterministic
nonce derivation, because their nonce may be different on reconnection
and our previous `commit_sig` would thus not be valid anymore.

We now re-sign the next commitment on reconnection, using the latest
nonces we receive from `channel_reestablish`.

Fix flaky test in `OfferPaymentSpec` (#3165)

Fix flaky `ReputationRecorder` test (#3166)

Sometimes, the test publishes events to the `EventStream` before the `ReputationRecorder` has subscribed, which leads to dropped events.
We fix this by bypassing the `EventStream` in tests.
We also subscribe to `OutgoingHtlcSettled` before subscribing to `OutgoingHtlcAdded` to prevent the unlikely edge case where a HTLC stays pending forever because it settled before `ReputationRecorder` subscribed to `OutgoingHtlcSettled`.

Update taproot commit weight to match `lnd` (#3158)

`lnd` uses a pessimistic weight estimate, assuming that varints take
5 bytes instead of 1 (when encoding the number of inputs and outputs
of the transaction).

Remove legacy channel codecs and DB migrations (#3150)

* Remove legacy channel codecs

We remove legacy channel codecs (versions earlier than v5). We also
remove the corresponding DB migrations: if node operators try to
upgrade from a version of eclair that is older than v0.13, we tell
them to first run the v0.13 version to migrate their channel data.

We regenerate serialization backwards-compatibility test vectors
based on anchor outputs or taproot channel types.

* Check channels DB version early

We check the channels DB version before running any DB migration, to
ensure that node operators can safely run the v0.13 release first.
Otherwise we may have started migrating an unrelated table to a newer
version that isn't included in the v0.13 release, which would thus
fail at start-up.

* Remove migration from `sqlite` to `postgres`

We now expect users to directly use `postgres` if they expect their node
to become large. The `sqlite` option should only be used for small nodes
for individuals, where it is performant enough.

Update Bitcoin Core to v29.1 (#3153)

Update Bitcoin Core to v29.1. This release doesn't contain any breaking
change. It contains the following interesting features that we want to
leverage in future eclair versions:

- orphan handling improvements which lead to better propagation of
force-close transactions
- support for ephemeral dust, which we'll need for 0-fee commitments
(v3 transactions)

See release notes here: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-29.0.md

Back to dev (#3155)

After the v0.13.0 release.

Eclair v0.13.0 release (#3154)

Fix flaky `OfferPaymentSpec` (#3164)

Add high-S signature Bolt 11 test vector (#3163)

We must accept both high-S and low-S signatures in Bolt 11 invoices
when performing public key recovery (which matches secp256k1's
behavior).

See https://github.com/lightning/bolts/pull/1284

Relax taproot feature dependency (#3161)

It appears that `lnd` nodes don't always set `option_simple_close`
when setting `taproot_staging`, which creates disconnection issues.

We will enforce this for the official taproot feature bit, but we
should relax it for the staging bit.

Fix comparison of utxos in the balance (#3160)

The `Utxo` case class has many fields, for comparison we must use the
`outPoint`.