Browse Source

doc: Update sendpay and waitsendpay manpages.

ppa-0.6.1
ZmnSCPxj 7 years ago
committed by Rusty Russell
parent
commit
8fd71ad654
  1. 3
      doc/Makefile
  2. 12
      doc/lightning-sendpay.7
  3. 26
      doc/lightning-sendpay.7.txt
  4. 0
      doc/lightning-waitsendpay.7
  5. 91
      doc/lightning-waitsendpay.7.txt

3
doc/Makefile

@ -14,7 +14,8 @@ MANPAGES := doc/lightning-cli.1 \
doc/lightning-pay.7 \
doc/lightning-sendpay.7 \
doc/lightning-waitinvoice.7 \
doc/lightning-waitanyinvoice.7
doc/lightning-waitanyinvoice.7 \
doc/lightning-waitsendpay.7
doc-all: $(MANPAGES)

12
doc/lightning-sendpay.7

@ -2,12 +2,12 @@
.\" Title: lightning-sendpay
.\" Author: [see the "AUTHOR" section]
.\" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/>
.\" Date: 02/06/2018
.\" Date: 03/08/2018
.\" Manual: \ \&
.\" Source: \ \&
.\" Language: English
.\"
.TH "LIGHTNING\-SENDPAY" "7" "02/06/2018" "\ \&" "\ \&"
.TH "LIGHTNING\-SENDPAY" "7" "03/08/2018" "\ \&" "\ \&"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
@ -38,10 +38,12 @@ The \fBsendpay\fR RPC command attempts to send funds associated with the given \
.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\&.
.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"
.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
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
@ -194,7 +196,7 @@ has the UPDATE bit set, as per BOLT #4\&.
Rusty Russell <rusty@rustcorp\&.com\&.au> is mainly responsible\&.
.SH "SEE ALSO"
.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"
.sp
Main web site: https://github\&.com/ElementsProject/lightning

26
doc/lightning-sendpay.7.txt

@ -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)
again to retry.
The response will occur when the payment fails or succeeds. Once a
payment has succeeded, calls to *sendpay* with the same 'hash' will
fail; this prevents accidental multiple payments.
The response will occur when the payment is on its way to the
destination.
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
------------
On success, a 'preimage' hex string is returned as proof that the
destination received the payment. The 'preimage' will SHA256 to the
'hash' given by the caller.
On success, an object with field 'completed' is returned.
Typically this field is 'false', but if the payment has already
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
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
--------
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
---------

0
doc/lightning-waitsendpay.7

91
doc/lightning-waitsendpay.7.txt

@ -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…
Cancel
Save