The JSON-RPC call `getroute` and the functionality to compute the
actual route have been split so that we can reuse it independently of
the JSON-interface. Since this is now a routing-only method I also
moved it into `routing.[ch]` instead of `pay.c`.
The spec 4af8e1841151f0c6e8151979d6c89d11839b2f65 uses a 32-byte 'channel-id'
field, not to be confused with the 8-byte short ID used by gossip. Rename
appropriately, and update to the new handshake protocol.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Moved the broadcast functionality to broadcast.[ch]. So far this
includes only the enqueuing side of broadcasts, the dequeuing and
actual push to the peer is daemon dependent. This also adds the
broadcast_state to the routing_state and the last broadcast index to
the peer for the legacy daemon.
This was the only time we actually reference non-routing structs in
routing, so moving this out should allow us to get it working in the
new subdaemons.
This allows us to move some legacy functions closer to where they are
actually used, and not worry about them when including routing.h into
the new subdaemons. `struct peer` is the main culprit here.
This used to be part of `lightningd_state` which is being split up for
the various subdaemons. The main change is the addition of the `struct
routing_state` in `routing.h` and the addition of `rstate` in `struct
lightningd_state` for backwards compatibility.
828eda61df5a7be27051c605f7808e4f690739e4, in particular, it has the
new address format for node_announcement.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The gossip protocol spec refers to channels by their `channel_id` and
a direction. Furthermore, inbetween the `channel_announcement` and the
`channel_update` for either direction, the channel direction is in an
undefined state and cannot be used, so added the `half_add_connection`
function and an `active` flag to differentiate usable connections from
unusable ones.
Allocate the route off the current command, not dstate. And in the
case where the route is somehow not via a peer, don't leak memory.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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 allows hardcoded routes in the config file, which is required until
we get route advertisements.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Christian Decker
Rusty Russell