diff --git a/doc/Makefile b/doc/Makefile index 10e78060b..06c2e3a60 100644 --- a/doc/Makefile +++ b/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) diff --git a/doc/lightning-sendpay.7 b/doc/lightning-sendpay.7 index bb0b2b644..63f78059b 100644 --- a/doc/lightning-sendpay.7 +++ b/doc/lightning-sendpay.7 @@ -2,12 +2,12 @@ .\" Title: lightning-sendpay .\" Author: [see the "AUTHOR" section] .\" Generator: DocBook XSL Stylesheets v1.79.1 -.\" 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 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 diff --git a/doc/lightning-sendpay.7.txt b/doc/lightning-sendpay.7.txt index 6d9329414..162b80598 100644 --- a/doc/lightning-sendpay.7.txt +++ b/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 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 --------- diff --git a/doc/lightning-waitsendpay.7 b/doc/lightning-waitsendpay.7 new file mode 100644 index 000000000..e69de29bb diff --git a/doc/lightning-waitsendpay.7.txt b/doc/lightning-waitsendpay.7.txt new file mode 100644 index 000000000..1b63caa54 --- /dev/null +++ b/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 is mainly responsible. + +SEE ALSO +-------- +lightning-sendpay(7), lightning-pay(7). + +RESOURCES +--------- +Main web site: https://github.com/ElementsProject/lightning