* set a configurable `maxPaymentFee` as safety
Sending a payment will not be attempted if the cheapest route found is
more expensive than this value. Default value is 3%.
This is meant as a protection mechanism, to protect against an
intermediate well-connected node to set outrageous fees.
* reduced default `fee-base-msat` to 1 sat
* (gui) using max fee from node params when sending payment from ui
Implementation should guarantee that in case of a
`BITCOIN_FUNDING_PUBLISH_FAILED` event, the funding tx will *never* be
published (see `commit` method in trait `EclairWallet`).
With that in mind, there is no need for a `ERR_FUNDING_PUBLISH_FAILED`
state, instead we can just permanently close the channel. Note that the
user will receive an error "couldn't publish funding tx".
Both the GUI and the API should handle AskTimeoutException failures as
specific cases: GUI should ignore them, API should print a pretty
response. Increased ask timeout to 60s.
Akka http server responses with the same format as other errors.
Fixes#414 where eclair-cli would fail to parse the server
timeout response.
As soon as we receive a valid closing signature, we will publish the
resulting closing tx instead of our commitment tx if we need to
immediately close the channel (before end of negotiation, e.g. in case
of errors, or in case the counterparty goes OFFLINE).
When the closing signature didn't correspond to one we sent ourselves, we
weren't properly recognizing the publishing tx and went into
`ERR_INFORMATION_LEAK` state.
CMD_CLOSE is now split it to commands:
* `CMD_CLOSE`: this command will succeed only if the current
channel state is in NORMAL, or if the channel hasn't yet been created.
* `CMD_FORCECLOSE`: the channel will publish its current local
commitment (or its best signed closing tx if it has one).
Using `CMD_FORCECLOSE` is more expensive and it incurs a delay before
funds are spendable, but this can be useful in some situations, for
example when the counterparty isn't responding anymore.
Added a new `forceclose` method to the API and a force close button in
the GUI.
(this fixes a regression caused by 24dadff625)
* restore the old node key path
use the same path as before the change in key management so node id will
remain the same after an upgrade
* add a non-regression test
we check that if the seed does not change, then the node id won't change
either, which could be a problem during a node upgrade.
* type-ified `ShortChannelId`
* removed unused `listUnspent` method and test
* updated sqlite version to 3.21.0.1
* ignore `ReadAck` in `PaymentLifecycle`
The Bitcoin Core `addwitnessaddress` rpc command is deprecated in version 0.16.0. Thus, the example `bitcoin.conf` needs to be extended to with the option `deprecatedrpc=addwitnessaddress`.
Without this change, Eclair will not be able to open new channels and the following error message will be written to eclair.log:
```
WARN akka.actor.OneForOneStrategy akka://default/user/$h/switchboard/peer-0390b6fbf04dd277955ce454c87b270d3c910fa96ef3d78afa4bf17d3b733fb877 - addwitnessaddress is deprecated and will be fully removed in v0.17. To use addwitnessaddress in v0.16, restart bitcoind with -deprecatedrpc=addwitnessaddress. Projects should transition to using the address_type argument of getnewaddress, or option -addresstype=[bech32|p2sh-segwit] instead. (code: -32)
```
* generate all channel keys and secrets from the node key and channel number
* use a key manager
the key manager does not export private keys or secrets.
It exports public keys, and points, and provide methods to sign
transaction.
There is just one exception: it does export revocation secrets, since
we need to send them back when we receive a commitment signature.
* key management: cache private keys and public keys
* add key manager to node parameters
* create an interface for key manager
and an implementation which keeps private keys locally
* generate a new BIP32 key path for each new channel
When we create a new channel we generate a new random BIP32 key path
with 128 bits of entropy
* use a `DirectedWeightedPseudograph`
Because we want a directed graph with multiple weighted edges between two
vertices, and loops allowed.
See discussion in [1] for more details.
* take node fee into account when finding route
Fees vary depending on the amount we want to send, so as a simplification
we use a default `DEFAULT_AMOUNT_MSAT`=`10000000` to compute edges weight.
This fixes#310.
* reuse the same graph for all payments
In `findRoute`, if we have specific updates to add/remove, we don't mutate
the main graph and create a copy instead.
[1]
http://jgrapht-users.107614.n3.nabble.com/Difference-between-a-directed-multigraph-and-a-directed-pseudograph-td4024788.html
Make `Commitment` return `ExpiryTooSmall` and `ExpiryTooBig` when
appropriate, and don't do the check in the `Relayer`.
Be more restrictive when sending HTLCs, so that counterparty doesn't
close the channel when a block just appeared and there is temporarily a
1-block discrepancy between two peers.
Proper management of `FinalExpiryTooSoon` in the payment handler.
On top of that, added more tests and simplified some.
* moved CoinUtils to eclair-core to expose conversion methods
Parsing and converting string amount to BtcAmount objects, and
displaying BtcAmount as well formatted string is a common use case.
Methods that were developed for the gui module should be exposed from
eclair-core so that they can be reused elsewhere.
* increased timeouts in integration tests
* have bitcoin wallet and watcher use a separate client
* return more information on channel opening
* removed `storedChannels` from `Peer` constructor
1) so that they can be garbage-collected
2) that was a memory leak because closed channel would stay forever
* OpenChannel now accepts a feerate param for the funding Tx
User should be able to override the fee rate of the funding tx that he
sends when he opens a channel. This custom fee is entered as a fee rate
in satoshi per byte, and converted to a fee rate per kw.
The default value of this fee rate does not change, and still aims for
the funding tx to be included in a block within the next 6 blocks,
estimation which is made through the FeeProvider class.
* reworked payment events
and made sure we send events even when `PaymentLifecycle` disappeared, e.g.
when we restart right after having sent a payment.
A `FailureMessage` should include a detailed description. A `transformForUser`
static method is also added to streamline the list of failures associated to a
`PaymentFailure`.
In the GUI, the payment notification shows a message for each failed attempts
* announcements are pruned before they are sent for `initial_routing_sync` (this was removed by #422)
* is now considered stale a channel that is older than 2 weeks and hasn't any `channel_update` younger than two weeks (again, before #422 we were more lax because of pre-validation pruning)
* pruning was rewritten without use of very expensive `exists` function
* we don't prune anymore on startup
* removed `ThrottleForwarder` and `WriteAckSender`, and handle both TCP read/write backpressure at the `TransportHandler` level, which is much more efficient (e.g. we don't serialize/encrypt outgoing data if OS buffer is already full, which saves RAM and CPU)
* added a simple priority management that reduces priority of routing announcements so that they don't block channel messages on `initial_routing_sync`
* call `doPublish` in `handleMutualClose`
That's more consistent with other closing scenarii, and we weren't
putting a `WatchConfirmed` in case of unexpected closing tx.
* store the unsigned closing tx along with sent `closing_signed`
So that we can identify txes based on txid when they are published,
instead of on their (malleable) signature.
* don't log publish error when tx is already in blockchain
* store the last signed closing tx during negotiation
And use it instead of our local commitment if channel fails before end of
negotiation.
* fixed `SYNCING`->`NEGOTIATING` transition
There were three bugs:
(1) we weren't re-sending our `shutdown`
(2) we were re-sending all previous `closing_signed` instead of restarting
the negotiation
(3) there was even a bug in (2) since
1aee6e8c21
On top of that, had to implement changes as per
https://github.com/lightningnetwork/lightning-rfc/pull/36.
Note that this is unfinished, as there is a corner case where fundee
reuses previous `closing_signed` to compute its next closing fee, even if
it was just disconnected for possibly a long time and network fees have
changed a lot in the meantime.
* watch for closing tx published in `OFFLINE` and `SYNCING`
* added a tx json serializer
* use a separate list for each attempted negotiation
This allow us to properly handle restarting a negotiation after a
reconnect.
* This is based on the `option-data-loss-protect` feature defined in BOLT 9.
* At reconnection, when the counterparty proves us that our commitment is outdated, we politely ask them to publish their commitment. This is done by adding a new state `WAIT_FOR_REMOTE_PUBLISH_FUTURE_COMMITMENT`, and introducing a new "future" remote commitment type, in addition to existing "current" and "next".
* Slightly changed the signature of `Helpers`.`claimRemoteCommitMainOutput` so that current/next/future commitments are all handled the same way.
* Made sure that we never publish our local commitment when we know it is outdated, as it would be a cheating attempt and would result in a total loss of funds.
* Support both optional/required modes for option `option_data_loss_protect`
* removed unused `WAITING_FOR_VALIDATION` state
* unwatch connection when peer is dequeued from `initial_routing_sync` waitlist
* Updated testnet electrum servers list
* Added error log in supervisor when throwable is caught
The default error logging does not log the stack.
* filter updates in one pass
* filter stale channels in one pass
* added `strategy` to supervisor logs
* add the downstream htlc to `Forward*` messages
* make `listPeers` return a `Map`
* use `Seq` instead of `List` in db trait, and implement using `Queue`s
Append is a O(1) in `Queue` and O(n) in `List`.
* use a `Map` to store unacked incoming messages
* used `Vector` instead of `List` in decryption
We now use a queue instead of relying on a scheduler that re-send the request.
Also, better management of dead connection, they get cleaned up and removed from the queue.
In order to gracefully handle cases when the counterparty goes online while we are in
the middle of processing payments, we need to explicitely ack all
`fulfill`/`fail`/`fail_malformed` messages.
We previously only acked `fulfill` messages.
Also, we now fail timed out htlcs at the right time, which is:
- for dust htlcs, when the commitment tx reaches `min_depth`
- for non-dust htlcs, when the htlc-timeout or claim-htlc-timeout tx
reaches `min_depth`
Moved preimage extraction to `Helper` file.
This fixes#376, #377 and #378.
We now use [akka tcp pull mode](https://doc.akka.io/docs/akka/2.5.3/scala/io-tcp.html#read-back-pressure-with-pull-mode) for both incoming and outgoing connections.
In combination with setting a relatively low value for `akka.io.tcp.max-received-message-size`, this results in less RAM consumption, in particular when validating a whole routing table.
Also improved the router:
- Removed the grouping of `channel_announcement` because batching is done lower in the stack, in the bitcoin json-rpc client. Channels are now validated as they arrive.
- Keep track of all origin peers for every announcement (instead of the first one), in order not to send back the same announcements to peers.
- Better choice of data structures, which increases constant time operation (but don't completely eliminate less efficient access)
- Reworked management of private/not-yet-announced channels
* (gui) added channel fees (base and proportional) and capacity to the list
of channels in network
* (gui) fixed issues with gui being updated from wrong threads
* channel capacity is now saved in network DB along with the tx id when
a channel is discovered. `ChannelDiscovered` now contains the capacity.
A compatibility check for the network DB is added in startup. This check is
separated from the node DB check because a network DB check failure is
less severe and the network DB file can be safely removed with no impact
on the node.
* TCPException sets a message when extending RuntimeException
If no message was set for the exception, a 'null' message was displayed to
the user when TCPException is thrown. Instead, we now display the exception class name.
This fixes#399.
* store channel funding txid in network db
* directly load announcements from disk without re-validating them all
* use dedicated sqlite file for network announcements db
* re-send `ChannelDiscovered` and `NodeDiscovered` on startup
Also removed unused `ChannelDiscovered`.`capacity` field.
This should fix#415.
Removed regex validation from the open channel controller, using parser instead for error management. URI with ports below 0 and above 65535 are rejected.
Replaced "url" by "uri" in GUI
