Archives
/
chantools
mirror of https://github.com/guggero/chantools
2
0
Fork 0
Code Issues Releases Wiki Activity

README: add more information

Browse Source
pull/69/head
Oliver Gugger 1 year ago
parent 2a1997844d
commit a84a59ed76
No known key found for this signature in database
GPG Key ID: 8E4256593F177720
1 changed files with 328 additions and 167 deletions
Show Stats Download Patch File Download Diff File

495
README.md
Unescape Escape View File

@ -23,7 +23,8 @@ a private API URL with `--apiurl`.
## Installation ## Installation
The easiest way to install `chantools` is to [download a pre-built binary for The easiest way to install `chantools` is to [download a pre-built binary for
your operating system and architecture](https://github.com/guggero/chantools/releases). your operating system and
architecture](https://github.com/guggero/chantools/releases).
Example (make sure you always use the latest version!): Example (make sure you always use the latest version!):
@ -47,6 +48,104 @@ cd chantools
make install make install
``` ```
## When should I use what command?
This list contains a list of scenarios that users seem to run into sometimes.
**Before you start running any `chantools` command, you MUST read the
["What should I NEVER do?"](#what-should-i-never-do) section below!**
Scenarios:
- **My node/disk/database crashed and I only have the seed and `channel.backup`
file.**
This is the "normal" recovery scenario for which you don't need `chantools`.
Just follow the [`lnd` recovery guide][recovery].
All channels will be closed to recover funds, so you should still try to avoid
This scenario. You only need `chantools` if you had [zombie
channels][safety-zombie] or a channel that did not confirm in time (see
below).
- **My node/disk/database crashed and I only have the seed.**
This is very bad and recovery will take manual steps and might not be
successful for private channels. If you do not have _any_ data left from your
node, you need to follow the [`chantools fakechanbackup` command
](doc/chantools_fakechanbackup.md) help text. If you do have an old version of
your `channel.db` file, DO NOT UNDER ANY CIRCUMSTANCES start your node with
it. Instead, try to extract a `channel.backup` from it using the [`chantools
chanbackup`](doc/chantools_chanbackup.md) command. If that is successful,
follow the steps in the [`lnd` recovery guide][recovery].
This will not cover new channels opened after the backup of the `channel.db`
file was created. You might still need to create the fake channel backup.
- **I suspect my channel.db file to be corrupt.**
This can happen due to unclean shutdowns or power outages. Try running
[`chantools compactdb`](doc/chantools_compactdb.md). If there are NO ERRORS
during the execution of that command, things should be back to normal, and you
can continue running your node. If you get errors, you should probably follow
the [recovery scenario described below](#channel-recovery-scenario) to avoid
future issues. This will close all channels, however.
- **I don't have a `channel.backup` file but all my peers force closed my
channels, why don't I see the funds with just my seed?**
When a channel is force closed by the remote party, the funds don't
automatically go to a normal on-chain address. You need to sweep those funds
using the [`chantools sweepremoteclosed`](doc/chantools_sweepremoteclosed.md)
command.
- **My channel peer is online, but they don't force close a channel when using
a `channel.backup` file**.
This can have many reasons. Often it means the channels is a legacy channel
type (not an anchor output channel) and the force close transaction the peer
has doesn't have enough fees to make it into the mempool. In that case waiting
for an empty mempool might be the only option.
Another reason might be that the peer is a CLN node with a specific version
that doesn't react to force close requests normally. You can use the
[`chantools triggerforceclose` command](doc/chantools_triggerforceclose.md) in
that case (ONLY works with CLN peers of a certain version).
## What should I NEVER do?
- You should never panic. There are extremely few situations in which doing
nothing makes things worse. On the contrary, most cases where users actually
lost funds it was due to them running commands they did not understand in a
rush of panic. So stay calm, try to find out what the reason for the problem
is, ask for help (see [Slack][slack], [`lnd` discussions][discussions]) or use
Google.
Create a backup of all your files in the `lnd` data directory (just in case,
but never [start a node from a file based backup][safety-file-backup])
before running _any_ command. Also read the [`lnd` Operational Safety
Guidelines][safety].
- Whatever you might read in any issue, you should never use
`lncli abandonchannel` on a channel that was confirmed on chain. Even if you
have an SCB (Static Channel Backup, unfortunately poorly named) file
(`channel.backup`) or export from `lncli exportchanbackup`. Those files DO NOT
contain enough information to close a channel if your peer does not have the
channel data either (which might happen if the channel took longer than 2
weeks to confirm). If the channel confirmed on chain, you need to force close
it from your node if it does not operate normally. Running `abandonchannel`
deletes the information needed to be able to force close.
- When running Umbrel, NEVER just uninstall the Lightning App when encountering
a problem. Uninstalling the app deletes important data that might be needed
for recovery in edge cases. The channel backup (SCB) in the cloud does NOT
cover "expired" channels (channels that took longer than 2 weeks to confirm)
or [zombie channels][safety-zombie].
- The term "backup" in SCB (Static Channel Backup) or the `channel.backup` file
or the output of `lncli exportchanbackup` is not optimal as it implies the
channels can be fully restored or brought back to an operational state. But
the content of those files are for absolute emergencies only. Channels are
always closed when using such a file (by asking the remote peer to issue their
latest force close transaction they have). So chain fees occur. And there are
some edge cases where funds are not covered by those files, for example when
a channel funding transaction is not confirmed in time. Or for channels where
the peer is no longer online. So deleting your `lnd` data directory should
never ever be something to be done lightly (see Umbrel above).
## Channel recovery scenario ## Channel recovery scenario
The following flow chart shows the main recovery scenario this tool was built The following flow chart shows the main recovery scenario this tool was built
@ -63,177 +162,208 @@ compacting the DB).
**Explanation:** **Explanation:**
1. **Node crashed**: For some reason your `lnd` node crashed and isn't starting 1. **Node crashed**: For some reason your `lnd` node crashed and isn't starting
anymore. If you get errors similar to anymore. If you get errors similar to
[this](https://github.com/lightningnetwork/lnd/issues/4449), [this](https://github.com/lightningnetwork/lnd/issues/4449),
[this](https://github.com/lightningnetwork/lnd/issues/3473) or [this](https://github.com/lightningnetwork/lnd/issues/3473) or
[this](https://github.com/lightningnetwork/lnd/issues/4102), it is possible [this](https://github.com/lightningnetwork/lnd/issues/4102), it is possible
that a simple compaction (a full copy in safe mode) can solve your problem. that a simple compaction (a full copy in safe mode) can solve your problem.
See [`chantools compactdb`](doc/chantools_compactdb.md). See [`chantools compactdb`](doc/chantools_compactdb.md).
<br/><br/> <br/><br/>
If that doesn't work and you need to continue the recovery, make sure you can If that doesn't work and you need to continue the recovery, make sure you can
at least extract the `channel.backup` file and if somehow possible any version at least extract the `channel.backup` file and if somehow possible any
of the `channel.db` from the node. version
<br/><br/> of the `channel.db` from the node.
Whatever you do, do **never, ever** replace your `channel.db` file with an old <br/><br/>
version (from a file based backup) and start your node that way. Whatever you do, do **never, ever** replace your `channel.db` file with an
[Read this explanation why that can lead to loss of funds.](https://github.com/lightningnetwork/lnd/blob/master/docs/safety.md#file-based-backups) old
version (from a file based backup) and start your node that way.
[Read this explanation why that can lead to loss of
funds.][safety-file-backup]
2. **Rescue on-chain balance**: To start the recovery process, we are going to 2. **Rescue on-chain balance**: To start the recovery process, we are going to
re-create the node from scratch. To make sure we don't overwrite any old data re-create the node from scratch. To make sure we don't overwrite any old data
in the process, make sure the old data directory of your node (usually `.lnd` in the process, make sure the old data directory of your node (usually `.lnd`
in the user's home directory) is safely moved away (or the whole folder in the user's home directory) is safely moved away (or the whole folder
renamed) before continuing.<br/> renamed) before continuing.<br/>
To start the on-chain recovery, [follow the sub step "Starting On-Chain Recovery" of this guide](https://github.com/lightningnetwork/lnd/blob/master/docs/recovery.md#starting-on-chain-recovery). To start the on-chain recovery, [follow the sub step "Starting On-Chain
Don't follow the whole guide, only this single chapter! Recovery" of this guide][2].
<br/><br/> Don't follow the whole guide, only this single chapter!
This step is completed once the `lncli getinfo` command shows both <br/><br/>
`"synced_to_chain": true` and `"synced_to_graph": true` which can take several This step is completed once the `lncli getinfo` command shows both
hours depending on the speed of your hardware. **Do not be alarmed** that the `"synced_to_chain": true` and `"synced_to_graph": true` which can take
`lncli getinfo` command shows 0 channels. This is normal as we haven't started several
the off-chain recovery yet. hours depending on the speed of your hardware. **Do not be alarmed** that the
`lncli getinfo` command shows 0 channels. This is normal as we haven't
started
the off-chain recovery yet.
3. **Recover channels using SCB**: Now that the node is fully synced, we can try 3. **Recover channels using SCB**: Now that the node is fully synced, we can try
to recover the channels using the [Static Channel Backups (SCB)](https://github.com/lightningnetwork/lnd/blob/master/docs/safety.md#static-channel-backups-scbs). to recover the channels using the [Static Channel Backups (SCB)][safety-scb].
For this, you need a file called `channel.backup`. Simply run the command For this, you need a file called `channel.backup`. Simply run the command
`lncli restorechanbackup --multi_file <path-to-your-channel.backup>`. **This `lncli restorechanbackup --multi_file <path-to-your-channel.backup>`. **This
will take a while!**. The command itself can take several minutes to complete, will take a while!**. The command itself can take several minutes to
depending on the number of channels. The recovery can easily take a day or complete,
two as a lot of chain rescanning needs to happen. It is recommended to wait at depending on the number of channels. The recovery can easily take a day or
least one full day. You can watch the progress with the `lncli pendingchannels` two as a lot of chain rescanning needs to happen. It is recommended to wait
command. If the list is empty, congratulations, you've recovered all channels! at
If the list stays un-changed for several hours, it means not all channels least one full day. You can watch the progress with
could be restored using this method. the `lncli pendingchannels`
[One explanation can be found here.](https://github.com/lightningnetwork/lnd/blob/master/docs/safety.md#zombie-channels) command. If the list is empty, congratulations, you've recovered all
channels!
If the list stays un-changed for several hours, it means not all channels
could be restored using this method.
[One explanation can be found here.][1]
4. **Install chantools**: To try to recover the remaining channels, we are going 4. **Install chantools**: To try to recover the remaining channels, we are going
to use `chantools`. Simply [follow the installation instructions.](#installation) to use `chantools`.
The recovery can only be continued if you have access to some version of the Simply [follow the installation instructions.](#installation)
crashed node's `channel.db`. This could be the latest state as recovered from The recovery can only be continued if you have access to some version of the
the crashed file system, or a version from a regular file based backup. If you crashed node's `channel.db`. This could be the latest state as recovered from
do not have any version of a channel DB, `chantools` won't be able to help the crashed file system, or a version from a regular file based backup. If
with the recovery. See step 11 for some possible manual steps. you
do not have any version of a channel DB, `chantools` won't be able to help
with the recovery. See step 11 for some possible manual steps.
5. **Create copy of channel DB**: To make sure we can read the channel DB, we 5. **Create copy of channel DB**: To make sure we can read the channel DB, we
are going to create a copy in safe mode (called compaction). Simply run are going to create a copy in safe mode (called compaction). Simply run
<br/><br/> <br/><br/>
`chantools compactdb --sourcedb <recovered-channel.db> --destdb ./results/compacted.db` `chantools compactdb --sourcedb <recovered-channel.db> --destdb ./results/compacted.db`
<br/><br/> <br/><br/>
We are going to assume that the compacted copy of the channel DB is located in We are going to assume that the compacted copy of the channel DB is located
`./results/compacted.db` in the following commands. in
`./results/compacted.db` in the following commands.
6. **chantools summary**: First, `chantools` needs to find out the state of each 6. **chantools summary**: First, `chantools` needs to find out the state of each
channel on chain. For this, a blockchain API (by default [blockstream.info](https://blockstream.info)) channel on chain. For this, a blockchain API (by
is queried. The result will be written to a file called default [blockstream.info](https://blockstream.info))
`./results/summary-yyyy-mm-dd.json`. This result file will be needed for the is queried. The result will be written to a file called
next command. `./results/summary-yyyy-mm-dd.json`. This result file will be needed for the
<br/><br/> next command.
`chantools --fromchanneldb ./results/compacted.db summary` <br/><br/>
`chantools --fromchanneldb ./results/compacted.db summary`
7. **chantools rescueclosed**: It is possible that by now the remote peers have 7. **chantools rescueclosed**: It is possible that by now the remote peers have
force-closed some of the remaining channels. What we now do is try to find the force-closed some of the remaining channels. What we now do is try to find
private keys to sweep our balance of those channels. For this we need a shared the
secret which is called the `commit_point` and is changed whenever a channel is private keys to sweep our balance of those channels. For this we need a
updated. We do have the latest known version of this point in the channel DB. shared
The following command tries to find all private keys for channels that have secret which is called the `commit_point` and is changed whenever a channel
been closed by the other party. The command needs to know what channels it is is
operating on, so we have to supply the `summary-yyy-mm-dd.json` created by the updated. We do have the latest known version of this point in the channel DB.
previous command: The following command tries to find all private keys for channels that have
<br/><br/> been closed by the other party. The command needs to know what channels it is
`chantools --fromsummary ./results/<summary-file-created-in-last-step>.json rescueclosed --channeldb ./results/compacted.db` operating on, so we have to supply the `summary-yyy-mm-dd.json` created by
<br/><br/> the
This will create a new file called `./results/rescueclosed-yyyy-mm-dd.json` previous command:
which will contain any found private keys and will also be needed for the next <br/><br/>
command. Use `bitcoind` or Electrum Wallet to sweep all of the private keys. `chantools --fromsummary ./results/<summary-file-created-in-last-step>.json rescueclosed --channeldb ./results/compacted.db`
<br/><br/>
This will create a new file called `./results/rescueclosed-yyyy-mm-dd.json`
which will contain any found private keys and will also be needed for the
next
command. Use `bitcoind` or Electrum Wallet to sweep all of the private keys.
8. **chantools forceclose**: This command will now close all channels that 8. **chantools forceclose**: This command will now close all channels that
`chantools` thinks are still open. This is achieved by publishing the latest `chantools` thinks are still open. This is achieved by publishing the latest
known channel state of the `channel.db` file. known channel state of the `channel.db` file.
<br/>**Please read the full warning text of the <br/>**Please read the full warning text of the
[`forceclose` command below](doc/chantools_forceclose.md) as this command can put [`forceclose` command below](doc/chantools_forceclose.md) as this command can
your funds at risk** if the state in the channel DB is not the most recent put
one. This command should only be executed for channels where the remote peer your funds at risk** if the state in the channel DB is not the most recent
is not online anymore. one. This command should only be executed for channels where the remote peer
<br/><br/> is not online anymore.
`chantools --fromsummary ./results/<rescueclosed-file-created-in-last-step>.json forceclose --channeldb ./results/compacted.db --publish` <br/><br/>
<br/><br/> `chantools --fromsummary ./results/<rescueclosed-file-created-in-last-step>.json forceclose --channeldb ./results/compacted.db --publish`
This will create a new file called `./results/forceclose-yyyy-mm-dd.json` <br/><br/>
which will be needed for the next command. This will create a new file called `./results/forceclose-yyyy-mm-dd.json`
<br/><br/> which will be needed for the next command.
If you get the error `non-mandatory-script-verify-flag (Signature must be zero <br/><br/>
for failed CHECK(MULTI)SIG operation)`, you might be affected by an old bug If you get the
of `lnd` that was fixed in the meantime. But it means the signature in the error `non-mandatory-script-verify-flag (Signature must be zero
force-close transaction is invalid and needs to be fixed. There is [a guide for failed CHECK(MULTI)SIG operation)`, you might be affected by an old bug
on how to do exactly that here](doc/fix-commitment-tx.md). of `lnd` that was fixed in the meantime. But it means the signature in the
force-close transaction is invalid and needs to be fixed. There is [a guide
on how to do exactly that here](doc/fix-commitment-tx.md).
9. **Wait for timelocks**: The previous command closed the remaining open 9. **Wait for timelocks**: The previous command closed the remaining open
channels by publishing your node's state of the channel. By design of the channels by publishing your node's state of the channel. By design of the
Lightning Network, you now have to wait until the channel funds belonging to Lightning Network, you now have to wait until the channel funds belonging to
you are not time locked any longer. Depending on the size of the channel, you you are not time locked any longer. Depending on the size of the channel, you
have to wait for somewhere between 144 and 2000 confirmations of the have to wait for somewhere between 144 and 2000 confirmations of the
force-close transactions. Only continue with the next step after the channel force-close transactions. Only continue with the next step after the channel
with the highest `csv_delay` has reached that many confirmations of its with the highest `csv_delay` has reached that many confirmations of its
closing transaction. You can check this by looking up each force closed closing transaction. You can check this by looking up each force closed
channel transaction on a block explorer (like channel transaction on a block explorer (like
[blockstream.info](https://blockstream.info) for example). Open the result [blockstream.info](https://blockstream.info) for example). Open the result
JSON file of the last command (`./results/forceclose-yyyy-mm-dd.json`) and JSON file of the last command (`./results/forceclose-yyyy-mm-dd.json`) and
look up every TXID in `"force_close" -> "txid"` on the explorer. If the number look up every TXID in `"force_close" -> "txid"` on the explorer. If the
of confirmations is equal to or greater to the value shown in number
`"force_close" -> "csv_delay"` for each of the channels, you can proceed. of confirmations is equal to or greater to the value shown in
`"force_close" -> "csv_delay"` for each of the channels, you can proceed.
10. **chantools sweeptimelock**: Once all force-close transactions have reached 10. **chantools sweeptimelock**: Once all force-close transactions have reached
the number of transactions as the `csv_timeout` in the JSON demands, these the number of transactions as the `csv_timeout` in the JSON demands, these
time locked funds can now be swept. Use the following command to sweep all the time locked funds can now be swept. Use the following command to sweep all
channel funds to an address of your wallet: the
<br/><br/> channel funds to an address of your wallet:
`chantools --fromsummary ./results/<forceclose-file-created-in-last-step>.json sweeptimelock --publish --sweepaddr <bech32-address-from-your-wallet>` <br/><br/>
`chantools --fromsummary ./results/<forceclose-file-created-in-last-step>.json sweeptimelock --publish --sweepaddr <bech32-address-from-your-wallet>`
11. **Manual intervention necessary**: You got to this step because you either 11. **Manual intervention necessary**: You got to this step because you either
don't have a `channel.db` file or because `chantools` couldn't rescue all your don't have a `channel.db` file or because `chantools` couldn't rescue all
node's channels. There are a few things you can try manually that have some your
chance of working: node's channels. There are a few things you can try manually that have some
chance of working:
- Make sure you can connect to all nodes when restoring from SCB: It happens - Make sure you can connect to all nodes when restoring from SCB: It happens
all the time that nodes change their IP addresses. When restoring from a all the time that nodes change their IP addresses. When restoring from a
static channel backup, your node tries to connect to the node using the IP static channel backup, your node tries to connect to the node using the IP
address encoded in the backup file. If the address changed, the SCB restore address encoded in the backup file. If the address changed, the SCB
process doesn't work. You can use block explorers like [1ml.com](https://1ml.com) restore
to try to find an IP address that is up-to-date. Just run process doesn't work. You can use block explorers
`lncli connect <node-pubkey>@<updated-ip-address>:<port>` in the recovered like [1ml.com](https://1ml.com)
`lnd` node from step 3 and wait a few hours to see if the channel is now to try to find an IP address that is up-to-date. Just run
being force closed by the remote node. `lncli connect <node-pubkey>@<updated-ip-address>:<port>` in the recovered
- Find out who the node belongs to: Maybe you opened the channel with someone `lnd` node from step 3 and wait a few hours to see if the channel is now
you know. Or maybe their node alias contains some information about who the being force closed by the remote node.
node belongs to. If you can find out who operates the remote node, you can - Find out who the node belongs to: Maybe you opened the channel with
ask them to force-close the channel from their end. If the channel was opened someone
with the `option_static_remote_key`, (`lnd v0.8.0` and later), the funds can you know. Or maybe their node alias contains some information about who
be swept by your node. the
node belongs to. If you can find out who operates the remote node, you can
ask them to force-close the channel from their end. If the channel was
opened
with the `option_static_remote_key`, (`lnd v0.8.0` and later), the funds
can
be swept by your node.
12. **Use Zombie Channel Recovery Matcher**: As a final, last resort, you can 12. **Use Zombie Channel Recovery Matcher**: As a final, last resort, you can
go to [node-recovery.com](https://www.node-recovery.com/) and register your go to [node-recovery.com](https://www.node-recovery.com/) and register your
node's ID for being matched up against other nodes with the same problem. node's ID for being matched up against other nodes with the same problem.
<br/><br/> <br/><br/>
Once you were contacted with a match, follow the instructions on the Once you were contacted with a match, follow the instructions on the
[Zombie Channel Recovery Guide](doc/zombierecovery.md) page. [Zombie Channel Recovery Guide](doc/zombierecovery.md) page.
<br/><br/> <br/><br/>
If you know the peer of a zombie channel and have a way to contact them, you If you know the peer of a zombie channel and have a way to contact them, you
can also skip the registration/matching process and [create your own match can also skip the registration/matching process and [create your own match
file](doc/zombierecovery.md#file-format). file](doc/zombierecovery.md#file-format).
## Seed and passphrase input ## Seed and passphrase input
All commands that require the seed (and, if set, the seed's passphrase) offer All commands that require the seed (and, if set, the seed's passphrase) offer
three distinct possibilities to specify it: three distinct possibilities to specify it:
1. **Enter manually on the terminal**: This is the safest option as it makes 1. **Enter manually on the terminal**: This is the safest option as it makes
sure that the seed isn't stored in the terminal's command history. sure that the seed isn't stored in the terminal's command history.
2. **Pass the extened master root key as parameter**: This is added as an option 2. **Pass the extened master root key as parameter**: This is added as an option
for users who don't have the full seed anymore, possibly because they used for users who don't have the full seed anymore, possibly because they used
`lnd`'s `--noseedbackup` flag and extracted the `xprv` from the wallet `lnd`'s `--noseedbackup` flag and extracted the `xprv` from the wallet
database with the `walletinfo` command. Those users can specify the master database with the `walletinfo` command. Those users can specify the master
root key by passing the `--rootkey` command line flag to each command that root key by passing the `--rootkey` command line flag to each command that
requires the seed. requires the seed.
3. **Use environment variables**: This option makes it easy to automate usage of 3. **Use environment variables**: This option makes it easy to automate usage of
`chantools` by removing the need to type into the terminal. There are three `chantools` by removing the need to type into the terminal. There are three
environment variables that can be set to skip entering values through the environment variables that can be set to skip entering values through the
terminal: terminal:
- `AEZEED_MNEMONIC`: Specifies the 24 word `lnd` aezeed. - `AEZEED_MNEMONIC`: Specifies the 24 word `lnd` aezeed.
- `AEZEED_PASSPHRASE`: Specifies the passphrase for the aezeed. If no - `AEZEED_PASSPHRASE`: Specifies the passphrase for the aezeed. If no
passphrase was used during the creation of the seed, the special value passphrase was used during the creation of the seed, the special value
@ -260,6 +390,7 @@ Your BIP32 HD root key is: xprv9s21ZrQH1...
``` ```
### Are my funds safe? ### Are my funds safe?
Some commands require the seed. But your seed will never leave your computer. Some commands require the seed. But your seed will never leave your computer.
Most commands don't require an internet connection: you can and should Most commands don't require an internet connection: you can and should
@ -281,6 +412,7 @@ Available Commands:
compactdb Create a copy of a channel.db file in safe/read-only mode compactdb Create a copy of a channel.db file in safe/read-only mode
deletepayments Remove all (failed) payments from a channel DB deletepayments Remove all (failed) payments from a channel DB
derivekey Derive a key with a specific derivation path derivekey Derive a key with a specific derivation path
doublespendinputs Tries to double spend the given inputs by deriving the private for the address and sweeping the funds to the given address. This can only be used with inputs that belong to an lnd wallet.
dropchannelgraph Remove all graph related data from a channel DB dropchannelgraph Remove all graph related data from a channel DB
dumpbackup Dump the content of a channel.backup file dumpbackup Dump the content of a channel.backup file
dumpchannels Dump all channel information from an lnd channel database dumpchannels Dump all channel information from an lnd channel database
@ -319,32 +451,61 @@ Use "chantools [command] --help" for more information about a command.
Detailed documentation for each sub command is available in the Detailed documentation for each sub command is available in the
[docs](doc/chantools.md) folder. [docs](doc/chantools.md) folder.
Quick access: The following table provides quick access to each command's documentation.
+ [chanbackup](doc/chantools_chanbackup.md) Legend:
+ [closepoolaccount](doc/chantools_closepoolaccount.md)
+ [compactdb](doc/chantools_compactdb.md) - :pencil: This command requires the seed to be entered (see [seed and
+ [deletepayments](doc/chantools_deletepayments.md) passphrase input](#seed-and-passphrase-input)).
+ [derivekey](doc/chantools_derivekey.md) - :warning: Should not be used unless no other option exists, can lead to
+ [dropchannelgraph](doc/chantools_dropchannelgraph.md) malfunction of the node.
+ [dumpbackup](doc/chantools_dumpbackup.md) - :skull: Danger of loss of funds, only use when instructed to.
+ [dumpchannels](doc/chantools_dumpchannels.md) - :pushpin: Command was created for a very specific version or use case and most
+ [fakechanbackup](doc/chantools_fakechanbackup.md) likely does not apply to 99.9% of users
+ [filterbackup](doc/chantools_filterbackup.md)
+ [fixoldbackup](doc/chantools_fixoldbackup.md) | Command | Use when |
+ [forceclose](doc/chantools_forceclose.md) |-------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------|
+ [genimportscript](doc/chantools_genimportscript.md) | [chanbackup](doc/chantools_chanbackup.md) | :pencil: Extract a `channel.backup` file from a `channel.db` file |
+ [migratedb](doc/chantools_migratedb.md) | [closepoolaccount](doc/chantools_closepoolaccount.md) | :pencil: Manually close an expired Lightning Pool account |
+ [recoverloopin](doc/chantools_recoverloopin.md) | [compactdb](doc/chantools_compactdb.md) | Run database compaction manually to reclaim space |
+ [removechannel](doc/chantools_removechannel.md) | [deletepayments](doc/chantools_deletepayments.md) | Remove ALL payments from a `channel.db` file to reduce size |
+ [rescueclosed](doc/chantools_rescueclosed.md) | [derivekey](doc/chantools_derivekey.md) | :pencil: Derive a single private/public key from `lnd`'s seed, use to test seed |
+ [rescuefunding](doc/chantools_rescuefunding.md) | [doublespendinputs](doc/chantools_doublespendinputs.md) | :pencil: Tries to double spend the given inputs by deriving the private for the address and sweeping the funds to the given address |
+ [showrootkey](doc/chantools_showrootkey.md) | [dropchannelgraph](doc/chantools_dropchannelgraph.md) | (:warning:) Completely drop the channel graph from a `channel.db` to force re-sync |
+ [signrescuefunding](doc/chantools_signrescuefunding.md) | [dumpbackup](doc/chantools_dumpbackup.md) | :pencil: Show the content of a `channel.backup` file as text |
+ [summary](doc/chantools_summary.md) | [dumpchannels](doc/chantools_dumpchannels.md) | Show the content of a `channel.db` file as text |
+ [sweepremoteclosed](doc/chantools_sweepremoteclosed.md) | [fakechanbackup](doc/chantools_fakechanbackup.md) | :pencil: Create a fake `channel.backup` file from public information |
+ [sweeptimelock](doc/chantools_sweeptimelock.md) | [filterbackup](doc/chantools_filterbackup.md) | :pencil: Remove a channel from a `channel.backup` file |
+ [sweeptimelockmanual](doc/chantools_sweeptimelockmanual.md) | [fixoldbackup](doc/chantools_fixoldbackup.md) | :pencil: (:pushpin:) Fixes an issue with old `channel.backup` files |
+ [triggerforceclose](doc/chantools_triggerforceclose.md) | [forceclose](doc/chantools_forceclose.md) | :pencil: (:skull: :warning:) Publish an old channel state from a `channel.db` file |
+ [vanitygen](doc/chantools_vanitygen.md) | [genimportscript](doc/chantools_genimportscript.md) | :pencil: Create a script/text file that can be used to import `lnd` keys into other software |
+ [walletinfo](doc/chantools_walletinfo.md) | [migratedb](doc/chantools_migratedb.md) | Upgrade the `channel.db` file to the latest version |
+ [zombierecovery](doc/chantools_zombierecovery.md) | [recoverloopin](doc/chantools_recoverloopin.md) | :pencil: Recover funds from a failed Lightning Loop inbound swap |
| [removechannel](doc/chantools_removechannel.md) | (:skull: :warning:) Remove a single channel from a `channel.db` file |
| [rescueclosed](doc/chantools_rescueclosed.md) | :pencil: (:pushpin:) Rescue funds in a legacy (pre `STATIC_REMOTE_KEY`) channel output |
| [rescuefunding](doc/chantools_rescuefunding.md) | :pencil: (:pushpin:) Rescue funds from a funding transaction. Deprecated, use [zombierecovery](doc/chantools_zombierecovery.md) instead |
| [showrootkey](doc/chantools_showrootkey.md) | :pencil: Display the master root key (`xprv`) from your seed (DO NOT SHARE WITH ANYONE) |
| [signrescuefunding](doc/chantools_signrescuefunding.md) | :pencil: (:pushpin:) Sign to funds from a funding transaction. Deprecated, use [zombierecovery](doc/chantools_zombierecovery.md) instead |
| [summary](doc/chantools_summary.md) | Create a summary of channel funds from a `channel.db` file |
| [sweepremoteclosed](doc/chantools_sweepremoteclosed.md) | :pencil: Find channel funds from remotely force closed channels and sweep them |
| [sweeptimelock](doc/chantools_sweeptimelock.md) | :pencil: Sweep funds in locally force closed channels once time lock has expired (requires `channel.db`) |
| [sweeptimelockmanual](doc/chantools_sweeptimelockmanual.md) | :pencil: Manually sweep funds in a locally force closed channel where no `channel.db` file is available |
| [triggerforceclose](doc/chantools_triggerforceclose.md) | :pencil: (:pushpin:) Request certain CLN peers to force close a channel that don't react to normal SCB recovery requests |
| [vanitygen](doc/chantools_vanitygen.md) | Generate an `lnd` seed for a node public key that starts with a certain sequence of hex digits |
| [walletinfo](doc/chantools_walletinfo.md) | Show information from a `wallet.db` file, requires access to the wallet password |
| [zombierecovery](doc/chantools_zombierecovery.md) | :pencil: Cooperatively rescue funds from channels where normal recovery is not possible (see [full guide here][zombie-recovery]) |
[safety]: https://github.com/lightningnetwork/lnd/blob/master/docs/safety.md
[safety-zombie]: https://github.com/lightningnetwork/lnd/blob/master/docs/safety.md#zombie-channels
[safety-file-backup]: https://github.com/lightningnetwork/lnd/blob/master/docs/safety.md#file-based-backups
[safety-scb]: https://github.com/lightningnetwork/lnd/blob/master/docs/safety.md#static-channel-backups-scbs
[recovery]: https://github.com/lightningnetwork/lnd/blob/master/docs/recovery.md
[slack]: https://lightning.engineering/slack.html
[discussions]: https://github.com/lightningnetwork/lnd/discussions
[zombie-recovery]: doc/zombierecovery.md
Write Preview
Loading…
Cancel
Save