Eclair

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.

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.

Allow reply-less pings (#3284)

BOLT1 says:

```
A node receiving a ping message:
- if num_pong_bytes is less than 65532:
- MUST respond by sending a pong message, with byteslen equal to num_pong_bytes.
- otherwise (num_pong_bytes is not less than 65532):
- MUST ignore the ping.
```

These reply-less pings are used to insert cover traffic to thwart
network-level traffic analysis. We wanted to allow them in #3278
but we missed this ping flood protection that needed to be updated.

We also had an off-by-one in the maximum pong length that
is now fixed.

Add backwards-compatible parts of the official splicing protocol (#3261)

* Add `funding_txid` to `commit_sig`

In https://github.com/lightning/bolts/pull/1160 we add a TLV field to
`commit_sig` messages to let the receiver know to which `funding_txid`
this signature applies. This is more resilient than relying on the
order of the `commit_sig` messages in the batch. This is an odd TLV,
so we can start writing it right now without creating compatibility
issues.

We also slightly refactor existing code to make it easier to introduce
a backwards-compat layer when migrating to the official splicing. We
also increase the default number of RBF attempts allowed.

* Insert a `start_batch` message during splices

In https://github.com/lightning/bolts/pull/1160, we introduce a message
to let our peer know how many `commit_sig` messages they will receive
and treat them as a batch. This replaces our previous version that did
something similar, but by adding a batch TLV in every `commit_sig`
message we send.

We currently do both: we keep inserting the experimental batch TLV, and
we start by sending a `start_batch` message (with the same information).
Since it is an odd message (127), it should be safely ignored if our
peer doesn't understand it.

Add fuzzing infrastructure (#3276)

Add a fuzzing module based on Jazzer to allow fuzzing parts of eclair.
This commit includes fuzz tests for codecs to be used as examples.
It is a separate module (minimal interaction with the other modules).
We include helper scripts to run many fuzz tests in parallel or generate
reports.

Use bitcoin-lib 0.47 (#3268)

* Use bitcoin-lib 0.47

* Add checksums for secp256k1-kmp 0.23.0

* der2compact() and compact2der() methods have been removed, new signInputCompact() method has been added

* Use Transaction.encodeWitnessEcdsaSig() instead of low-level calls

* Replace local der() methode with bitcoin-lib's encodeWitnessEcdsaSig()

Close connection when receiving malformed messages (#3273)

When receiving a message that we're supposed to be able to decode, for
which decoding fails, we must send a warning and close the connection.
This ensures that the connection state cannot become corrupted, which
may otherwise happen if we fail to deserialize a `commit_sig` message
(for example) and simply ignored it while continuing to process the
next messages.

Fixes #3271

(Minor) Upgrade postgres libs (#3238)

Upgrade the jdbc driver to the latest version.

Add duration information to payment events (#3241)

We now record start and end time for payment events, and for remote
failures, which lets us easily identify slower paths and faulty nodes.
We properly track the settlement of each individual payment now.

We also clean-up field names and harmonize those events. Note that we
don't update the DB schema at that point: this will be done in another
PR that batches all DB schema changes.

Use bitcoin-lib 0.46 (taproot tweak refactor) (#3225)

* Use bitcoin-lib 0.46 (taproot tweak refactor)

* Update eclair-core/src/main/scala/fr/acinq/eclair/transactions/Transactions.scala

Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>

Identify failing node by its index (#3224)

When a HTLC is failed remotely, the failing node was previously identified by its node id.
However this is not enough if the same node appears multiple times in the payment route, for instance for circular rebalancing.
We now identify the failing node using its index in the payment route.

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.

Nits (#3203)

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.

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.

Use bitcoin-lib 0.44 (#3185)