2016-09-06 16:47:41 +09:30
'\" t
. \" Title: lightning-getroute
. \" Author: [see the "AUTHOR" section]
. \" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/>
2019-03-01 14:26:16 +10:30
. \" Date: 03/01/2019
2016-09-06 16:47:41 +09:30
. \" Manual: \ \&
. \" Source: \ \&
. \" Language: English
. \"
2019-03-01 14:26:16 +10:30
.TH "LIGHTNING\-GETROUTE" "7" "03/01/2019" "\ \&" "\ \&"
2016-09-06 16:47:41 +09:30
. \" -----------------------------------------------------------------
. \" * Define some portability stuff
. \" -----------------------------------------------------------------
. \" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
. \" http://bugs.debian.org/507673
. \" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
. \" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n (.g .ds Aq \(aq
.el .ds Aq '
. \" -----------------------------------------------------------------
. \" * set default formatting
. \" -----------------------------------------------------------------
. \" disable hyphenation
.nh
. \" disable justification (adjust text to left margin only)
.ad l
. \" -----------------------------------------------------------------
. \" * MAIN CONTENT STARTS HERE *
. \" -----------------------------------------------------------------
.SH "NAME"
2018-04-26 13:22:09 +03:00
lightning-getroute \- Command for routing a payment (low\- level)\& .
2016-09-06 16:47:41 +09:30
.SH "SYNOPSIS"
.sp
2019-03-01 14:26:16 +10:30
\fB getroute\fR \fI id\fR \fI msatoshi\fR \fI riskfactor\fR [\fI cltv\fR ] [\fI fromid\fR ] [\fI fuzzpercent\fR ] [\fI exclude\fR ] [\fI maxhops\fR ]
2016-09-06 16:47:41 +09:30
.SH "DESCRIPTION"
.sp
2018-01-17 06:14:32 +10:30
The \fB getroute\fR RPC command attempts to find the best route for the payment of \fI msatoshi\fR to lightning node \fI id\fR , such that the payment will arrive at \fI id\fR with \fI cltv\fR \- blocks to spare (default 9)\& .
2016-09-06 16:47:41 +09:30
.sp
2019-02-23 14:06:29 +10:30
\fI msatoshi\fR is in millisatoshi precision; it can be a whole number, or a whole number ending in \fI msat\fR or \fI sat\fR , or a number with three decimal places ending in \fI sat\fR , or a number with 1 to 11 decimal places ending in \fI btc\fR \& .
2019-02-21 13:10:31 +10:30
.sp
2019-02-16 12:55:44 +02:00
There are two considerations for how good a route is: how low the fees are, and how long your payment will get stuck in a delayed output if a node goes down during the process\& . The \fI riskfactor\fR floating\- point field controls this tradeoff; it is the annual cost of your funds being stuck (as a percentage)\& .
2016-09-06 16:47:41 +09:30
.sp
2019-02-16 12:55:44 +02:00
For example, if you thought the convenience of keeping your funds liquid (not stuck) was worth 20% per annum interest, \fI riskfactor\fR would be 20\& .
2016-09-06 16:47:41 +09:30
.sp
If you didn\(cq t care about risk, \fI riskfactor\fR would be zero\& .
2018-02-16 16:00:58 +00:00
.sp
2019-01-15 14:25:27 +10:30
\fI fromid\fR is the node to start the route from: default is this node\& .
2018-02-16 16:00:58 +00:00
.sp
2019-01-15 14:25:27 +10:30
The \fI fuzzpercent\fR is a positive floating\- point number, representing a percentage of the actual fee\& . The \fI fuzzpercent\fR is used to distort computed fees along each channel, to provide some randomization to the route generated\& . 0\& .0 means the exact fee of that channel is used, while 100\& .0 means the fee used might be from 0 to twice the actual fee\& . The default is 5\& .0, or up to 5% fee distortion\& .
2019-03-01 14:26:16 +10:30
.sp
\fI exclude\fR is a JSON array of short\- channel\- id/direction (e\& .g\& . [ "564334x877x1/0", "564195x1292x0/1" ]) which should be excluded from consideration for routing\& . The default is not to exclude any channels\& .
.sp
\fI maxhops\fR is the maximum number of channels to return; default is 20\& .
2016-09-06 16:47:41 +09:30
.SH "RISKFACTOR EFFECT ON ROUTING"
.sp
The risk factor is treated as if it were an additional fee on the route, for the purposes of comparing routes\& .
.sp
The formula used is the following approximation:
.sp
.if n \{ \
.RS 4
. \}
.nf
2019-02-01 16:23:39 +10:30
risk\- fee = amount x blocks\- timeout x per\- block\- cost
2016-09-06 16:47:41 +09:30
.fi
.if n \{ \
.RE
. \}
.sp
2019-02-01 16:23:39 +10:30
We are given a \fI riskfactor\fR expressed as a percentage\& . There are 52596 blocks per year, thus \fI per\- block\- cost\fR is \fI riskfactor\fR divided by 5,259,600\& .
2016-09-06 16:47:41 +09:30
.sp
The final result is:
.sp
.if n \{ \
.RS 4
. \}
.nf
2019-02-01 16:23:39 +10:30
risk\- fee = amount x blocks\- timeout x riskfactor / 5259600
2016-09-06 16:47:41 +09:30
.fi
.if n \{ \
.RE
. \}
.sp
2019-02-16 12:55:44 +02:00
Here are the risk fees in millisatoshis, using various parameters\& . I assume a channel charges the default of 1000 millisatoshis plus 1 part\- per\- million\& . Common to_self_delay values on the network at 14 and 144 blocks\& .
2016-09-06 16:47:41 +09:30
.TS
allbox tab(:);
ltB ltB ltB ltB ltB.
T{
2019-02-01 16:23:39 +10:30
Amount (msat)
2016-09-06 16:47:41 +09:30
T}:T{
2019-02-01 16:23:39 +10:30
Riskfactor
2016-09-06 16:47:41 +09:30
T}:T{
2019-02-01 16:23:39 +10:30
Delay
2016-09-06 16:47:41 +09:30
T}:T{
2019-02-01 16:23:39 +10:30
Risk Fee
2016-09-06 16:47:41 +09:30
T}:T{
2019-02-01 16:23:39 +10:30
Route fee
2016-09-06 16:47:41 +09:30
T}
.T &
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
2019-02-01 16:23:39 +10:30
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
lt lt lt lt lt
2016-09-06 16:47:41 +09:30
lt lt lt lt lt.
T{
.sp
2019-02-01 16:23:39 +10:30
10,000
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
1
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
14
2016-09-06 16:47:41 +09:30
T}:T{
.sp
0
T}:T{
.sp
2019-02-01 16:23:39 +10:30
1001
2016-09-06 16:47:41 +09:30
T}
T{
.sp
2019-02-01 16:23:39 +10:30
10,000
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
10
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
14
2016-09-06 16:47:41 +09:30
T}:T{
.sp
0
T}:T{
.sp
2019-02-01 16:23:39 +10:30
1001
T}
T{
.sp
10,000
T}:T{
.sp
100
T}:T{
.sp
14
T}:T{
.sp
2
T}:T{
.sp
1001
2016-09-06 16:47:41 +09:30
T}
T{
.sp
2019-02-01 16:23:39 +10:30
10,000
T}:T{
.sp
2016-09-06 16:47:41 +09:30
1000
T}:T{
.sp
2019-02-01 16:23:39 +10:30
14
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
26
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
1001
T}
T{
.sp
1,000,000
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
1
T}:T{
.sp
14
T}:T{
.sp
2
T}:T{
.sp
1001
2016-09-06 16:47:41 +09:30
T}
T{
.sp
2019-02-01 16:23:39 +10:30
1,000,000
2016-09-06 16:47:41 +09:30
T}:T{
.sp
10
T}:T{
.sp
2019-02-01 16:23:39 +10:30
14
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
26
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
1001
2016-09-06 16:47:41 +09:30
T}
T{
.sp
2019-02-01 16:23:39 +10:30
1,000,000
T}:T{
.sp
100
T}:T{
.sp
14
T}:T{
.sp
266
T}:T{
.sp
1001
T}
T{
.sp
1,000,000
T}:T{
.sp
1000
T}:T{
.sp
14
T}:T{
.sp
2661
T}:T{
.sp
1001
T}
T{
.sp
100,000,000
T}:T{
.sp
2016-09-06 16:47:41 +09:30
1
T}:T{
.sp
2019-02-01 16:23:39 +10:30
14
T}:T{
.sp
266
T}:T{
.sp
1100
T}
T{
.sp
100,000,000
T}:T{
.sp
2016-09-06 16:47:41 +09:30
10
T}:T{
.sp
2019-02-01 16:23:39 +10:30
14
T}:T{
.sp
2661
T}:T{
.sp
1100
T}
T{
.sp
100,000,000
T}:T{
.sp
100
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
14
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
26617
T}:T{
.sp
1100
2016-09-06 16:47:41 +09:30
T}
T{
.sp
2019-02-01 16:23:39 +10:30
100,000,000
T}:T{
.sp
2016-09-06 16:47:41 +09:30
1000
T}:T{
.sp
2019-02-01 16:23:39 +10:30
14
T}:T{
.sp
266179
T}:T{
.sp
1100
T}
T{
.sp
10,000
T}:T{
.sp
1
T}:T{
.sp
144
T}:T{
.sp
0
T}:T{
.sp
1001
T}
T{
.sp
10,000
T}:T{
.sp
2016-09-06 16:47:41 +09:30
10
T}:T{
.sp
2019-02-01 16:23:39 +10:30
144
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
2
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
1001
2016-09-06 16:47:41 +09:30
T}
T{
.sp
2019-02-01 16:23:39 +10:30
10,000
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
100
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
144
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
27
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
1001
2016-09-06 16:47:41 +09:30
T}
T{
.sp
2019-02-01 16:23:39 +10:30
10,000
T}:T{
.sp
1000
T}:T{
.sp
144
T}:T{
.sp
273
T}:T{
.sp
1001
T}
T{
.sp
1,000,000
T}:T{
.sp
2016-09-06 16:47:41 +09:30
1
T}:T{
.sp
2019-02-01 16:23:39 +10:30
144
T}:T{
.sp
27
T}:T{
.sp
1001
T}
T{
.sp
1,000,000
T}:T{
.sp
10
T}:T{
.sp
144
T}:T{
.sp
273
T}:T{
.sp
1001
T}
T{
.sp
1,000,000
T}:T{
.sp
100
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
144
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
2737
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
1001
2016-09-06 16:47:41 +09:30
T}
T{
.sp
2019-02-01 16:23:39 +10:30
1,000,000
T}:T{
.sp
2016-09-06 16:47:41 +09:30
1000
T}:T{
.sp
2019-02-01 16:23:39 +10:30
144
T}:T{
.sp
27378
T}:T{
.sp
1001
T}
T{
.sp
100,000,000
T}:T{
.sp
1
T}:T{
.sp
144
T}:T{
.sp
2737
T}:T{
.sp
1100
T}
T{
.sp
100,000,000
T}:T{
.sp
10
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
144
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
27378
2016-09-06 16:47:41 +09:30
T}:T{
.sp
2019-02-01 16:23:39 +10:30
1100
T}
T{
.sp
100,000,000
T}:T{
.sp
100
T}:T{
.sp
144
T}:T{
.sp
273785
T}:T{
.sp
1100
T}
T{
.sp
100,000,000
T}:T{
.sp
1000
T}:T{
.sp
144
T}:T{
.sp
2737850
T}:T{
.sp
1100
2016-09-06 16:47:41 +09:30
T}
.TE
.sp 1
.SH "RECOMMENDED RISKFACTOR VALUES"
.sp
2019-02-01 16:23:39 +10:30
The default \fI fuzz\fR factor is 5%, so as you can see from the table above, that tends to overwhelm the effect of \fI riskfactor\fR less than about 5\& .
2016-09-06 16:47:41 +09:30
.sp
1 is a conservative value for a stable lightning network with very few failures\& .
.sp
1000 is an aggressive value for trying to minimize timeouts at all costs\& .
2019-02-01 16:23:39 +10:30
.sp
The default for lightning\- pay(7) is 10, which starts to become a major factor for larger amounts, and is basically ignored for tiny ones\& .
2016-09-06 16:47:41 +09:30
.SH "RETURN VALUE"
.sp
2019-02-21 13:10:31 +10:30
On success, a "route" array is returned\& . Each array element contains \fI id\fR (the node being routed through), \fI msatoshi\fR (the millisatoshis sent), \fI amount_msat\fR (the same, with \fI msat\fR appended), and \fI delay\fR (the number of blocks to timeout at this node)\& .
2016-09-06 16:47:41 +09:30
.sp
2019-01-23 10:39:56 -06:00
The final \fI id\fR will be the destination \fI id\fR given in the input\& . The difference between the first \fI msatoshi\fR minus the \fI msatoshi\fR given in the input is the fee\& . The first \fI delay\fR is the very worst case timeout for the payment failure, in blocks\& .
2016-09-06 16:47:41 +09:30
.SH "AUTHOR"
.sp
Rusty Russell <rusty@rustcorp\& .com\& .au> is mainly responsible\& .
.SH "SEE ALSO"
.sp
2018-01-13 21:51:33 +10:30
lightning\- pay(7), lightning\- sendpay(7)\& .
2016-09-06 16:47:41 +09:30
.SH "RESOURCES"
.sp
Main web site: https://github\& .com/ElementsProject/lightning