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.
Appending the channel direction ensures that the directions will be
treated independently. Without this only one direction would be
forwarded to the peers.
The direction bit was computed in several spots and was inconsistent
in some cases. Now we compute it just in routing, and once when
starting up `channeld`, this avoids recomputing it all over the place.
Before exiting, `channeld` constructs and sends a `channel_update`
marking the channel as disabled. This is the pro-active signalling
that the channel may no longer be used.
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.
Other than being neater (no more global list to edit!), this lets the
new daemon and old daemon have their own separate routines.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Connections are in a half-open state after receiving the
`channel_announcement` and before the `channel_update` makes them
usable, so we need to ignore channels that are not yet fully open.
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>
Fixes#50. Was causing a segfault because it was creating an empty route
and was trying to extract the first hop as next hop. Routes through self
can still be created manually, but `sendpay` would still refuse to act
on them due to the missing self-link.
getnodes returns an object containing a single array of 'nodes'. Each
element contains the node's ID, its hostname and its port. If
unknown (because we haven't seen a node announcement yet) then the port
is 0 and the hostname is null.
'getchannels' returns a 'channels' array containing an object for each
known channel. Each channel object represents one direction of a
bidirectional channel, with a from and a to node ID along with the fees
for that direction. This matched the internal storage of channels and
allows unbalanced fees for each direction.
Rename the structs to match (and remove dev-echo).
This makes it clear that they're not the normal API.
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>
The first hop is being stripped from computed routes, however the
first channel of the route is being used to get our peer address. This
results in segfaults if the route is just one hop, i.e., has no first
channel to get the peer's address from. Fixed by simply using an
existing pointer to our peer.
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>
We're about to change the code so that if it can't route, it will fail
the HTLC. The current low-level tests will hate this, so have a dev switch
to turn that off.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Christian Decker
Rusty Russell