Eclair

Use bitcoin-lib 0.48 (#3316)

Refactor attribution data (#3320)

* Refactor attribution data

We refactor the attribution data code to make it more consistent with
the rest of the Sphinx-related code. We add comments and intermediate
variables to make it more readable. We introduce intermediate classes
to hold data and add better symmetry between the success and failure
cases.

This will make it easier to implement trampoline attribution and add
fulfillment data (https://github.com/lightning/bolts/pull/1344).

* Refactor trampoline attribution data

We correctly extract shared secrets (including trampoline shared
secrets) and detect when we're inside a blinded path to avoid
including attribution data. Note that we don't use the trampoline
shared secret yet, since full trampoline isn't implemented (see
https://github.com/ACINQ/eclair/pull/2819 for the full changes).

We add tests for attribution data with blinded paths and trampoline
payments.

Remove deprecated `bip125 replaceable` field in mempool transaction class (#3319)

`bip125-replaceable` field in Bitcoin Core RPC had been deprecated since v29 and has now been removed.
Full RBF has been the default policy since v28.

Send `splice_locked` if necessary while reconnecting (#3318)

When we lock a commitment while reconnecting, we currently have a bug
where if we've sent our `channel_reestablish` but we haven't received
the remote `channel_reestablish`, we will not send `splice_locked`
which results in a mismatch in the expected number of `commit_sig`
messages for our peer, triggering a force-close.

We now send `splice_locked` when we are in the `SYNCING` state when
that makes sense. The logic is very similar to the `NORMAL` state,
but we don't emit events that are meant to be used when the channel
is ready to handle payments.

Back to dev (#3313)

After the 0.14.0 release.

Eclair v0.14.0 release (#3312)

Fix Bolt12 path fee hiding (#3311)

When using blinded paths in our Bolt12 invoices, we may use a feature
where instead of making the payer pay the fees for the blinded path,
we deduce them from the amount we wish to receive (the recipient pays
for the privacy it gains from using blinded paths, instead of making
the payer pay for something that they didn't opt into). See #2993
for more details.

The constraint on path fees was wrong in some rounding cases, so we
fix that, otherwise we would unnecessarily reject some payments.
This was found by testing blinded trampoline payments.

Add support for zero-fee commitment format (#3192)

* Add support for zero-fee commitment format

We add support for the zero-fee commitment format specified in
https://github.com/lightning/bolts/pull/1228.

Channels using this commitment format benefit from better protection
against pinning attacks (thanks to TRUC/v3 transactions), don't need
the `update_fee` mechanism, have less dust exposure risk, and use an
overall simpler state machine.

In this commit, we simply introduce the commitment format and create
the corresponding transactions.

* Rename `ClaimRemoteDelayedOutputTx`

It isn't delayed anymore for v3 transactions. We could use static wallet
public key, but in most cases it wouldn't work and adds extra complexity
so we don't do it. We add a comment in the documentation of this class
to explain why we're always making a 2nd-stage transaction.

* Validate channel parameters

We apply slightly different validation for zero-fee commitments:

- the commit feerate must be `0 sat/byte`
- the max number of accepted HTLCs must be at most 114
- `update_fee` cannot be used

We verify those requirements during channel creation and add tests
for normal channel operation.

* Handle force-closing zero-fee channels

We add support for force-close zero-fee channels. When publishing the
local commit, this works mostly the same way as other channel types.
The only difference is that we don't even attempt to publish the commit
tx individually: we always bundle it with the anchor transaction.

When we detect the remote commit though, we're able to introduce some
new behavior:

- if we have a large enough main output, we use that to pay the fees
of the remote commit tx (unless it is already confirmed), which avoids
using a wallet input
- otherwise, we spend the anchor output, which competes with the remote
peer package

Since we're only using the anchor transaction or our main output to
spend the ephemeral anchor, we cannot publish HTLC txs until the
commit tx is confirmed. We will in the future make *all* transactions
go through the `ReplaceableTxPublisher`, and at the point we'll be able
to simplify this, but it's too early for this refactoring, so for now
we simply wait for the commit tx to be confirmed before publishing
HTLC txs.

* Don't force-close on remote `error`

When using zero-fee commitments, we don't force-close when receiving an
`error` from our peer: if they want to force-close the channel, they can
publish their commitment instead of forcing us to publish ours. It is
especially true when the commit tx doesn't pay any fees, because the
publisher will pay the entire fees for the force-close.

Note that for wallet peers, we could introduce a mechanism where they
send us their signed commit tx in the error message if they don't have
any wallet input to pay the fees, and we could be nice and publish it
while paying the fees from our main output (which isn't delayed since
it is the remote commit from our point of view).

Change RBF feerate bump rule to match BIP125 (#3298)

The 25/24 multiplicative feerate bump for `tx_init_rbf` can produce
increments too small for Bitcoin Core to relay the replacement
transaction under BIP125's minimum relay fee policy (default
`incrementalRelayFee` of 0.1 sat/vB since Bitcoin Core v30.0). Add a
minimum additive increment of 25 sat/kw alongside the existing
multiplicative rule, using whichever produces a higher feerate.

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

Update features early on reconnection (#3310)

Otherwise some upgrade paths may fail.

Fix edge case in `availableBalanceForSend/Receive` (#3308)

There was a small discrepancy between `availableBalanceForSend/Receive`
and `canSendAdd/canReceiveAdd` when the sender is not paying the commit
tx fees. In `canSendAdd/canReceiveAdd`, we verify that the receiver
(who pays the commit fees) can still pay those fees after adding the
new HTLC to the commit tx. In `availableBalanceForSend/Receive`, we did
not verify that.

This only happens in very rare cases where the receiver is paying the
commit fees and is very close this its channel reserve, so it should
rarely happen in practice, but it sometimes makes our fuzz tests fail.

Compute channel keys once on on startup (#3306)

We compute channel keys when we load and verify channels from our
database, and pass them along instead of re-computing them later
(which can be expensive when done at scale).

Implemented by @sstone, with small modifications by @t-bast.

Bump org.postgresql:postgresql version (#3305)

This fixes a vulnerability, which doesn't apply to eclair in known
deployements, but is worth fixing in case some nodes use untrusted
database hosts which could lead to DoS attacks.

Docker: auto-approve apt-get install command (#3302)

Otherwhile the build will wait for a user input and eventually fail.

Add previous commitments to ChannelFundingConfirmed event (#3303)

Event stream subscribers could use this field to find extra information about previous states that could have been pruned from the current commitments.

Add liquidity ads metrics (#3301)

We add metrics for liquidity ads (purchased amount and mining fee
refund).

We refactor the interactive-tx metrics to record them *after* tx
validation, instead of *before*. We also remove the input/output
count for the "shared" case, since it's always 0 or 1.

Add metrics on interactive-tx inputs and outputs (#3300)

We track:
- global input/output count by type and distribution of amounts
- per-session input/output count by type

Fix flaky DER signature weight test (#3299)

This test was flaky because for the funding output, we provide two
signatures, which means that we need twice the slack for the variable
DER encoding length.

Use official feature bit for `option_simple_taproot` (#3144)

Use the official feature bit and name for taproot channels and the
corresponding channel types. Activate taproot channels support by
default (without support for announcing such channels yet).

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

Add support for the official splicing protocol (#2887)

We replace our experimental version of `splice_init`, `splice_ack` and
`splice_locked` by their official version. If our peer is using the
experimental feature bit, we convert our outgoing messages to use the
experimental encoding and incoming messages to the official messages.

We also change the TLV fields added to `tx_add_input`, `tx_signatures`
and `splice_locked` to match the spec version. We always write both the
official and experimental TLV to updated nodes (because the experimental
one is odd and will be ignored) but we drop the official TLV if our
peer is using the experimental feature, because it won't understand the
even TLV field.

We do the same thing for the `commit_sig` TLV. For peers who support the
official splicing version, we insert the `start_batch` message before
the batch of `commit_sig` messages.

This guarantees backwards-compatibility with peers who only support the
experimental feature.

We introduce a `retransmit_flags` field to `my_current_funding_locked`
and `next_funding` to ask our peer to retransmit `commitment_signed` or
`announcement_signatures` if we're expecting them. With this change, we
don't need to retransmit `splice_locked` on reconnection anymore to
trigger the exchange of `announcement_signatures`. We don't need to
retransmit it to let our peer know that we've seen enough confirmations
for the splice either, since `my_current_funding_locked` implies that.

This allows us to completely remove retransmission of `splice_locked` on
reconnection, and also get rid of the `your_last_funding_locked` TLV,
which greatly simplifies the reconnection logic. We do keep them for
backwards-compatibility with existing Phoenix users though, but we'll
be able to clean it up once they have updated.

Note that this works with taproot channels since we will simply provide
nonces in `channel_reestablish` when we need our peer to send
announcement signatures (not supported yet since taproot channels are
never announced).

We rollback using the `next_commitment_number` to let our peer know that
we haven't received their `commit_sig` and instead use the retransmit
flags added to the `next_funding` TLV, unless our peer is using the
legacy splicing protocol.

More aggressive peer scorer idle channels management (#3295)

We previously lowered fees from idle channels only if our latest update
was from more than 24 hours ago, and closed them if our latest update
was more than 5 days ago and using our minimal fees.

The issue is that our channel update may have been refreshed without
changing the relay fees, for example if our peer disconnected. We don't
track when our relay fees reached the minimum amount, so we may have
a recent channel update even though we reached our minimum relay fees
weeks ago.

We use smaller durations for those thresholds to see if that helps
reclaim liquidity more aggressively.

We also disable old peers revival by default.
This feature is useful when feerates have been high for a while and
funding was thus put on hold, but when feerates are frequently below
our feerate threshold, this is wasting liquidity. It should be enabled
after a high-fee period.

Store our closing_complete in the simple close session (#3289)

In the simple close session, which is never persisted, we just need to remember our closing_complete and
the partial signatures it contains, instead of keeping our musig2 nonces and generating our partial signatures a second time to build the final closing tx when we receive our peer's partial signatures.
We also check our peer's partial signature and fail early if they're not valid, instead of building a fully sign
closing tx and then verify that it is correct.

Increase start-up ZMQ timeout (#3294)

We connect to bitcoind over ZMQ right after spawning all actors in the
system, which can consume a lot of our available sockets/bandwidth. We
increase the default timeout from 5 seconds to 30 seconds.

Add threshold for disabling `from_future_htlc` (#3293)

When funding a transaction using `from_future_htlc`, we are taking the
risk that the remote node doesn't fulfill the corresponding HTLCs. If
we detect that too many peers fail such HTLCs, this may indicate a bug
on the wallet side, so we automatically disable `from_future_htlc` to
limit our exposure.

We also ensure that nodes that already had one suspicious payment are
blacklisted for other payments. This issue can happen when wallet users
use multiple devices in unsupported scenarios.

Add peer scorer documentation (#3277)

We add release notes about the peer scorer for node operators who like
living on the bleeding edge. We also remove the workaround for the lack
of DB data on restart.

We also add metrics to track rolling profit and payment volume.