d2c626820f
channel: Wait for 6 confirmations before sending announcement sigs
The protocol specifies that in order for an announcement to be valid,
the channel has to have at least 6 confirmations.
8 years ago
38bffc0f0c
lightningd/subd: support multiple fds sent at once in request reply.
Instead of indicating where to place the fd, you say how many: the
fd array gets passed into the callback.
This is also clearer for the users.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
8 years ago
3045e25624
gossip: Returning a gossip-client upon peer_ready
This fd is handed to the owner of the peer so that it can talk to the
gossip daemon.
8 years ago
da5c7e0a08
daemon/subdaemon: remove in favor of daemon/subd.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
8 years ago
c0b4bb1387
daemon/lightningd: store more state in peer.
We need to keep more information about the peer for handing off to the
channel daemon.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
8 years ago
fd258fe495
lightningd: wire up opening daemon.
Now we can actually open a channel.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
8 years ago
dc8b174e3a
lightningd/lightningd: maintain a per-peer log.
At the moment we just log each condition change.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
8 years ago
83b156517f
lightningd/lightningd: maintain "condition" for each peer.
This lets us return better messages to the connect json command on failure.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
8 years ago
7aaffda779
lightningd/lightningd: finish connect command once gossip started.
This is after the INIT message is received, so we know there are no
incompatible features.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
8 years ago
1800e84db7
subdaemon: callback to handle subdaemon status updates.
It's a bit messy, since some status messages are accompanied by an FD:
in this case, the handler returns STATUS_NEED_FD and we read that then
re-call the handler.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
8 years ago
03758af4e1
lightningd/lightningd: create unique ID for each peer.
This distinguishes them before they have an ID, and also if the daemon
doesn't know the ID.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
8 years ago
211491f4d7
lightningd/lightningd: add lightning_handshake.
Now we do crypto handshake when peer comes in.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
8 years ago
Christian Decker
Rusty Russell