This is part of our new "Python programmers are people too" policy.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Not very useful by itself, but when combined with decodemsg it can tell
us quite a bit.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Suggested-by: @rustyrussell
Signed-off-by: Mark Beckwith <wythe@intrig.com>

The `json_tok_X` functions now consistently check the success case first
and call `command_fail` at the end.

Signed-off-by: Mark Beckwith <wythe@intrig.com>

We were returning a pointer but expecting a bool.

Signed-off-by: Mark Beckwith <wythe@intrig.com>

Note: Unlike before, this will now accept positional parameters.

Note: In case of error we no longer report the hop number.  Is this acceptable?
We still report the name of the bad param and its value.

One option is to log the hop number if param() returns false.  This would require
a change to command_fail so it doesn't delete the cmd, so we can still
access cmd->ld->log.

Signed-off-by: Mark Beckwith <wythe@intrig.com>

Added utility function json_tok_is_num so I would avoid using goto.

Signed-off-by: Mark Beckwith <wythe@intrig.com>

Signed-off-by: Mark Beckwith <wythe@intrig.com>

This could have been a local static but its used by the run-param test,
so putting it in json.c made things easier.

Signed-off-by: Mark Beckwith <wythe@intrig.com>

Needed to do this so I could remove the implementation in
the run-param test.

Signed-off-by: Mark Beckwith <wythe@intrig.com>

Signed-off-by: Mark Beckwith <wythe@intrig.com>

Signed-off-by: Mark Beckwith <wythe@intrig.com>

Signed-off-by: Mark Beckwith <wythe@intrig.com>

Signed-off-by: Mark Beckwith <wythe@intrig.com>

Signed-off-by: Mark Beckwith <wythe@intrig.com>

Signed-off-by: Mark Beckwith <wythe@intrig.com>

Well its about time.

Signed-off-by: Mark Beckwith <wythe@intrig.com>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

We're a daemon.  They're subdaemons.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

We already have access via the ld object, and we initialized this one
twice anyway.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

We have a transaction anyway, and it's simpler.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Also, wallet has no business wiring up HTLCs; move that code to
peer_htlcs.c.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

@renepickhardt: why is it actually lightningd.c with a d but hsm.c without d ?

And delete unused gossipd/gossip.h.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Code changes:
1. Expose daemon_poll() so lightningd can call it directly, which avoids us
   having store a global and document it.
2. Remove the (undocumented, unused, forgotten) --rpc-file="" option to disable
   JSON RPC.
3. Move the ickiness of finding the executable path into subd.c, so it doesn't
   distract from lightningd.c overview.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Documentation changes:
1. Lots of extra detail suggested by @renepickhardt.
2. typo fixes from @practicalswift.
3. A section on 'const' usage.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Suggested-by: @practicalswift and @cdecker.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

This was found because it means we have a non-zero feerate without
filling in the history of that feerate:

==15895== Conditional jump or move depends on uninitialised value(s)
==15895==    at 0x408699: feerate_max (chaintopology.c:828)
==15895==    by 0x41BE49: peer_start_openingd (opening_control.c:733)
==15895==    by 0x425FE9: peer_connected (peer_control.c:515)
==15895==    by 0x40CB8F: connectd_msg (connect_control.c:304)
==15895==    by 0x42DB4E: sd_msg_read (subd.c:475)
==15895==    by 0x42D499: read_fds (subd.c:302)
==15895==    by 0x46EB18: next_plan (io.c:59)
==15895==    by 0x46F5E9: do_plan (io.c:387)
==15895==    by 0x46F627: io_ready (io.c:397)
==15895==    by 0x471187: io_loop (poll.c:310)
==15895==    by 0x41683D: main (lightningd.c:732)

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

It was annoying me, so I made it much nicer to use.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

These happen after we compact the store; every log I've seen of a
restart on a real node has a message about truncating the store,
because node_announcements predate channel_announcements.

I extracted one such case from testnet, and reduced it to test here.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

…unced channel.

If we receive a channel_announce but not a channel_update, we store the announce
but don't put it in the broadcast map.

When we delete a channel, we check if the node_announcement broadcast
now preceeds all channel_announcements, and if so, we move it to the
end of the map.  However, with a channel_announcement at index '0',
this test fails.

This is at least one potential cause of the node map getting out of order.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

… outgoing htlcs

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

It's an array: we were only saving the single element; if there was more than
one changed HTLC we'd get a bad signature!

The report in #1907 is probably caused by the other side re-requesting
something we considered already finalized; to avoid this particular error,
we should set the field to NULL if there's no last_sent_commit.

I'm increasingly of the opinion we want to just save all the update
packets to the db and blast them out, instead of doing this
second-guessing dance.

Fixes: #1907
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Installing pytest through pip3 (at least sometimes) doesn't create a script.
This means calling `which` won't work.
Changed configure so that it can also test if the module is present by calling python/python3.
Change the error message for when pytest can't be found, so that it's clear to the user `configure` must be ran again after installing pytest.