Files
lightning/openingd/opening_wire.csv
Rusty Russell 50f5eb34b4 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-09 19:44:27 +02:00

3.2 KiB

1#include <common/cryptomsg.h>
2#include <common/channel_config.h>
3#include <common/derive_basepoints.h>
4opening_init,6000
5# Which network are we configured for (as index into the chainparams)?
6opening_init,,network_index,u32
7# Base configuration we'll offer (channel reserve will vary with amount)
8opening_init,,our_config,struct channel_config
9# Minimum/maximum configuration values we'll accept
10opening_init,,max_to_self_delay,u32
11opening_init,,min_effective_htlc_capacity_msat,u64
12opening_init,,crypto_state,struct crypto_state
13opening_init,,our_basepoints,struct basepoints
14opening_init,,our_funding_pubkey,struct pubkey
15# Constraints in case the other end tries to open a channel.
16opening_init,,minimum_depth,u32
17opening_init,,min_feerate,u32
18opening_init,,max_feerate,u32
19# Optional msg to send.
20opening_init,,len,u16
21opening_init,,msg,len*u8
22#include <common/bip32.h>
23#include <common/htlc_wire.h>
24# Master->openingd: please fund a channel.
25opening_funder,6001
26opening_funder,,funding_satoshis,u64
27opening_funder,,push_msat,u64
28opening_funder,,feerate_per_kw,u32
29opening_funder,,change_satoshis,u64
30opening_funder,,change_keyindex,u32
31opening_funder,,channel_flags,u8
32#include <common/utxo.h>
33opening_funder,,num_inputs,u16
34opening_funder,,inputs,num_inputs*struct utxo
35opening_funder,,bip32,struct ext_key
36# Openingd->master: we've successfully offered channel.
37# This gives their sig, means we can broadcast tx: we're done.
38opening_funder_reply,6101
39opening_funder_reply,,their_config,struct channel_config
40opening_funder_reply,,first_commit,struct bitcoin_tx
41opening_funder_reply,,first_commit_sig,secp256k1_ecdsa_signature
42opening_funder_reply,,crypto_state,struct crypto_state
43opening_funder_reply,,revocation_basepoint,struct pubkey
44opening_funder_reply,,payment_basepoint,struct pubkey
45opening_funder_reply,,htlc_basepoint,struct pubkey
46opening_funder_reply,,delayed_payment_basepoint,struct pubkey
47opening_funder_reply,,their_per_commit_point,struct pubkey
48opening_funder_reply,,minimum_depth,u32
49opening_funder_reply,,remote_fundingkey,struct pubkey
50opening_funder_reply,,funding_txid,struct bitcoin_txid
51opening_funder_reply,,feerate_per_kw,u32
52opening_funder_reply,,our_channel_reserve_satoshis,u64
53# Openingd->master: they offered channel.
54# This gives their txid and info, means we can send funding_signed: we're done.
55opening_fundee,6003
56opening_fundee,,their_config,struct channel_config
57opening_fundee,,first_commit,struct bitcoin_tx
58opening_fundee,,first_commit_sig,secp256k1_ecdsa_signature
59opening_fundee,,crypto_state,struct crypto_state
60opening_fundee,,revocation_basepoint,struct pubkey
61opening_fundee,,payment_basepoint,struct pubkey
62opening_fundee,,htlc_basepoint,struct pubkey
63opening_fundee,,delayed_payment_basepoint,struct pubkey
64opening_fundee,,their_per_commit_point,struct pubkey
65opening_fundee,,remote_fundingkey,struct pubkey
66opening_fundee,,funding_txid,struct bitcoin_txid
67opening_fundee,,funding_txout,u16
68opening_fundee,,funding_satoshis,u64
69opening_fundee,,push_msat,u64
70opening_fundee,,channel_flags,u8
71opening_fundee,,feerate_per_kw,u32
72# The funding signed message: send this and we're committed.
73opening_fundee,,msglen,u16
74opening_fundee,,funding_signed_msg,msglen*u8
75opening_fundee,,our_channel_reserve_satoshis,u64