The plugin registers a new command `helpme` which will guide you through the main
components of C-lightning:
```
lightning-cli helpme
```
### How to get the balance of each channel ?
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](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#rationale).
A better option is to use the [`summary` plugin](https://github.com/lightningd/plugins/tree/master/summary)
-`rescanblockchain`: A `bitcoind` RPC call which rescans the blockchain
starting at the given height. This does not have an effect on c-lightning
as `lightningd` tracks all block and wallet data independently.
-`--rescan=depth`: A `lightningd` 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`: A `lightningd` 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 the `lightningd` wallet with `bitcoind`.
As it only operates on outputs already seen on chain by the `lightningd` internal
wallet, this will not find missing wallet funds.
### Database corruption / channel state lost
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](https://blockstream.info/block/0000000000000000000dd93b8fb5c622b9c903bf6f921ef48e266f0ead7faedb)
(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](https://lightning.readthedocs.io/lightning-listpeers.7.html)'s result.
Here is an example in Python checking if [one of the `option_static_remotekey` bits](https://github.com/lightningnetwork/lightning-rfc/blob/master/09-features.md) is set in the negotiated features corresponding to `0x02aaa2`:
### How do I get the `psbt` for RPC calls that need it?
A `psbt` is created and returned by a call to [`utxopsbt` with `reservedok=true`](https://lightning.readthedocs.io/lightning-utxopsbt.7.html?highlight=psbt).