Eclair

Update `bitcoin-lib` (#3213)

To add support for P2A PSBTs.

Use 73 bytes der-encoded signatures in weight estimation (#3210)

While 73 bytes der-encoded signatures aren't standard (they're only
possible with high-S signatures), miners could accept such signatures.

Most of our tests use 72 bytes der-encoded signatures because we will
never generate 73 bytes der-encoded signatures ourselves. But it's more
safe to use a 73 bytes signature in our weight estimation because:

- it's what the BOLTs recommend
- it's what other implementations use (e.g. LDK) which means they may
reject our interactive-tx attempts by thinking we're under-paying
fees

Allow aborting liquidity purchases after signing (#3206)

When a liquidity purchase is signed, we eagerly add it to our DB before
receiving the remote `interactive-tx` signatures. If we reach that step,
our peer should always finalize the signing steps, so we didn't bother
handling the case where they would instead send `tx_abort`. When that
happened, we kept the upstream HTLCs pending until they got close to
their expiry, at which point we failed them.

We've seen cases where seemingly non-malicious mobile wallets abort
that kind of liquidity purchases after a disconnection. It is harmful
for an honest sender to keep the HTLCs pending, so we now immediately
fail them in that case.

Check that relay fees are nonnegative (#3209)

Fixes #3204

Add `CommitSigBatch` codec (#3205)

While we send `commit_sig` messages individually on the wire, we need
a codec for the batch object when using the cluster mode, when peer
connection actors live on remote machines.

Enable detailed monitoring for singleton actors (#3200)

This allows tracking the `mailbox-size` for those actors, while existing group-level monitoring only tracks `time-in-mailbox`.

Add more logs around `commit_sig` (#3202)

We have a few force-close caused by invalid commit_sig messages. This
may happen when multiple devices are used in parallel, but some reports
don't seem to be using multiple devices.

Unfortunately, we didn't log the details of the commit tx we're building
in every case. Also, we only logged details of our local commit tx after
validating the remote `commit_sig`, which means we cannot troubleshoot
the case where we reject that remote `commit_sig`.

We now log details of the commit tx construction in every scenario,
which should allow detecting discrepancies between the local and remote
states.

Nits (#3203)

Add more tolerance in tests (#3199)

DER encoding size can vary by +- 3 bytes, not +- 2.

Stop sending `update_fee` for mobile wallets (#3186)

We stop sending `update_fee` and set the feerate to `1 sat/byte` for
channels with mobile wallet users. This removes edge cases around
`update_fee` handling in tricky cases (splicing, shutdown, etc) while
still allowing channels to force-close thanks to package relay.

Note that mobile wallets that don't have an on-chain wallet to use
CPFP on the commit transaction may not be able to get their commit
tx confirmed, but that was already the case before that change since
the LSP decides the commit feerate. This will get better with v3 txs
and https://delvingbitcoin.org/t/zero-fee-commitments-for-mobile-wallets/1453

Remove support for non-anchor channels (#3173)

We remove support for `static_remotekey` channels and `default`
channels, as advertised in the v0.13 release. This lets us remove
some code related to feerate management and simplifies the test
matrix.

Node operators that still have such channels must not run this
version of `eclair`, which will otherwise fail to start.

Note that for now, we keep sending `update_fee` whenever necessary.
We could remove that now that package relay allows 1p1c packages to
propagate even when the parent is below the mempool minimum feerate,
but we defer that to a later PR for simplicity.

Require closed channels migration before starting (#3198)

We require closed channels to be migrated to the closed channels table
introduced in #3170 before starting `eclair`. This ensures that we
will not lose channel data when removing support for non-anchor channels
in the next release.

Node operators will have to:

- run the v0.13.0 release to migrate their channel data to v5
- run the v0.13.1 release to migrate their closed channels

Afterwards, they'll be able to update to the (future) v0.14.x release
once all of their pre-anchor channels have been closed.

Back to dev (#3197)

After the v0.13.1 release.

Eclair v0.13.1 release (#3196)

More flexible mixing of clearnet addresses and tor proxy (#3054)

We improve the connection logic when a proxy is configured, but Tor shouldn't
be used for IPv4 or IPv6 remote addresses.

Configure bitcoind test instances to use bech32m addresses (#3195)

When addres type or change type is not specified, bitcoind will
now start with addresstype=bech32m and changetype=bech32m.

We take this opportunity to fix feerate tests that failed because
of the following reasons:

- first of all, we had a bug where we didn't take into account the
anchor amount in our fee calculation, so we ended up always adding
`330 sats` to the on-chain fees we paid, which was hidden by our
tolerance interval, but started appearing with smaller p2tr inputs
- then we fix the remaining tests that need manual tweaking of the
utxos available in the test wallet, because they end up creating
transactions where we don't have a change output (and overpay fees
slightly, but not enough to make it worth adding a change output),
these tests simply needed to be tweaked to accomodate p2tr weights

Co-authored by @sstone

Update `bitcoin-lib` (#3193)

We update `bitcoin-lib` to v0.45, which changes our JNI bindings for
`secp256k1` and adds support for P2A outputs.

Update Bitcoin Core to v29.2 (#3190)

Release note: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-29.2.md

Avoid negative on-the-fly funding fee (#3189)

Since we don't have access to channel params in the `Peer` actor, we
don't know the remote `htlc_minimum` when receiving a splice. This may
lead to cases where we later fail because we end up with a negative
funding fee, which doesn't make any sense.

To avoid those failures, we hard-code the `htlc_minimum` value used by
Phoenix (which is the only consumer of this protocol so far) and use
the max with our local `htlc_minimum`.

Only store txs spending our commit outputs (#3188)

Instead of storing every transaction spending the commit tx (which
potentially included remote anchor transactions, which we aren't
interested in), we explicitly store only the transactions that spend
outputs of the commit tx we're interested in. This is more verbose
than the previous code, but avoids unintended side-effects such as
storing remote transactions.

Don't store anchor transaction in channel data (#3187)

We don't need to store the anchor transaction in our channel data when
closing a channel: this isn't used anywhere and unnecessarily uses
space in our DB.

Also, once the commit tx is confirmed, we don't need to watch the
anchor output again on restarts.

Split MPP by maximizing expected delivered amount (#2792)

As suggested by @renepickhardt in https://github.com/ACINQ/eclair/pull/2785

Use bitcoin-lib 0.44 (#3185)

Create fresh shutdown nonce on reconnection (#3184)

When we disconnect after sending `shutdown`, we must re-send `shutdown`.
When using taproot, we must generate a fresh nonce and store the private
nonce locally, otherwise we won't be able to create our `closing_sig`.

Nits (#3183)