* Update code dependencies
I also wanted to update logback, but I'm hitting issues because of our
custom logger in `FixtureSpec` (`LoggingEventAware` not found).
* Update build dependencies
We're now using mvn 3.9.2 to build eclair, which reports warnings in some
of the build plugins we use. Updating plugins fixes most of the warnings,
and the remaining warnings have to be fixed by the plugins themselves
to support mvn 4.x.
After exchanging `tx_complete`, we validate the splice transaction before
sending our `commit_sig`. If we consider the transaction invalid, we send
`tx_abort`. But if our peer thinks the transaction is valid, they will send
their `commit_sig`, which we must ignore until they've acked our `tx_abort`.
Test assumes that payments inserted in the db will be returned in a deterministic order because they have different timestamps.
It may not always be the case if TimestampMilli.now() returns the save value twice.
So here we use explicitly different timestamps: now = TimestampMilli.now(), now + 1.milli, now + 2.milli ....
The previous repository we used removed the binaries for mvn 3.9.2, which
broke our docker build. It looks like `archive.apache.org` keeps artifacts
longer and hopefully won't break our docker build again soon.
When restarting, we weren't checking whether it was using blinded paths.
If we were an intermediate node in the blinded path, we were incorrectly
returning a normal failure: it should be ok, since the introduction node
is supposed to translate those failures, but it's safer to assume that
they don't.
For fighting jamming attempts, or even just to detect one, we need to know how fast relayed HTLCs are fulfilled. We now measure this and store it in the audit database. Previously the "IN" and "OUT" directions for the same HTLC were storing the same timestamp (corresponding to when the HTLC is fulfilled), we now use the timestamp at which we received the UpdateAddHtlc for the "IN" direction.
Move away from the "block target" approach.
Get rid of the `FeeEstimator` abstraction and use an `AtomicReference` to store and update the current feerates, similar to the block count.
When sending a message, the postman can now ask the router to find a route using channels only.
The same route is also used as a reply path when applicable.
The graph data structure has been updated to include both active and disabled edges.
The graph now contains features for vertices.
It turns out that #2688 broke the JSON serialization of the `channels`
API by introducing a new `ActorRef`. We never want to surface `ActorRef`
in JSON responses, so we're defining serializers to filter them out.
Co-authored-by: Fabrice Drouin <sstone@users.noreply.github.com>
The `Peer` actor can now directly be queried for the list of its channels.
This makes this feature more reusable than the previous actor that was
customized for the peer-ready scenario.
The spec says that we must return an error if:
- cltv_expiry < outgoing_cltv_value
- cltv_expiry < current_block_height + min_final_cltv_expiry_delta
For the second check, we actually tested if:
- cltv_expiry < max(outgoing_cltv_value, current_block_height) + min_final_cltv_expiry_delta
But that check should only verify that our `min_final_expiry_delta`
requirement is fulfilled, which is unrelated to the `outgoing_cltv_value`.
It was redundant with the first check, which already guarantees that
intermediate nodes inside the blinded path cannot cheat by using a higher
`cltv_expiry_delta` than what the recipient intended.
In cluster mode, outgoing connections are initiated by frontend nodes.
If there are no frontend node available, we fail the connection attempt
with a dedicated error.
The `initial-random-reconnect-delay` should be configured to allow
enough time for the front nodes to bootstrap at reconnection.
When initializing the DB, we potentially run some data migration that
cannot be reverted. We want to this last, after we've checked every other
start-up requirement, such as the bitcoind version.
Fixes#2609
LND and CLN already use 2016 blocks. The network is generally raising the
values of `cltv_expiry_delta` to account for high on-chain fees, so we'll
need to allow longer maximum deltas to avoid rejecting payments.
When we want to add new types of inputs/outputs that contain specific
tlvs, we will need to store them alongside standard inputs/outputs.
We will use traits and case classes inside `InteractiveTxBuilder`, and
need to thus add a discriminator when encoding them.
This RPC allows to access the historic channel data without
relying on third party services like LN explorers.
Note that when the `remoteNodeId` filter is not provided, this
query may be expensive on nodes with a lot of closed channels.
In theory we don't have to store their commit_sig here, as they
would re-send it if we disconnect, but it is more consistent with
the case where we send our tx_signatures first.
Previous implementation had the advantage of being all in one place, but it left holes:
- `last_connected_timestamp` was only set after the first disconnection
- in some corner cases the `closed_timestamp` was never set (nothing at stake, funding tx timeout, post-restart)
If we force-close with HTLCs that have just been signed by our peer but
for which we haven't received their revocation, we should ignore them.
We have not relayed those HTLCs so they can't be fulfilled. It is our
peer's responsibility to claim them on-chain (using their HTLC-timeout),
but if for some reason they don't claim it, we don't want the channel to
be stuck in the closing state.
Fixes#2669
The on-chain feerate can be arbitrarily high, but it wouldn't make sense
to pay more fees than the amount we have at risk and need to claim
on-chain.
We compute an upper bound on the fees we'll pay and make sure we don't
exceed it, even when trying to RBF htlc transactions that get close to
their deadline.
When performing a mutual close, we initially rejected fees that were
higher to the commit tx fees. This was removed from the specification
for anchor output channels, and doesn't make a lot of sense for standard
channels either: even at a higher fee, it makes sense to do a mutual
close to avoid waiting for relative delays on our outputs.
Fixes#2646
Bolt 2 requires the receiver of an HTLC to pay able to pay the commit tx
fee while maintaining its channel balance. This is an issue because it
can lead to a situation where the peer that has most of the channel's
funds is unable to send outgoing payments: the channel is stuck.
From the receiver's point of view, it's ok to dip into the channel reserve
as long as we're able to pay the commit tx fee, so we should accept those
HTLCs. Moreover, if those HTLCs are failed, we'll go back above our
channel reserve, and if those HTLCs are fulfilled, that will increase our
balance which guarantees we're above our channel reserve.
According to the spec, option_onion_messages signals that the node can forward onion messages which is different from being able to send or receive them (there is no feature bit for that).
We now allow nodes with this feature disabled to still receive messages and remove the NoRelay relay policy as it is redundant.
It seems like lnd sends this error whenever something wrong happens on
their side, regardless of whether the channel actually needs to be closed.
We ignore it to avoid paying the cost of a channel force-close, it's up
to them to broadcast their commitment if they wish.
See https://github.com/lightningnetwork/lnd/issues/7657 for example.
We were creating an index on the `remote_node_id` based on the channel's
JSON serialization, which isn't very robust. The data model changes for
splicing have changed the JSON format and thus broken that index.
We now use and explicit DB column for `remote_node_id`.
We add a `cpfpbumpfees` API that lets node operators bump the fees
of a package of unconfirmed transactions.
Node operators can for example ensure their funding txs confirm before
they hit the `2016` funding timeout. It's also very useful when you have
a long chain of unconfirmed funding transactions and/or mutual close
transactions and want to bump them all at once.
NB: the node operator needs to figure out which outpoints belong to him
(which should be fairly easy using existing APIs).
Included doc folder in the assembly zip. ** wildcard indicates all the files in the current folder and all the files in the subfolders of the current folder.
Fixes#1645
