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
* 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
* 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
* 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
This is a rework of #184 with numerous improvements and bugfixes.
* re-enabled `WatchSpentBasic`
* fixed several issues in watcher
* fixed pattern matching for INPUT_RECONNECTED event in CLOSING
* reduced logback_colors log level
* connect txes even if they arrive out of order
* wallet: send confidence event as soon as a tx is confirmed
* fixed 5985148f2f and improve events
* added `NewWalletReceiveAddress` event
* cleaned up electrum testnet seeds
* added a test on dumping routing state
* removed WAIT_FOR_FUNDING_PUBLISHED state and clarified funding tx publish assumptions
* wallet: use BIP49 derivation and 24 words mnemonic codes
we use segwit with p2sh-of-p2wkh so we should use BIP49 derivation
instead of BIP44 (same path with m/49'/... instead of m/44'/...)
* added a rollback function to `EclairWallet`
This rollback is called whenever we know we won't publish the funding tx,
so that we tell the wallet to release locks on utxos.
* fundee now checks feerates at `open_channel` reception
* proper handling of electrum connection/disconnection
* moved bitcoinj test to its own package
* make electrum wallet advertise address at startup
* set version to 0.2-SNAPSHOT
See https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#recommendation-on-pruning-stale-entries.
* send a new `channel_update` every 24h as keepalive
* use case object instead of symbol for ticks
* minor improvements in router init
* prune stale channels
Note that we don't want to prune brand new channels for which we didn't
yet receive a channel update, so we consider stale a channel that:
(1) is older than 2 weeks (2*7*144 = 2016 blocks)
AND
(2) didn't have an update during the last 2 weeks.
Pruning is triggered every day.
Also renamed event `BITCOIN_FUNDING_OTHER_CHANNEL_SPENT` to
`BITCOIN_FUNDING_EXTERNAL_CHANNEL_SPENT`.
* filter out duplicate announcements before checking sig
* changed routing table dump parameters
* main feerate source is now earn.com (21.co) instead of bitpay insight
* if main feerate source is unavailable, we now fallback to default values
* we retrieve feerates for a set of block delays instead of just one
* we now use different block delays depending on transactions:
- `block_delay`=`1` for txes that compete with others (eg: commitment
tx, htlc tx, penalty tx)
- `block_delay`=`6` for other txes (eg: funding tx, closing tx, delayed
output tx)
We previously used the `payment_key` both for our main output, and to sign
the local `htlc_success`/`htlc_timeout` transactions.
With this change we can keep the `payment_privkey` offline, which is far
better from a security point of view because an attacker getting control
of a node wouldn't be able to just publish the current commitment
transaction and get the funds. The attacker would only be able to get our
`htlc_privkey`, which we only use in a 2-of-2 multisig with our
counterparty, so it is useless except if the attacker and the counterparty
are the same person, and even in that case only the pending htlcs would be
at risk.
Note that this implementation is a first step and actually keeps the
payment key to spend our outputs in non-mutual close scenarios.
* delay `announcement_signatures` in state `WAIT_FOR_FUNDING_LOCKED`
* delay `announcement_signatures` in state `WAIT_FOR_FUNDING_CONFIRMED`
* always re-send our `announcement_signatures` in response to theirs
When doing an unilateral close (local or remote), we previously weren't
watching htlc outputs to decide whether the commit was finished or not.
This was incorrect because we didn't make sure the htlc-related
transactions had indeed been confirmed on the blockchain, making us
potentially lose money.
This is not trivial, because htlc transactions may be double-spent by the
counterparty, dependending on scenarios (ex: `htlc-timeout` vs
`claim-success`). On top of that, there may be several different kind of
commits in competition at the same time.
With this change, we now:
- put `WatchConfirm` watches on the commitment tx, and on all outputs only
us control (eg: our main output) ;
- put `WatchSpent` watches on the outputs that may be double spent by the
counterparty; when such an output is spent, we put a `WatchConfirm` on
the corresponding transaction and keep track of all outpoints spent ;
- every time a new transaction is confirmed, we find out if there are some
remaining transactions waiting for confirmation, taking into account the
fact that some 2nd/3rd-stage txs may never confirm because their input
has been doublespent.
We also don't rely anymore on dedicated `BITCOIN_CLOSE_DONE`,
`BITCOIN_LOCALCOMMIT_DONE`, ... events.
* properly handle new htlc requests when closing
When in NORMAL state and a `shutdown` message has already been
sent or received, then any subsequent `CMD_ADD_HTLC` fails and
the relayer is notified of the failure.
Same in SHUTDOWN state.
This fixes a possible race condition when a channel just switched
to SHUTDOWN, and the relayer keeps sending it new htlcs before
being notified of the state change.
* renamed Htlc->DirectedHtlc + cleanup
* storing origin of htlcs in the channel state
Currently this information is handled in the relayer, which is not
persisted. As a consequence, if eclair is shut down and there are
pending (signed) incoming htlcs, those will always expire (time out
and fail) even if the corresponding outgoing htlc is fulfilled, because
we lose the lookup table (the relayer's `bindings` map).
Storing the origin in the channel (as opposed to persisting the state
of the relayer) makes sense because we want to store the origin if and
only if an outgoing htlc was successfully sent and signed in a channel.
It is also probably more performant because we only need to do one disk
operation (which we have to do at signing anyway) instead of two
distinct operations.
* removed bindings from relayer
Instead, we rely on the origin stored in the actor state.
* preimages are now persisted and acknowledged
Upon reception of an `UpdateFulfillHtlc`, the relayer forwards it
immediately to the origin channel, *and* it stores the preimage in
a `PreimagesDb`.
When the origin channel has irrevocably committed the fulfill in a
`CommitSig`, it sends an `AckFulfillCmd` back to the relayer, which
will then remove the preimage from its database.
In addition to that, the relayer will re-send all pending fulfills
when it is notified that a channel reaches NORMAL, SHUTDOWN, or
CLOSING state. That way we make sure that the origin channel will
always get the fulfill eventually, even if it currently OFFLINE for
example. This fixes#146.
Also, the relayer now relies on the register to forward messages to
channels based on `channelId` or `shortChannelId`. This simplifies
the relayer but adds one hop when forwarding messages.
* modified `PaymentRelayed` event
Replaced `amountIn` and `feesEarned` by more explicit `amountIn`
and `amountOut`. `feesEarned` are simply the difference.
TODO:
- when local/remote closing a channel, we currently do not wait
for htlc-related transactions, we consider the channel CLOSED when
the commitment transactions has been buried deeply enough; this is
wrong because it wouldn't let us time to extract payment preimages
in certain cases
* Support building of outgoing payments with optional extra hops from payment requests
* Add test for route calculation with extra hops
* Simplify pattern matching in `buildExtra`
* `buildPayment` now uses a reverse Seq[Hop] to create a Seq[ExtraHop]
Since `Router` currently stores `ChannelUpdate`'s for non-public channels, it is possible to use it not only to get a route from payer to payee but also to get a "reverse" assisted route from payee when creating a `PaymentRequest`.
In principle this could be used to even generate a full reverse path to a payer which does not have an access to routing table for some reason.
* Can create `PaymentRequest`s with `RoutingInfoTag`s
* Bugfix and update test with data from live payment testing
* Move ExtraHop to PaymentRequest.scala
* payment request expiry encoding: add Anton's test
it shows that we don't encode/decode values which would take up more than 2 5-bits value
* payment request: encode expiry as a varlen unsigned value
fixes#186
Current version attempted to do everything at once, and would always
leave the NORMAL state after processing the `shutdown` message. In
addition to being overly complicated, it had bugs because it is just
not always possible to do so: for example when we have unsigned outgoing
`update_add_htlc` and are already in the process of signing older changes,
the only thing we can do is wait for the counterparty's `revoke_and_ack`
and sign again right away when we receive it. Only after that can we
send our `shutdown` message, and we can't accept new `update_add_htlc`
in the meantime.
Another issue with the current implementation was that we considered
unsigned outgoing *changes*, when only unsigned outgoing `update_add_htlc`
are relevant in the context of `shutdown` logic.
We now also fail to route htlcs in SHUTDOWN state, as recommended by BOLT 2.
This fixes#173.
