Eclair

Back to dev (#3339)

After the v0.14.1 release.

Eclair v0.14.1 release (#3338)

Disable Bolt12 recipient path fee discount (#3332)

In https://github.com/ACINQ/eclair/pull/2993, we introduced a mechanism
in the default Bolt12 offer handler to let the recipient pay the fees of
the blinded paths they include in their Bolt12 invoices, instead of the
payer having to pay fees for privacy chosen by the recipient (when the
recipient decides to use a "real" blinded path with external nodes they
don't control).

This wasn't correctly taking MPP into account: payers could split the
payment in many tiny parts such that each part used the whole path fee
discount. As a result, the payer would have still paid the whole amount
but most of it would be collected by intermediate nodes inside the path
instead of the recipient, which isn't the goal.

We're thus disabling this feature: we'll need a cleaner protocol to
correctly account for MPP with base fees. Bolt12 isn't used yet by
merchants so it's fine: we'll wait for recipients to adopt it before
deciding how we introduce a blinded path fee discount feature (if this
is something that users request). Note that we also recommend users
to implement their own offer handler to customize their blinded paths,
if they care about privacy, instead of using the default handler which
is mostly there as a reference.

Prevent `channel_id` collisions (#3337)

* Reject channel if initial DB write fails

If the first DB write of a channel fails, we want to abort the channel
immediately, otherwise our state may be unusable. If for some reason
we already have a channel (for example because of a partial restore
from a DB backup), we want to avoid overwriting this state as well.

* Add global `channel_id`s collision resistance

We add a global, concurrent map that keeps track of every temporary
and final `channel_id` being used. We always add to this map before
creating channel actors or transitioning to a final `channel_id`
(and thus before storing channel data in the DB).

We only remove from that map when a channel actor dies: no other
channel can be associated with the corresponding temporary or
final `channel_id` since the channel was created after registering
the IDs.

Apply RBF limits to remote closing transactions (#3331)

* Apply RBF limits to remote closing transactions

When using `option_simple_close`, we didn't apply explicit rate-limits
to remote closing transactions, apart from the fact that the feerate
must be higher for each attempt.

There is no good reason to make a large number of RBF attempts when
closing a channel cooperatively, so we apply the same rate-limits we
use for funding.

* Bound the number of local closing transactions

We apply the BOLTs recommendation for the maximum number of closing
transactions we create when using the legacy closing protocol (not
`option_simple_close`). We previously restricted remote closing
transactions, but we now also apply it to our local transactions.

* Apply the maximum attempts limit to splice RBF

We previously only applied the rate-limit (X attempts every Y blocks)
but we didn't apply the maximum attempts limit. The risk is that we may
end up with a splice that is stuck unconfirmed, but will eventually
confirm, unless the peer is malicious and the feerate was very badly
estimated (in which case they would have found a way to prevent the
splice from confirming anyway).

Reject `start_batch` with size <= 1 (#3333)

Bolt2 specifies that a receiving node:

```
If batch_size is not strictly greater than 1:
- MUST ignore the start_batch message.
- SHOULD send a warning.
```

Don't store duplicate settlement messages (#3336)

If our peer is buggy, or if we have a bug in our message queue, we may
receive duplicate settlement messages for pending HTLCs. It is fine to
handle them and relay the settlement downstream (instead of immediately
force-closing), but we shouldn't store the duplicate settlement in the
remote changes, otherwise it will trigger a force-close when exchanging
`commit_sig`.

Accept Bolt12 invoices with reply path (#3325)

We previously rejected Bolt12 invoices when a reply path was provided
in the onion message. This wasn't in the spec, and it could make sense
to provide a specific reply path with an invoice in case the payer
considers the invoice invalid and wants to send back an invoice_error
to inform the recipient.

This created compatibility issues with LDK.

Fixes #3322

Ignore repeated invalid `tx_signatures` (#3328)

When our peer sends us an invalid `tx_signatures`, we processed it and
ignored the failure when we've already sent our own `tx_signatures`,
because the transaction may be broadcast and may confirm anyway.

We now stop processing those invalid `tx_signatures` repeatedly: if our
peer sends us more than 3 invalid `tx_signatures` for a given funding
transaction, they're definitely buggy so we'll just wait for the
transaction to confirm without trying to obtain the fully signed one
locally.

We also now avoid unnecessary DB writes on `shutdown`.
We don't need to write to the DB every time we receive `shutdown` from
our peer, since the BOLTs require `shutdown` to be retransmitted on
reconnection.

Update Bitcoin Core to v31.1 (#3327)

This release contains a new index which we need for #3279.

Reject `temporary_channel_id` duplicates early (#3324)

We previously rejected duplicate `temporary_channel_id` immediately, but
we didn't immediately reject `temporary_channel_id`s that conflict with
a *final* `channel_id` with the same peer: the rejection would happen
later in the flow when transitioning from temporary to final IDs, which
made debugging harder.

Since the channel interceptor step isn't atomic, we must check for
duplicate channel IDs *after* rate-limiting, to ensure that we don't
try inserting an entry in the channels map that is already there.

Reject incoming HTLCs with a high `cltv_expiry` (#3323)

We currently reject HTLCs with a `cltv_expiry` higher than 2 weeks in
the future when sending them (in the `sendAdd` method). That's because
they would lock up our funds for a long period of time if our peer
decided to force-close. Also, a large `cltv_expiry` makes slow jamming
easier.

We now apply the same limits to incoming HTLCs for consistency (since
they may differ by `cltv_expiry_delta`). Note that we don't do it in
the `receiveAdd` function, which would trigger a force-close. We just
accept those HTLCs and then fail them, since it is harmless to have
them only temporarily in our commitment as long as we don't relay.

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.