|
|
|
|
#include <common/cryptomsg.h>
|
|
|
|
|
#include <common/wireaddr.h>
|
|
|
|
|
#include <wire/gen_onion_wire.h>
|
|
|
|
|
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
|
|
|
# Initialize the gossip daemon.
|
|
|
|
|
gossipctl_init,3000
|
|
|
|
|
gossipctl_init,,broadcast_interval,u32
|
|
|
|
|
gossipctl_init,,chain_hash,struct bitcoin_blkid
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
|
|
|
gossipctl_init,,id,struct pubkey
|
|
|
|
|
# If non-zero, port to listen on.
|
|
|
|
|
gossipctl_init,,port,u16
|
|
|
|
|
gossipctl_init,,gflen,u16
|
|
|
|
|
gossipctl_init,,gfeatures,gflen*u8
|
|
|
|
|
gossipctl_init,,lflen,u16
|
|
|
|
|
gossipctl_init,,lfeatures,lflen*u8
|
|
|
|
|
gossipctl_init,,num_wireaddrs,u16
|
|
|
|
|
gossipctl_init,,wireaddrs,num_wireaddrs*struct wireaddr
|
|
|
|
|
gossipctl_init,,rgb,3*u8
|
|
|
|
|
gossipctl_init,,alias,32*u8
|
|
|
|
|
gossipctl_init,,update_channel_interval,u32
|
|
|
|
|
# DEVELOPER only
|
|
|
|
|
gossipctl_init,,no_reconnect,bool
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
|
|
|
|
|
|
|
|
# Gossipd->master, I am ready.
|
|
|
|
|
gossipctl_init_reply,3100
|
|
|
|
|
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
|
|
|
# Master -> gossipd: Optional hint for where to find peer.
|
|
|
|
|
gossipctl_peer_addrhint,3014
|
|
|
|
|
gossipctl_peer_addrhint,,id,struct pubkey
|
|
|
|
|
gossipctl_peer_addrhint,,addr,struct wireaddr
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
|
|
|
|
|
|
|
|
# Master -> gossipd: connect to a peer.
|
|
|
|
|
gossipctl_connect_to_peer,3001
|
|
|
|
|
gossipctl_connect_to_peer,,id,struct pubkey
|
|
|
|
|
|
|
|
|
|
# Gossipd->master: result (not a reply since it can be out-of-order, but
|
|
|
|
|
# you will get one reply for every request).
|
|
|
|
|
gossipctl_connect_to_peer_result,3020
|
|
|
|
|
gossipctl_connect_to_peer_result,,id,struct pubkey
|
|
|
|
|
# True it connected.
|
|
|
|
|
gossipctl_connect_to_peer_result,,connected,bool
|
|
|
|
|
# Otherwise, why we can't reach them.
|
|
|
|
|
gossipctl_connect_to_peer_result,,failreason,wirestring
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
|
|
|
|
|
|
|
|
# Master -> gossipd: try to always maintain connection to this peer (or not)
|
|
|
|
|
gossipctl_peer_important,3010
|
|
|
|
|
gossipctl_peer_important,,id,struct pubkey
|
|
|
|
|
gossipctl_peer_important,,important,bool
|
|
|
|
|
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
|
|
|
# Gossipd -> master: we got a peer. Two fds: peer and gossip
|
|
|
|
|
gossip_peer_connected,3002
|
|
|
|
|
gossip_peer_connected,,id,struct pubkey
|
|
|
|
|
gossip_peer_connected,,addr,struct wireaddr
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
|
|
|
gossip_peer_connected,,crypto_state,struct crypto_state
|
|
|
|
|
gossip_peer_connected,,gflen,u16
|
|
|
|
|
gossip_peer_connected,,gfeatures,gflen*u8
|
|
|
|
|
gossip_peer_connected,,lflen,u16
|
|
|
|
|
gossip_peer_connected,,lfeatures,lflen*u8
|
|
|
|
|
|
|
|
|
|
# Gossipd -> master: peer sent non-gossip packet. Two fds: peer and gossip
|
|
|
|
|
gossip_peer_nongossip,3003
|
|
|
|
|
gossip_peer_nongossip,,id,struct pubkey
|
|
|
|
|
gossip_peer_nongossip,,addr,struct wireaddr
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
|
|
|
gossip_peer_nongossip,,crypto_state,struct crypto_state
|
|
|
|
|
gossip_peer_nongossip,,gflen,u16
|
|
|
|
|
gossip_peer_nongossip,,gfeatures,gflen*u8
|
|
|
|
|
gossip_peer_nongossip,,lflen,u16
|
|
|
|
|
gossip_peer_nongossip,,lfeatures,lflen*u8
|
|
|
|
|
gossip_peer_nongossip,,len,u16
|
|
|
|
|
gossip_peer_nongossip,,msg,len*u8
|
|
|
|
|
|
|
|
|
|
# Master -> gossipd: release a peer (so we can open a channel)
|
|
|
|
|
gossipctl_release_peer,3004
|
|
|
|
|
gossipctl_release_peer,,id,struct pubkey
|
|
|
|
|
|
|
|
|
|
# Gossipd -> master: reply to gossip_release_peer. Two fds: peer and gossip.
|
|
|
|
|
gossipctl_release_peer_reply,3104
|
|
|
|
|
gossipctl_release_peer_reply,,addr,struct wireaddr
|
|
|
|
|
gossipctl_release_peer_reply,,crypto_state,struct crypto_state
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
|
|
|
gossipctl_release_peer_reply,,gflen,u16
|
|
|
|
|
gossipctl_release_peer_reply,,gfeatures,gflen*u8
|
|
|
|
|
gossipctl_release_peer_reply,,lflen,u16
|
|
|
|
|
gossipctl_release_peer_reply,,lfeatures,lflen*u8
|
|
|
|
|
|
|
|
|
|
# Gossipd -> master: reply to gossip_release_peer if we couldn't find the peer.
|
|
|
|
|
gossipctl_release_peer_replyfail,3204
|
|
|
|
|
|
|
|
|
|
# master -> gossipd: take back peer, with optional msg. (+peer fd, +gossip fd)
|
|
|
|
|
gossipctl_hand_back_peer,3013
|
|
|
|
|
gossipctl_hand_back_peer,,id,struct pubkey
|
|
|
|
|
gossipctl_hand_back_peer,,crypto_state,struct crypto_state
|
|
|
|
|
gossipctl_hand_back_peer,,len,u16
|
|
|
|
|
gossipctl_hand_back_peer,,msg,len*u8
|
|
|
|
|
|
|
|
|
|
# master -> gossipd: peer has disconnected.
|
|
|
|
|
gossipctl_peer_disconnected,3015
|
|
|
|
|
gossipctl_peer_disconnected,,id,struct pubkey
|
|
|
|
|
|
|
|
|
|
# Pass JSON-RPC getnodes call through
|
|
|
|
|
gossip_getnodes_request,3005
|
|
|
|
|
# Can be 0 or 1 currently
|
|
|
|
|
gossip_getnodes_request,,num,u16
|
|
|
|
|
gossip_getnodes_request,,id,num*struct pubkey
|
|
|
|
|
|
|
|
|
|
#include <lightningd/gossip_msg.h>
|
|
|
|
|
gossip_getnodes_reply,3105
|
|
|
|
|
gossip_getnodes_reply,,num_nodes,u16
|
|
|
|
|
gossip_getnodes_reply,,nodes,num_nodes*struct gossip_getnodes_entry
|
|
|
|
|
|
|
|
|
|
# Pass JSON-RPC getroute call through
|
|
|
|
|
gossip_getroute_request,3006
|
|
|
|
|
gossip_getroute_request,,source,struct pubkey
|
|
|
|
|
gossip_getroute_request,,destination,struct pubkey
|
|
|
|
|
gossip_getroute_request,,msatoshi,u64
|
|
|
|
|
gossip_getroute_request,,riskfactor,u16
|
|
|
|
|
gossip_getroute_request,,final_cltv,u32
|
|
|
|
|
gossip_getroute_request,,fuzz,double
|
|
|
|
|
gossip_getroute_request,,seed,struct siphash_seed
|
|
|
|
|
|
|
|
|
|
gossip_getroute_reply,3106
|
|
|
|
|
gossip_getroute_reply,,num_hops,u16
|
|
|
|
|
gossip_getroute_reply,,hops,num_hops*struct route_hop
|
|
|
|
|
|
|
|
|
|
gossip_getchannels_request,3007
|
|
|
|
|
# In practice, 0 or 1.
|
|
|
|
|
gossip_getchannels_request,,num,u16
|
|
|
|
|
gossip_getchannels_request,,short_channel_id,num*struct short_channel_id
|
|
|
|
|
|
|
|
|
|
gossip_getchannels_reply,3107
|
|
|
|
|
gossip_getchannels_reply,,num_channels,u16
|
|
|
|
|
gossip_getchannels_reply,,nodes,num_channels*struct gossip_getchannels_entry
|
|
|
|
|
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
|
|
|
# Ping/pong test. Waits for a reply if it expects one.
|
|
|
|
|
gossip_ping,3008
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
|
|
|
gossip_ping,,id,struct pubkey
|
|
|
|
|
gossip_ping,,num_pong_bytes,u16
|
|
|
|
|
gossip_ping,,len,u16
|
|
|
|
|
|
|
|
|
|
gossip_ping_reply,3108
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
|
|
|
# False if id in gossip_ping was unknown.
|
|
|
|
|
gossip_ping_reply,,sent,bool
|
|
|
|
|
# 0 == no pong expected
|
|
|
|
|
gossip_ping_reply,,totlen,u16
|
|
|
|
|
|
|
|
|
|
# Given a short_channel_id, return the endpoints
|
|
|
|
|
gossip_resolve_channel_request,3009
|
|
|
|
|
gossip_resolve_channel_request,,channel_id,struct short_channel_id
|
|
|
|
|
|
|
|
|
|
gossip_resolve_channel_reply,3109
|
|
|
|
|
gossip_resolve_channel_reply,,num_keys,u16
|
|
|
|
|
gossip_resolve_channel_reply,,keys,num_keys*struct pubkey
|
|
|
|
|
|
|
|
|
|
# The main daemon asks for peers
|
|
|
|
|
gossip_getpeers_request,3011
|
|
|
|
|
# 0 or 1
|
|
|
|
|
gossip_getpeers_request,,num,u16
|
|
|
|
|
gossip_getpeers_request,,id,num*struct pubkey
|
|
|
|
|
|
|
|
|
|
gossip_getpeers_reply,3111
|
|
|
|
|
gossip_getpeers_reply,,num,u16
|
|
|
|
|
gossip_getpeers_reply,,id,num*struct pubkey
|
|
|
|
|
gossip_getpeers_reply,,addr,num*struct wireaddr
|
|
|
|
|
gossip_getpeers_reply,,numnodes,u16
|
|
|
|
|
gossip_getpeers_reply,,nodes,numnodes*struct gossip_getnodes_entry
|
|
|
|
|
|
|
|
|
|
# Channel daemon can ask for updates for a specific channel, for sending
|
|
|
|
|
# errors. Must be distinct from WIRE_CHANNEL_ANNOUNCEMENT etc. gossip msgs!
|
|
|
|
|
gossip_get_update,3012
|
|
|
|
|
gossip_get_update,,short_channel_id,struct short_channel_id
|
|
|
|
|
|
|
|
|
|
# If channel isn't known, update will be empty.
|
|
|
|
|
gossip_get_update_reply,3112
|
|
|
|
|
gossip_get_update_reply,,len,u16
|
|
|
|
|
gossip_get_update_reply,,update,len*u8
|
|
|
|
|
|
|
|
|
|
# Gossipd can tell channeld etc about gossip to fwd.
|
|
|
|
|
gossip_send_gossip,3016
|
|
|
|
|
gossip_send_gossip,,len,u16
|
|
|
|
|
gossip_send_gossip,,gossip,len*u8
|
|
|
|
|
|
|
|
|
|
# Both sides have seen the funding tx being locked, but we have not
|
|
|
|
|
# yet reached the announcement depth. So we add the channel locally so
|
|
|
|
|
# we can use it already.
|
|
|
|
|
gossip_local_add_channel,3017
|
|
|
|
|
gossip_local_add_channel,,short_channel_id,struct short_channel_id
|
|
|
|
|
gossip_local_add_channel,,chain_hash,struct bitcoin_blkid
|
|
|
|
|
gossip_local_add_channel,,remote_node_id,struct pubkey
|
|
|
|
|
gossip_local_add_channel,,cltv_expiry_delta,u16
|
|
|
|
|
gossip_local_add_channel,,htlc_minimum_msat,u64
|
|
|
|
|
gossip_local_add_channel,,fee_base_msat,u32
|
|
|
|
|
gossip_local_add_channel,,fee_proportional_millionths,u32
|
|
|
|
|
|
|
|
|
|
# Gossipd->master get this tx output please.
|
|
|
|
|
gossip_get_txout,3018
|
|
|
|
|
gossip_get_txout,,short_channel_id,struct short_channel_id
|
|
|
|
|
|
|
|
|
|
# master->gossipd here is the output, or empty if none.
|
|
|
|
|
gossip_get_txout_reply,3118
|
|
|
|
|
gossip_get_txout_reply,,short_channel_id,struct short_channel_id
|
|
|
|
|
gossip_get_txout_reply,,satoshis,u64
|
|
|
|
|
gossip_get_txout_reply,,len,u16
|
|
|
|
|
gossip_get_txout_reply,,outscript,len*u8
|
|
|
|
|
|
|
|
|
|
# client->gossipd: Disable the channel matching the short_channel_id
|
|
|
|
|
gossip_disable_channel,3019
|
|
|
|
|
gossip_disable_channel,,short_channel_id,struct short_channel_id
|
|
|
|
|
gossip_disable_channel,,direction,u8
|
|
|
|
|
gossip_disable_channel,,active,bool
|
|
|
|
|
|
|
|
|
|
# master->gossipd a routing failure occurred
|
|
|
|
|
gossip_routing_failure,3021
|
|
|
|
|
gossip_routing_failure,,erring_node,struct pubkey
|
|
|
|
|
gossip_routing_failure,,erring_channel,struct short_channel_id
|
|
|
|
|
gossip_routing_failure,,failcode,u16
|
|
|
|
|
gossip_routing_failure,,len,u16
|
|
|
|
|
gossip_routing_failure,,channel_update,len*u8
|
|
|
|
|
|
|
|
|
|
# master->gossipd temporarily mark a channel unroutable
|
|
|
|
|
# (used in case of unparseable onion reply)
|
|
|
|
|
gossip_mark_channel_unroutable,3022
|
|
|
|
|
gossip_mark_channel_unroutable,,channel,struct short_channel_id
|
|
|
|
|
|
|
|
|
|
# master->gossipd: Request to disconnect from a peer.
|
|
|
|
|
gossipctl_peer_disconnect,3023
|
|
|
|
|
gossipctl_peer_disconnect,,id,struct pubkey
|
|
|
|
|
|
|
|
|
|
# Gossipd -> master: reply to gossip_peer_disconnect with peer id.
|
|
|
|
|
gossipctl_peer_disconnect_reply,3123
|
|
|
|
|
|
|
|
|
|
# Gossipd -> master: reply to gossip_peer_disconnect if we couldn't find the peer.
|
|
|
|
|
gossipctl_peer_disconnect_replyfail,3223
|
|
|
|
|
gossipctl_peer_disconnect_replyfail,,isconnected,bool
|
|
|
|
|
|
|
|
|
|
# master -> gossipd: a potential funding outpoint was spent, please forget the eventual channel
|
|
|
|
|
gossip_outpoint_spent,3024
|
|
|
|
|
gossip_outpoint_spent,,short_channel_id,struct short_channel_id
|
