Lightning: Multiple channels not supported

[peername]

Other nodes are reporting that they can not connect back to us because our node is giving an error:

Error on open channel: rpc.RPCError: command failed: peer sent error: 'Multiple channels unsupported'

Why c-lightning is not supporting multiple channels? How to gain reverse capacity that way?

Are you planning to support this? Honestly, we will change the implementation otherwise. This is critical.

[cdecker]

There are a number of decisions that drove us to postpone multiple channels per peer:

1. It's just simpler to implement a single channel per peer, since there needs to be no multiplexing of channels over a single connection.
2. Users shouldn't really care with whom they have a channel open, as long as the destination is reachable, directly or indirectly. If direct channels are required we might as well give up.
3. Setting up dual-funded channels (which will be on the table for the November spec meeting) is far better than setting up multiple channels to achieve the same goal. Dual funded channels have half of the on-chain footprint, and have the sum total of capacities at their disposal rather than partitioning across multiple channels.
4. The same thing can be achieved via splicing (also going to be discussed in November), i.e., set up a single-funded channel, then have the other side splice some funds in, and you just bumped the capacity of the single channel (no need to increase the network graph size).

That being said, it still is on the roadmap, just not the highest priority issue :wink:

PS: has the "implement this or we'll stop using your implementation" threat ever worked before?

[rustyrussell]

I understand your frustration with this! We have made splicing a priority for the upcoming spec for this very reason: it's awkward to avoid multiple channels currently. Our security model works best with one-channel-one-process, however, and we're reluctant to compromise here.

[peername]

PS: has the "implement this or we'll stop using your implementation" threat ever worked before?

Sorry. I did not want to sound like a threat. Thanks for the detailed explanation.

I think that reverse capacity is the biggest problem in Lightning. This restriction is making the problem worst. At least in the current model.

[thestick613]

This is driving people away from c-lightning towards lnd.

[ZmnSCPxj]

I had a vague plan that would allow C-Lightning to support multiple channels per peer, without doing too much damage to the C-Lightning architecture. https://lists.ozlabs.org/pipermail/c-lightning/2018-July/000058.html

[ProofOfKeags]

@cdecker can you shed some light on the results of the spec meeting relating to dual funded channels and/or splicing? Your original comment is from over two years ago and since this issue hasn't been closed I'm assuming it hasn't been obviated by the aforementioned spec changes. Any info you have would be much appreciated 🙏🏼

[cdecker]

Thanks to @niftynei's efforts we have an experimental implementation of dual-funding (compile with EXPERIMENTAL_FEATURES=1). Once the specification is finalized we expect other implementations to implement the proposal as well.

[3nprob]

@cdecker Just to understand the state of things; if we compile with EXPERIMENTAL_FEATURES=1, does that mean the node should be able to open dual-funded channels as expected with LND nodes?

[cdecker]

Dual-funding refers to a single channel being funded with funds from both endpoints, whereas this issue is about having multiple channels between the same endpoints.

C-lightning is currently the only implementation that has a working dual-funding implementation, LND haven't started implementing it yet, so you won't be able to use it with one.