Note that balance events are logged at most once every 30s, and only when
the balance actually changes (e.g. won't log if a payment is failed).
Also, only send `AvailableBalanceChanged` when needed.
We were sending this event everytime we sent a `commit_sig`, which is
incorrect because our balance doesn't change if, say, we are signing an
incoming htlc.
Note that we only send this event in `NORMAL` state, not in `SHUTDOWN`
state, because the balance is not really _available_ in the latter.
This includes support for hosting onion services, and connecting to them, which are two separate things:
- Opening an onion service implie interacting with the tor daemon controller, which requires authentication. We support both `SAFECOOKIE` and `HASHEDPASSWORD` authentication mechanisms, with a default to `SAFECOOKIE`. We support v2 and v3 services, with a default to v3 as recommended by the tor project.
- Connecting to onion services requires tunnelling through tor's local SOCKS5 proxy.
Incoming and outgoing tor connections are thus separate matters that needs to be configured independently. A specific documentation has been added to guide users through these steps.
Big thanks to @rorp for doing the heavy lifting on all this!
While it makes sense to exclude from the routing table channels for
which there is a spending tx in the mempool, we shouldn't blame our
peers for considering the channel still opened if the spending tx hasn't
yet been confirmed.
Also, reworked `ValidateResult` with better types. It appears that the
`NonexistingChannel` error wasn't really useful (a malicious peer would
probably point to an existing funding tx, so there is no real difference
between "txid not found" and "invalid script"), so it was replaced by
`InvalidAnnouncement` error which is a more serious offense (punished
by a disconnection, and probably a ban when we implement that sort of
things).
* Make route randomization optional (enabled by default), option is exposed in SendPayment/RouteRequest
* Fix non deterministic behavior in IntegrationTest
* relay to channel with lowest possible balance
Our current channel selection is very simplistic: we relay to the
channel with the largest balance. As time goes by, this leads to all
channels having the same balance.
A better strategy is to relay to the channel which has the smallest
balance but has enough to process the payment. This way we save larger
channels for larger payments, and also on average channels get depleted
one after the other.
* added tests...
...and found bugs!
Note that there is something fishy in BOLT 4, filed a PR:
https://github.com/lightningnetwork/lightning-rfc/pull/538
Also, first try of softwaremill's quicklens lib (in scope test for now)
* minor: fixed typo (h/t @btcontract)
This is a simple mechanism to test our direct peers by sending fake
small payments to them. A probe is considered successful if the peer
replies with an `UnknownPaymentHash` error.
Probing is configurable and disabled by default.
We use Yen's algorithm to find the k-shortest (loopless) paths in a graph, and dijkstra as search algo.
We then pick a random route up among the cheapest ones.
* Improved amounts readability (fixes#542) and added the Bits unit
denomination in the documentation
* Improved channel panel UI layout
* Added a confirmation dialog when closing a channel, with a short summary
of the channel to be closed
The balance bar has been shrunk in size so that it should not be mistaken as
a separator element between channels. The channel's balance, capacity and
peer node id are now more visible. Also added the short channel id to the
channel's pane.
fixes#690
* Added node's aggregated balance in the status bar
fixes#775
* Support searching backward from the target
* Use the amount+fees with testing for min/max htlc value of edges
* Build the adjacency list graph with incoming edges instead of outgoing
* Make sure we don't find routes longer than the max allowed by the spec
* Remove default amount msat, enhance 'findroute' API
* Optimize tests for ignored edges in Dijkstra
* Enhance test for max route length, fix the length to 20 channels
* Add test for routing to a target that is not in the graph (assisted routes)
* Correctly parse short channel id
* Add test for RPC APIs
* Put akka.http.version in parent project pom
Co-Authored-By: araspitzu <a.raspitzu@protonmail.com>
* Implement "GetHeaders" RPC call
* Add checkpoints and pow verification
* Don't resolve server address too soon
* Add testnet checkpoints
* Store headers in a sqlite wallet db
* Use 1.4 protocol
Request protocol version 1.4 (this is the default setting in Electrum wallet).
Retrieve and store all headers as binary blobs in bitcoin format.
* Insert headers in batch
* Optimize headers sync and persistence
We assume that there won't be a reorg of more that 2016 blocks (which
could be handled by publishing a new checkpoint) and persist our headers
except for the last 2016 we have received: when we restart, we will ask
our server for at least 2016 headers.
* Persists transactions
Transactions are persisted only when they've been verified (i.e. we've receive
a valid Merkle proof)
* Disable difficulty check on testnet and regtest
On testnet there can be difficulty adjustements even within a re-targeting window.
* Update checkpoints
* Use proper Ping message
`version` can not longer be sent as a ping as we did before.
* Don't ask for Merkle proofs for unconfirmed transactions
* Improve startup time
We now store a new checkpoint and headers up to that checkpoint as soon as our
best chain is 2016 + 500 blocks long
* Properly detect connection loss
* Update electrum mainnet servers list
Using the list from Electrum 3.3.2
* Don't open multiple connection to the same Electrum servers
We want to keep connection to 3 different servers, but when we have less than 3 different
addresses it's pointless to attempt to keep maintain 3 connections.
Our current channel selection is very simplistic: we relay to the
channel with the largest balance. As time goes by, this leads to all
channels having the same balance.
A better strategy is to relay to the channel which has the smallest
balance but has enough to process the payment. This way we save larger
channels for larger payments, and also on average channels get depleted
one after the other.
If we have stopped eclair while it was forwarding HTLCs, it is possible
that we are in a state were an incoming HTLC
was committed by both sides, but we didn't have time to send
and/or sign the corresponding HTLC to the downstream node.
In that case, if we do nothing, the incoming HTLC will
eventually expire and we won't lose money, but the channel
will get closed, which is a major inconvenience.
This check will detect this and will allow us
to fast-fail HTLCs and thus preserve channels.
The goal is to reduce attempts from other nodes in the network to use
channels that are unbalanced and can't be used to relay payments.
This leaks information about the current balance and is a privacy
tradeoff, particularly in this simplistic implementation. A better way
would be to add some kind of hysteresis in order to prevent trivial
probing of channels.
We were previously handling `UpdateFailHtlc` and
`UpdateFailMalformedHtlc` similarly to `UpdateFulfillHtlc`, but that is
wrong:
- a fulfill needs to be propagated as soon as possible, because it
allows us to pull funds from upstream
- a fail needs to be cross-signed downstream (=irrevocably confirmed)
before forwarding it upstream, because it means that we won't
be able to pull funds anymore. In other words we need to be absolutely
sure that the htlc won't be fulfilled downstream if we fail it upstream,
otherwise we risk losing money.
Also added tests.
* Consider htlc_minimum/maximum_msat when computing a route
* Compare shortChannelIds first as it is less costly than comparing the pubkeys
* Remove export to dot functionality
* Remove dependency jgraph
* Add optimized constructor to build the graph faster
* Use fibonacci heaps from jheaps.org
* Use Set instead of Seq for extraEdges, remove redundant publishing of channel updates
* Use Set for ignored edges
* replaced akka.io by netty in electrum client and enabled ssl support
* updated docker-testkit to 0.9.8 so that electrum tests pass on windows
* use ssl port on testnet/mainnet
* removed experimental warning on electrum
* added a revocation timeout
If a peer doesn't quickly reply to a `commit_sig`, we assume that it is
experiencing technical issues, and we disconnect. This will make pending
(unsigned) `update_add_htlc` to be fast-failed and will hopefully limit
the number of htlc that time out in the network.
By default we wait 20 seconds, configurable with
`eclair.revocation-timeout`.
This fixes#745.
We persist htlc data in order to be able to claim htlc outputs in
case a revoked tx is published by our counterparty, so only htlcs
above remote's `dust_limit` matter.
Removed the TODO because we need data to be indexed by commit number so
it is ok to write the same htlc data for every commitment it is included
in.
* updated to scalatest 3.0.5
* use scalatest runner instead of junit
Output is far more readable, and makes console (incl. travis) reports
actually usable.
Turned off test logs as error reporting is enough to figure out what
happens.
The only downside is that we can't use junit's categories to group
tests, like we did for docker related tests. We could use nested suites,
but that seems to be overkill so I just removed the categories. Users
will only have the possibility to either skip/run all tests.
* update scala-maven-plugin to 3.4.2
NB: This requires maven 3.5.4, which means that we currently need to
manually install maven on travis.
Also updated Docker java version to 8u181 (8u171 for compiling).
When updating relay fee in state OFFLINE, the new channel_update must
have the disabled flag on.
This caused tests to be flaky, added necessary checks to always make
them fail in case that kind of regression happens again.
Previously it was only possible to update relay fee in NORMAL state,
which is not very convenient because most of the time there are always
some channels in OFFLINE state.
This works like the NORMAL case, except that the new `channel_update`
won't be broadcast immediately. It will be sent out next time the
channel goes back to NORMAL, in the same `channel_update` that sets the
`enable` flag to true.
Also added a default handler that properly rejects the
CMD_UPDATE_RELAY_FEE command in all other states.
Bitcoin core returns an error `missing inputs (code: -25)` if the tx that we want to publish has already been published and its output have been spent. When we receive this error, we try to get the tx, in order to know if it is in the blockchain, or if its inputs were spent by another tx.
Note: If the outputs of the tx were still unspent, bitcoin core would return "transaction already in block chain (code: -27)" and this is already handled.
This is a simple optimisation, we don't have to keep all `update_fee`, just the last one.
cf BOLT 2:
> An update_fee message is sent by the node which is paying the Bitcoin fee. Like any update, it's first committed to the receiver's commitment transaction and then (once acknowledged) committed to the sender's. Unlike an HTLC, update_fee is never closed but simply replaced.
* Fix handling of born again channels
When we receive a recent update for a channel that we had marked as stale we
must send a query to the underlying transport, not the origin of the update (which
would send the query back to the router)
