Browse Source
Also report tx and txid, and whether we closed unilaterally or bilaterally, if we could close the channel. Also make a manpage. Fixes: #1207 Fixes: #714 Fixes: #622ppa-0.6.1
ZmnSCPxj
7 years ago
committed by
Rusty Russell
12 changed files with 360 additions and 28 deletions
@ -0,0 +1,59 @@ |
|||
'\" t |
|||
.\" Title: lightning-close |
|||
.\" Author: [see the "AUTHOR" section] |
|||
.\" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/> |
|||
.\" Date: 04/15/2018 |
|||
.\" Manual: \ \& |
|||
.\" Source: \ \& |
|||
.\" Language: English |
|||
.\" |
|||
.TH "LIGHTNING\-CLOSE" "7" "04/15/2018" "\ \&" "\ \&" |
|||
.\" ----------------------------------------------------------------- |
|||
.\" * Define some portability stuff |
|||
.\" ----------------------------------------------------------------- |
|||
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|||
.\" http://bugs.debian.org/507673 |
|||
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html |
|||
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|||
.ie \n(.g .ds Aq \(aq |
|||
.el .ds Aq ' |
|||
.\" ----------------------------------------------------------------- |
|||
.\" * set default formatting |
|||
.\" ----------------------------------------------------------------- |
|||
.\" disable hyphenation |
|||
.nh |
|||
.\" disable justification (adjust text to left margin only) |
|||
.ad l |
|||
.\" ----------------------------------------------------------------- |
|||
.\" * MAIN CONTENT STARTS HERE * |
|||
.\" ----------------------------------------------------------------- |
|||
.SH "NAME" |
|||
lightning-close \- Protocol for closing channels with direct peers |
|||
.SH "SYNOPSIS" |
|||
.sp |
|||
\fBclose\fR \fIid\fR [\fIforce\fR] [\fItimeout\fR] |
|||
.SH "DESCRIPTION" |
|||
.sp |
|||
The \fBclose\fR RPC command attempts to close the channel cooperatively with the peer\&. It applies to the active channel of the direct peer corresponding to the given peer \fIid\fR\&. |
|||
.sp |
|||
The \fBclose\fR command will time out and return with an error when the number of seconds specified in \fItimeout\fR is reached\&. If unspecified, it times out in 30 seconds\&. |
|||
.sp |
|||
The \fIforce\fR argument, if the JSON value \fItrue\fR, will cause the channel to be unilaterally closed when the timeout is reached\&. If so, timeout will not cause an error, but instead cause the channel to be failed and put onchain unilaterally\&. Unilateral closes will lead to your funds getting locked according to the \fIto_self_delay\fR parameter of the peer\&. |
|||
.sp |
|||
Normally the peer needs to be live and connected in order to negotiate a mutual close\&. Forcing a unilateral close can be used if you suspect you can no longer contact the peer\&. |
|||
.SH "RETURN VALUE" |
|||
.sp |
|||
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\&. |
|||
.sp |
|||
A unilateral close may still occur with \fIforce\fR set to \fIfalse\fR if the peer did not behave correctly during the close negotiation\&. |
|||
.sp |
|||
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\&. |
|||
.sp |
|||
On failure, if \fBclose\fR failed due to timing out with \fIforce\fR argument \fIfalse\fR, the channel will still eventually close once we have contacted the peer\&. |
|||
.SH "AUTHOR" |
|||
.sp |
|||
ZmnSCPxj <ZmnSCPxj@protonmail\&.com> is mainly responsible\&. |
|||
.SH "SEE ALSO" |
|||
.SH "RESOURCES" |
|||
.sp |
|||
Main web site: https://github\&.com/ElementsProject/lightning |
@ -0,0 +1,70 @@ |
|||
LIGHTNING-CLOSE(7) |
|||
================== |
|||
:doctype: manpage |
|||
|
|||
NAME |
|||
---- |
|||
lightning-close - Protocol for closing channels with direct peers |
|||
|
|||
SYNOPSIS |
|||
-------- |
|||
*close* 'id' ['force'] ['timeout'] |
|||
|
|||
DESCRIPTION |
|||
----------- |
|||
|
|||
The *close* RPC command attempts to close the channel cooperatively |
|||
with the peer. |
|||
It applies to the active channel of the direct peer corresponding to |
|||
the given peer 'id'. |
|||
|
|||
The *close* command will time out and return with an error when the |
|||
number of seconds specified in 'timeout' is reached. |
|||
If unspecified, it times out in 30 seconds. |
|||
|
|||
The 'force' argument, if the JSON value 'true', will cause the |
|||
channel to be unilaterally closed when the timeout is reached. |
|||
If so, timeout will not cause an error, but instead cause the |
|||
channel to be failed and put onchain unilaterally. |
|||
Unilateral closes will lead to your funds getting locked according |
|||
to the 'to_self_delay' parameter of the peer. |
|||
|
|||
Normally the peer needs to be live and connected in order to negotiate |
|||
a mutual close. |
|||
Forcing a unilateral close can be used if you suspect you can no longer |
|||
contact the peer. |
|||
|
|||
RETURN VALUE |
|||
------------ |
|||
|
|||
On success, an object with fields 'tx' and 'txid' containing the |
|||
closing transaction are returned. |
|||
It will also have a field 'type' which is either the JSON string |
|||
'mutual' or the JSON string 'unilateral'. |
|||
A 'mutual' close means that we could negotiate a close with the |
|||
peer, while a 'unilateral' close means that the 'force' flag was |
|||
set and we had to close the channel without waiting for the |
|||
counterparty. |
|||
|
|||
A unilateral close may still occur with 'force' set to 'false' 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 'to_self_delay' setting, not |
|||
your own setting. |
|||
|
|||
On failure, if *close* failed due to timing out with 'force' |
|||
argument 'false', the channel will still eventually close once |
|||
we have contacted the peer. |
|||
|
|||
AUTHOR |
|||
------ |
|||
ZmnSCPxj <ZmnSCPxj@protonmail.com> is mainly responsible. |
|||
|
|||
SEE ALSO |
|||
-------- |
|||
|
|||
|
|||
RESOURCES |
|||
--------- |
|||
Main web site: https://github.com/ElementsProject/lightning |
Loading…
Reference in new issue