2017-08-28 17:05:01 +01:00
|
|
|
#include <common/cryptomsg.h>
|
|
|
|
|
#include <common/channel_config.h>
|
2018-07-23 03:23:03 +01:00
|
|
|
#include <common/derive_basepoints.h>
|
2019-06-03 19:11:25 +01:00
|
|
|
#include <common/per_peer_state.h>
|
2018-07-23 03:23:03 +01:00
|
|
|
|
2019-07-23 23:51:11 +01:00
|
|
|
msgtype,opening_init,6000
|
2018-09-08 12:37:29 +01:00
|
|
|
# Which network are we configured for?
|
2019-07-23 23:51:11 +01:00
|
|
|
msgdata,opening_init,chain_hash,bitcoin_blkid,
|
2017-03-10 10:56:53 +00:00
|
|
|
# Base configuration we'll offer (channel reserve will vary with amount)
|
2019-07-23 23:51:11 +01:00
|
|
|
msgdata,opening_init,our_config,channel_config,
|
2017-03-10 10:56:53 +00:00
|
|
|
# Minimum/maximum configuration values we'll accept
|
2019-07-23 23:51:11 +01:00
|
|
|
msgdata,opening_init,max_to_self_delay,u32,
|
|
|
|
|
msgdata,opening_init,min_effective_htlc_capacity_msat,amount_msat,
|
|
|
|
|
msgdata,opening_init,pps,per_peer_state,
|
|
|
|
|
msgdata,opening_init,our_basepoints,basepoints,
|
|
|
|
|
msgdata,opening_init,our_funding_pubkey,pubkey,
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
# Constraints in case the other end tries to open a channel.
|
2019-07-23 23:51:11 +01:00
|
|
|
msgdata,opening_init,minimum_depth,u32,
|
|
|
|
|
msgdata,opening_init,min_feerate,u32,
|
|
|
|
|
msgdata,opening_init,max_feerate,u32,
|
|
|
|
|
msgdata,opening_init,lfeatures_len,u16,
|
|
|
|
|
msgdata,opening_init,lfeatures,u8,lfeatures_len
|
2019-09-10 03:23:27 +01:00
|
|
|
msgdata,opening_init,option_static_remotekey,bool,
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
# Optional msg to send.
|
2019-07-23 23:51:11 +01:00
|
|
|
msgdata,opening_init,len,u16,
|
|
|
|
|
msgdata,opening_init,msg,u8,len
|
2019-09-18 02:05:05 +01:00
|
|
|
msgdata,opening_init,dev_fast_gossip,bool,
|
2017-03-10 10:56:53 +00:00
|
|
|
|
2019-05-20 06:05:24 +01:00
|
|
|
# Openingd->master: they offered channel, should we continue?
|
2019-07-23 23:51:11 +01:00
|
|
|
msgtype,opening_got_offer,6005
|
|
|
|
|
msgdata,opening_got_offer,funding_satoshis,amount_sat,
|
|
|
|
|
msgdata,opening_got_offer,push_msat,amount_msat,
|
|
|
|
|
msgdata,opening_got_offer,dust_limit_satoshis,amount_sat,
|
|
|
|
|
msgdata,opening_got_offer,max_htlc_value_in_flight_msat,amount_msat,
|
|
|
|
|
msgdata,opening_got_offer,channel_reserve_satoshis,amount_sat,
|
|
|
|
|
msgdata,opening_got_offer,htlc_minimum_msat,amount_msat,
|
|
|
|
|
msgdata,opening_got_offer,feerate_per_kw,u32,
|
|
|
|
|
msgdata,opening_got_offer,to_self_delay,u16,
|
|
|
|
|
msgdata,opening_got_offer,max_accepted_htlcs,u16,
|
|
|
|
|
msgdata,opening_got_offer,channel_flags,u8,
|
|
|
|
|
msgdata,opening_got_offer,shutdown_len,u16,
|
|
|
|
|
msgdata,opening_got_offer,shutdown_scriptpubkey,u8,shutdown_len
|
2019-05-20 06:05:24 +01:00
|
|
|
# master->openingd: optional rejection message
|
2019-07-23 23:51:11 +01:00
|
|
|
msgtype,opening_got_offer_reply,6105
|
|
|
|
|
msgdata,opening_got_offer_reply,rejection,?wirestring,
|
2018-08-09 01:25:29 +01:00
|
|
|
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
# Openingd->master: we've successfully offered channel.
|
2017-05-23 12:07:42 +01:00
|
|
|
# This gives their sig, means we can broadcast tx: we're done.
|
2019-07-23 23:51:11 +01:00
|
|
|
msgtype,opening_funder_reply,6101
|
|
|
|
|
msgdata,opening_funder_reply,their_config,channel_config,
|
|
|
|
|
msgdata,opening_funder_reply,first_commit,bitcoin_tx,
|
|
|
|
|
msgdata,opening_funder_reply,first_commit_sig,bitcoin_signature,
|
|
|
|
|
msgdata,opening_funder_reply,pps,per_peer_state,
|
|
|
|
|
msgdata,opening_funder_reply,revocation_basepoint,pubkey,
|
|
|
|
|
msgdata,opening_funder_reply,payment_basepoint,pubkey,
|
|
|
|
|
msgdata,opening_funder_reply,htlc_basepoint,pubkey,
|
|
|
|
|
msgdata,opening_funder_reply,delayed_payment_basepoint,pubkey,
|
|
|
|
|
msgdata,opening_funder_reply,their_per_commit_point,pubkey,
|
|
|
|
|
msgdata,opening_funder_reply,minimum_depth,u32,
|
|
|
|
|
msgdata,opening_funder_reply,remote_fundingkey,pubkey,
|
|
|
|
|
msgdata,opening_funder_reply,funding_txid,bitcoin_txid,
|
|
|
|
|
msgdata,opening_funder_reply,funding_txout,u16,
|
|
|
|
|
msgdata,opening_funder_reply,feerate_per_kw,u32,
|
|
|
|
|
msgdata,opening_funder_reply,our_channel_reserve_satoshis,amount_sat,
|
|
|
|
|
msgdata,opening_funder_reply,shutdown_len,u16,
|
|
|
|
|
msgdata,opening_funder_reply,shutdown_scriptpubkey,u8,shutdown_len
|
2017-03-10 10:56:53 +00:00
|
|
|
|
2019-05-22 00:51:52 +01:00
|
|
|
# master->openingd: start channel establishment for a funding
|
|
|
|
|
# tx that will be paid for by an external wallet
|
2019-07-23 23:51:11 +01:00
|
|
|
msgtype,opening_funder_start,6002
|
|
|
|
|
msgdata,opening_funder_start,funding_satoshis,amount_sat,
|
|
|
|
|
msgdata,opening_funder_start,push_msat,amount_msat,
|
|
|
|
|
msgdata,opening_funder_start,feerate_per_kw,u32,
|
|
|
|
|
msgdata,opening_funder_start,channel_flags,u8,
|
2019-05-22 00:51:52 +01:00
|
|
|
|
|
|
|
|
# openingd->master: send back output script for 2-of-2 funding output
|
2019-07-23 23:51:11 +01:00
|
|
|
msgtype,opening_funder_start_reply,6102
|
|
|
|
|
msgdata,opening_funder_start_reply,script_len,u8,
|
|
|
|
|
msgdata,opening_funder_start_reply,scriptpubkey,u8,script_len
|
2019-05-22 00:51:52 +01:00
|
|
|
|
2019-06-05 01:26:39 +01:00
|
|
|
# master->openingd: complete channel establishment for a funding
|
2019-05-25 01:40:00 +01:00
|
|
|
# tx that will be paid for by an external wallet
|
|
|
|
|
# response to this is a normal `opening_funder_reply` ??
|
2019-07-23 23:51:11 +01:00
|
|
|
msgtype,opening_funder_complete,6012
|
|
|
|
|
msgdata,opening_funder_complete,funding_txid,bitcoin_txid,
|
|
|
|
|
msgdata,opening_funder_complete,funding_txout,u16,
|
2019-05-25 01:40:00 +01:00
|
|
|
|
2019-05-31 22:57:04 +01:00
|
|
|
#master->openingd: cancel channel establishment for a funding
|
2019-07-23 23:51:11 +01:00
|
|
|
msgtype,opening_funder_cancel,6013
|
2019-05-31 22:57:04 +01:00
|
|
|
|
2018-08-09 01:25:29 +01:00
|
|
|
# Openingd->master: we failed to negotiation channel
|
2019-07-23 23:51:11 +01:00
|
|
|
msgtype,opening_funder_failed,6004
|
|
|
|
|
msgdata,opening_funder_failed,reason,wirestring,
|
2018-08-09 01:25:29 +01:00
|
|
|
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
# Openingd->master: they offered channel.
|
2017-05-23 12:07:42 +01:00
|
|
|
# This gives their txid and info, means we can send funding_signed: we're done.
|
2019-07-23 23:51:11 +01:00
|
|
|
msgtype,opening_fundee,6003
|
|
|
|
|
msgdata,opening_fundee,their_config,channel_config,
|
|
|
|
|
msgdata,opening_fundee,first_commit,bitcoin_tx,
|
|
|
|
|
msgdata,opening_fundee,first_commit_sig,bitcoin_signature,
|
|
|
|
|
msgdata,opening_fundee,pps,per_peer_state,
|
|
|
|
|
msgdata,opening_fundee,revocation_basepoint,pubkey,
|
|
|
|
|
msgdata,opening_fundee,payment_basepoint,pubkey,
|
|
|
|
|
msgdata,opening_fundee,htlc_basepoint,pubkey,
|
|
|
|
|
msgdata,opening_fundee,delayed_payment_basepoint,pubkey,
|
|
|
|
|
msgdata,opening_fundee,their_per_commit_point,pubkey,
|
|
|
|
|
msgdata,opening_fundee,remote_fundingkey,pubkey,
|
|
|
|
|
msgdata,opening_fundee,funding_txid,bitcoin_txid,
|
|
|
|
|
msgdata,opening_fundee,funding_txout,u16,
|
|
|
|
|
msgdata,opening_fundee,funding_satoshis,amount_sat,
|
|
|
|
|
msgdata,opening_fundee,push_msat,amount_msat,
|
|
|
|
|
msgdata,opening_fundee,channel_flags,u8,
|
|
|
|
|
msgdata,opening_fundee,feerate_per_kw,u32,
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
# The funding signed message: send this and we're committed.
|
2019-07-23 23:51:11 +01:00
|
|
|
msgdata,opening_fundee,msglen,u16,
|
|
|
|
|
msgdata,opening_fundee,funding_signed_msg,u8,msglen
|
|
|
|
|
msgdata,opening_fundee,our_channel_reserve_satoshis,amount_sat,
|
|
|
|
|
msgdata,opening_fundee,shutdown_len,u16,
|
|
|
|
|
msgdata,opening_fundee,shutdown_scriptpubkey,u8,shutdown_len
|
2018-11-22 02:17:29 +00:00
|
|
|
|
|
|
|
|
# master -> openingd: do you have a memleak?
|
2019-07-23 23:51:11 +01:00
|
|
|
msgtype,opening_dev_memleak,6033
|
2018-11-22 02:17:29 +00:00
|
|
|
|
2019-07-23 23:51:11 +01:00
|
|
|
msgtype,opening_dev_memleak_reply,6133
|
|
|
|
|
msgdata,opening_dev_memleak_reply,leak,bool,
|
