Batch Channel Opens

[TheBlueMatt]

We should probably support a single funding transaction funding multiple channels. This is a bit complicated, though - we have to make sure we never broadcast the funding transaction until all channels are ready, not just one. This may require a new state flag in channels to indicate we're waiting on another channel.

Worse, there's a really nasty race condition where a user creates two channels, funds both of them in one transaction, then one of the peers disconnects. Now there's only one channel that LDK remembers but the transaction the user created pays to two channel outputs. Thus when we go to broadcast the second channel funds are locked. I'm not really sure how to address this without making the user provide the list of transactions they're funding when giving the transaction to LDK.

[johncantrell97]

I'm not sure if this is exactly what you mean but I'd expect/want an api like:

channel_manager.funding_transaction_generated(temp_ids: Vec<&[u8; 32]>, funding_tx: Transaction>) -> Result<(), APIError>

Basically just allow passing a list of channel ids we are funding with this transaction.

[TheBlueMatt]

Yes, I think that's what we'll have to have, its kinda annoying because we're reverting the old change to not make users provide the temp channel id, but that's okay.

[TheBlueMatt]

Retargeting 0.116, since server folks will probably want this more than the more mobile-targeted folks.

[TheBlueMatt]

Slipping to 0.1 again as we don't yet have anyone who has time to work on this.

[wvanlint]

I am interested in taking a look at this.

From my understanding:

• The funding transaction and corresponding funded channels will be provided with ChannelManager:: funding_transaction_generated.
• The set of channels that will be funded together will need to be maintained in addition to whether they have received a funding_signed message. They can likely be maintained and tracked in ChannelManager as maintaining the dependent channels per channel introduces more complexity.
• With regard to failure handling, funding nodes should forget channels for which they haven't broadcast the funding transaction upon disconnection.
• A flag can be added to the FundingSent state (maybe rename to FundingSigned?) that can indicate that we've received funding_signed for the current channel but are waiting for additional channels and should not broadcast the transaction. Noting that the ChannelState is sometimes inspected by comparing the enum discriminant value e.g.:

  rust-lightning/lightning/src/ln/channel.rs

  Line 1203 in c383f06

  self.channel_state >= ChannelState::FundingSent as u32

• The actual broadcasting and creation of the monitors can be performed when all channels have received the funding_signed messages:

  rust-lightning/lightning/src/ln/channelmanager.rs

  Lines 5481 to 5482 in c383f06

  	let update_res = self.chain_monitor.watch_channel(chan.get().context.get_funding_txo().unwrap(), monitor);
  	let mut res = handle_new_monitor_update!(self, update_res, peer_state_lock, peer_state, per_peer_state, chan, INITIAL_MONITOR);