Otherwise `ReplyShortChannelIdsEnd` may overtake announcements.
There is an exception for `AnnouncementSignatures` which is more a channel message than a routing message.
There are two issues:
1. because we forward commands *before* writing to disk in
`PendingRelayDb.safeSend` in order to reduce latency, there is a race
where the channel can process and acknowledge the command before the
db write. As a result, the command stays in the pending relay db and
will be cleaned up by the post-restart-htlc-cleaner at next restart.
2. in the general case, the channel acknowledges commands *before* it
writes its state to disk, which opens a window for losing the command
if we stop eclair at that exact time.
In order to fix 2., we introduce a new `acking` transition method, which
will be called after `storing`. This method adds a delay before actually
acknowledging the commands, which should be more than enough to solve 1.
I'm not sure we need that additional delay, because now that we
acknowledge the commands *after* storing the state, the channel should
lose the race most of the time.
These tests have been flaky because external APIs tend to be down or throttle
our calls. and we don't want our test suite to fail because of that.
In practice it's enough if developers run these tests locally once in a while.
When we query future blocks that bitcoinheaders.net doesn't have, instead
of returning a DNS resolve error, it returns a DNS response without a
block header.
We want to avoid logging it as an error, so we check for this specific case.
When the recipient is a direct peer, we can use the accurate knowledge
of our local channels instead of hard-coded MPP parameters to choose
the number of routes and the minimum route amount.
This change makes it possible to easily send all local funds in one
payment when we're directly connected to the recipient.
Plugins can now implement custom commitment schemes, different from specified ones.
This requires extra care when restarting a node, as some HTLCs may be in a broken state
and need to be failed upstream.
Plugins must identify these HTLCs and implement the right trait to provide these HTLCs to
the PostRestartHtlcCleaner, which will watch them and fail/fulfill them accordingly.
This test was randomly failing because of a race condition: we sometimes
sent the payment failure before the payment FSM asked for routes, so it
was ignored and the test could not progress.
Introduce a blockchain watchdog that fetches headers from multiple sources
in order to detect whether we're being eclipsed.
Use blockchainheaders.net, blockstream.info, blockcypher.com and mempool.space
as first sources of blockchain data. More blockchain sources can be be added
later.
When we have a trusted relationship with some of our peers (business
relations, family members, our own mobile wallet, etc) it makes sense to
relax the feerate mismatch constraint.
This must be done per-node, to avoid leaving the gates open for attackers.
The `supportedMandatoryFeatures` set made less and less sense as we start
supporting more features and allowing users to turn features on and off
depending on the peers they connect to.
Instead of `Peer` watching `PeerConnection`, we have `PeerConnection`
notify `Peer` when it dies. Not relying on a watch allows for harder
security settings when enabling akka cluster.
In the revoked commit tx case, both nodes are competing to claim the
HTLC outputs from the commit tx.
The test incorrectly assumed that node F would always win that race.
When a channel gets confirmed while nodes are disconnected, recent lnd
nodes sometimes fail to send their channel_reestablish message and instead
send a funding_locked first (due to a race condition on their side).
When that happened, the channel stayed stuck in the SYNCING state.
To avoid that, we trigger a reconnection until the race condition is eventually
won by the channel_reestablish.
There is no good reason to completely disable `var_onion_optin` and it can
even be harmful: pending HTLCs after a restart may be lost if they used a
variable-length onion, causing a loss of funds and potential channel closes.
We were calling `nodeParams.features` from inside the channel, which is
problematic because we may have overridden those features for specific
peers. This is now fixed.
* Send payment through specific channels
While `sendtoroute` was letting you provide a custom route as a list of
nodes, it made it difficult to have fine-grain control over the channels
used by payments.
The API now allows choosing the exact channels that will be used for the
payment; in particular, this will be helpful when consolidating and
rebalancing multiple channels to a given node.
Fixes#1472
* Fix serialization regression
#1520 introduced a regression in the serialization of channel data,
impacted the `channels` and `channel` APIs.
We restrict the custom command response serializer to revert to the
previous behavior.
Features are now provided by the `switchboard`, in response to the
`PeerConnection.Authenticated` message.
The `switchboard` will also decide whether or not we sync with that
peer, depending on the `syncWhiteList` configuration.
* [ChannelRelayer] Expose Wrapped messages to tests
Exposing the private wrapped messages to tests allows removing the
dependency on capturing logs which felt very brittle.
* Prioritize low capacity channels during relay
This makes it more difficult for attackers to "squat" high-capacity channels
by sending HTLCs and then hodling them.
It results in less locked liquidity during this kind of attacks.
When using MPP, if we can't find a route, we need to add an entry to the
DB. Otherwise when users query their payment status, nothing will be
returned which is a bad UX.
Fixes#1512
We were previously only counting the additional HTLC at twice
the current feerate.
An HTLC in isolation doesn't make much sense: the feerate
applies to the whole commit tx. Our fee buffer needs to account
for a x2 feerate increase on the commit tx + an additional htlc.
Note that this introduces another subtlety. The commit tx fee at twice the
current feerate may actually be lower than the commit tx fee at the current
feerate (if the commit tx contains many htlcs that are only slightly above
the trim threshold).
Don't swallow bitcoind exceptions: we wrap them but preserve the
original one.
Allow configuring bitcoin core wallet: it makes sense to allow users
to use a different wallet from the default one.
There's one important caveat: once set, users shouldn't change it while
they have open channels. We mention it clearly in the documentation.
Fixes#1538
Send basic channel events to websockets listeners:
* Channel open initiated
* Channel state change
* Channel closed
We only send basic, high-level data about these events.
If the listener is interested in details, it should call the `channelInfo`
API to get all of the channel's data.
Fixes#1509
This change makes `IntegrationSpec` an abstract class trait that defines
common utilities used in most integration tests, and splits the actual tests
in two separate files that extend that class. Channel tests have themselves
been split between standard and anchor commitments to gain extra
parallelism.
The tests themselves aren't changed at all, except for the TCP ports they
use, and to remove nodes that have become useless in each of the specs. `expectMsg`
have been increased to 60 seconds to account for the increased parallelization.
Some tests have been refactored, cleaned up and block expiries have been reduced.
