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.

Back to dev (#3379)

After the v0.14.3 release.

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>

Tor: allow password auth on private networks (#3375)

This is a follow-up to #3354: we allow using a password on private networks. It is useful in cluster deployments.

Back to dev (#3371)

After the v0.14.2 release.

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.

Force-close on invalid HTLC `cltv_expiry` (#3367)

Bolt 2 specifies that if tje sending node sets `cltv_expiry` to greater
or equal to 500000000, we should send a warning and close the connection
or send an error and fail the channel. We never implemented that, which
was fine because we already rejected large `cltv_expiry` before that
threshold (without force-closing), but it's better to explicitly force
close if our peer is sending such invalid values.

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

Fix a batch of low-severity issues (#3355)

* Remove explicit cast in channel codec

We used an explicit cast in our channel codec: this is safe for data
that we created ourselves, but would throw an exception if our data is
corrupted. It's trivial to be safe by removing the cast.

* Require `tls-tcp` when using cluster mode

We require that encryption is used between the front and backend nodes
in cluster mode, otherwise private data would be exposed. This protects
node from messing up their deployment configuration without realizing
it.

* Remove exception details from failed RPCs

We don't return the exception message anymore for failed RPC calls, to
avoid potentially leaking private information. This guarantees that only
the node operator, with access to the logs, can see why RPC calls fail.

* Don't decode unknown onion message TLVs

We don't support any TLV for onion messages yet. Since onion messages
can be spammy, we don't need to waste any ressources trying to decode
unknown TLVs that we'll throw away anyway.

* Limit the number of onion messages self-hops

We only include ourselves multiple times in an onion message path when
using dummy hops. If we're included too many times in a path, that's
most likely a remote node messing with us: we just drop the message.

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.

Improve liquidity ads codec performance (#3344)

* Improve liquidity ads codec

We improve the performance of the liquidity ads codec by ignoring
unknown payment types, and simply checking whether the payment types
we support are activated or not.

* Reject node_announcement with invalid liquidity TLV

If the liquidity ads TLVs is present but with empty fields, we fail to
correctly re-encode it. We must reject it immediately instead.

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.

Back to dev (#3339)

After the v0.14.1 release.