* Type fee rates info
Fixes#1188
* Fix vsize comment
This is an alternative to #1425.
This may not correctly represent what Bitcoin Core does, it's likely that
we can in fact use a value smaller than 253, but this shows how we choose
to err on the side of safety with that calculation.
* Add 1008 feerate block target
Fixes#1486
It can be useful to sign arbitrary messages with the key associated with our node_id (to prove ownership of a node).
Adds 2 new API commands:
eclair-cli signmessage --msg=${message}
eclair-cli verifymessage --msg=${message} --sig=${signature}
We previously refused to relay HTLCs that would result in a low expiry
delta for the next node. However it's not our decision to make, it's the
remote's. We should forward these HTLCs and let the remote decide whether
they fail them because the expiry is too close or fulfill them.
Allow activating anchor outputs and have fully operating channels
during normal operation (open, add/fulfill/fail htlcs, close).
Interop testing has been done with lnd, and there is only one pending
issue during mutual close, where they incorrectly compute the closing
amounts, which they should fix soon.
However, anchor outputs should NOT be activated yet as unilateral
close scenario are not fully handled yet.
We don't do any kind of automatic fee bumping either; this will be done
later, once we have PSBT support and once bitcoind offers the
`psbtbumpfee` RPC (see bitcoin/bitcoin#18654).
* allow to explicitly disable features from configuration
* improved Features.toString
* explicitely disable unlisted features
Co-authored-by: pm47 <pm.padiou@gmail.com>
Watching the blockchain is an asynchronous task, so it is "always late"
and it doesn't matter if we don't synchronously set the watch back when
the node is restarted.
It allows us to smoothen the load if needed at startup, because setting
tens of thousands of `watch-spent` all at once at startup is pretty
expensive.
Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
* Activate wumbo by default
This is safe as `max-funding-satoshis` is set to 16777215 sats, which is
the non-wumbo limit.
If users want to increase the maximum channel size, they can update this
configuration value.
* Update default minFinalCltvExpiryDelta
See https://github.com/lightningnetwork/lightning-rfc/pull/785
* Set minFinalCltvExpiryDelta in invoices
Our default fulfill-safety-window is now greater than the spec's default
min-final-expiry-delta in invoices, so we need to explicitly tell payers
what value they must use.
Otherwise we may end up closing channels if a block is produced while we're
waiting for our peer to accept an UpdateFulfillHtlc.
* Introduce transaction commitment format trait
This lets us re-use most of our existing transaction utilities for
anchor outputs.
Channels will always use the default commitment format (current spec),
but we will be able to change that by setting the `ChannelVersion` to
something appropriate for anchor outputs (and later other commitment formats).
* Clean up transaction tests
Remove obsolete claim-htlc tests: they used a different format from what
lightning uses and are redundant with existing tests in TransactionsSpec.
Add missing test cases in TransactionsSpec.
* Implement anchor outputs commitment transaction
Add support for creating an anchor outputs commitment transaction,
without any HTLC.
Support for the new HTLC format will be added in a separate commit.
* Refactor TestVectorsSpec
For anchor outputs, some values will not match the hard-coded ones.
We will instead need to read from the test vector.
* TestVectorsSpec filter unimplemented anchor outputs
Anchor outputs isn't fully implemented yet, so we need to ignore the tests
that are currently not passing.
* Implement anchor outputs HTLC transactions
Add support for HTLC transactions with a 1-block relative delay.
Add missing anchor outputs spec tests.
Add missing tests for some revoked paths.
* Always subtract both anchors from funder amount
For simplicity's sake, we always subtract both anchors from the funder's
main output, even if only one anchor materializes.
Shuffle methods around between ExtendedBitcoinClient and
BitcoinCoreWallet to help readability and separate concerns.
Add some documentation and fix harmless warnings.
Add bitcoin client tests.
* Non blocking bounded mailbox for backup handler
Akka 2.4 introduced a non-blocking unbounded mailbox.
It makes sense to upgrade the backup handler to that mailbox type.
We also add some backup-related metrics.
* Wrap DB calls to record metrics
We record the number of times each operation is executed and its
duration.
When we receive an `UpdateFulfillHtlc` from a downstream channel, it is
critical that we don't lose it because that is what allows us to pull
funds from the corresponding upstream channel(s). But this(ese) upstream
channel(s) may very well be currently OFFLINE and unable to update the
commitment right away, so we need to remember it for later. Same applies
to an `UpdateFailHtlc` (although it is less critical), because we don't
want the upstream htlc to timeout and cause a channel to force-close.
We were previously relying on a `CommandBuffer` actor, that uses a
"pending relay" database to store commands. Once the command is processed
by the target channel, it sends back an acknowledgment to the
`CommandBuffer`, which then removes the command from the database.
Unacknowledged commands are replayed at each reconnection or app restart.
This works well, but the flow is a little cumbersome and not easy to
understand.
With this PR, the sender (channel, payment handler, ...) is responsible for
storing commands to the pending relay db, instead of the command buffer,
which is completely removed. The target channel will acknowledge the
message and remove it from the pending relay db.
In the end, the logic is the same as before, we have just dropped the
intermediate `CommandBuffer`.
* Split feerate mismatch configuration
We want to be much stricter with feerates that are below our estimation
than feerates that are above it.
This also makes this configuration parameter easier to understand
for end users.
* Tolerate feerate mismatch while channel is unused
We can relax the conditions where we close a channel because of a feerate
mismatch: when the channel has no pending HTLCs, it's ok to temporarily
disagree on the feerate.
While we disagree on feerates, we don't use this channel to offer outgoing
HTLCs. If we receive an incoming HTLC, we have to close the channel because
that HTLC would be at risk (incorrect feerate).
This mechanism gives us time to adapt to feerate changes, hopefully reducing
the amount of unnecessary channel closures.
The channelstats API only returns results for the *outgoing* channels
used when relaying. We must also include the *incoming* channels, otherwise
it looks like they're inactive which doesn't reflect their real usage.
Fixes#1465
- Test was not executed (because the "tests" variable was an iterator that was emptied by the call to .size())
- HTLC regex had to be updated to skip over the HTLC number that was added to the reference test vectors
* Add metric to track onion payload format
This will be useful to decide when we can safely phase out support for
the legacy format.
* Add metric to track htlcs in flight
We track both the number of HTLCs and their amounts.
We track this at the channel level and globally.
If all trampoline retries fail, we should convert the error to a route
not found. We tried multiple fee targets and none of those was enough to
allow the trampoline node to find a satisfying route.
MPP lifecycle shares preimage as soon as received.
This allows removing the use of the node-relayer as a passthrough for
fulfills, it can now simply listen to this event.
Long term, this could be sent to the event stream to share with more actors.
* PaymentLifecycle cleanup
Remove temporary hooks added for first version of MPP (route prefix,
empty routes, etc).
Allow specifying the whole route (not only nodeIds) in SendPaymentToRoute.
* Rework MultiPartPaymentLifecycle
Use the Router's new MPP RouteRequest.
Remove the "blind" split based on channel balances.
Reactivate trampoline relay to MPP non-trampoline recipient.
* Add MPP payment metrics
* Activate MPP feature by default
This provider will save the feerates retrieved by another provider to
database.
This feature can be used to retrieve the last used feerates when starting
the node, which will save time. This can have a significant effect on nodes
running with a slow connection (e.g. mobile devices).
Note that this commit does not affect the current setup and does not
actually create the database, the feature must be implemented separately.
Fixes#1447
Legacy codecs are isolated in a separate file, with a visibility restricted to "package" in order to reduce the risk of using those codecs. Also codecs are restricted to `decodeOnly` for the same reason.
* localPaymentBasepoint->staticPaymentBasepoint
Use `getOrElse` on the option value to decide between static/dynamic
payment point, instead of the `ChannelVersion` bit.
* define explicit method to test channel features
Also reduce visibility of a few members of `ChannelVersion`, and some
cleanup.
* use `if/else` instead of `match` for version bit
Leverage Yen's k-shortest paths and a simple split algorithm
to move MPP entirely inside the Router.
This is currently unused, the multipart payment lifecycle needs
to be updated to leverage this new algorithm.
We go to the `CLOSING` if and only if the funding tx has been spent by
one transaction. The `require` is absolutely necessary. We could
probably enforce this constraint at the compilation level by more clever
typing but that's another matter.
It should return stats for all channels (funder and fundee).
The previous code was incorrectly filtering on channels for which we paid
an on-chain fees, excluding the channels for which we were fundee.
Fixes#1449.
Light clients don't always validate channels by fetching the blockchain tx.
That means they don't have access to the exact capacity.
When that happens, we can fallback to htlc_maximum_msat if
available, or to a default capacity (otherwise path-finding will ignore
these edges).
When we announce a new public channel, make sure we don't override the
balance information with None.
Clean up IntegrationSpec warnings.
Fix PaymentLifecycle test: this test was broken by the recent changes in
BaseRouterSpec.
* Electrum client: downgrade log-level for errors that happened before a proper handshake
We only care for errors that we received during or after the "handshake" (i.e. the exchange of "version" messages).
Other errors cause by dead/unresponsive servers... which are very common on testnet just add spams to the logs.
* Electrum client pool: downgrade log level for errors with our secondary servers
We care for errors with our master electrum servers.
* Update Electrum checkpoints
Move the maximum fee computation outside of `findRoute`: this should be
done earlier in the payment pipeline if we want to allow accurate fee control
for MPP retries.
Right now MPP uses approximations when retrying which can lead to payments
that exceed the maximum configured fees. This is a first step towards
ensuring that this situation cannot happen anymore.
* Replace ArrayDeque by Queue
This is clearly not a hot path. This collection will have less than
10 elements and the bottleneck is rather on the dijkstra call.
ArrayDeque doesn't exist in Scala 2.11 so it makes the merge to
eclair-mobile more cumbersome.
* Use standard Scala collections in Dijkstra
Collections performance has improved greatly in Scala 2.13.
This change yields a consistent 10% improvement compared to the previous
implementation on my laptop based on the mainnet graph.
Both `Client` and `TransportHandler` were watching the connection actor,
which resulted in undeterministic behavior during termination of
`PeerConnection`.
We now always return a message when a connection fails during
authentication.
Took the opportunity to add more typing (insert
deathtoallthestring.jpg).
