2016-10-18 16:37:32 +02:00

2016-01-21 15:39:56 +01:00
2017-03-17 19:08:24 +01:00
[](https://travis-ci.org/ACINQ/eclair)
2017-03-17 19:07:29 +01:00
[](LICENSE)
2018-08-29 14:54:38 +02:00
[](https://gitter.im/ACINQ/eclair)
2016-01-21 15:39:56 +01:00
2017-03-17 19:07:29 +01:00
**Eclair** (french for Lightning) is a scala implementation of the Lightning Network. It can run with or without a GUI, and a JSON-RPC API is also available.
2016-01-21 15:39:56 +01:00
2018-03-28 20:21:19 +02:00
This software follows the [Lightning Network Specifications (BOLTs) ](https://github.com/lightningnetwork/lightning-rfc ). Other implementations include [c-lightning ](https://github.com/ElementsProject/lightning ) and [lnd ](https://github.com/LightningNetwork/lnd ).
2017-03-17 19:07:29 +01:00
2017-03-21 17:32:15 +01:00
---
2018-03-28 20:21:19 +02:00
:construction: Both the BOLTs and Eclair itself are still a work in progress. Expect things to break/change!
2017-03-17 19:07:29 +01:00
2018-03-28 20:21:19 +02:00
:rotating_light: If you intend to run Eclair on mainnet:
- Keep in mind that it is beta-quality software and **don't put too much money** in it
- Eclair's JSON-RPC API should **NOT** be accessible from the outside world (similarly to Bitcoin Core API)
- Specific [configuration instructions for mainnet ](#mainnet-usage ) are provided below (by default Eclair runs on testnet)
2017-05-02 11:12:57 +02:00
2016-10-18 16:23:31 +02:00
---
2017-03-17 19:07:29 +01:00
## Lightning Network Specification Compliance
2017-04-07 12:04:07 +02:00
Please see the latest [release note ](https://github.com/ACINQ/eclair/releases ) for detailed information on BOLT compliance.
2016-10-18 16:23:31 +02:00
2017-03-17 19:07:29 +01:00
## Overview
2016-10-18 16:23:31 +02:00

## Installation
2016-01-21 15:39:56 +01:00
2017-03-17 19:07:29 +01:00
### Configuring Bitcoin Core
2016-02-16 18:03:40 +01:00
Update Android branch (#746)
* Fixed regression in rebroadcast (#713)
Fixed regression caused by 2c1811d: we now don't force sending a
channel_update at the same time with channel_announcement.
This greatly simplifies the rebroadcast logic, and is what caused the
integration test to fail.
Added proper test on Peer, testing the actor, not only static methods.
* Routing sync fixes (#712)
* Router: reset sync state on reconnection
When we're reconnected to a peer we will start a new sync process and should reset our sync
state with that peer.
* Ignore 'origin htlc not found' in CLOSING (#708)
If we don't have the origin, it means that we already have forwarded the fulfill so that's not a big deal.
This can happen if they send a signature containing the fulfill, then fail the channel before we have time to sign it.
* Fix handling of born again channels (#717)
* 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)
* Replace `update_fee` in commitments (#709)
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.
* Tests: use bitcoind 0.16.3 (#715)
Bitcoind 0.16.0 is no longer available
* Make `publishTransaction` idempotent (#711)
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.
* Improved eclair-cli (#718)
This fixes #695, and also adds the channel point in the default channel output.
```bash
$ ./eclair-cli channel 00fd4d56d94af93765561bb6cb081f519b9627d3f455eba3215a7846a1af0e46
{
"nodeId": "0232e20e7b68b9b673fb25f48322b151a93186bffe4550045040673797ceca43cf",
"shortChannelId": "845230006070001",
"channelId": "00fd4d56d94af93765561bb6cb081f519b9627d3f455eba3215a7846a1af0e46",
"state": "NORMAL",
"balanceSat": 9858759,
"capacitySat": 10000000,
"channelPoint": "470eafa146785a21a3eb55f4d327969b511f08cbb61b566537f94ad9564dfd00:1"
}
```
* Handle update relay fee in OFFLINE state (#719)
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.
* Fixed regression caused by 7a4f175 (#722)
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.
* Logging: use a rolling file appender (#721)
* Logging: use a rolling file appender
Use one file per day, keep 90 days of logs with a total maximum size
capped at 5 Gb
* Router: log routing broadcast in debug level only
* set version to 0.2-beta6
* set version back to 0.2-SNAPSHOT
* Simplify bitcoind version check (#731)
Bitcoind returns version as MMmmrr (major, minor, revision), use an int representation
and compare it to our minimum version target.
* Update scalatest and remove junit runner (#728)
* 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).
* Add instructions for Bitcoin Core 0.17.0 [ci skip] (#732)
* Add instructions for Bitcoin Core 0.17.0 [ci skip]
Bitcoin Core 0.17.0 deprecates the `signrawtransaction` RPC call, which will be removed in version 0.18.0, you need to enable this call if you want your eclair node to use a 0.1.70 node.
* README: add an example of how to use the new bitcoin.conf sections [ci skip]
* Only persist trimmed htlcs (#724)
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.
* set version to 0.2-beta7
* set version to 0.2-SNAPSHOT
* Add `htlcMaximumMsat` field to `ChannelUpdate` message (#738)
* Add `htlcMaximumMsat` field to `ChannelUpdate` message
* added compatibility test with c-lightning
* Fix encoding of FinalIncorrectHtlcAmount error message (#740)
* set version to 0.2-beta8
* set version to 0.2-SNAPSHOT
* Always add 1 block to the `finalCltvExpiry` (#742)
This fixes #651.
* ignore IntegrationSpec (no server on android)
* back to SNAPSHOT
* use proper [gs]etNullableLong method for Sqlite
2018-10-25 17:50:48 +02:00
:warning: Eclair requires Bitcoin Core 0.16.3 or higher. If you are upgrading an existing wallet, you need to create a new address and send all your funds to that address.
2018-03-26 20:56:51 +02:00
Eclair needs a _synchronized_ , _segwit-ready_ , **_zeromq-enabled_** , _wallet-enabled_ , _non-pruning_ , _tx-indexing_ [Bitcoin Core ](https://github.com/bitcoin/bitcoin ) node.
Eclair will use any BTC it finds in the Bitcoin Core wallet to fund any channels you choose to open. Eclair will return BTC from closed channels to this wallet.
2016-02-17 16:45:24 +01:00
2017-03-31 18:08:59 +02:00
Run bitcoind with the following minimal `bitcoin.conf` :
2016-11-14 17:19:29 +01:00
```
2017-12-22 23:26:29 +01:00
testnet=1
2016-10-18 16:23:31 +02:00
server=1
2018-01-18 14:25:12 +00:00
rpcuser=foo
rpcpassword=bar
2017-03-17 19:07:29 +01:00
txindex=1
2017-03-31 18:08:59 +02:00
zmqpubrawblock=tcp://127.0.0.1:29000
zmqpubrawtx=tcp://127.0.0.1:29000
2018-03-02 17:12:56 +01:00
addresstype=p2sh-segwit
2016-02-16 17:55:10 +01:00
```
2016-10-18 16:23:31 +02:00
Update Android branch (#746)
* Fixed regression in rebroadcast (#713)
Fixed regression caused by 2c1811d: we now don't force sending a
channel_update at the same time with channel_announcement.
This greatly simplifies the rebroadcast logic, and is what caused the
integration test to fail.
Added proper test on Peer, testing the actor, not only static methods.
* Routing sync fixes (#712)
* Router: reset sync state on reconnection
When we're reconnected to a peer we will start a new sync process and should reset our sync
state with that peer.
* Ignore 'origin htlc not found' in CLOSING (#708)
If we don't have the origin, it means that we already have forwarded the fulfill so that's not a big deal.
This can happen if they send a signature containing the fulfill, then fail the channel before we have time to sign it.
* Fix handling of born again channels (#717)
* 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)
* Replace `update_fee` in commitments (#709)
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.
* Tests: use bitcoind 0.16.3 (#715)
Bitcoind 0.16.0 is no longer available
* Make `publishTransaction` idempotent (#711)
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.
* Improved eclair-cli (#718)
This fixes #695, and also adds the channel point in the default channel output.
```bash
$ ./eclair-cli channel 00fd4d56d94af93765561bb6cb081f519b9627d3f455eba3215a7846a1af0e46
{
"nodeId": "0232e20e7b68b9b673fb25f48322b151a93186bffe4550045040673797ceca43cf",
"shortChannelId": "845230006070001",
"channelId": "00fd4d56d94af93765561bb6cb081f519b9627d3f455eba3215a7846a1af0e46",
"state": "NORMAL",
"balanceSat": 9858759,
"capacitySat": 10000000,
"channelPoint": "470eafa146785a21a3eb55f4d327969b511f08cbb61b566537f94ad9564dfd00:1"
}
```
* Handle update relay fee in OFFLINE state (#719)
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.
* Fixed regression caused by 7a4f175 (#722)
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.
* Logging: use a rolling file appender (#721)
* Logging: use a rolling file appender
Use one file per day, keep 90 days of logs with a total maximum size
capped at 5 Gb
* Router: log routing broadcast in debug level only
* set version to 0.2-beta6
* set version back to 0.2-SNAPSHOT
* Simplify bitcoind version check (#731)
Bitcoind returns version as MMmmrr (major, minor, revision), use an int representation
and compare it to our minimum version target.
* Update scalatest and remove junit runner (#728)
* 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).
* Add instructions for Bitcoin Core 0.17.0 [ci skip] (#732)
* Add instructions for Bitcoin Core 0.17.0 [ci skip]
Bitcoin Core 0.17.0 deprecates the `signrawtransaction` RPC call, which will be removed in version 0.18.0, you need to enable this call if you want your eclair node to use a 0.1.70 node.
* README: add an example of how to use the new bitcoin.conf sections [ci skip]
* Only persist trimmed htlcs (#724)
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.
* set version to 0.2-beta7
* set version to 0.2-SNAPSHOT
* Add `htlcMaximumMsat` field to `ChannelUpdate` message (#738)
* Add `htlcMaximumMsat` field to `ChannelUpdate` message
* added compatibility test with c-lightning
* Fix encoding of FinalIncorrectHtlcAmount error message (#740)
* set version to 0.2-beta8
* set version to 0.2-SNAPSHOT
* Always add 1 block to the `finalCltvExpiry` (#742)
This fixes #651.
* ignore IntegrationSpec (no server on android)
* back to SNAPSHOT
* use proper [gs]etNullableLong method for Sqlite
2018-10-25 17:50:48 +02:00
:warning: If you are using Bitcoin Core 0.17.0 you need to add following line to your `bitcoin.conf` :
```
deprecatedrpc=signrawtransaction
```
2017-03-17 19:07:29 +01:00
### Installing Eclair
2016-10-18 16:23:31 +02:00
2017-08-17 13:04:43 +02:00
The released binaries can be downloaded [here ](https://github.com/ACINQ/eclair/releases ).
2017-03-17 19:07:29 +01:00
#### Windows
Just use the windows installer, it should create a shortcut on your desktop.
2017-03-31 18:19:39 +02:00
#### Linux, macOS or manual install on Windows
2017-03-17 19:07:29 +01:00
2017-03-31 18:19:39 +02:00
You need to first install java, more precisely a [JRE 1.8 ](http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html ).
2017-08-30 13:42:58 +02:00
:warning: If you are using the OpenJDK JRE, you will need to build OpenJFX yourself, or run the application in headless mode (see below).
2017-03-17 19:07:29 +01:00
2017-07-26 19:11:44 +02:00
Then download the latest fat jar and depending on whether or not you want a GUI run the following command:
* with GUI:
```shell
2017-08-23 19:28:18 +02:00
java -jar eclair-node-gui-< version > -< commit_id > .jar
2017-07-26 19:11:44 +02:00
```
* without GUI:
2016-10-18 16:23:31 +02:00
```shell
2017-08-23 19:28:18 +02:00
java -jar eclair-node-< version > -< commit_id > .jar
2016-11-14 17:19:29 +01:00
```
2016-02-16 18:03:40 +01:00
2017-03-17 19:07:29 +01:00
### Configuring Eclair
2017-08-30 13:42:58 +02:00
#### Configuration file
2016-02-16 17:55:10 +01:00
2017-12-21 10:28:35 +01:00
Eclair reads its configuration file, and write its logs, to `~/.eclair` by default.
2017-03-21 17:32:15 +01:00
2017-12-21 10:28:35 +01:00
To change your node's configuration, create a file named `eclair.conf` in `~/.eclair` . Here's an example configuration file:
2017-03-27 11:14:54 +02:00
2017-08-30 13:42:58 +02:00
```
2018-03-28 20:21:19 +02:00
eclair.chain=testnet
2017-08-30 13:42:58 +02:00
eclair.node-alias=eclair
eclair.node-color=49daaa
```
2017-03-27 11:14:54 +02:00
2017-08-30 13:42:58 +02:00
Here are some of the most common options:
2017-03-17 19:07:29 +01:00
2018-01-23 15:25:53 +01:00
name | description | default value
-----------------------------|---------------------------------------------------------------------------------------|--------------
2018-03-28 20:21:19 +02:00
eclair.chain | Which blockchain to use: *regtest* , *testnet* or *mainnet* | testnet
2018-01-23 15:25:53 +01:00
eclair.server.port | Lightning TCP port | 9735
eclair.api.enabled | Enable/disable the API | false. By default the API is disabled. If you want to enable it, you must set a password.
eclair.api.port | API HTTP port | 8080
eclair.api.password | API password (BASIC) | "" (must be set if the API is enabled)
eclair.bitcoind.rpcuser | Bitcoin Core RPC user | foo
eclair.bitcoind.rpcpassword | Bitcoin Core RPC password | bar
2018-01-29 19:41:40 +02:00
eclair.bitcoind.zmq | Bitcoin Core ZMQ address | "tcp://127.0.0.1:29000"
2018-01-23 15:25:53 +01:00
eclair.gui.unit | Unit in which amounts are displayed (possible values: msat, sat, mbtc, btc) | btc
2016-10-18 16:23:31 +02:00
2017-11-14 10:56:10 +01:00
Quotes are not required unless the value contains special characters. Full syntax guide [here ](https://github.com/lightbend/config/blob/master/HOCON.md ).
2017-08-17 13:04:43 +02:00
→ see [`reference.conf` ](eclair-core/src/main/resources/reference.conf ) for full reference. There are many more options!
2016-10-18 16:23:31 +02:00
2017-08-30 13:42:58 +02:00
#### Java Environment Variables
Some advanced parameters can be changed with java environment variables. Most users won't need this and can skip this section.
2017-12-21 10:28:35 +01:00
:warning: Using separate `datadir` is mandatory if you want to run **several instances of eclair** on the same machine. You will also have to change ports in `eclair.conf` (see above).
2017-08-30 13:42:58 +02:00
name | description | default value
----------------------|--------------------------------------------|--------------
eclair.datadir | Path to the data directory | ~/.eclair
eclair.headless | Run eclair without a GUI |
eclair.printToConsole | Log to stdout (in addition to eclair.log) |
For example, to specify a different data directory you would run the following command:
```shell
java -Declair.datadir=/tmp/node1 -jar eclair-node-gui-< version > -< commit_id > .jar
```
2018-08-30 13:00:24 +01:00
#### Logging
Eclair uses [`logback` ](https://logback.qos.ch ) for logging. To use a different configuration, and override the internal logback.xml, run:
```shell
java -Dlogback.configurationFile=/path/to/logback-custom.xml -jar eclair-node-gui-< version > -< commit_id > .jar
```
2016-10-18 16:37:32 +02:00
## JSON-RPC API
2018-02-27 19:36:56 +01:00
method | params | description
------------- |----------------------------------------------------------------------------------------|-----------------------------------------------------------
getinfo | | return basic node information (id, chain hash, current block height)
connect | nodeId, host, port | open a secure connection to a lightning node
connect | uri | open a secure connection to a lightning node
open | nodeId, fundingSatoshis, pushMsat = 0, feerateSatPerByte = ?, channelFlags = 0x01 | open a channel with another lightning node, by default push = 0, feerate for the funding tx targets 6 blocks, and channel is announced
Audit: Keep track of sent/received/relayed payments and relay/network fees (#654)
Added a new `AuditDb` which keeps tracks of:
- every single payment (received/sent/relayed)
- every single network fee paid to the miners (funding, closing, and all commit/htlc transactions)
Note that network fees are considered paid when the corresponding tx has reached `min_depth`, it makes sense and allows us to compute the fee in one single place in the `CLOSING` handler. There is an exception for the funding tx, for which we consider the fee paid when the tx has successfully been published to the network. It simplifies the implementation and the tradeoff seems acceptable.
Three new functions have been added to the json-rpc api:
- `audit`: returns all individual payments, with optional filtering on timestamp.
- `networkfees`: returns every single fee paid to the miners, by type (`funding`, `mutual`, `revoked-commit`, etc.) and by channel, with optional filtering on timestamp.
- `channelstats`: maybe the most useful method; it returns a number of information per channel, including the `relayFee` (earned) and the `networkFee` (paid).
The `channels` method now returns details information about channels. It makes it far easier to compute aggregate information about channels using the command line.
Also added a new `ChannelFailed` event that allows e.g. the mobile app to know why a channel got closed.
2018-07-25 16:47:38 +02:00
updaterelayfee | channelId, feeBaseMsat, feeProportionalMillionths | update relay fee for payments going through this channel
2018-02-27 19:36:56 +01:00
peers | | list existing local peers
channels | | list existing local channels
channels | nodeId | list existing local channels opened with a particular nodeId
channel | channelId | retrieve detailed information about a given channel
Audit: Keep track of sent/received/relayed payments and relay/network fees (#654)
Added a new `AuditDb` which keeps tracks of:
- every single payment (received/sent/relayed)
- every single network fee paid to the miners (funding, closing, and all commit/htlc transactions)
Note that network fees are considered paid when the corresponding tx has reached `min_depth`, it makes sense and allows us to compute the fee in one single place in the `CLOSING` handler. There is an exception for the funding tx, for which we consider the fee paid when the tx has successfully been published to the network. It simplifies the implementation and the tradeoff seems acceptable.
Three new functions have been added to the json-rpc api:
- `audit`: returns all individual payments, with optional filtering on timestamp.
- `networkfees`: returns every single fee paid to the miners, by type (`funding`, `mutual`, `revoked-commit`, etc.) and by channel, with optional filtering on timestamp.
- `channelstats`: maybe the most useful method; it returns a number of information per channel, including the `relayFee` (earned) and the `networkFee` (paid).
The `channels` method now returns details information about channels. It makes it far easier to compute aggregate information about channels using the command line.
Also added a new `ChannelFailed` event that allows e.g. the mobile app to know why a channel got closed.
2018-07-25 16:47:38 +02:00
channelstats | | retrieves statistics about channel usage (fees, number and average amount of payments)
2018-02-27 19:36:56 +01:00
allnodes | | list all known nodes
allchannels | | list all known channels
allupdates | | list all channels updates
allupdates | nodeId | list all channels updates for this nodeId
receive | description | generate a payment request without a required amount (can be useful for donations)
receive | amountMsat, description | generate a payment request for a given amount
2018-06-19 12:13:07 +01:00
receive | amountMsat, description, expirySeconds | generate a payment request for a given amount that expires after given number of seconds
2018-03-24 09:51:15 +00:00
checkinvoice | paymentRequest | returns node, amount and payment hash in an invoice/paymentRequest
findroute | paymentRequest|nodeId | given a payment request or nodeID checks if there is a valid payment route returns JSON with attempts, nodes and channels of route
2018-02-27 19:36:56 +01:00
send | amountMsat, paymentHash, nodeId | send a payment to a lightning node
send | paymentRequest | send a payment to a lightning node using a BOLT11 payment request
send | paymentRequest, amountMsat | send a payment to a lightning node using a BOLT11 payment request and a custom amount
checkpayment | paymentHash | returns true if the payment has been received, false otherwise
checkpayment | paymentRequest | returns true if the payment has been received, false otherwise
close | channelId | close a channel
close | channelId, scriptPubKey | close a channel and send the funds to the given scriptPubKey
2018-03-15 18:53:14 +01:00
forceclose | channelId | force-close a channel by publishing the local commitment tx (careful: this is more expensive than a regular close and will incur a delay before funds are spendable)"
Audit: Keep track of sent/received/relayed payments and relay/network fees (#654)
Added a new `AuditDb` which keeps tracks of:
- every single payment (received/sent/relayed)
- every single network fee paid to the miners (funding, closing, and all commit/htlc transactions)
Note that network fees are considered paid when the corresponding tx has reached `min_depth`, it makes sense and allows us to compute the fee in one single place in the `CLOSING` handler. There is an exception for the funding tx, for which we consider the fee paid when the tx has successfully been published to the network. It simplifies the implementation and the tradeoff seems acceptable.
Three new functions have been added to the json-rpc api:
- `audit`: returns all individual payments, with optional filtering on timestamp.
- `networkfees`: returns every single fee paid to the miners, by type (`funding`, `mutual`, `revoked-commit`, etc.) and by channel, with optional filtering on timestamp.
- `channelstats`: maybe the most useful method; it returns a number of information per channel, including the `relayFee` (earned) and the `networkFee` (paid).
The `channels` method now returns details information about channels. It makes it far easier to compute aggregate information about channels using the command line.
Also added a new `ChannelFailed` event that allows e.g. the mobile app to know why a channel got closed.
2018-07-25 16:47:38 +02:00
audit | | list all send/received/relayed payments
audit | from, to | list send/received/relayed payments in that interval (from < = timestamp < to )
networkfees | | list all network fees paid to the miners, by transaction
networkfees |from, to | list network fees paid to the miners, by transaction, in that interval (from < = timestamp < to )
2018-02-27 19:36:56 +01:00
help | | display available methods
2016-02-16 17:55:10 +01:00
2017-12-08 23:36:50 +09:00
## Docker
2018-04-13 13:53:30 +02:00
A [Dockerfile ](Dockerfile ) image is built on each commit on [docker hub ](https://hub.docker.com/r/acinq/eclair ) for running a dockerized eclair-node.
2017-12-08 23:36:50 +09:00
You can use the `JAVA_OPTS` environment variable to set arguments to `eclair-node` .
```
2018-05-04 01:56:45 -07:00
docker run -ti --rm -e "JAVA_OPTS=-Xmx512m -Declair.api.binding-ip=0.0.0.0 -Declair.node-alias=node-pm -Declair.printToConsole" acinq/eclair
2017-12-08 23:36:50 +09:00
```
If you want to persist the data directory, you can make the volume to your host with the `-v` argument, as the following example:
```
2018-05-04 01:56:45 -07:00
docker run -ti --rm -v "/path_on_host:/data" -e "JAVA_OPTS=-Declair.printToConsole" acinq/eclair
2017-12-08 23:36:50 +09:00
```
2018-03-28 20:21:19 +02:00
## Mainnet usage
Following are the minimum configuration files you need to use for Bitcoin Core and Eclair.
### Bitcoin Core configuration
```
testnet=0
server=1
rpcuser=< your-rpc-user-here >
rpcpassword=< your-rpc-password-here >
txindex=1
zmqpubrawblock=tcp://127.0.0.1:29000
zmqpubrawtx=tcp://127.0.0.1:29000
addresstype=p2sh-segwit
```
Update Android branch (#746)
* Fixed regression in rebroadcast (#713)
Fixed regression caused by 2c1811d: we now don't force sending a
channel_update at the same time with channel_announcement.
This greatly simplifies the rebroadcast logic, and is what caused the
integration test to fail.
Added proper test on Peer, testing the actor, not only static methods.
* Routing sync fixes (#712)
* Router: reset sync state on reconnection
When we're reconnected to a peer we will start a new sync process and should reset our sync
state with that peer.
* Ignore 'origin htlc not found' in CLOSING (#708)
If we don't have the origin, it means that we already have forwarded the fulfill so that's not a big deal.
This can happen if they send a signature containing the fulfill, then fail the channel before we have time to sign it.
* Fix handling of born again channels (#717)
* 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)
* Replace `update_fee` in commitments (#709)
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.
* Tests: use bitcoind 0.16.3 (#715)
Bitcoind 0.16.0 is no longer available
* Make `publishTransaction` idempotent (#711)
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.
* Improved eclair-cli (#718)
This fixes #695, and also adds the channel point in the default channel output.
```bash
$ ./eclair-cli channel 00fd4d56d94af93765561bb6cb081f519b9627d3f455eba3215a7846a1af0e46
{
"nodeId": "0232e20e7b68b9b673fb25f48322b151a93186bffe4550045040673797ceca43cf",
"shortChannelId": "845230006070001",
"channelId": "00fd4d56d94af93765561bb6cb081f519b9627d3f455eba3215a7846a1af0e46",
"state": "NORMAL",
"balanceSat": 9858759,
"capacitySat": 10000000,
"channelPoint": "470eafa146785a21a3eb55f4d327969b511f08cbb61b566537f94ad9564dfd00:1"
}
```
* Handle update relay fee in OFFLINE state (#719)
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.
* Fixed regression caused by 7a4f175 (#722)
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.
* Logging: use a rolling file appender (#721)
* Logging: use a rolling file appender
Use one file per day, keep 90 days of logs with a total maximum size
capped at 5 Gb
* Router: log routing broadcast in debug level only
* set version to 0.2-beta6
* set version back to 0.2-SNAPSHOT
* Simplify bitcoind version check (#731)
Bitcoind returns version as MMmmrr (major, minor, revision), use an int representation
and compare it to our minimum version target.
* Update scalatest and remove junit runner (#728)
* 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).
* Add instructions for Bitcoin Core 0.17.0 [ci skip] (#732)
* Add instructions for Bitcoin Core 0.17.0 [ci skip]
Bitcoin Core 0.17.0 deprecates the `signrawtransaction` RPC call, which will be removed in version 0.18.0, you need to enable this call if you want your eclair node to use a 0.1.70 node.
* README: add an example of how to use the new bitcoin.conf sections [ci skip]
* Only persist trimmed htlcs (#724)
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.
* set version to 0.2-beta7
* set version to 0.2-SNAPSHOT
* Add `htlcMaximumMsat` field to `ChannelUpdate` message (#738)
* Add `htlcMaximumMsat` field to `ChannelUpdate` message
* added compatibility test with c-lightning
* Fix encoding of FinalIncorrectHtlcAmount error message (#740)
* set version to 0.2-beta8
* set version to 0.2-SNAPSHOT
* Always add 1 block to the `finalCltvExpiry` (#742)
This fixes #651.
* ignore IntegrationSpec (no server on android)
* back to SNAPSHOT
* use proper [gs]etNullableLong method for Sqlite
2018-10-25 17:50:48 +02:00
:warning: If you are using Bitcoin Core 0.17.0 you need to add following line to your `bitcoin.conf` :
```
deprecatedrpc=signrawtransaction
```
You may also want to take advantage of the new configuration sections in `bitcoin.conf` to manage parameters that are network speficic, so you can reasliy run your bitcoin node on both mainnet and testnet. For example you could use:
```
server=1
txindex=1
addresstype=p2sh-segwit
deprecatedrpc=signrawtransaction
[main]
rpcuser=< your-mainnet-rpc-user-here >
rpcpassword=< your-mainnet-rpc-password-here >
zmqpubrawblock=tcp://127.0.0.1:29000
zmqpubrawtx=tcp://127.0.0.1:29000
[test]
rpcuser=< your-testnet-rpc-user-here >
rpcpassword=< your-testnet-rpc-password-here >
zmqpubrawblock=tcp://127.0.0.1:29001
zmqpubrawtx=tcp://127.0.0.1:29001
```
2018-03-28 20:21:19 +02:00
### Eclair configuration
```
eclair.chain=mainnet
eclair.bitcoind.rpcport=8332
Update Android branch (#746)
* Fixed regression in rebroadcast (#713)
Fixed regression caused by 2c1811d: we now don't force sending a
channel_update at the same time with channel_announcement.
This greatly simplifies the rebroadcast logic, and is what caused the
integration test to fail.
Added proper test on Peer, testing the actor, not only static methods.
* Routing sync fixes (#712)
* Router: reset sync state on reconnection
When we're reconnected to a peer we will start a new sync process and should reset our sync
state with that peer.
* Ignore 'origin htlc not found' in CLOSING (#708)
If we don't have the origin, it means that we already have forwarded the fulfill so that's not a big deal.
This can happen if they send a signature containing the fulfill, then fail the channel before we have time to sign it.
* Fix handling of born again channels (#717)
* 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)
* Replace `update_fee` in commitments (#709)
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.
* Tests: use bitcoind 0.16.3 (#715)
Bitcoind 0.16.0 is no longer available
* Make `publishTransaction` idempotent (#711)
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.
* Improved eclair-cli (#718)
This fixes #695, and also adds the channel point in the default channel output.
```bash
$ ./eclair-cli channel 00fd4d56d94af93765561bb6cb081f519b9627d3f455eba3215a7846a1af0e46
{
"nodeId": "0232e20e7b68b9b673fb25f48322b151a93186bffe4550045040673797ceca43cf",
"shortChannelId": "845230006070001",
"channelId": "00fd4d56d94af93765561bb6cb081f519b9627d3f455eba3215a7846a1af0e46",
"state": "NORMAL",
"balanceSat": 9858759,
"capacitySat": 10000000,
"channelPoint": "470eafa146785a21a3eb55f4d327969b511f08cbb61b566537f94ad9564dfd00:1"
}
```
* Handle update relay fee in OFFLINE state (#719)
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.
* Fixed regression caused by 7a4f175 (#722)
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.
* Logging: use a rolling file appender (#721)
* Logging: use a rolling file appender
Use one file per day, keep 90 days of logs with a total maximum size
capped at 5 Gb
* Router: log routing broadcast in debug level only
* set version to 0.2-beta6
* set version back to 0.2-SNAPSHOT
* Simplify bitcoind version check (#731)
Bitcoind returns version as MMmmrr (major, minor, revision), use an int representation
and compare it to our minimum version target.
* Update scalatest and remove junit runner (#728)
* 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).
* Add instructions for Bitcoin Core 0.17.0 [ci skip] (#732)
* Add instructions for Bitcoin Core 0.17.0 [ci skip]
Bitcoin Core 0.17.0 deprecates the `signrawtransaction` RPC call, which will be removed in version 0.18.0, you need to enable this call if you want your eclair node to use a 0.1.70 node.
* README: add an example of how to use the new bitcoin.conf sections [ci skip]
* Only persist trimmed htlcs (#724)
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.
* set version to 0.2-beta7
* set version to 0.2-SNAPSHOT
* Add `htlcMaximumMsat` field to `ChannelUpdate` message (#738)
* Add `htlcMaximumMsat` field to `ChannelUpdate` message
* added compatibility test with c-lightning
* Fix encoding of FinalIncorrectHtlcAmount error message (#740)
* set version to 0.2-beta8
* set version to 0.2-SNAPSHOT
* Always add 1 block to the `finalCltvExpiry` (#742)
This fixes #651.
* ignore IntegrationSpec (no server on android)
* back to SNAPSHOT
* use proper [gs]etNullableLong method for Sqlite
2018-10-25 17:50:48 +02:00
eclair.bitcoind.rpcuser=< your-mainnet-rpc-user-here >
eclair.bitcoind.rpcpassword=< your-mainnet-rpc-password-here >
2018-03-28 20:21:19 +02:00
```
2016-07-22 16:33:21 +02:00
## Resources
2018-01-11 19:23:17 +01:00
- [1] [The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments ](https://lightning.network/lightning-network-paper.pdf ) by Joseph Poon and Thaddeus Dryja
- [2] [Reaching The Ground With Lightning ](https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf ) by Rusty Russell
2017-12-23 18:32:13 +01:00
- [3] [Lightning Network Explorer ](https://explorer.acinq.co ) - Explore testnet LN nodes you can connect to