2016-10-18 16:37:32 +02:00
![Eclair Logo ](.readme/logo.png )
2016-01-21 15:39:56 +01:00
2020-07-02 11:02:47 +02:00
[![Build Status ](https://github.com/ACINQ/eclair/workflows/Build%20&%20Test/badge.svg )](https://github.com/ACINQ/eclair/actions?query=workflow%3A%22Build+%26+Test%22)
2019-05-09 11:42:38 +02:00
[![codecov ](https://codecov.io/gh/acinq/eclair/branch/master/graph/badge.svg )](https://codecov.io/gh/acinq/eclair)
2017-03-17 19:07:29 +01:00
[![License ](https://img.shields.io/badge/license-Apache%202.0-blue.svg )](LICENSE)
2016-01-21 15:39:56 +01:00
2020-05-05 11:51:39 +02:00
**Eclair** (French for Lightning) is a Scala implementation of the Lightning Network.
2016-01-21 15:39:56 +01:00
2022-12-30 11:14:56 +01:00
This software follows the [Lightning Network Specifications (BOLTs) ](https://github.com/lightning/bolts ).
Other implementations include [core lightning ](https://github.com/ElementsProject/lightning ), [lnd ](https://github.com/LightningNetwork/lnd ), [electrum ](https://github.com/spesmilo/electrum/ ), and [ldk ](https://github.com/lightningdevkit/rust-lightning ).
2019-07-31 15:35:26 +02:00
---
2021-09-03 14:11:48 +02:00
* [Lightning Network Specification Compliance ](#lightning-network-specification-compliance )
* [JSON API ](#json-api )
* [Documentation ](#documentation )
* [Installation ](#installation )
* [Prerequisite: Bitcoin Core ](#prerequisite-bitcoin-core )
* [Installing Eclair ](#installing-eclair )
* [Configuration ](#configuration )
* [Configuration file ](#configuration-file )
* [Configure Bitcoin Core wallet ](#configure-bitcoin-core-wallet )
* [Java Environment Variables ](#java-environment-variables )
* [Logging ](#logging )
* [Backup ](#backup )
* [Docker ](#docker )
* [Plugins ](#plugins )
* [Testnet usage ](#testnet-usage )
2022-02-06 20:28:50 +01:00
* [Tools ](#tools )
2021-09-03 14:11:48 +02:00
* [Resources ](#resources )
2016-10-18 16:23:31 +02:00
---
2017-03-17 19:07:29 +01:00
## Lightning Network Specification Compliance
2019-07-31 15:35:26 +02:00
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
2019-03-26 18:29:23 +01:00
## JSON API
2021-02-08 11:20:23 +01:00
Eclair offers a feature-rich HTTP API that enables application developers to easily integrate.
2019-03-26 18:29:23 +01:00
For more information please visit the [API documentation website ](https://acinq.github.io/eclair ).
2021-07-16 17:32:34 +02:00
:rotating_light: Eclair's JSON API should **NOT** be accessible from the outside world (similarly to Bitcoin Core API)
2019-07-31 15:35:26 +02:00
## Documentation
2022-02-06 20:28:50 +01:00
Please visit our [docs ](./docs ) folder to find detailed instructions on how to [configure ](./docs/Configure.md ) your
2022-11-14 13:47:48 +01:00
node, connect to other nodes, open channels, send and receive payments, and help with more advanced scenarios.
2019-07-31 15:35:26 +02:00
2022-02-06 20:28:50 +01:00
You will also find detailed [guides ](./docs/Guides.md ) and [frequently asked questions ](./docs/FAQ.md ) there.
2019-07-31 15:35:26 +02:00
2016-10-18 16:23:31 +02:00
## Installation
2016-01-21 15:39:56 +01:00
2021-07-16 17:32:34 +02:00
### Prerequisite: Bitcoin Core
2016-02-16 18:03:40 +01:00
2022-11-03 09:04:20 +01:00
Eclair relies on Bitcoin Core to interface with and monitor the blockchain and to manage on-chain funds: Eclair does not include an on-chain wallet, channel opening transactions are funded by your Bitcoin Core node, and channel closing transactions return funds to your Bitcoin Core node.
2018-03-26 20:56:51 +02:00
2022-11-03 09:04:20 +01:00
This means that instead of re-implementing them, Eclair benefits from the verifications and optimisations (including fee management with RBF/CPFP, ...) that are implemented by Bitcoin Core. Eclair uses our own [bitcoin library ](https://github.com/ACINQ/bitcoin-kmp ) to verify data provided by Bitcoin Core.
2020-09-28 12:07:15 +02:00
2022-11-14 13:47:48 +01:00
:warning: This also means that Eclair has strong requirements on how your Bitcoin Core node is configured (see below), and that you must back up your Bitcoin Core wallet as well as your Eclair node (see [here ](#configure-bitcoin-core-wallet )):
* Eclair needs a _synchronized_ , _segwit-ready_ , **_zeromq-enabled_** , _wallet-enabled_ , _non-pruning_ , _tx-indexing_ [Bitcoin Core ](https://github.com/bitcoin/bitcoin ) node.
2022-11-30 15:44:40 +01:00
* You must configure your Bitcoin node to use `bech32` or `bech32m` (segwit) addresses. If your wallet has "non-segwit UTXOs" (outputs that are neither `p2sh-segwit` , `bech32` or `bech32m` ), you must send them to a `bech32` or `bech32m` address before running Eclair.
2023-08-16 17:10:03 +02:00
* Eclair requires Bitcoin Core 24.1 or higher. If you are upgrading an existing wallet, you may need to create a new address and send all your funds to that address.
2016-02-17 16:45:24 +01:00
2017-03-31 18:08:59 +02:00
Run bitcoind with the following minimal `bitcoin.conf` :
2019-07-31 15:35:26 +02:00
```conf
2016-10-18 16:23:31 +02:00
server=1
2018-01-18 15:25:12 +01:00
rpcuser=foo
rpcpassword=bar
2017-03-17 19:07:29 +01:00
txindex=1
2022-11-30 15:44:40 +01:00
addresstype=bech32
changetype=bech32
2021-08-30 18:08:22 +02:00
zmqpubhashblock=tcp://127.0.0.1:29000
2017-03-31 18:08:59 +02:00
zmqpubrawtx=tcp://127.0.0.1:29000
2016-02-16 17:55:10 +01:00
```
2016-10-18 16:23:31 +02:00
2021-09-03 14:11:48 +02:00
Depending on the actual hardware configuration, it may be useful to provide increased `dbcache` parameter value for faster verification and `rpcworkqueue` parameter value for better handling of API requests on `bitcoind` side.
2021-08-25 09:14:20 +02:00
```conf
# UTXO database cache size, in MiB
dbcache=2048
# Number of allowed pending RPC requests (default is 16)
rpcworkqueue=128
# How many seconds bitcoin will wait for a complete RPC HTTP request.
# after the HTTP connection is established.
rpcclienttimeout=30
```
2017-03-17 19:07:29 +01:00
### Installing Eclair
2016-10-18 16:23:31 +02:00
2020-05-05 11:51:39 +02:00
Eclair is developed in [Scala ](https://www.scala-lang.org/ ), a powerful functional language that runs on the JVM, and is packaged as a ZIP archive.
2017-08-17 13:04:43 +02:00
2021-02-08 11:20:23 +01:00
To run Eclair, you first need to install Java, we recommend that you use [OpenJDK 11 ](https://adoptopenjdk.net/?variant=openjdk11&jvmVariant=hotspot ). Other runtimes also work, but we don't recommend using them.
2017-03-17 19:07:29 +01:00
2020-05-05 11:51:39 +02:00
Then download our latest [release ](https://github.com/ACINQ/eclair/releases ), unzip the archive and run the following command:
2019-07-31 15:35:26 +02:00
2016-10-18 16:23:31 +02:00
```shell
2020-02-24 15:42:26 +01:00
eclair-node-< version > -< commit_id > /bin/eclair-node.sh
2016-11-14 17:19:29 +01:00
```
2016-02-16 18:03:40 +01:00
2022-02-06 20:28:50 +01:00
You can then control your node via [eclair-cli ](./docs/Usage.md ) or the [API ](./docs/API.md ).
2020-05-05 11:51:39 +02:00
2021-09-03 14:11:48 +02:00
:warning: Be careful when following tutorials/guides that may be outdated or incomplete. You must thoroughly read the official eclair documentation before running your own node.
2021-07-16 17:32:34 +02:00
## Configuration
2017-03-17 19:07:29 +01:00
2021-07-16 17:32:34 +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
2019-07-31 15:35:26 +02:00
```conf
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
2022-08-19 11:15:05 +02:00
name | description | default value
-----------------------------|----------------------------------------------------------------------|--------------
eclair.chain | Which blockchain to use: *regtest* , *testnet* , *signet* or *mainnet* | mainnet
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
eclair.bitcoind.zmqblock | Bitcoin Core ZMQ block address | "tcp://127.0.0.1:29000"
eclair.bitcoind.zmqtx | Bitcoin Core ZMQ tx address | "tcp://127.0.0.1:29000"
eclair.bitcoind.wallet | Bitcoin Core wallet name | ""
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 ).
2020-10-23 09:31:34 +02:00
→ see [here ](./docs/Configure.md ) for more configuration options.
2016-10-18 16:23:31 +02:00
2021-07-16 17:32:34 +02:00
### Configure Bitcoin Core wallet
2020-09-28 12:07:15 +02:00
Eclair will use the default loaded Bitcoin Core wallet to fund any channels you choose to open.
If you want to use a different wallet from the default one, you must set `eclair.bitcoind.wallet` accordingly in your `eclair.conf` .
:warning: Once a wallet is configured, you must be very careful if you want to change it: changing the wallet when you have channels open may result in a loss of funds (or a complex recovery procedure).
Eclair will return BTC from closed channels to the wallet configured.
Any BTC found in the wallet can be used to fund the channels you choose to open.
2023-05-04 18:20:27 +02:00
We also recommend tweaking the following parameters in `bitcoin.conf` :
```conf
# This parameter ensures that your wallet will not create chains of unconfirmed
# transactions that would be rejected by other nodes.
walletrejectlongchains=1
# The following parameters set the maximum length of chains of unconfirmed
# transactions to 20 instead of the default value of 25.
limitancestorcount=20
limitdescendantcount=20
```
Setting these parameters lets you unblock long chains of unconfirmed channel funding transactions by using child-pays-for-parent (CPFP) to make them confirm.
Delegate Bitcoin Core's private key management to Eclair (#2613)
* Make Eclair manage bitcoin core's wallet private keys
We create an empty watch-only wallet and import public descriptors generated by Eclair.
Bitcoin Core can fund transaction and manage utxos, but can no longer sign transactions.
* Check that spent amounts and utxos are consistent before we sign a PSBT
PSBT utxo fields include the amount that are being spent by the PSBT inputs, but there is a "fee attack"
where using amounts that are lower than what is actually spent may make us sign a tx that spends much more
in fees than we think.
* Check that non-segwit uxto has been provided and inputs are signed with SIGHASH_ALL
* Verify that Bitcoin Core's fee match what we specified
When we call Bitcoin Core's `fundrawtransaction` RPC method, we check that the fee that we pay match the fee rate that we requested.
The fee is computed using the utxo information that Bitcoin Core adds to our PSBT before we sign it.
We can safely used this information because if Bitcoin Core lies about the value of the inputs that we're spending then the signature we produce will also not be valid (it commits to the value being spent).
When we're adding wallet inputs to "bump" the fees of a parent transaction we need to take the whole package into account when we verify the actual fee rate, which is why some internal methods were modified to return the package weight that was used as reference when `fundrawtransaction` was called.
* Check that fundrawtransaction does not add more than 1 change output
* Validate addresses and keys generated by bitcoin core
When eclair manages private keys, make sure that we can re-compute addresses and keys
generated by bitcoin core.
* Add a separate configuration file for Eclair's onchain signer
Eclair's onchain signer now has its own `eclair-signer.conf` configuration file in HOCON format.
It includes BIP39 mnemonic codes and passphrase, a wallet name and a timestamp.
When an `eclair-signer.conf` file is found, Eclair's API will return descriptors that can be imported into an
empty watch-only Bitcoin Wallet.
When wallet name in `eclair-signer.conf` matches the name of the Bitcoin Core wallet defined in `eclair.conf`
(`eclair.bitcoind.wallet`), Eclair will bypass Bitcoin Core and sign onchain transactions directly.
* Skip validation of local non-change outputs:
Local non-change outputs send to an external address, for splicing out funds for example.
We assume that these inputs are trusted i.e have been created by a trusted API call and our local
onchain key manager will not validate them during the signing process.
* Document why we use a separate, specific file for the onchain key manager
Using a new signer section is eclair.conf would be simpler but "leaks" because it becomes available everywhere
in the code through the actor system's settings instead of being contained to where it is actually needed
and could potentially be exposed through a bug that "exports" the configuration (through logs, ....)
though this is highly unlikely.
* Additional changes to delegate bitcoin core keys to eclair (#2726)
Refactor the `BitcoinCoreClient` and `LocalOnChainKeyManager` to:
- rely less on exceptions
- use more idiomatic scala (reduce dependency on kotlin types)
- provide more detailed logs
We also simplify the `useEclairSigner` field in `BitcoinCoreClient`.
The complexity of handling the case where there was an on-chain key
manager but for a different wallet than the one configured isn't
something that should be used, so it wasn't worth supporting.
Some checks were inconsistent and are now unified:
- checking the exact `scriptPubKey` in our outputs in TODO and TODO
- we allow using `fundTransaction` with a tx that already includes a
change output (which may happen when RBF-ing a transaction)
- `getP2wpkhPubkeyHashForChange` didn't verify the returned key
We completely separate the two cases in `signPsbt`, because otherwise
in the non eclair-backed case, we were calling bitcoind's `processpsbt`
twice for no good reason, which is bad for performance.
We also decouple the `OnChainKeyManager` from the `BitcoinCoreClient`.
This lets users keep running their eclair node with a bitcoin client that
owns the private key while configuring the on-chain key manager for a
future bitcoin client that will leverage this on-chain key manager.
Users can use the eclair APIs to get the master xpub and descriptors to
properly configure their next bitcoin core node, and switch to it once it
has synchronized the descriptors.
* Simplify replaceable tx funding
We were previously signing twice (with makes a call to `bitcoind`),
just to get the final weights and adjust the change outputs. This was
unnecessary, as we can adjust the weights before adding inputs.
We were also duplicating the checks where we verify that `bitcoind` is
malicious. We only need to check that once, during the final signing step.
---------
Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
2023-09-21 15:54:28 +02:00
With the default `bitcoind` parameters, if your node created a chain of 25 unconfirmed funding transactions with a low-feerate, you wouldn't be able to use CPFP to raise their fees because your CPFP transaction would likely be rejected by
the rest of the network.
You can also configure Eclair to manage Bitcoin Core's private keys, see our [guides ](./docs/Guides.md ) for more details.
2023-05-04 18:20:27 +02:00
2021-07-16 17:32:34 +02:00
### Java Environment Variables
2017-08-30 13:42:58 +02:00
Some advanced parameters can be changed with java environment variables. Most users won't need this and can skip this section.
2021-08-25 09:14:20 +02:00
However, if you're seeing Java heap size errors, you can try increasing the maximum memory allocated to the JVM with the `-Xmx` parameter.
You can for example set it to use up to 512 MB (or any value that fits the amount of RAM on your machine) with:
```shell
export JAVA_OPTS=-Xmx512m
```
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.printToConsole | Log to stdout (in addition to eclair.log) |
For example, to specify a different data directory you would run the following command:
2019-07-31 15:35:26 +02:00
2017-08-30 13:42:58 +02:00
```shell
2020-02-24 15:42:26 +01:00
eclair-node-< version > -< commit_id > /bin/eclair-node.sh -Declair.datadir=/tmp/node1
2017-08-30 13:42:58 +02:00
```
2021-07-16 17:32:34 +02:00
### Logging
2018-08-30 14:00:24 +02:00
2022-02-06 20:28:50 +01:00
Eclair uses [`logback` ](https://logback.qos.ch ) for logging. To use a [different configuration ](./docs/Logging.md ), and override the internal logback.xml, run:
2018-08-30 14:00:24 +02:00
```shell
2020-02-24 15:42:26 +01:00
eclair-node-< version > -< commit_id > /bin/eclair-node.sh -Dlogback.configurationFile=/path/to/logback-custom.xml
2018-08-30 14:00:24 +02:00
```
2021-07-16 17:32:34 +02:00
### Backup
2019-04-19 22:35:12 +02:00
2022-01-24 16:32:13 +01:00
You need to backup:
2022-11-14 13:47:48 +01:00
* your Bitcoin Core wallet
* your Eclair channels
For Bitcoin Core, you need to backup the wallet file for the wallet that Eclair is using. You only need to do this once, when the wallet is
created. See [Managing Wallets ](https://github.com/bitcoin/bitcoin/blob/master/doc/managing-wallets.md ) in the Bitcoin Core documentation for more information.
2022-01-24 16:32:13 +01:00
2022-02-06 20:28:50 +01:00
For Eclair, the files that you need to backup are located in your data directory. You must backup:
2019-07-31 15:35:26 +02:00
2020-11-05 11:33:50 +01:00
* your seeds (`node_seed.dat` and `channel_seed.dat` )
2022-08-19 11:15:05 +02:00
* your channel database (`eclair.sqlite.bak` under directory `mainnet` , `testnet` , `signet` or `regtest` depending on which chain you're running on)
2019-04-19 22:35:12 +02:00
2020-11-05 11:33:50 +01:00
Your seeds never change once they have been created, but your channels will change whenever you receive or send payments. Eclair will
2019-07-31 15:35:26 +02:00
create and maintain a snapshot of its database, named `eclair.sqlite.bak` , in your data directory, and update it when needed. This file is
2021-02-08 11:20:23 +01:00
always consistent and safe to use even when Eclair is running, and this is what you should back up regularly.
2019-04-19 22:35:12 +02:00
2021-02-08 11:20:23 +01:00
For example, you could configure a `cron` task for your backup job. Or you could configure an optional notification script to be called by eclair once a new database snapshot has been created, using the following option:
2019-07-31 15:35:26 +02:00
```conf
2021-07-16 17:32:34 +02:00
eclair.file-backup.notify-script = "/absolute/path/to/script.sh"
2019-04-19 22:35:12 +02:00
```
2019-07-31 15:35:26 +02:00
2021-02-08 11:20:23 +01:00
Make sure your script is executable and uses an absolute path name for `eclair.sqlite.bak` .
2019-04-19 22:35:12 +02:00
2019-07-31 15:35:26 +02:00
Note that depending on your filesystem, in your backup process we recommend first moving `eclair.sqlite.bak` to some temporary file
2019-04-19 22:35:12 +02:00
before copying that file to your final backup location.
2017-12-08 15:36:50 +01:00
## Docker
2022-06-23 16:11:21 +02:00
A [Dockerfile ](Dockerfile ) x86_64 image is built on each commit on [docker hub ](https://hub.docker.com/r/acinq/eclair ) for running a dockerized eclair-node.
2022-11-14 13:47:48 +01:00
For arm64 platforms you can use an [arm64 Dockerfile ](contrib/arm64v8.Dockerfile ) to build your own arm64 container.
2017-12-08 15:36:50 +01:00
You can use the `JAVA_OPTS` environment variable to set arguments to `eclair-node` .
2019-07-31 15:35:26 +02:00
```shell
2018-05-04 10:56:45 +02: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 15:36:50 +01: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:
2019-07-31 15:35:26 +02:00
```shell
2018-05-04 10:56:45 +02:00
docker run -ti --rm -v "/path_on_host:/data" -e "JAVA_OPTS=-Declair.printToConsole" acinq/eclair
2017-12-08 15:36:50 +01:00
```
2022-02-06 20:28:50 +01:00
If you enabled the API you can check the status of Eclair using the command line tool:
2019-07-31 15:35:26 +02:00
```shell
2019-07-05 09:10:06 +02:00
docker exec < container_name > eclair-cli -p foobar getinfo
```
2019-04-19 18:10:47 +02:00
## Plugins
For advanced usage, Eclair supports plugins written in Scala, Java, or any JVM-compatible language.
2021-09-03 14:11:48 +02:00
A valid plugin is a jar that contains an implementation of the [Plugin ](eclair-node/src/main/scala/fr/acinq/eclair/Plugin.scala ) interface, and a manifest entry for `Main-Class` with the FQDN of the implementation.
2019-04-19 18:10:47 +02:00
Here is how to run Eclair with plugins:
2019-07-31 15:35:26 +02:00
2019-04-19 18:10:47 +02:00
```shell
2022-12-30 11:14:56 +01:00
eclair-node-< version > /bin/eclair-node.sh < plugin1.jar > < plugin2.jar > < ... >
2019-04-19 18:10:47 +02:00
```
2022-12-30 11:14:56 +01:00
You can find more details about plugins in the [eclair-plugins ](https://github.com/ACINQ/eclair-plugins ) repository.
2021-04-12 16:37:04 +02:00
2019-05-09 11:30:26 +02:00
## Testnet usage
2018-03-28 20:21:19 +02:00
2022-08-19 11:15:05 +02:00
Eclair is configured to run on mainnet by default, but you can still run it on testnet (or regtest/signet): start your Bitcoin node in
2019-05-09 11:30:26 +02:00
testnet mode (add `testnet=1` in `bitcoin.conf` or start with `-testnet` ), and change Eclair's chain parameter and Bitcoin RPC port:
2018-03-28 20:21:19 +02:00
2019-07-31 15:35:26 +02:00
```conf
2019-05-09 11:30:26 +02:00
eclair.chain=testnet
eclair.bitcoind.rpcport=18332
2018-10-15 14:28:19 +02:00
```
2022-08-19 11:15:05 +02:00
For regtest, add `regtest=1` in `bitcoin.conf` or start with `-regtest` , and modify `eclair.conf` :
```conf
eclair.chain = "regtest"
eclair.bitcoind.rpcport=18443
```
For signet, add `signet=1` in `bitcoin.conf` or start with `-signet` , and modify `eclair.conf` :
```conf
eclair.chain = "signet"
eclair.bitcoind.rpcport=38332
```
2019-07-31 15:35:26 +02:00
You may also want to take advantage of the new configuration sections in `bitcoin.conf` to manage parameters that are network specific,
2022-02-06 20:28:50 +01:00
so you can easily run your Bitcoin node on both mainnet and testnet. For example you could use:
2018-10-15 14:28:19 +02:00
2019-07-31 15:35:26 +02:00
```conf
2018-10-15 14:28:19 +02:00
server=1
txindex=1
2023-05-04 18:20:27 +02:00
2022-11-30 15:44:40 +01:00
addresstype=bech32
changetype=bech32
2022-08-19 11:15:05 +02:00
2023-05-04 18:20:27 +02:00
walletrejectlongchains=1
limitancestorcount=20
limitdescendantcount=20
2018-10-15 14:28:19 +02:00
[main]
rpcuser=< your-mainnet-rpc-user-here >
rpcpassword=< your-mainnet-rpc-password-here >
2021-08-30 18:08:22 +02:00
zmqpubhashblock=tcp://127.0.0.1:29000
2018-10-15 14:28:19 +02:00
zmqpubrawtx=tcp://127.0.0.1:29000
2022-08-19 11:15:05 +02:00
2018-10-15 14:28:19 +02:00
[test]
rpcuser=< your-testnet-rpc-user-here >
rpcpassword=< your-testnet-rpc-password-here >
2021-08-30 18:08:22 +02:00
zmqpubhashblock=tcp://127.0.0.1:29001
2018-10-15 14:28:19 +02:00
zmqpubrawtx=tcp://127.0.0.1:29001
```
2022-02-06 20:28:50 +01:00
## Tools
* [Demo Shop ](https://starblocks.acinq.co/ ) - an example testnet Lightning web shop.
* [Network Explorer ](https://explorer.acinq.co/ ) - a Lightning network visualization tool.
2016-07-22 16:33:21 +02:00
## Resources
2019-07-31 15:35:26 +02: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
* [3] [Lightning Network Explorer ](https://explorer.acinq.co ) - Explore testnet LN nodes you can connect to