If your peer uses unconfirmed inputs in the interactive-tx protocol, you
will end up paying for the fees of their unconfirmed previous transactions.
This may be undesirable in some cases, so we allow requiring confirmed
inputs only. This is currently set to false, but can be tweaked based on
custom tlvs or values in the open/accept messages.
When fee-bumping an interactive-tx, we want to be more lenient and accept
transactions that improve the feerate, even if peers didn't contribute
equally to the feerate increase.
This is particularly useful for scenarios where the non-initiator dedicated
a full utxo for the channel and doesn't want to expose new utxos when
bumping the fees (or doesn't have more utxos to allocate).
While it makes sense to assume that relayed payments will fail in the context of balance computation (meaning that we don't earn a fee), the opposite is true for payments sent from the local node, which will cause the full htlc amount to be deducted from the balance.
This way we are consistent: the balance computation is pessismistic and always assume the lowest outcome.
Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
This PR enables capturing and printing logs for tests that failed, and is compatible with parallel testing. The core idea is to use a different `LoggerContext` for each test (see [logback's doc on context selection](https://logback.qos.ch/manual/contextSelector.html)).
Actual capture and printing of logs is realized through the same technique as Akka's builtin `LogCapture` helpers, that is:
- a custom appender accumulates log events in memory
- a dedicated logger (defined in logback-test.xml and disabled by default) is manually called by the custom appender when logs need to be printed
I unfortunately had to introduce boilerplate classes `MyContextSelector`, `MySlf4jLogger` and `MyCapturingAppender`, the last two being tweaked versions of Akka's existing classes.
Note that the log capture is only enabled for tests that use `FixtureSpec`. The `ActorSystem` needs to be configured to log to `MySlf4jLogger`.
Advantages over existing technique:
- compatible with parallel testing
- no funny business with reflection in FixtureSpec.scala
- use configuratble logback formatting instead of raw println
- allows logging from lightning-kmp (depends on https://github.com/ACINQ/lightning-kmp/pull/355)
Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
We previously supported a 65-bytes fixed-size sphinx payload, which has
been deprecated in favor of variable length payloads containing a tlv
stream (see https://github.com/lightning/bolts/pull/619).
It looks like the whole network now supports the variable-length format,
so we can stop accepting the old one. It is also being removed from the
spec (see https://github.com/lightning/bolts/pull/962).
The test `ChannelCodecsSpec.backward compatibility older codecs (integrity)` uses reference json stored as text files. Depending on git settings and OS, the test may fail due to line ending differences.
We need to validate early that a `tx_add_input` message can be converted
into an `OutPoint` without raising an out of bounds exception.
We also fix a flaky test on slow machines.
Add support for bumping the fees of a dual funding transaction.
We spawn a transient dedicated actor: if the RBF attempt fails, or if we
are disconnected before completing the protocol, we should forget it.
Add more tests for scenarios where an unconfirmed channel is force-closed,
where the funding transaction that confirms may not be the last one.
When an alternative funding transaction confirms, we need to unlock other
candidates: we may not have published them yet if for example we didn't
receive remote signatures.
Once we've exchanged signatures for the funding tx, we wait for it to
confirm.
Note that we don't allow mutual closing an unconfirmed channel, but that
is also the case for single-funded channels. We can improve that in the
future if necessary, but it is more efficient to double-spend an unconfirmed
channel rather than mutual close it.
To match the latest changes in https://github.com/lightning/bolts/pull/765
at commit aed5518a80aade56218da87f92e0a39963b660cf
The main change was the introduction of the `payment_relay`,
`payment_constraints` and `allowed_features` tlvs, with small
additional codec updates.
Apply @rustyrussell's neat truncating integer arithmetic formula to
calculate the amount that should be forwarded by blinded path nodes
instead of our previous approximation.
It is now possible to specify a DNS host name as one of your
`server.public-ips` addresses.
DNS host names will not be resolved until eclair attempts to
connect to the peer.
See https://github.com/lightning/bolts/pull/911
After exchanging `open_channel2` and `accept_channel2`, we start building
the funding transaction.
We stop once we've generated our signatures for the funding transaction,
at which point we should store the channel in the DB (which will be done in
future commits).
Before eclair v0.6.0, we didn't store a mapping between htlc_id and htlc
txs, which made it tricky to correctly remove identical htlcs that used
MPP during force-close, when an htlc tx was confirmed.
We have added that mapping since then and released it more than one year
ago, so we can now safely remove that code.
We previously incorrectly pruned only once both channel updates were stale.
This was incorrect, we must prune channels as soon as one side becomes stale.
There are ~100 channels on the network today that have one inactive side,
while the other side regularly refreshes their channel update, but those
channels won't be usable for routing. They should eventually be closed,
but the active side is probably hoping for the inactive side to come back
online to get the opportunity to do a mutual close.
Following #2361, we reject channel updates that don't contain the
`htlc_maximum_msat` field. However, the network DB may contain such
channel updates, that we need to remove when starting up.
This is a follow up of #2264 where we refactor handling of channel updates
in failures coming from routing hints.
For failures in one of the routing hints, we use the node_id pair (source,
destination) instead of the short_channel_id to identify the edge.
We implement the first step of the dual funding protocol: exchanging
`open_channel2` and `accept_channel2`.
We currently stop after exchanging these two messages. Future commits will
add the interactive-tx protocol used to build the funding transaction.
Note on log capture:
- akka version (`... with LogCapturing`): only works when tests are run sequentially (that is: useless on CI), otherwise outputs of all test are mixed together
- my version: separate between tests, but ugly formatting, because akka's `StdOutLogger` dosen't use logback settings.
The specification is removing support for old channel updates that didn't
include an `htlc_maximum_msat` (https://github.com/lightning/bolts/pull/996).
Every implementation has been generating updates containing this field for
years, so we can safely reject updates that don't contain it.
When we have nothing at stake (channel was never used and we don't have
funds to claim), we previously directly went to the CLOSED state without
publishing our commitment. This can be an issue for our peer if they have
lost data or had a hard time getting a funding tx confirmed.
We now publish our commitment once to help them get their funds back in
all cases and avoid the CSV delays when getting their funds back.
Fixes#1730
We introduced a way to get a "light" payments view in #1225.
This was a performance improvement for mobile wallets embedding eclair.
Mobile wallets should now use lightning-kmp instead of eclair, so we can
get rid of that unused code.
The flaky test was `ZeroConfAliasIntegrationSpec`.`a->b->c (b-c private)`.
Due to a race between node watchers, we were sometimes entering into
this scenario between bob and carol:
1) carol's watcher wins the race and sends her `channel_ready` to bob
before bob has received `WatchFundingConfirmedTriggered` from his own
watcher
2) the channel isn't officially zeroconf, but bob gladly accepts carol's
early `channel_ready` and moves directly to `WAIT_FOR_CHANNEL_READY` and
then `NORMAL`, *without a real scid*.
3) bob ignores the `WatchFundingConfirmedTriggered` that it receives in
state `WAIT_FOR_CHANNEL_READY` or `NORMAL`
4) bob later receives the `WatchFundingDeeplyBuriedTriggered`, discovers
his own real scid and emits a `ShortChannelIdAssigned` event, but the
channel relayer only listens to `LocalChannelUpdate`.
5) subsequent a->b->c payment using a real scid for b-c as routing hint
fails because b's relayer doesn't know it.
There are two ways of fixing this:
a) make the relayer listen to `ShortChannelIdAssigned` (like it did before)
b) emit a `LocalChannelUpdate` event containing the new real scid and
the same `channel_update`.
In this commit, we chose to implement (b).
Co-authored-by: t-bast <bastuc@hotmail.fr>
We were using hints from `SendPaymentConfig.invoice` to populate `PathFindingExperimentMetrics`, but the invoice is optional and not populated for trampoline relay.
In `SendPaymentToNode`, the routing hints were present twice: once in `invoice` and once in `extraEdges`. I'm only keeping `invoice`.
Also make the `ExtraEdge` trait use `def` as there may be problems with `val`.
When a channel force-close without any pending htlcs, funds are not at
risk. We want to eventually get our main output back, but if we are not
in a rush we can save on fees by never spending the anchors.
This is disabled by default as there is a potential risk: if the commit
tx doesn't confirm and the feerate rises, the commit tx may eventually be
below the network's min-relay-fee and won't confirm (at least until package
relay is available).
We now use either our local alias or the real scid in the channel update
that we store internally. When we send that channel update directly to
our peer, we override it to use the remote alias when it makes sense.
The `override-init-features` field in `eclair.conf` was not previously
applied on top of the `features` field, so node operators were usually
copy-pasting their `features` overrides in every `override-init-features`.
The overrides are now applied on top of the base `features` configuration,
which makes it easier and more intuitive to configure per-node features.
* improve bitcoin client metrics
* only use batching bitcoin client for the watcher
* use named args for defaultFromFeatures method
* use default min_depth in edge case scenario
* add OutgoingChannelParams trait
* update amounts in ChannelRelayerSpec
* make register take typed replyTo
* improve codecs non-reg tests
Bolt11 uses routing hints to add extra edges for the path-finding, blinded routes are also extra edges added to the path-finding but they have a different format. The new type `ExtraEdge` is more flexible and can be expanded to cover new kinds of extra edges such as blinded routes.
If the current chunk of data read from the TCP connection only contains unknown messages (in particular, could be only one isolated unknown message on an otherwise idle connection), we never resumed reading on the connection.
This means all subsequent messages, including pings/pongs, won't be read, which is why the most visible effect is disconnecting due to no response to ping.
Related to https://github.com/ElementsProject/lightning/pull/5347.
Reported by @wtogami.
Since actors are initialized asynchronously, and the initialization sometimes involves subscribing to an `EventStream`, we don't know when they are ready to process messages, especially in tests, which lead to race conditions. By making actors publish `SubscriptionsComplete ` on the same `EventStream` they are subscribing to, we guarantee that if we receive `SubscriptionsComplete ` the actor has been initialized and its subscriptions have been taken into account.
Allow eclair to expose a metrics scraping endpoint for Prometheus
for users who don't want to rely on Kamon's hosted infrastructure.
Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
Create new database for each unit test instead of spawning a new db
instance.
Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
We can currently deduce the `channel_id` of a public channel because it
is based on the funding transaction coordinates, but that won't be the
case with dual-funding, where the `channel_id` will be private information
between the two channel peers.
We make it explicit that conversion from a string to an scid uses the tx
coordinates and can fail.
We also clean up compiler warnings in updated test files.
