forked from ElementsProject/lightning
-
Notifications
You must be signed in to change notification settings - Fork 0
/
lightning-keysend.7
125 lines (81 loc) · 5.46 KB
/
lightning-keysend.7
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
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
.TH "LIGHTNING-KEYSEND" "7" "" "" "lightning-keysend"
.SH NAME
lightning-keysend - Send funds to a node without an invoice
.SH SYNOPSIS
\fBkeysend\fR \fIdestination\fR \fImsatoshi\fR [\fIlabel\fR] [\fImaxfeepercent\fR] [\fIretry_for\fR] [\fImaxdelay\fR] [\fIexemptfee\fR]
.SH DESCRIPTION
The \fBkeysend\fR RPC command attempts to find a route to the given destination,
and send the specified amount to it\. Unlike the \fBpay\fR RPC command the
\fBkeysend\fR command does not require an invoice, instead it uses the
\fBdestination\fR node ID, and \fBamount\fR to find a route to the specified node\.
In order for the destination to be able to claim the payment, the
\fBpayment_key\fR is randomly generated by the sender and included in the
encrypted payload for the destination\. As a consequence there is not
proof-of-payment, like there is with an invoice where the \fBpayment_key\fR is
generated on the destination, and the only way sender could have it is by
sending a payment\. Please ensure that this matches your use-case when using
\fBkeysend\fR\.
\fBdestination\fR is the 33 byte, hex-encoded, node ID of the node that the payment should go to\.
\fBmsatoshi\fR is in millisatoshi precision; it can be a whole number, or a whole number with suffix \fBmsat\fR or \fBsat\fR, or a three decimal point number with suffix \fBsat\fR, or an 1 to 11 decimal point number suffixed by \fBbtc\fR\.
The \fBlabel\fR field is used to attach a label to payments, and is returned in \fBlightning-listpays\fR(7) and \fBlightning-listsendpays\fR(7)\.
The \fBmaxfeepercent\fR limits the money paid in fees as percentage of the total amount that is to be transferred, and defaults to \fI0\.5\fR\.
The \fBexemptfee\fR option can be used for tiny payments which would be dominated by the fee leveraged by forwarding nodes\.
Setting \fBexemptfee\fR allows the \fBmaxfeepercent\fR check to be skipped on fees that are smaller than \fIexemptfee\fR (default: 5000 millisatoshi)\.
The response will occur when the payment fails or succeeds\.
Unlike \fBlightning-pay\fR(7), issuing the same \fBkeysend\fR commands multiple times will result in multiple payments being sent\.
Until \fIretry_for\fR seconds passes (default: 60), the command will keep finding routes and retrying the payment\.
However, a payment may be delayed for up to \fBmaxdelay\fR blocks by another node; clients should be prepared for this worst case\.
When using \fIlightning-cli\fR, you may skip optional parameters by using
\fInull\fR\. Alternatively, use \fB-k\fR option to provide parameters by name\.
.SH RANDOMIZATION
To protect user privacy, the payment algorithm performs some randomization\.
1: Route Randomization
Route randomization means the payment algorithm does not always use the
lowest-fee or shortest route\. This prevents some highly-connected node
from learning all of the user payments by reducing their fees below the
network average\.
2: Shadow Route
Shadow route means the payment algorithm will virtually extend the route
by adding delays and fees along it, making it appear to intermediate nodes
that the route is longer than it actually is\. This prevents intermediate
nodes from reliably guessing their distance from the payee\.
Route randomization will never exceed \fImaxfeepercent\fR of the payment\.
Route randomization and shadow routing will not take routes that would
exceed \fImaxdelay\fR\.
.SH RETURN VALUE
On success, \fBkeysend\fR will return a number of internal statistics and details of the attempts to reach the \fIdestination\fR\.
You can monitor the progress and retries of a payment using the \fBlightning-paystatus\fR(7) command\.
The following error codes may occur:
.RS
.IP \[bu]
\fB-1\fR: Catchall nonspecific error\.
.IP \[bu]
\fB203\fR: Permanent failure at destination\. The \fIdata\fR field of the error will be routing failure object\.
.IP \[bu]
\fB205\fR: Unable to find a route\.
.IP \[bu]
\fB206\fR: Route too expensive\. Either the fee or the needed total locktime for the route exceeds your \fImaxfeepercent\fR or \fImaxdelay\fR settings, respectively\. The \fIdata\fR field of the error will indicate the actual \fIfee\fR as well as the \fIfeepercent\fR percentage that the fee has of the destination payment amount\. It will also indicate the actual \fIdelay\fR along the route\.
.IP \[bu]
\fB210\fR: Payment timed out without a payment in progress\.
.RE
A routing failure object has the fields below:
.RS
.IP \[bu]
\fBerring_index\fR: 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\.
.IP \[bu]
\fBerring_node\fR: The hex string of the pubkey id of the node that reported the error\.
.IP \[bu]
\fBerring_channel\fR: The short channel ID of the channel that has the error, or \fI0:0:0\fR if the destination node raised the error\.
.IP \[bu]
\fBfailcode\fR: The failure code, as per BOLT #4\.
.IP \[bu]
\fBchannel_update\fR\. The hex string of the \fIchannel_update\fR message received from the remote node\. Only present if error is from the remote node and the \fIfailcode\fR has the \fBUPDATE\fR bit set, as per BOLT #4\.
.RE
.SH AUTHOR
Christian Decker \fI<[email protected]\fR> is mainly responsible\.
.SH SEE ALSO
\fBlightning-listpays\fR(7), \fBlightning-decodepay\fR(7), \fBlightning-listinvoice\fR(7),
\fBlightning-delinvoice\fR(7), \fBlightning-getroute\fR(7), \fBlightning-invoice\fR(7)\.
.SH RESOURCES
Main web site: \fIhttps://github.com/ElementsProject/lightning\fR
\" SHA256STAMP:8d26499787c316e9b75ad304ffc1c872af523564750558ba986c2ccde63294c7