We were extracting F's commit tx from its internal state right after receiving
the `PaymentSent` event. The issue is that this could happen before the fulfill
was completely signed on both sides, so the commit tx we obtained would still
contain the HTLC and would be different from the one F would publish when
closing.
Actor names cannot conflict.
Even though blockchain watchdog actors stop themselves after fetching block
data, when blocks are found in a short interval, we may end up with multiple
actors of the same type simultaneously alive, so we need them to have
unique names.
The blockcount isn't sufficient to make their names unique because forks
can happen.
Fixes#1665
We had a delay mechanism before re-enabling reconnected channels
to avoid creating frequent channel updates on flappy connections and flooding
the network with unnecessary gossip.
We don't need this protection for private channels since they're not gossiped
to the rest of the network. And in the case of private channels to mobile
wallets, we don't want to add any delay, otherwise the reconnected channel
will not be in the router's graph and we'll have issues routing payments to
that wallet (especially if they quickly disconnect, before our 10-seconds
delay).
When a channel goes to the CLOSED state, the actor will stop itself.
We were previously sending messages to the actor asking for its state,
which returns a failure when the actor is stopped. We can simply listen
to state events to safely get the same result.
Electrum can return unconfirmed txs in an address' history. When that
happens, we should not try to fetch its confirmed position, it will
return an error.
We simply need to ignore these events and wait for the tx to confirm.
When a revoked commitment is published, we didn't correctly settle pending
HTLCs, which could lead to upstream channel closure.
This would not cause a loss of funds (especially since we would gain
funds from the revoked channel) but it's a temporary liquidity loss that
we'd like to avoid.
* move and rename fee provider parameters
* set the min-feerate to 1 sat/byte
This only affects the value returned by fee providers, it is
overriden by the other bitcoin-core enforced minimum (currently 253
sat/kiloweight).
The router can return local channels, with all necessary information to
build routing hints from these channels.
It's not eclair-core's responsibility to choose what channels to use in
routing hints: this is really a wallet strategy, so each wallet should
have its own heuristics to choose what channels to include (if any).
It can be useful to override the default relay fees when opening channels
to specific nodes.
Note that these initial relay fees are not persisted in the DB. That means
that if your node reboots before the funding transaction confirms, the
channel will be opened with the default relay fees, not the overridden values.
Fixes#1507
This commit contains several changes related to on-chain fees:
* Retrieve the minimum fee required to enter our mempool
* Add a metric to track this value
* Remove fallback fee providers when Bitcoin Core is used
* Add a metric to track feerate retrieval errors
For fallback fee providers that don't have any mempool information, we
default to the 1008 block target. It doesn't matter as these fee providers
will not be used anyway.
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.
