Lightning: Batch Funding Transaction for opening several channels (feature request)

[renepickhardt]

When new nodes come to the network and they run the autopilot (c.f.: https://github.com/ElementsProject/lightning/pull/1888 ) they might want to open several channels. I think there is no need to do it (as currently implemented) sequentially but we could adapt the process so that it is just transaction with 1 output for each channel to be opened. This would save space and allow for more channels to be opened per block.

I believe the API of c-lightning could be extended to support a batch channel open (and consequently also a batch channel closing command. I believe there is quite some protocol overhead as communication with all channel partners has to be established and commitment txs have to be signed before the batch funding tx could be published. However I think this would not interfere with the current protocol specification for channel establishment.

I think this should not be an urgent feature but I believe it will be very useful on the long term as it saves precious blockchain space

I ping @rustyrussell as he asked me to open this as an issue here.

[leishman]

This would be an awesome feature. 💯

[ZmnSCPxj]

• [x] split fundchannel #2672
• [x] split withdraw #2713
• [x] implement multiple-destination split txprepare #2964
• [x] implement ability to cancel (without closingd or onchaind) a channel we funded but whose funding tx we did not broadcast. #2740
• [x] implement multifundchannel

[ZmnSCPxj]

People are trying to implement multi-channel funding txes and getting badly bitten.

First: You really really really need to implement #2740 first.

Secondly:

fundchannel_complete is arguably a bad name. It completes the openingd process but does not, in fact, complete the entire funding process: the completion of the funding process is the transition from CHANNELD_AWAITING_LOCKIN to CHANNELD_NORMAL.

So, let us clarify the proper process of funding (1 or more) channels:

1. Start fundchannel_start on the node(s) you want to open channels to.
   
   
   
   • Note down the addresses specified.
   
   
2. Create but do not sign or broadcast a transaction which pays the exact amount to the above address from fundchannel_start.
   
   
   
   • If multiple nodes, make a single transaction that pays out all of those.
   
   
   • Determine the txid of this unsigned, unbroadcast transaction.
   
   
3. Invoke fundchannel_complete on the nodes.
   
   
   
   • If any fail, abort: trigger errors on all of the other channels that succeeded fundchannel_complete. dev-fail might work, though maybe it will try to unilaterally close instead of just forgetting the channel, it is a dev- command so you need DEVELOPER option during compile. See #2740 .
   
   
4. If all fundchannel_complete succeeded, sign and broadcast the funding transaction.
5. Wait for channel state to move from CHANNELD_AWAITING_LOCKIN to CHANNELD_NORMAL.

[ZmnSCPxj]

Only "implement multifundchannel" is missing. Of note, to mitigate the effects of #2741, we should probably reconnect inside multifundchannel in case of failure.

[ZmnSCPxj]

I believe #2983 is included in 0.7.3 simply because of the desire to have a multifundchannel implementation, as this comment: https://github.com/ElementsProject/lightning/issues/2983#issuecomment-523713151

This issue is more accurate to implement the multifundchannel and #2983 can probably be closed in favor of this one.

[ZmnSCPxj]

The current fundchannel accepts these parameters:

• id
• amount
• feerate
• announce
• minconf
• utxos
• push_msat

I propose the multifundchannel:

• destinations
• feerate
• minconf
• utxos

Where destinations is an array of objects with fields:

• id
• amount
• announce (optional)
• push_msat (optional)