Just a small cleanup of the indentation code, so we don't have to reformat all
the issue reports to become readable. This is much closer to what `jq` or
`json_pp` spit out and doesn't have those infinitely long lines.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
We move it into jsonrpc where it belongs, and make it fail the command.
This means it can tell us exactly what was wrong.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change could break users who accidentally have typos in scripts,
so we need to check sooner rather than later.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
ie. non-printable, quotes or escapes. We allow these outside tokens
(we expect tabs and \n for example).
This is a big hammer, but if someone really wants we can add support
later.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Don't try to escape them. It's whack-a-mole and they shouldn't do it anyway.
Suggested-by: Christian Decker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
They don't currently, since callers check, but be safe. In addition,
handle NULL returns from these in the bitcoind code.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Also, we split the more sophisticated json_add helpers to avoid pulling in
everything into lightning-cli, and unify the routines to print struct
short_channel_id (it's ':', not '/' too).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The new onion uses the `channel_id` instead of the `node_id` of the
next hop to identify where to forward the payment. So we return the
exact channel chosen by the routing algo, to avoid having to look it
up again later.
We need some way to reflect the tradeoff between the possible delay if
a payment gets stuck, and the fees charged by nodes. This adds a risk
factor which reflects the probability that a node goes down, and the
cost associated with losing access to our funds for a given time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is less convenient to use, but makes far more sense for a real
user (like a wallet). It can ask about the route, then decide whether
to use it or not.
This will make even more sense once we add a parameter to control how
long we let the HTLC be delayed for, so a client can query for high,
medium and low tolerances and compare results.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Christian Decker
practicalswift
Rusty Russell
ZmnSCPxj
Björge Dijkstra
Andrew Chow