Eclair

Upgrade postgresql client from 42.7.11 to 42.7.12 (#3330)

Bumps [org.postgresql:postgresql](https://github.com/pgjdbc/pgjdbc) from 42.7.11 to 42.7.12.
- [Release notes](https://github.com/pgjdbc/pgjdbc/releases)
- [Changelog](https://github.com/pgjdbc/pgjdbc/blob/master/CHANGELOG.md)
- [Commits](https://github.com/pgjdbc/pgjdbc/compare/REL42.7.11...REL42.7.12)

---

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: pm47 <pm.padiou@gmail.com>

Use bitcoin-kmp 0.49 (depends on bitcoin-kmp 0.32.0 and secp256k1-kmp 0.24.0) (#3362)

Update build to improve release process (#3381)

* Update maven plugins

* Don't store commit id in eclair-core jar manifest

It creates a chicken-and-egg problem if you want to commit the checksum of eclair-core.jar to .mvn/checksums/checksums-workspace.sha256.

* Add maven profile for eclair-fuzz

To build eclair-fuzz, use the with-eclair-fuzz profile with -Pwith-eclair-fuzz

Reject API access from browsers (#3380)

Any request carrying an `Origin` header is now rejected with 403 before the inner route runs: browsers set it on every cross-site request and every non-GET/HEAD request, while `curl` and `eclair-cli` never do. Checking presence rather than value also covers `Origin: null` and DNS rebinding.

This is a defence against browser CSRF, not an authentication mechanism — `Origin` is trivially omitted by a non-browser client, and the API should still never be exposed beyond loopback.

Breaking change: the API can no longer be called from a web browser, even same-origin; anyone serving a web front-end against it now needs their own back-end in front.

Fixes project-loupe/audit-eclair#223, and by construction any other CSRF report against an individual endpoint.

Improve the deterministic build (#3378)

Explicitly specify file permissions and line endings so it is easier to end up with the same binaries in various set ups.

More AI fixes and defense-in-depth (#3376)

* loupe: add min-to-self-delay check

See: https://github.com/project-loupe/audit-eclair/issues/205

* loupe: use distinct nonces for initial commitments

See https://github.com/project-loupe/audit-eclair/issues/83

* loupe: check signed psbt

See https://github.com/project-loupe/audit-eclair/issues/44

* loupe: prevent overflow on relay-fee calculation

See https://github.com/project-loupe/audit-eclair/issues/31

* Validate relay parameters before on-the-fly funding

When relaying a blinded payment to a wallet node we don't have a channel
with, we cannot validate the relay parameters against a channel_update,
so we skipped that validation entirely before attempting on-the-fly
funding. A malicious wallet node could thus create a blinded path with
a null cltv_expiry_delta for our node, and we would fund a channel and
relay an HTLC that expires at the same block as the upstream HTLC. That
HTLC could then be fulfilled on-chain by the wallet node while the
upstream HTLC times out, making us lose the HTLC amount.

We now validate the relay parameters against the ones the channel we
would create would use (our expiry delta, htlc minimum and our default
relay fees) and fail early instead of funding a
channel for a payment we would have rejected anyway.

See: https://github.com/project-loupe/audit-eclair/issues/162

* Force-close with a publishable commitment

When we sign a splice transaction first (which always happens when we
don't contribute any input) and our peer withholds their tx_signatures,
we cannot publish that splice transaction. Our latest commitment builds
on it, so its commit tx cannot confirm unless our peer publishes the
splice transaction. We still force-closed with that commitment, and the
publisher then retried forever waiting for the parent.

A malicious peer could exploit this to lock our funds indefinitely, or
worse, to steal pending HTLCs: they wait for the upstream HTLC to time
out, then publish the previous commitment and claim the HTLC with its
preimage, since we were unable to time it out on-chain.

When force-closing, we now skip commitments whose funding transaction
hasn't been fully signed and use the latest one that can confirm. The
commitments themselves are left untouched: the closing state now
resolves the commitment matching each published commit txid (ours or
our peer's) wherever it needs commitment-specific data (HTLC signatures,
keys, format), including when restoring after a restart and when
reporting the closed channel. Revoked and future commit txs cannot be
matched and keep using the latest commitment, as before. If our peer
later publishes that splice transaction and it confirms, our commit tx
is double-spent and we force-close again with the latest commitment.

* Bound closing fees proposed by our peer

When we pay the closing fees and our peer sends a closing_signed with a
fee outside of our fee range, we try to converge towards their fee, for
compatibility with implementations that ignore fee ranges. But nothing
bounded that fee: a malicious peer could propose a fee larger than our
balance, we would drop our output and sign a closing transaction that
sends our whole balance to miners, in a single round-trip.

We now refuse fees that exceed what our maximum closing feerate allows
when we pay the fees, and reply with a warning: our peer must propose a
reasonable fee, or we can force-close.

See: https://github.com/project-loupe/audit-eclair/issues/63

* Extract preimage from taproot HTLC-success with annex

When our peer publishes their commit tx and claims an HTLC with an
HTLC-success transaction, we extract the preimage from its witness to
relay it upstream. For taproot channels, we only handled the witness
without an annex, whereas we already handled both cases for
Claim-HTLC-success transactions. If an HTLC-success transaction with an
annex was confirmed, we would fail to extract the preimage and treat
the HTLC as timed out, failing it upstream even though it was fulfilled
downstream.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* Use pending signed commitment in canSendFee

When checking that we can afford a new feerate, we were using the spec
of the remote commitment we last received a revocation for, ignoring
the changes we had already signed in a pending commit_sig. Every other
balance check uses the pending commitment when there is one. We could
thus send an update_fee that our peer cannot accept, since they check
it against the commitment we signed, which would make them force-close.

* Bound hidden blinded path fees per payment part

When we hide part of the blinded path fees from the payer, we accept
HTLCs whose amount is smaller than the onion amount by at most those
fees. That bound was computed on the whole invoice amount for every
HTLC, so a payer splitting the payment in several parts could underpay
us by the proportional fee on each part.

The hidden fees are paid on each part, so we now compute the bound on
the part's onion amount. We add a small tolerance since LDK doesn't use
the BOLT 4 formula to compute amt_to_forward inside blinded paths and
rounds down the fee it pays as a sender, which can leave parts short by
a few msat.

* Only accept derivation paths tracked by our wallet

When using the eclair signer, Bitcoin Core only holds a watch-only
wallet built from our BIP84 and BIP86 account xpubs. We verified that
addresses and change outputs it provides belong to us by re-deriving
the public key along the derivation path it gives us, but we accepted
any path. Since Bitcoin Core knows our account xpubs, a malicious node
could provide addresses for deeper or non-standard branches: we would
consider them ours and use them for channel closing scripts, splice
outputs and change, but our wallet would never track them and we would
be unable to find those funds.

We now only accept paths of the form purpose'/coin_type'/account'/{0,1}/i
matching the descriptors we import, with the purpose matching the
address type.

* Check mining fees of wallet-funded interactive txs

When funding an interactive transaction (dual funding or splice), we
let bitcoind select wallet inputs and add a change output. We verified
that the funding output and our outputs were preserved, but never that
the resulting mining fee was sane: interactive-tx validation only
enforces a lower bound on the feerate, and splices don't provide a fee
budget. A malicious bitcoind could thus select inputs worth much more
than needed and skip the change output: all checks would pass and the
difference would be paid to miners once we sign.

We now verify that the mining fee we pay stays close to the target
feerate before announcing our inputs to our peer, like we already do
for single-funded channels.

* Add max-funding-feerate configuration parameter

The feerate we use for funding and splice transactions comes from our
fee estimator, which relies on external data. Nothing bounded that
feerate, so inaccurate or malicious data could make us pay arbitrarily
high mining fees on every channel open or splice. Closing transactions
were already protected by max-closing-feerate.

We add a max-funding-feerate parameter (50 sat/byte by default) that
caps the feerate we use for funding and splice transactions. Operators
can RBF their transactions or increase this value and restart their
node if their transactions don't confirm when the mempool is congested.

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

More robust splicing edge cases (#3366)

We apply some defense-in-depth to better handle edge cases during
splicing where a remote peer doesn't follow the BOLTs. This also
includes more thorough pattern-matching, which protects against
future refactoring or new features from inadvertently introducing
a vulnerability related to splicing.

Co-authored-by: Fabrice Drouin <sstone@users.noreply.github.com>

Add optional rate-limit on incoming pre-auth connections (#3356)

Peers that open a connection but never complete the BOLT 8 handshake
consume resources on our node (memory, file descriptors and CPU).

We now bound how many of those we're willing to keep around, with an
eviction mechanism that lets honest peers eventually get connected.

Note that this only affects incoming connections: outgoing connections
are not rate-limited, which means that peers with whom we have channels
cannot be negatively affected by this mechanism since we'll actively
reconnect to them.

This isn't a foolproof DDoS protection at all however: attackers that
spam connection attempts can still severely delay or prevent honest
new peers from connecting. It should be coupled with a DDoS protection
layer at the cloud provider layer, where it is easier to do correctly
and more efficient.

Fix a batch of Tor-related issues (#3354)

* Verify that Tor cookie is 32-bytes

In order to be valid, a Tor cookie must be exactly 32 bytes.
We verify that and fail otherwise.

* Use Tor safe-cookie mode by default

And fail if password mode is used but the host is remote.

* Fix race condition in file permissions

There was a race condition in file permissions that allowed attackers
on the machine to read secrets, because we started by creating the
secret and only after that we set the file permissions.

We now reverse that flow: we create an empty file with the right
permissions and then write the secret to it.

This applies to our seed files and to tor private keys.

Reject messages that include the wrong type of signatures (#3368)

Signatures can either be standard signatures, for non-taproot channels, or partial signatures for taproot channels.
Here we reject messages that include signatures that don't match the channel commitment format.
This will fix an error where, for non-taproot channels, when our peer sends a message that contains a valid "single"
signature and an invalid "partial" signature, we would check the correct "single" signature, but store the invalid "partial" signature.

Add support for fulfillment payload (#3321)

This adds support for including a payload in `update_fulfill_htlc` that
the recipient encrypts for the payer. This can be useful to transmit
data atomically with the fulfillment of a payment. The main challenge
is that intermediate nodes may drop or tamper with this fulfillment
payload, which is why we include it in the HMACs of the attribution
data, which lets senders detect which pair of nodes may be malicious.

We limit error packets and fulfillment payloads to 32kB to leave room
for future TLVs. We silently truncate payloads that are larger, which
ensures that the messages we create are always compliant. We truncate
attribution data that doesn't have the expected length as well.

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

Explicitly match on-the-fly HTLCs after a restart (#3357)

When we restart our node, we look at HTLCs that have been received but
not relayed yet: they must be failed back, otherwise we would let them
in the incoming channel until their timeout is reached, which would
force our peer to force-close.

There is an exception for HTLCs that are paying for an on-the-fly funded
channel: we will explicitly retry relaying those HTLCs, even after a
restart, because that's how we get paid for the funding fees. We were
only matching them by `payment_hash`, which wasn't precise enough: an
attacker could initiate an on-the-fly channel and then send unrelated
HTLCs that use the same `payment_hash`, just to mess up with us and get
some of our channels force-closed.

We already have the detailed information about on-the-fly HTLCs in our
DB, so we now use that to match HTLCs on the corresponding `channel_id`
and `htlc_id`, which guarantees uniqueness.

Better documentation for remote `bitcoind` (#3359)

Our documentation didn't make it clear enough that `bitcoind` should
ideally run on the same machine as `eclair`. If that's not possible,
since `bitcoind` doesn't provide support for TLS for its RPC and ZMQ
endpoints, the node operator MUST setup a secure tunnel (providing
encryption and authentication) between `eclair` and `bitcoind`. If
that isn't provided, a network attacker may drop or alter messages
between `eclair` and `bitcoind`, which can lead to a loss of funds.

Fix several on-the-fly-funding bugs (#3351)

* Handle on-the-fly on-chain downstream failure post-restart

When restarting our node, we have a custom hook to avoid failing HTLCs
downstream when they're used with on-the-fly funding, because we want
to retry relaying those HTLCs. That doesn't apply to on-chain failures
though, because at that point the downstream channel has been closed.

* Don't relay on-the-fly HTLCs twice after restart

Before relaying on-the-fly HTLCs, we verify that they aren't already
being relayed. We only look at the pending changes, because once the
HTLCs are relayed we change their in-memory state in the Peer actor.

But if we restart after cross-signing on-the-fly HTLCs, we previously
would relay them again, thus paying the downstream user twice. We now
also look at the commitment transactions to avoid that.

* Force-close unpaid on-the-fly channels

When we fund an on-the-fly channel for which fees must be paid in the
follow-up HTLCs, our peer may act maliciously and ignore those HTLCs
when we relay them after funding the channel. We've already funded
the channel so it's too late to recover the on-chain fees we've paid,
so we previously just failed back the corresponding upstream HTLCs and
gave up on relaying them to the funded channel.

However, the HTLCs may already be cross-signed and pending on the funded
channel, which means that our peer could fulfill it and get paid while
we have failed the corresponding upstream HTLCs. In that case, we lose
funds. We can only fail the upstream HTLCs if we're sure that we haven't
relayed them yet,

Since obtaining this state is asynchronous and complex, we now opt-in to
a safer approach: we force-close the channel, check its commitments, and
only fail the upstream HTLCs that weren't relayed. If they have been
relayed, they will automatically be failed back when our HTLC-timeout
transaction confirms.

* Reject on-the-fly payment for batch of `payment_hashes`

While the protocol supports batching `payment_hashes`, we currently only
use it for one `payment_hash` at a time. It's thus safer to restrict it
to this to prevent potential abuse. We also explicitly reject the case
where an attacker tries to insert the same `payment_hash` twice to mess
up our state.

* Correctly relay preimages upstream after timeout

If we receive the preimage for an on-the-fly payment *after* the HTLC
has timed out, we still need to relay that preimage upstream, otherwise
we've paid downstream without being paid upstream.

Harden permissions of seeds and datadir (#3340)

Several improvements suggested by Loupe (#3348)

* Remove transport keys from DEBUG logs

While `DEBUG` logs shouldn't be activated on mainnet, it is dangerous
that they expose key material. We remove those logs.

* Remove onion shared secrets from unparsable failure logs

When receiving a failure that we couldn't parse, we added the shared
secrets in the logs to help us troubleshoot (because we've seen that
error frequently on our node). It didn't let us figure out the issue,
which most likely comes from a buggy intermediate or final node. We
now remove those secrets from the logs for safety.

* Make incoming connection tracker idempotent

If we receive multiple times a request to track a given node, we ignore
the redundant ones.

* More robust network DB clean-up on restart

On restart, we remove `channel_update`s that we cannot decode from our
network DB. The way the code was written could be an issue depending
on the postgres driver, because it potentially interleaved SELECT and
DELETE clauses. It apparently doesn't matter for our current version
of the postgres driver, but it's more future-proof to explicitly split
the SELECTs from the DELETEs.

* Check wake-up config before trying message wake-up

We didn't check the wake-up config parameter when relaying onion
messages, which wasted resources by creating actors that would be
useless.

* Include wallet node_id encoding when resolving blinded paths

When resolving the introduction point of a blinded path and checking
whether one of the nodes is ourselves, we must check that with all
potential encodings, including the wallet-reserved one.

* Don't include extraneous HTLCs in trampolinefee calculation

When relaying a trampoline payment, we must ensure that we don't include
extraneous payments (that are rejected), otherwise we will use a very
large route fee budget.

* Correctly clean up MPP payment-initiator state

When directly crafting MPP payments using the `sendtoroute` API, we
use the child payment ID as tracking key in the `PaymentInitiator`
internal state. If the payment fails, the `PaymentFailed` event will
correctly use that ID, so the state will be cleaned up. But if the
payment succeeds, the `PaymentSent` event uses the *parent* payment ID
so the state wasn't correctly cleaned up. We now clean up the child
state as well.

* Explicitly handle empty payment types

We've recently improved our liquidity ads codec, but we weren't
properly handling the case where no payment types are provided
(even though this will likely be rejected by remote nodes).

Multiple bug fixes found by AI scanning (#3346)

* Fix 0-fee commitments fee bumping with remote-main

When using 0-fee commitments, if our peer publishes their commitment
and our main output is large enough, we don't need to use a wallet
input to pay RBF fees, we can directly do it using our main output.

However, we didn't take into account the whole package weight when
doing so: this means that there was a balance range where we would
not correctly bump the commit tx to the target feerate.

* Retry transaction publishing on unclassified failures

We classify bitcoind publish failures by substring-matching the RPC
error message. Any rejection that doesn't match any of the RPC error
messages that we know would previously not be retried.

This was dangerous, as it could cause us to abandon a time-sensitive
transaction, which could cause loss of funds. We now eagerly retry
when we cannot classify the RPC publish failure.

* Fix `channel_ready` using invalid musig2 nonce if RBF

We must use `commitments1` instead of `d.commitments` when creating our
`channel_ready` message to ensure that we use the correct musig2 nonce
for taproot channels. Otherwise, if we have multiple RBF attempts and
the ony confirming is *not* the latest one, we will use the wrong nonce.

* Fix out-of-bound array access in payment FSM

Remote failures can be manipulated to trigger an out-of-bound array
access which crashes the payment lifecycle actor.

Correctly handle unknown flags in `channel_update` (#3341)

We previously ignored unknown `channel_flags` and `message_flags` in
the channel updates we received at decoding time, which means we would
always replace them by `0` when re-encoding the channel update before
forwarding it. If a flag that we don't understand was set to `1`, the
signature becomes invalid.

In order to be future-proof, we must preserve the values of unknown
flags during a codec round-trip: this way old eclair nodes will still
correctly relay future channel updates that contain flags that haven't
yet been specified.

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.

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.

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).

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.

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.

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.