mirror of
https://github.com/ElementsProject/lightning.git
synced 2025-01-18 05:12:45 +01:00
doc: Update sendpay and waitsendpay manpages.
This commit is contained in:
parent
411c9583a7
commit
8fd71ad654
@ -14,7 +14,8 @@ MANPAGES := doc/lightning-cli.1 \
|
|||||||
doc/lightning-pay.7 \
|
doc/lightning-pay.7 \
|
||||||
doc/lightning-sendpay.7 \
|
doc/lightning-sendpay.7 \
|
||||||
doc/lightning-waitinvoice.7 \
|
doc/lightning-waitinvoice.7 \
|
||||||
doc/lightning-waitanyinvoice.7
|
doc/lightning-waitanyinvoice.7 \
|
||||||
|
doc/lightning-waitsendpay.7
|
||||||
|
|
||||||
doc-all: $(MANPAGES)
|
doc-all: $(MANPAGES)
|
||||||
|
|
||||||
|
@ -2,12 +2,12 @@
|
|||||||
.\" Title: lightning-sendpay
|
.\" Title: lightning-sendpay
|
||||||
.\" Author: [see the "AUTHOR" section]
|
.\" Author: [see the "AUTHOR" section]
|
||||||
.\" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/>
|
.\" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/>
|
||||||
.\" Date: 02/06/2018
|
.\" Date: 03/08/2018
|
||||||
.\" Manual: \ \&
|
.\" Manual: \ \&
|
||||||
.\" Source: \ \&
|
.\" Source: \ \&
|
||||||
.\" Language: English
|
.\" Language: English
|
||||||
.\"
|
.\"
|
||||||
.TH "LIGHTNING\-SENDPAY" "7" "02/06/2018" "\ \&" "\ \&"
|
.TH "LIGHTNING\-SENDPAY" "7" "03/08/2018" "\ \&" "\ \&"
|
||||||
.\" -----------------------------------------------------------------
|
.\" -----------------------------------------------------------------
|
||||||
.\" * Define some portability stuff
|
.\" * Define some portability stuff
|
||||||
.\" -----------------------------------------------------------------
|
.\" -----------------------------------------------------------------
|
||||||
@ -38,10 +38,12 @@ The \fBsendpay\fR RPC command attempts to send funds associated with the given \
|
|||||||
.sp
|
.sp
|
||||||
Generally, a client would call getroute(7) to resolve a route, then use \fBsendpay\fR to send it\&. If it fails, it would call getroute(7) again to retry\&.
|
Generally, a client would call getroute(7) to resolve a route, then use \fBsendpay\fR to send it\&. If it fails, it would call getroute(7) again to retry\&.
|
||||||
.sp
|
.sp
|
||||||
The response will occur when the payment fails or succeeds\&. Once a payment has succeeded, calls to \fBsendpay\fR with the same \fIhash\fR will fail; this prevents accidental multiple payments\&.
|
The response will occur when the payment is on its way to the destination\&. The \fBsendpay\fR RPC command does not wait for definite success or definite failure of the payment\&. Instead, use the \fBwaitsendpay\fR RPC command to poll or wait for definite success or definite failure\&.
|
||||||
|
.sp
|
||||||
|
Once a payment has succeeded, calls to \fBsendpay\fR with the same \fIhash\fR but a different amount or destination will fail; this prevents accidental multiple payments\&. Calls to \fBsendpay\fR with the same \fIhash\fR, amount, and destination as a previous successful payment (even if a different route) will return immediately with success\&.
|
||||||
.SH "RETURN VALUE"
|
.SH "RETURN VALUE"
|
||||||
.sp
|
.sp
|
||||||
On success, a \fIpreimage\fR hex string is returned as proof that the destination received the payment\&. The \fIpreimage\fR will SHA256 to the \fIhash\fR given by the caller\&.
|
On success, an object with field \fIcompleted\fR is returned\&. Typically this field is \fIfalse\fR, but if the payment has already succeeded before to the same destination and amount, the field shall be set to \fItrue\fR and the \fIpreimage\fR will be returned also\&.
|
||||||
.sp
|
.sp
|
||||||
On error, if the error occurred from a node other than the final destination, the route table will be updated so that getroute(7) should return an alternate route (if any)\&. An error from the final destination implies the payment should not be retried\&.
|
On error, if the error occurred from a node other than the final destination, the route table will be updated so that getroute(7) should return an alternate route (if any)\&. An error from the final destination implies the payment should not be retried\&.
|
||||||
.sp
|
.sp
|
||||||
@ -194,7 +196,7 @@ has the UPDATE bit set, as per BOLT #4\&.
|
|||||||
Rusty Russell <rusty@rustcorp\&.com\&.au> is mainly responsible\&.
|
Rusty Russell <rusty@rustcorp\&.com\&.au> is mainly responsible\&.
|
||||||
.SH "SEE ALSO"
|
.SH "SEE ALSO"
|
||||||
.sp
|
.sp
|
||||||
lightning\-listinvoice(7), lightning\-delinvoice(7), lightning\-getroute(7), lightning\-invoice(7)\&.
|
lightning\-listinvoice(7), lightning\-delinvoice(7), lightning\-getroute(7), lightning\-invoice(7), lightning\-pay(7), lightning\-waitsendpay(7)\&.
|
||||||
.SH "RESOURCES"
|
.SH "RESOURCES"
|
||||||
.sp
|
.sp
|
||||||
Main web site: https://github\&.com/ElementsProject/lightning
|
Main web site: https://github\&.com/ElementsProject/lightning
|
||||||
|
@ -20,16 +20,27 @@ Generally, a client would call getroute(7) to resolve a route, then
|
|||||||
use *sendpay* to send it. If it fails, it would call getroute(7)
|
use *sendpay* to send it. If it fails, it would call getroute(7)
|
||||||
again to retry.
|
again to retry.
|
||||||
|
|
||||||
The response will occur when the payment fails or succeeds. Once a
|
The response will occur when the payment is on its way to the
|
||||||
payment has succeeded, calls to *sendpay* with the same 'hash' will
|
destination.
|
||||||
fail; this prevents accidental multiple payments.
|
The *sendpay* RPC command does not wait for definite success or
|
||||||
|
definite failure of the payment.
|
||||||
|
Instead, use the *waitsendpay* RPC command to poll or wait for
|
||||||
|
definite success or definite failure.
|
||||||
|
|
||||||
|
Once a payment has succeeded, calls to *sendpay* with the same 'hash'
|
||||||
|
but a different amount or destination will fail; this prevents
|
||||||
|
accidental multiple payments.
|
||||||
|
Calls to *sendpay* with the same 'hash', amount, and destination as a
|
||||||
|
previous successful payment (even if a different route) will return
|
||||||
|
immediately with success.
|
||||||
|
|
||||||
RETURN VALUE
|
RETURN VALUE
|
||||||
------------
|
------------
|
||||||
|
|
||||||
On success, a 'preimage' hex string is returned as proof that the
|
On success, an object with field 'completed' is returned.
|
||||||
destination received the payment. The 'preimage' will SHA256 to the
|
Typically this field is 'false', but if the payment has already
|
||||||
'hash' given by the caller.
|
succeeded before to the same destination and amount, the field
|
||||||
|
shall be set to 'true' and the 'preimage' will be returned also.
|
||||||
|
|
||||||
On error, if the error occurred from a node other than the final
|
On error, if the error occurred from a node other than the final
|
||||||
destination, the route table will be updated so that getroute(7)
|
destination, the route table will be updated so that getroute(7)
|
||||||
@ -73,7 +84,8 @@ Rusty Russell <rusty@rustcorp.com.au> is mainly responsible.
|
|||||||
SEE ALSO
|
SEE ALSO
|
||||||
--------
|
--------
|
||||||
lightning-listinvoice(7), lightning-delinvoice(7),
|
lightning-listinvoice(7), lightning-delinvoice(7),
|
||||||
lightning-getroute(7), lightning-invoice(7).
|
lightning-getroute(7), lightning-invoice(7),
|
||||||
|
lightning-pay(7), lightning-waitsendpay(7).
|
||||||
|
|
||||||
RESOURCES
|
RESOURCES
|
||||||
---------
|
---------
|
||||||
|
0
doc/lightning-waitsendpay.7
Normal file
0
doc/lightning-waitsendpay.7
Normal file
91
doc/lightning-waitsendpay.7.txt
Normal file
91
doc/lightning-waitsendpay.7.txt
Normal file
@ -0,0 +1,91 @@
|
|||||||
|
LIGHTNING-WAITSENDPAY(7)
|
||||||
|
========================
|
||||||
|
:doctype: manpage
|
||||||
|
|
||||||
|
NAME
|
||||||
|
----
|
||||||
|
lightning-waitsendpay - Protocol for sending a payment via a route.
|
||||||
|
|
||||||
|
SYNOPSIS
|
||||||
|
--------
|
||||||
|
*waitsendpay* 'hash' ['timeout']
|
||||||
|
|
||||||
|
DESCRIPTION
|
||||||
|
-----------
|
||||||
|
|
||||||
|
The *waitsendpay* RPC command polls or waits for the status of
|
||||||
|
an outgoing payment that was initiated by a previous *sendpay*
|
||||||
|
invocation.
|
||||||
|
|
||||||
|
Optionally the client may provide a 'timeout', an integer in
|
||||||
|
seconds, for this RPC command to return.
|
||||||
|
If the 'timeout' is provided and the given amount of time
|
||||||
|
passes without the payment definitely succeeding or definitely
|
||||||
|
failing, this command returns with a 200 error code (payment
|
||||||
|
still in progress).
|
||||||
|
If 'timeout' is not provided this call will wait indefinitely.
|
||||||
|
|
||||||
|
Indicating a 'timeout' of 0 effectively makes this call a
|
||||||
|
pollable query of the status of the payment.
|
||||||
|
|
||||||
|
If the payment completed with success, this command returns
|
||||||
|
with success.
|
||||||
|
Otherwise, if the payment completed with failure, this command
|
||||||
|
returns an error.
|
||||||
|
|
||||||
|
RETURN VALUE
|
||||||
|
------------
|
||||||
|
|
||||||
|
On success, an object with field 'completed' is returned.
|
||||||
|
This field will be 'true' and another field 'preimage' of the
|
||||||
|
object will be set to the preimage.
|
||||||
|
|
||||||
|
On error, if the error occurred from a node other than the final
|
||||||
|
destination, the route table will be updated so that getroute(7)
|
||||||
|
should return an alternate route (if any). An error from the final
|
||||||
|
destination implies the payment should not be retried.
|
||||||
|
|
||||||
|
The following error codes may occur:
|
||||||
|
|
||||||
|
* -1. Catchall nonspecific error.
|
||||||
|
* 200. Timed out before the payment could complete.
|
||||||
|
* 202. Unparseable onion reply. The 'data' field of the error
|
||||||
|
will have an 'onionreply' field, a hex string representation
|
||||||
|
of the raw onion reply.
|
||||||
|
* 203. Permanent failure at destination. The 'data' field of
|
||||||
|
the error will be routing failure object.
|
||||||
|
* 204. Failure along route; retry a different route. The 'data'
|
||||||
|
field of the error will be routing failure object.
|
||||||
|
* 208. A payment for 'hash' was never made and there is nothing
|
||||||
|
to wait for.
|
||||||
|
* 209. The payment already failed, but the reason for failure
|
||||||
|
was not stored. This should only occur when querying failed
|
||||||
|
payments on very old databases.
|
||||||
|
|
||||||
|
A routing failure object has the fields below:
|
||||||
|
|
||||||
|
* 'erring_index'. The index of the node along the route that
|
||||||
|
reported the error. 0 for the local node, 1 for the first
|
||||||
|
hop, and so on.
|
||||||
|
* 'erring_node'. The hex string of the pubkey id of the node
|
||||||
|
that reported the error.
|
||||||
|
* 'erring_channel'. The short channel ID of the channel that
|
||||||
|
has the error, or '0:0:0' if the destination node raised
|
||||||
|
the error.
|
||||||
|
* 'failcode'. The failure code, as per BOLT #4.
|
||||||
|
* 'channel_update'. The hex string of the 'channel_update'
|
||||||
|
message received from the remote node. Only present if
|
||||||
|
error is from the remote node and the 'failcode' has the
|
||||||
|
UPDATE bit set, as per BOLT #4.
|
||||||
|
|
||||||
|
AUTHOR
|
||||||
|
------
|
||||||
|
ZmnSCPxj <ZmnSCPxj@protonmail.com> is mainly responsible.
|
||||||
|
|
||||||
|
SEE ALSO
|
||||||
|
--------
|
||||||
|
lightning-sendpay(7), lightning-pay(7).
|
||||||
|
|
||||||
|
RESOURCES
|
||||||
|
---------
|
||||||
|
Main web site: https://github.com/ElementsProject/lightning
|
Loading…
Reference in New Issue
Block a user