closing a channel should output more info

[thestick613]

lightning-cli close xyxyxyxyxyxyxyx...xxxxxxxxxxxx
outputs only
{ }

Running it a second time outputs:

lightning-cli close xyxyxyxyxyxyxyx...xxxxxxxxxxxx
"Peer is in state CHANNELD_SHUTTING_DOWN"

I guess that the first run should output the closing transaction id, for more verbosity.

[ZmnSCPxj]

It should also probably output whether it was able to do a bilateral close, or used a unilateral one.

[alaniz3]

It seems to me like a more elaborate response should be added here, https://github.com/ElementsProject/lightning/blob/master/lightningd/peer_control.c#L2721, I'm not familiar enough with the codebase yet to submit a PR to show the closing txid but any guidance (and/or) a similar example would be interesting to me to further understand the codebase. As far as I understand each of these 'functions' has its own daemon but its not clear to me how peer_control.c communicates with say closingd in order to be able to use the response from closingd in the command_success response.

[ZmnSCPxj]

It is channeld which actually initiates the closing. I am unsure how closingd works in detail myself.

Look up files ending in csv --- these contain message definitions. In general a csv file in a subdaemon directory is for messages that subdaemon uses. By convention, a message pair, with the same prefix and with one ending in request and the other ending in reply, is a request-reply pair (obviously, although this is not a strict convention and there are a few violations). In the code you pointed to, notice that the function towire_channel_send_shutdown is called a few lines above, to get the message sent by subd_send_msg; towire_channel_send_shutdown creates the serialization of the channel_send_shutdown message (whose definition you can find in channeld/channel_wire.csv). Note that subd_send_msg is a one-sided send, meaning it does not wait for a reply; this means that channeld does not report the result of closing to lightningd.

You might occassionally see references to masterd, this is basically the main lightningd binary.

So the modifications needed involve making channel_send_shutdown into channel_send_shutdown_request and chanel_send_shutdown_reply messages; by convention, the reply message number is +100 to the request message number, so channel_send_shutdown_request would be 1023 while channel_send_shutdown_reply would be 1123. channel_send_shutdown_reply would have to contain the txid of the closing transaction (a struct bitcoin_txid), and probably boolean flag indicating whether a bilateral or a unilateral close was done. Actually it looks like we do not support using a unilateral close yet, I am uncertain how that happens.

You would then have to study channeld in more detail and consider how to reply; that is beyond my current state of knowledge.

[ZmnSCPxj]

Duplicates: #622

[alaniz3]

Thanks @ZmnSCPxj, I'll look into what you have said as I familiarize myself further with the codebase.