forked from ElementsProject/lightning
-
Notifications
You must be signed in to change notification settings - Fork 0
/
lightning-sendpay.7.txt
103 lines (85 loc) · 3.52 KB
/
lightning-sendpay.7.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
LIGHTNING-SENDPAY(7)
====================
:doctype: manpage
NAME
----
lightning-sendpay - Command for sending a payment via a route.
SYNOPSIS
--------
*sendpay* 'route' 'hash' ['msatoshi']
DESCRIPTION
-----------
The *sendpay* RPC command attempts to send funds associated with the
given 'hash', along a route to the final destination in the route.
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 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.
The 'msatoshi' amount, if provided, is the amount that will be
recorded as the target payment value.
If not specified, it will be the final amount to the destination.
If specified, then the final amount at the destination must be
from the specified 'msatoshi' to twice the specified 'msatoshi',
inclusive.
This is intended to obscure payments by overpaying slightly at
the destination;
the actual target payment is what should be specified as the
'msatoshi' argument.
Once a payment has succeeded, calls to *sendpay* with the same 'hash'
but a different 'msatoshi' or destination will fail; this prevents
accidental multiple payments.
Calls to *sendpay* with the same 'hash', 'msatoshi', and destination as a
previous successful payment (even if a different route) will return
immediately with success.
RETURN VALUE
------------
On success, an object similar to the output of *listpayments* will
be returned.
This object will have a 'status' field that is typically the
string '"pending"', but may be '"complete"' if the payment was
already performed successfully.
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.
* 201. Already paid with this 'hash' using different amount or
destination.
* 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.
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
------
Rusty Russell <rusty@rustcorp.com.au> is mainly responsible.
SEE ALSO
--------
lightning-listinvoice(7), lightning-delinvoice(7),
lightning-getroute(7), lightning-invoice(7),
lightning-pay(7), lightning-waitsendpay(7).
RESOURCES
---------
Main web site: https://github.com/ElementsProject/lightning