Instead of using two separate maps (for channels and channel_updates), we now use a single map, which groups channel+channel_updates. This is also true for data storage, resulting in the removal of the channel_updates table.
Untyped cltv expiry was confusing: delta and absolute expiries really need to be handled differently.
Even variable names were sometimes misleading.
Now the compiler will help us catch errors early.
* Type all amounts used in eclair
* Add eclair.MilliSatoshi class
* Use bitcoin-lib 0.14
* Add specialized codecs for Satoshi/MilliSatoshi
* Rename 'toSatoshi' to 'truncateToSatoshi' to highlight it's a precision-losing conversion
* Use feeEstimator in NodeParams, remove all calls to Globals.feeratePerKw
* Introduce FeeConf object and config block for confirmation targets, remove unused 'smartfeeNBlocks'
* Use a custom confirmation target for commitment transaction
* Use a custom confirmation target for funding transaction
* Use custom confirmation target for mutual close transaction
* Use custom confirmation target for claim transactions
* Add confirmation target block 144
* Use block target = 12 as default for claim transactions
It was obsole since
068b0bccf9.
Note that we use a signed long, but it doesn't matter since 2^64
milli-satoshis is greater than the total number of bitcoins.
Until now, if the peer is unresponsive (typically doesn't respond to
`open_channel` or `funding_created`), we waited indefinitely, or until the
connection closed.
It translated to an API timeout for users, and uncertainty about the
state of the channel.
This PR:
- adds an optional `--openTimeoutSeconds` timeout to the `open` endpoint, that will
actively cancel the channel opening if it takes too long before reaching
state `WAIT_FOR_FUNDING_CONFIRMED`.
- makes the `ask` timeout configurable per request with a new `--timeoutSeconds`
- makes the akka http timeout slightly greater than the `ask` timeout
Ask timeout is set to 30s by default.
There is no unique identifier for payments in LN protocol. Critically,
we can't use `payment_hash` as a unique id because there is no way to
ensure unicity at the protocol level.
Also, the general case for a "payment" is to be associated to multiple
`update_add_htlc`s, because of automated retries. We also routinely
retry payments, which means that the same `payment_hash` will be
conceptually linked to a list of lists of `update_add_htlc`s.
In order to address this, we introduce a payment id, which uniquely
identifies a payment, as in a set of sequential `update_add_htlc`
managed by a single `PaymentLifecycle` that ends with a `PaymentSent` or
`PaymentFailed` outcome.
We can then query the api using either `payment_id` or `payment_hash`.
The former will return a single payment status, the latter will return a
set of payment statuses, each identified by their `payment_id`.
* Add a payment identifier
* Remove InvalidPaymentHash channel exception
* Remove unused 'close' from paymentsDb
* Introduce sent_payments in PaymentDB, bump db version
* Return the UUID of the ongoing payment in /send API
* Add api to query payments by ID
* Add 'fallbackAddress' in /receive API
* Expose /paymentinfo by paymentHash
* Add id column to audit.sent table, add test for db migration
* Add invoices to payment DB
* Add license header to ExtraDirective.scala
* Respond with HTTP 404 if the corresponding invoice/paymentHash was not found.
* Left-pad numeric bolt11 tagged fields to have a number of bits multiple of five (bech32 encoding).
* Add invoices API
* Remove CheckPayment message
* GUI: consume UUID reply from payment initiator
* API: reply with JSON encoded response if the queried element wasn't found
* Return a payment request object in /receive
* Remove limit of pending payment requests!
* Avoid printing "null" fields when serializing an invoice to json
* Add index on paymentDb.sent_payments.payment_hash
* Order results in descending order in listPaymentRequest
See https://github.com/ACINQ/bitcoin-lib/pull/31.
We still have to use `Array[Byte]` for low-level cryptographic primitives, and `akka.util.ByteBuffer` for tcp connections. In order to reduce unnecessary copies, we used `ByteVector.view(...)` as much as possible.
Took the opportunity to do a project-wide optimize imports. We might as well do it now since pretty much all files have been touched already.
NB: temporarily use bitcoin-lib 0.10.1-SNAPSHOT because maven central is very slow and we can't access the recently release 0.10 for now.
* Upgrade to JDK11
Eclair can be built and used on Oracle JDK 1.8 or OpenJDK 11.
JavaFX is now embedded in eclair-node-gui and does not need to be installed separately.
* Install: update java download links
OpenJDK 11 is now our recommendation. Tell users to download java from https://jdk.java.net/11
* README: Rewrite installation instructions
The GUI took a very long time to startup because nodes and channels were
stored in javafx `ObervableList` which doesn't allow random access. We
can't easily use `ObservableMap` because `TableView` do not support
them.
As a workaround, created an `IndexedObservableList` which keeps track of
indices in `ObservableList` so that we can still have fast random
access.
Also, now grouping announcements in `NetworkEvent` instead of sending
them one by one.
* Enable searching for routes with size/CLTV/fee limits
* Expose the RouteParams in RouteRequest
* Expose the RouteParams in SendPayment
* Rename DEFAULT_ROUTE_MAX_LENGTH
* If we couldn't find a route on the first attempt, retry relaxing the restriction on the route size
* Avoid returning an empty path, collapse the route not found cases into one
* When retrying to search for a route, relax 'maxCltv'
* Move the default params for route searching in the conf, refactor together router params into a config class
* Remove max-payment-fee in favor of router.search-max-fee-pct
* Group search params configurations into a block
* Rename config keys for router path-finding
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!
* 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
* 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
This allows for a user of the library to implicitly pass the `ActorSystem` to the eclair node. Although if you are running multiple eclair instances on the same machine you need to make sure the `ActorSystems` that are passed implicitly are unique.
* add api call to update channel relay fees
* fixed bug in GUI, as channel can had different fees in each direction!
* fire transitions on `TickRefreshChannelUpdate` (fixes#621)
* make router publish `channel_update`s on startup
* (gui) Channel info fees are now options and case where channels have no known fees data is now properly handled.
* feerate: use satoshi/kb instead of satoshi/byte
* API fixup: convert input feerate from sat/bytes to sat/kw
* fixup: convert input feerate from sat/bytes to sat/kw
* add cleaner access to current feerate
implementation (blocks 2,6,12...) is not exposed, users will call getFeerate()
* fix feerate conversions
a kilobyte is 1000 bytes, not 1024 bytes (thanks @jimpo)
* revert commit 179dadc
keep this PR focused on 1 task only
* rename FeeratesPerKb to FeeratesPerKB
* reproduces bug decoding ipv4-mapped-as-ipv6 addresses
* handle IPv4-mapped addresses
`InetAddress.getByAddress` automatically converted IPv4-mapped addresses
into IPv4 addresses, which resulted in them being serialized as IPv4
addresses instead of IPv6 addresses, invalidating the signature.
We now use `Inet6Address.getByAddress` instead.
* added support for parsing tor2/tor3 addresses
Note that there are currently invalid announcements on mainnet due to
https://github.com/ElementsProject/lightning/pull/1175#pullrequestreview-111994441.
* Update funding tx id value upon receiving ChannelStateChanged to WAIT_FOR_FUNIDNG_CONFIRMED
Currently the only time the "Funding tx id" text in GUI is updated is
upon receiving the ChannelRestored event, which means that if the GUI is
not restarted the value keeps showing "N/A".
add electrum router, which manages a set of client
primary client is the one on the longest chain, when a secondary client
has a chain that is longer than master + 2 it becomes the new master.
this will allow us to move away from "dead" electrum servers that are not
up to date with the blockchain.
electrum client: add 'get header' method
electrum: maintain a chain of headers for each client
and switch to the one with the longest chain
electrum: handle case when received header connects to our first header
it can happen when we connect to a server and ask for the last N headers
electrum: automatic reconnection
when we lose connection to our master client, we consider that we are
disconnected.
when we lose connection to a secondary client, we try to find an address
that is not used and connect to it. If there is no such address we wait
a bit and try to reconnect to the failing client
electrum: check that incoming header proof of work is valid
electrum router: migrate to Akka's FSM
electrum: fix match error for `ready` message
add missing copyright headers
move Blockchain to electrum package
electrum: simplify router
electrum client: fix handling of dead subscribers
electrum: move blockchain validation into electrum client
client will now send `ready` notifications and subscriptions messages only when it has a valid and
long enough blockchain
pass execution context as argument
reworked `ElectrumRouter` following
3dc1c2b61c82debeaed8d0d92238c0b5ee5c49c8
renamed `ElectrumRouter` -> `ElectrumMultiClient`
reformat
`var` -> `val`
electrum: rename multiclient -> pool + cleanup
* 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
