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`
* 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.
* (gui) Added funding tx id to channel panel
fixes#335
* (gui) close channel button hidden when CLOSING or CLOSED
fixes#332
* (gui) User can define a preferred display unit
On startup FxApp reads the configuration from `eclair.conf` and sets
a unit to which all the amounts in the UI must be converted.
This unit is a CoinUnit object. Only `sat`, `mbtc` and `btc` are accepted.
`msat` is not accepted because it's an internal accounting unit which
should be invisible to the user. Default unit is `btc`
The gui does not expose any ui feature to update this unit at runtime.
* (gui) Notification message wraps and can now be copied
Notification message should be readable especially when an error occurs.
The message can be copied for easier issue reporting.
* Payment attempts is limited to 1
* (gui) consistent order in status bar contextual actions
* (gui) fixed unit parsing
* (gui) added menu shortcuts
fixes#347
* Revert "Payment attempts is limited to 1"
This reverts commit 1f4168aacb.
* (gui) BtcAmount are convertible to raw big decimal without loss
Fix issue where the decimal part of a BtcAmount could be lost.
Millisatoshi is now accepted as a user preferred unit.
* Set a minimum htlc amount of 1 mSat by default
By default, the node configuration should be permissive and accept low
value payments. It is up to the node admin to set up a restrictive
configuration if he needs it.
* (gui) port in node uri is optional
* (gui) added reactive errors in open channel window
* (gui) format max pr amount to user preferred unit
* (gui) Payment Request QR should be uppercased
see #375
* (gui) added a conf for the gui module
* Added eclair.gui.unit option in README
We previously only checked this counter when receiving parseable failures
(of type `ErrorPacket`).
This would lead to infinite payment loop in certain cases.
This fixes#355.
* Make payment request expiry configurable
* Add payment request expiry to test constants
* Remove outdated unpaid requests from LocalPaymentHandler
* Add max allowed number of pending requests
* Update request pruning code in LocalPaymentHandler, replace def with lazy val in PaymentRequest
* Make payment handler return an error when we are over `max-pending-payment-requests`
Payment preimage is important for the sender of the payment as it proves
that he actually paid the request. It must then be available from the
`PaymentSent` event.
(gui) Payment preimage column is added to the 'payments sent' table in Activity tab
* NodeURI can now handle ipv6 addresses
The address field in `NodeURI` is now a `HostAndPort` object. The reasoning is that `InetSocketAddress` is a network object and should not be directly used in an utility object. Using `HostAndPort` makes for a more readable and less bug prone code.
This especially helps with the parsing of ipv6 addresses which is more complex than ipv4. It also avoids a early lookup when the `NodeURI` object is created.
Deserialization to `NodeURI` now defaults to port 9735 if the port could not be found in the string.
fixes#343fixes#346
* reworked eclair-cli
* API is disabled by default, disabled CORS and require basic auth password
* better error handling
* Fixed latest version in README
* Increased connection timeout to 15s in electrum client test
* Rgb in NodeAnnouncement is now a Color object
Makes the color field more practical to handle and enable finer
serialization with a more readable code.
allnodes command in api now exports a list with node announcements.
* Added api call to list all the channels updates
This call can also filter the channels for a given nodeId
This fixes#344.
* added logs
* more efficient logging
* added huge bitcoin jsonrpc queue
* only publish/watch txes if needed when restarting in `CLOSING` state
* limit number of parallel routing state dump
* added a supervision strategy to authenticator hierarchy
* only forward Rebroadcast to connected peers
* rework management of `origins` in router
* explicitely close sqlite prepared statements
* fixed pruning logic
* send instead of forward announcement to router
* store txes that have reached `mindepth` in `CLOSING` state
* add a minimum 10s delay between two reconnection attempts
otherwise, this would frequently cause 2 successful parallel connections
* don't trigger a `NewBlock` event when receiving a new `WatchConfirmed`
Instead, just check this particular watch
* TransportHandler: fix typo when logging received data that has a bad prefix
* better handling of connection errors
* kill WriteAckSender when connection dies, don't send connection errors when auto connecting
* streamlined io actors
* handle parallel connections in peer
This fixes#357.
* Fix encoding of failure messages (fixes#363)
When a failure message includes a channel update field, this field must be encoded as:
[ len | channel update] and we did not include the len field.
* add `ExpiryTooFar` failure message
* always print `shortChannelId` in hex
* fixed logs in `ThrottleForwarder`
* logs the `paymentHash` when relaying an htlc
* don't print all channel data when restoring a channel
* added logs to relayer
* reduced log level in Peer
* cleaned up switchboard logs
* fixed `id`/`channelId` mixup in relayer logs
* slight changes in log levels
* do not log as warning when tx generation is simply skipped
* streamlined relayer logs
* improved router logs
* don't display errors when witness can't be parsed
* don't log connection errors as warnings
* reduce amount of logs in case of local known error
* removed reconnection message to deadletter
* try a cleaner way of displaying channel errors
* put some reconnection-related logs from info to debug
* peer: ignore `Rebroadcast` messages in `INITIALIZING`
* less verbose exception logging in channel
* display friendlier close type
* reduced default log level to INFO
* reworked peer management
- connection and channel opening are now separated, simplified
`switchboard`
- use a single authenticator for both incoming and outgoing connections
- `peers` api call now returns current state and channel count
* fixed last commit
* fixed last merge
* added inetsocketaddress serializer
* forget about channels older than 3 days and prune every minute
* Revert "forget about channels older than 3 days and prune every minute"
This reverts commit 347e01b5c18208f162b31663d383d5b7de36eea7.
* added pruning pre-validation
* don't pre-prune channels that don't have channel_update, but don't validate them either
* removed println
* removed useless handler
* cleanup announcement db at startup
* simplified pruning logic and re-enabled tests
* fix `getStaleChannels`
* fixed integration tests
* Electrum: Add unix timestamp to WalletReady notification
* Electrum: don't send WalletReady when we get disconnected
* Electrum: check that WalletReady notification is sent on reconnection
* Electrum: don't same the same ready notification more than once
We don't use state transitions to send notifications anymore
* Electrum client: use tcp keep-alive
* factorized socket options
Service pattern matching code visually separates each method and
params to improve the code readability and maintenance. Route completion
is handle on a case by case basis, for each call. This enables better error
management and useful feedback to the caller.
Added custom rejections to handle cases where the given rpc method or
params are not found or not correct.
HTTP code should now be consistent with the error returned.
* Core fee estimator: return result in satoshi per byte
It was still in satoshi per kb
* Electrum: use actual tx weight to estimate fees when funding a tx
This fixes#303
* Received payments are stored in a DB; added api calls for basic select
When the local payment handler receives a valid htlc, a Payment { payment_hash,
amount_msat, timestamp } is added in a sqlite DB. This enables the node
operator to check if a payment has been received.
Two methods are added to the JSON RPC API: list the payments and find a payment
by its payment hash.
* Test LocalPaymentHandler checking that received payment is saved in DB
* Payment API call accepts only valid paymentHash and paymentRequest arg
* API should expose only a `checkpayment` method
Interaction with payment DB from API goes through the payment handler
Also removed exception/rejection handlers to stay consistent with the api
* Updated README with checkpayment API method; moved Payment to PaymentDB
The previous assumption that a `channel_update` only exists when we have a
related `channel_announcement` does not always hold true. There are two
special cases:
- we want the `router` to know of our outgoing `channel_update` as soon as
a channel reaches `NORMAL` state, so that we can immediately send
payments
- we need to know remote's `channel_update` even for private (unannounced)
channels, in order to be able to receive funds (we will put those as
hints in the payment request using the `r` field); we also need to send
out our `channel_update` for private channels for the same reason
In order to do that, two fields were added to the `router`'s state:
- `privateChannels`: similar to `channels`, but holds a fake `channel_announcement`s for local channels that are private or are public but not yet announced
- `privateUpdates`: similar to `updates`, but holds `channel_update`s related to local channels that are private, or are public but not yet announced.
For local public channels, we will have `channel_update` both in `updates` and in `privateUpdates`, but the latter has the precedence when computing routes.
Also, in the `channel` we now handle the sending of new `channel_update` during the transitions, as opposed to in the state handlers.
Note that this changes the serialization format, making this upgrade not backward-compatible.
This fixes#244.
In commit 2e2a47e5fd we inverted the
`local`/`remote` `toSelfDelay` when building the commitment tx, but forgot
to do the same when claiming the outputs.
Updated integration tests to reproduce the issue.
This fixes#290.
The `relayer` was missing failures sent by the `channel`, which led to `htlc` lingering without being failed. Sender would see payments stuck in `PENDING` state until they eventually timeout and cause the channel to be unilaterally closed.
This is a regression caused by f47ea72369.
This fixes#264.
The `relayer` wasn't correctly handling failures from the `register`, which led to `htlc` lingering without being failed. Sender would see payments stuck in `PENDING` state until they eventually timeout and cause the channel to be unilaterally closed.
This is a regression caused by f47ea72369.
* include raw tx when sig check fails
See BOLT 1 recommendation:
"when failure was caused by an invalid signature check:
SHOULD include the raw, hex-encoded transaction in reply to a
funding_created, funding_signed, closing_signed, or commitment_signed
message."
Also, removed redundant signature check in state
`WAIT_FOR_FUNDING_SIGNED`.
* enforce closing fee <= commitment fee
In accordance to BOLT 2.
Note that it is safe to consider feerates instead of fees, because
weight(closingTx) < weight(commitTx).
This fixes#243.
* use channel logger in Helpers.scala and Commitment.scala
* handle multiple closing txes
Nothing prevents the counterparty to publish any or several of the closing txes
before the negotiation is finished, we need to handle this case.
This fixes#245.
* added msg+state when chanel failure occurs
* proper handling of invalid closing sig
* removed hardcoded error messages in channel
* return an `error` to sync attemps when in CLOSING
* peer now return an error for unknown channels
* added fee negotiation details in logs
* properly display errors, reject closing fee to high
* return `UnknownNextPeer` when next channel is unknown
* correctly relay channels errors (fixes#227)
* keeping `channel_update` in DATA_NORMAL
* moved class `ForwardLocalFail`->`AddHtlcFailed`
* made `AddHtlcFailed` a `ChannelException`
* unannounced channels now return `channel_update` in errors
* use remote `htlc_minimum_msat` in `channel_update`
also set default `htlc-minimum-msat`=`10000`
This fixes#248.
* Announce short channel id when funding depth ok
* added logs to router
* channel do not send `node_announcement` anymore
Dependency to `git` has been removed, we now use `notag` when building without
a git directory.
In order to reliably fetch all dependencies, we do a first blank build
(with no source files), then we copy the sources and do a real commit.
This is a simpler and more robust approach.
Also, fixed the .dockerignore to filter out IDE files.
* disable dust limit checks on regtest and testnet
* fundee should also check dust limit they received open_channel (see #236)
* channel state tests: accept optional node parameters
use defaults if not provided
* Enable generation of a payment request without amount
The amount field in a `PaymentRequest` was already optional but eclair
did not permit the generation of such a request.
Added a new `receive` service with no required amount field.
In the GUI, the parsing of the amount field and its conversion to
`MilliSatoshi` are reworked to better handle decimals.
* (gui) Amount's can be overriden when sending a payment request
The amount of a payment request can be changed and it is up to the
receiving node to accept or deny the payment according to its
implementation.
This also enables the user to pay through the GUI a payment request
where the amount has not been set, such as a donation. The amount is still
required!
The description field has also been added in the GUI. It is empty if the
description has not been set.
* (gui) Properly parse amounts from open channel form
* (gui) added optional `lightning:` scheme to payment request
We check that channel parameters are compliant with [BOLT 2](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md) (this fixes#236).
We make sure that the counterparty chooses a decent `dust_limit`
because we want them to be able to publish their commitment, e.g. in a
data loss scenario. We also make sure that our configurable `dust_limit` isn't too low (this
fixes#234).
Also fixed our min `dust_limit` (542->546).
GUI:
* Using funding constants from `Channel`
* Also fixed an issue here `push` amount was compared to the max funding amount
instead of the actual `funding` amount
To avoid malleability issues, ask users to only have p2sh-of-p2wkh outputs.
on testnet, on startup we check that all UTXOs are p2sh (we cannot check that the
p2sh script is a p2wpkh script). It is not needed on regtest since there is no
chance that wallet tx will be malleated.
This was a workaround because bitcoin-core could produce malleable funding
transactions.
We now:
1) assume that all existing funds in bitcoin core are in segwit P2S addresses
2) manually create segwit change addresses when we create new transactions
Also disabled unused/unreliable bitcoinj tests
