vincenzopalazzo
/
rgb-cln
1
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity
rgb-cln/doc/lightning-close.7

69 lines
2.5 KiB
Groff
Raw Normal View History

doc/manpages: regenerate manpages using markdown templates
2019-08-10 01:12:44 +01:00
.TH "LIGHTNING-CLOSE" "7" "" "" "lightning-close"
.SH NAME
lightning-close - Command for closing channels with direct peers
.SH SYNOPSIS
close: change to a unilateraltimeout argument. `close` takes two optional arguments: `force` and `timeout`. `timeout` doesn't timeout the close (there's no way to do that), just the JSON call. `force` (default `false`) if set, means we unilaterally close at the timeout, instead of just failing. Timing out JSON calls is generally deprecated: that's the job of the client. And the semantics of this are confusing, even to me! A better API is a timeout which, if non-zero, is the time at which we give up and unilaterally close. The transition code is awkward, but we'll manage for the three releases until we can remove it. The new defaults are to unilaterally close after 48 hours. Fixes: #2791 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2019-08-08 07:46:05 +01:00
\fBclose\fR \fIid\fR [\fIunilateraltimeout\fR]
doc/manpages: regenerate manpages using markdown templates
2019-08-10 01:12:44 +01:00
.SH DESCRIPTION
The \fBclose\fR RPC command attempts to close the channel cooperatively
with the peer, or unilaterally after \fIunilateraltimeout\fR\.
If the given \fIid\fR is a peer ID (66 hex digits as a string), then it
applies to the active channel of the direct peer corresponding to the
given peer ID\. If the given \fIid\fR is a channel ID (64 hex digits as a
string, or the short channel ID \fIblockheight:txindex:outindex\fR form),
then it applies to that channel\.
If \fIunilateraltimeout\fR is not zero, the \fBclose\fR command will
unilaterally close the channel when that number of seconds is reached\.
If \fIunilateraltimeout\fR is zero, then the \fBclose\fR command will wait
indefinitely until the peer is online and can negotiate a mutual close\.
The default is 2 days (172800 seconds)\.
The peer needs to be live and connected in order to negotiate a mutual
close\. The default of unilaterally closing after 48 hours is usually a
reasonable indication that you can no longer contact the peer\.
.SH NOTES
Prior to 0\.7\.2, \fBclose\fR took two parameters: \fIforce\fR and \fItimeout\fR\.
\fItimeout\fR was the number of seconds before \fIforce\fR took effect (default,
30), and \fIforce\fR determined whether the result was a unilateral close or
an RPC error (default)\. Even after the timeout, the channel would be
closed if the peer reconnected\.
.SH RETURN VALUE
On success, an object with fields \fItx\fR and \fItxid\fR containing the closing
transaction are returned\. It will also have a field \fItype\fR which is
either the JSON string \fImutual\fR or the JSON string \fIunilateral\fR\. A
\fImutual\fR close means that we could negotiate a close with the peer,
while a \fIunilateral\fR close means that the \fIforce\fR flag was set and we
had to close the channel without waiting for the counterparty\.
A unilateral close may still occur at any time if the peer did not
behave correctly during the close negotiation\.
Unilateral closes will return your funds after a delay\. The delay will
vary based on the peer \fIto_self_delay\fR setting, not your own setting\.
.SH AUTHOR
docs: Update manpages to be recognized correctly by mrkd mrkd started enforcing the `name -- short description` style of top-level headings somewhere, and was thus failing to build the man-pages. I swapped the title and with the existing short description to make it work again. `mrkd` will automatically infer the section from the filename so no need to put it in the title as well. In addition I removed the "last updated" lines at the bottom since they are out of date at best, and misleading at the worst. If we want to keep them, I'd suggest generating them from the commit that last touched them.
2019-08-31 13:30:56 +01:00
ZmnSCPxj \fI<ZmnSCPxj@protonmail.com\fR> is mainly responsible\.
doc/manpages: regenerate manpages using markdown templates
2019-08-10 01:12:44 +01:00
.SH SEE ALSO
\fBlightning-disconnect\fR(7), \fBlightning-fundchannel\fR(7)
.SH RESOURCES
docs: Update manpages to be recognized correctly by mrkd mrkd started enforcing the `name -- short description` style of top-level headings somewhere, and was thus failing to build the man-pages. I swapped the title and with the existing short description to make it work again. `mrkd` will automatically infer the section from the filename so no need to put it in the title as well. In addition I removed the "last updated" lines at the bottom since they are out of date at best, and misleading at the worst. If we want to keep them, I'd suggest generating them from the commit that last touched them.
2019-08-31 13:30:56 +01:00
Main web site: \fIhttps://github.com/ElementsProject/lightning\fR
doc/manpages: regenerate manpages using markdown templates
2019-08-10 01:12:44 +01:00