There is a C-lightning plugin specifically for this purpose, it's called
helpme
.
Assuming you have followed the installation steps, have lightningd
up and running, and lightning-cli
in your $PATH
you can start the plugin like so:
# Clone the plugins repository
git clone https://github.com/lightningd/plugins
# Make sure the helpme plugin is executable (git should have already handled this)
chmod +x plugins/helpme/helpme.py
# Install its dependencies (there is only one actually)
pip3 install --user -r plugins/helpme/requirements.txt
# Then just start it :)
lightning-cli plugin start $PWD/plugins/helpme/helpme.py
The plugin registers a new command helpme
which will guide you through the main
components of C-lightning:
lightning-cli helpme
You can use the listfunds
command and take a ratio of our_amount_msat
over
amount_msat
. Note that this doesn't account for the channel reserve.
A better option is to use the summary
plugin
which nicely displays channel balances, along with other useful channel information.
See the listpeers command manpage.
There are many reasons for a payment failure. The most common one is a failure along the route from you to the payee. The best (and most common) solution to a route failure problem is to open more channels, which should increase the available routes to the recipient and lower the probability of a failure.
Hint: use the pay
command which is will iterate through trying all possible routes,
instead of the low-level sendpay
command which only tries the passed in route.
In order to receive payments you need inbound liquidity. You get inbound liquidity when another node opens a channel to you or by successfully completing a payment out through a channel you opened.
If you need a lot of inbound liquidity, you can use a service that trustlessly swaps on-chain Bitcoin for Lightning channel capacity. There are a few online service providers that will create channels to you. A few of them charge fees for this service. Note that if you already have a channel open to them, you'll need to close it before requesting another channel.
There is no risk to your channels if your IP address changes. Other nodes might not be able to connect to you, but your node can still connect to them. But Core Lightning also has an integrated IPv4/6 address discovery mechanism. If your node detects an new public address, it will update its announcement. For this to work binhind a NAT router you need to forward the TCP port 9735 to your node.
Alternatively, you can setup a TOR hidden service for your node that will also work well behind NAT firewalls.
Can I have two hosts with the same public key and different IP addresses, both online and operating at the same time?
No.
Yes. All bitcoind
calls are handled by the bundled bcli
plugin. lightningd
does not use
bitcoind
's wallet. While on the topic, lightningd
does not require the -txindex
option on bitcoind
.
If you use a single bitcoind
for multiple lightningd
's, be sure to raise the bitcoind
max RPC thread limit (-rpcthreads
), each lightningd
can use up to 4 threads, which is
the default bitcoind
max.
Spark-wallet is the most popular remote control
HTTP server for lightningd
.
Use it behind tor.
Effort has been made to get lightningd
running on Android,
see issue #3484. Currently unusable.
See BACKUP.md for a more comprehensive discussion of your options.
In summary: as a Bitcoin user, one may be familiar with a file or a seed (or some mnemonics) from which it can recover all its funds.
Core Lightning has an internal bitcoin wallet, which you can use to make "on-chain"
transactions, (see withdraw.
These on-chain funds are backed up via the HD wallet seed, stored in byte-form in hsm_secret
.
lightningd
also stores information for funds locked in Lightning Network channels, which are stored
in a database. This database is required for on-going channel updates as well as channel closure.
There is no single-seed backup for funds locked in channels.
While crucial for node operation, snapshot-style backups of the lightningd
database is discouraged,
as any loss of state may result in permanent loss of funds.
See the penalty mechanism
for more information on why any amount of state-loss results in fund loss.
Real-time database replication is the recommended approach to backing up node data.
Tools for replication are currently in active development, using the db_write
plugin hook.
There are 3 types of 'rescans' you can make:
rescanblockchain
: Abitcoind
RPC call which rescans the blockchain starting at the given height. This does not have an effect on Core Lightning aslightningd
tracks all block and wallet data independently.--rescan=depth
: Alightningd
configuration flag. This flag is read at node startup and tells lightningd at what depth from current blockheight to rebuild its internal state. (You can specify an exact block to start scanning from, instead of depth from current height, by using a negative number.)dev-rescan-outputs
: Alightningd
RPC call. Only available if your node has been configured and built in DEVELOPER mode (i.e../configure --enable-developer
) This will sync the state for known UTXOs in thelightningd
wallet withbitcoind
. As it only operates on outputs already seen on chain by thelightningd
internal wallet, this will not find missing wallet funds.
If you lose data (likely corrupted lightningd.sqlite3
) about a channel with option_static_remotekey
enabled,
you can wait for your peer to unilateraly close the channel, then use tools/hsmtool
with the
guesstoremote
command to attempt to recover your funds from the peer's published unilateral close transaction.
If option_static_remotekey
was not enabled, you're probably out of luck. The keys for your funds in your peer's
unilateral close transaction are derived from information you lost. Fortunately, since version 0.7.3
channels
are created with option_static_remotekey
by default if your peer supports it.
Which is to say that channels created after block 598000
(short channel id starting with > 598000) have a high chance of supporting option_static_remotekey
.
You can verify it using the features
field from the listpeers
command's result.
Here is an example in Python checking if one of the option_static_remotekey
bits is set in the negotiated features corresponding to 0x02aaa2
:
>>> bool(0x02aaa2 & ((1 << 12) | (1 << 13)))
True
If option_static_remotekey
is enabled you can attempt to recover the
funds in a channel following this tutorial on
how to extract the necessary information from the network topology. If
successful, result will be a private key matching a unilaterally
closed channel, that you can import into any wallet, recovering the
funds into that wallet.
A psbt
is created and returned by a call to utxopsbt
with reservedok=true
.