[BobLawblaw]

 

[1714215995]

1714215995

[1714215995]

1714215995

[1714215995]

1714215995

[achow101]

How do I see a list of already generated addresses,

There should be a command for (I don't remember what it is). You can list commands using the help command.

where is this data stored ?

Also, what happens when I fund a channel, and lightningd crashes ? Are the funds gone ? Does it remember I had the channel open and funded ?

Finally, when I manually connect to servers using the cli, is there any way to have it remember them when I relaunch lightningd ? Sorta plays into the hesitation of losing funds if it crashes; is it not supposed to remember prior connections ?

It has its own data directory where there is a database file. All of that information is stored in the database and will be loaded next time you start so that everything persists between restarts.

[achow101]

So, if I manually establish connections to other nodes, a properly working configuration should remember those prior-connected nodes, and reconnect on restart ?

Even if the connects are unfunded ?

It should.

[ZmnSCPxj]

First, please take note, that funding c-lightning is not same as funding a channel.  When sending an address generated by newaddr, this adds onchain funds.  You need to execute a separate fundchannel command to transfer from onchain to a LN channel.

If lightningd crashes, channels should be recoverable.  But, "should".  This is alpha-level software, maybe lost coins can happen.  However, lost/stuck coins are somewhat less now than maybe a month ago, I think...

lightningd will reconnect to peers you establish channels with.  If you do not make channels, then on restart no automatic reconnect.

The routing map is not updated if you do not have a channel.  The point of those maps, is to route.  If you have no public channels, cannot route, so you will not be gossiped onto the map.  Note that only connecting will not add you to the map; you need to make channel.

Please note, the routing map is kept in a separate process by lightningd from the channel-handling process.  Thus, route generation ignores state of your local channels; getroute can select channels that have no capacity on your side or where your peer is disconnected.  Attempting to sendpay or pay will report the state from the channel-handling process to the routing-map process, so if your pay command fails with routing failure, please retry quickly so different route is made by routing-map process.

[ZmnSCPxj]

Use `close` command to close channels.  If peer is on, it will negotiate and attempt to use ONCHAIND_MUTUAL, which is a mutual, immediate close.  If peer is offline, cannot negotiate, so it will use ONCHAIND_OUR_UNILATERAL and close the channel, and retrieve your funds after 144 blocks.  If you were offline while your peer closed, that is ONCHAIND_THEIR_UNILATERAL, channel is closed and you get your funds as soon as you bring your node back online.

Note however that we have some bugs recently regarding closing and opening.