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

Signed-off-by: Rusty Russell <[email protected]>

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

Signed-off-by: Rusty Russell <[email protected]>

Suggested-by: @rustyrussell
Signed-off-by: Mark Beckwith <[email protected]>

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

Signed-off-by: Mark Beckwith <[email protected]>

We were returning a pointer but expecting a bool.

Signed-off-by: Mark Beckwith <[email protected]>

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 <[email protected]>

Added utility function json_tok_is_num so I would avoid using goto.

Signed-off-by: Mark Beckwith <[email protected]>

Signed-off-by: Mark Beckwith <[email protected]>

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 <[email protected]>

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

Signed-off-by: Mark Beckwith <[email protected]>

Signed-off-by: Mark Beckwith <[email protected]>

Signed-off-by: Mark Beckwith <[email protected]>

Signed-off-by: Mark Beckwith <[email protected]>

Signed-off-by: Mark Beckwith <[email protected]>

Signed-off-by: Mark Beckwith <[email protected]>

Signed-off-by: Mark Beckwith <[email protected]>

Well its about time.

Signed-off-by: Mark Beckwith <[email protected]>

Signed-off-by: Rusty Russell <[email protected]>

We're a daemon.  They're subdaemons.

Signed-off-by: Rusty Russell <[email protected]>

Signed-off-by: Rusty Russell <[email protected]>

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

Signed-off-by: Rusty Russell <[email protected]>

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

Signed-off-by: Rusty Russell <[email protected]>

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

Signed-off-by: Rusty Russell <[email protected]>

Signed-off-by: Rusty Russell <[email protected]>

@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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

Suggested-by: @practicalswift and @cdecker.

Signed-off-by: Rusty Russell <[email protected]>

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 <[email protected]>

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

Signed-off-by: Rusty Russell <[email protected]>

Signed-off-by: Rusty Russell <[email protected]>

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 <[email protected]>

…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 <[email protected]>

… outgoing htlcs

Signed-off-by: Rusty Russell <[email protected]>

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 <[email protected]>

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.