When a peer is disconnected, the register will return a forward failure.
This can happen if the peer is connected when we start the payment FSM and
then disconnects before we send them an HTLC.
Obviously the route amount must be strictly positive.
We don't control htlcMinimumMsat (it is set by our peer) and for backwards
compatibility reasons we allow it to be 0 msat (even though it doesn't make
much sense), so we need to enrich our condition to detect empty channels.
We keep the GetRoutingState API available in the router as it's useful to
query network information locally (or between actors), but we stop sending
that data to remote nodes.
It's useful to separate channel state test methods in a dedicated trait
instead of always bundling it with `FixtureTestSuite`.
In particular, it was previously impossible to use both `BitcoindService`
and `StateTestsHelperMethods` because `BitcoindService` doesn't work with
fixtures (it leverages `beforeAll` and `afterAll` instead because launching
one bitcoind instance per-test would be too expensive and useless).
Front-end logs can produce a huge amount of logs, with significant
duplication. In order to reduce the log volume, we truncate `nodeId` and
`channelId` in the MDC to only keep the first 8 hexadecimal characters.
Also, override a few `toString` because some channel-queries-related
case classes produce huge strings.
This reduces the bandwidth used: it doesn't make sense to sync with every
node that connects to us.
We also better track sync requests, to reject unsolicited sync responses.
To ensure that nodes don't need to explicitly reconnect after creating
their first channel in order to get the routing table, we add a mechanism
to trigger a sync when the first channel is created.
The routing hint we get in a Bolt 11 invoice may be obsolete when we attempt
the payment: one of the nodes in the route may have updated his relay fees.
Since this affects a private channel that is not kept in the routing graph,
we need to update the routing hints before injecting them in the router.
This was already done in `PaymentLifecycle` with automatic retries, but when
using MPP we retried in the `MultiPartPaymentLifecycle` instead of inside
the `PaymentLifecycle`, so we need to handle routing hints updates there.
Clarify why we don't actively update channel relay fees when the default
values change in eclair.conf. It would override manual changes made via
the API which is bad.
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.
We now use a regular release zip, and use it in the awseb bundle.
The default logback configuration now logs to a file, like
`eclair-node`, and we use a dedicated logback configuration for AWS
beanstalk.
By default the front reads the node secret key from the node seed in
the standard `.eclair` directory.
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.
