lightningd -- Daemon for running a Lightning Network node

SYNOPSIS

lightningd [--conf=<config-file>] [OPTIONS]

DESCRIPTION

lightningd starts the Core Lightning daemon, which implements a
standards-compliant Lightning Network node.

CONFIGURATION OPTIONS

--conf=FILE
Specify configuration file. If not an absolute path, will be relative
from the lightning-dir location. Defaults to config.
--lightning-dir=DIR
Set the directory for the Core Lightning daemon. Defaults to
$HOME/.lightning.

MORE OPTIONS

Command line options are mirrored as configuration options in the
configuration file, so foo in the configuration file simply becomes
--foo on the command line, and foo=bar becomes --foo=bar.

See lightningd-config(5) for a comprehensive list of all available
options.

LOGGING AND COMMANDING CORE LIGHTNING

By default, Core Lightning will log to the standard output.
To log to a specific file, use --log-file=PATH.
Sending SIGHUP will cause Core Lightning to reopen this file,
for example to do log rotation.

Core Lightning will set up a Unix domain socket for receiving
commands.
By default this will be the file lightning-rpc in your
specified lightning-dir.
You can use lightning-cli(1) to send commands to Core Lightning
once lightningd has started; you need to match the
--lightning-dir and --rpc-file options between them.

Commands for Core Lightning are described in various manpages
in section 7, with the common prefix lightning-.

QUICK START

First, decide on and create a directory for lightning-dir, or just use
the default $HOME/.lightning. Then create a config file in this
directory containing your configuration.

Your other main preparation would be to set up a mainnet Bitcoin
fullnode, i.e. run a bitcoind(1) instance. The rest of this quick start
guide will assume you are reckless and want to spend real funds on
Lightning: otherwise indicate network=testnet in your config file explicitly.

Core Lightning needs to communicate with the Bitcoin Core RPC. You can set
this up using bitcoin-datadir, bitcoin-rpcconnect,
bitcoin-rpcport, bitcoin-rpcuser, and bitcoin-rpcpassword options
in your config file.

Finally, just to keep yourself sane, decide on a log file name and
indicate it using log-file=lightningd.log in your config file. You
might be interested in viewing it periodically as you follow along on
this guide.

Once the bitcoind instance is running, start lightningd(8):

$ lightningd --lightning-dir=$HOME/.lightning --daemon

This starts lightningd in the background due to the --daemon
option.

Check if things are working:

$ lightning-cli --lightning-dir=$HOME/.lightning help
$ lightning-cli --lightning-dir=$HOME/.lightning getinfo

The getinfo command in particular will return a blockheight field,
which indicates the block height to which lightningd has been
synchronized to (this is separate from the block height that your
bitcoind has been synchronized to, and will always lag behind
bitcoind). You will have to wait until the blockheight has reached
the actual blockheight of the Bitcoin network.

Before you can get funds offchain, you need to have some funds onchain
owned by lightningd (which has a separate wallet from the
bitcoind it connects to). Get an address for lightningd via
lightning-newaddr(7) command as below (--lightning-dir option has been
elided, specify it if you selected your own lightning-dir):

$ lightning-cli newaddr

This will provide a native SegWit bech32 address. Alternatively you can
generate a taproot address with:

$ lightning-cli newaddr p2tr

Transfer a small amount of onchain funds to the given address. Check the
status of all your funds (onchain and on-Lightning) via
lightning-listfunds(7):

$ lightning-cli listfunds

Now you need to look for an arbitrary Lightning node to connect to,
which you can do by using dig(1) and querying lseed.bitcoinstats.com:

$ dig lseed.bitcoinstats.com A

This will give 25 IPv4 addresses, you can select any one of those. You
will also need to learn the corresponding public key, which you can
determine by searching the IP addrss on https://1ml.com/ . The public
key is a long hex string, like so:
024772ee4fa461febcef09d5869e1238f932861f57be7a6633048514e3f56644a1.
(this example public key is not used as of this writing)

After determining a public key, use lightning-connect(7) to connect to
that public key at that IP:

$ lightning-cli connect $PUBLICKEY $IP

Then open a channel to that node using lightning-fundchannel(7):

$ lightning-cli fundchannel $PUBLICKEY $SATOSHI

This will require that the funding transaction be confirmed before you
can send funds over Lightning. To track this, use lightning-listpeers(7)
and look at the state of the channel:

$ lightning-cli listpeers $PUBLICKEY

The channel will initially start with a state of
CHANNELD_AWAITING_LOCKIN. You need to wait for the channel state
to become CHANNELD_NORMAL, meaning the funding transaction has been
confirmed deeply.

Once the channel state is CHANNELD_NORMAL, you can start paying
merchants over Lightning. Acquire a Lightning invoice from your favorite
merchant, and use lightning-pay(7) to pay it:

$ lightning-cli pay $INVOICE

ERRORS CODE

1: Generic lightning-cli error
10: Error executing subdaemons
11: Error locking pidfile (often another lightningd running)
20: Generic error related to HSM secret
21: HSM secret is encrypted
22: Bad password used to decrypt the HSM secred
23: Error caused from the I/O operation during a HSM decryption/encryption operation
30: Wallet database does not match (network or hsm secret)

BUGS

You should report bugs on our github issues page, and maybe submit a fix
to gain our eternal gratitude!

AUTHOR

ZmnSCPxj <[email protected]> wrote the initial version of
this man page, but many others did the hard work of actually
implementing a standards-compliant Lightning Network node
implementation.

RESOURCES

Main web site: https://github.com/ElementsProject/lightning

COPYING

Note: the modules in the ccan/ directory have their own licenses, but
the rest of the code is covered by the BSD-style MIT license.