Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple channels not supported #2001

Open
peername opened this issue Oct 9, 2018 · 11 comments
Open

Multiple channels not supported #2001

peername opened this issue Oct 9, 2018 · 11 comments
Labels

Comments

@peername
Copy link

peername commented Oct 9, 2018

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
Copy link
Member

cdecker commented Oct 10, 2018

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 😉

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

@rustyrussell
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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

@ZmnSCPxj
Copy link
Collaborator

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
Copy link

@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
Copy link
Member

cdecker commented Jan 19, 2021

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
Copy link

3nprob commented Feb 2, 2021

@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
Copy link
Member

cdecker commented Feb 2, 2021

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.

@ProofOfKeags
Copy link

It occurs to me though that until splicing is viable, this feature may still be desirable. IIRC @rustyrussell did a poll about this a while back asking what people would prefer. I don't remember the results, but it definitely seems like one of those two features would be needed as people add more liquidity for a peer they already have a channel with.

@manreo
Copy link
Contributor

manreo commented Jul 21, 2021

Guys @cdecker and @rustyrussell, @ZmnSCPxj this thing really fu**ed me...
I used https://lightningnetwork.plus/ to open channels, and I committed to open a channel with a node but because he already have a channel to me I can not do it. This really effect my rating in the website and my ability to open new channels in the future as I did not follow my commitment. (PS. I can not know which node will be assigned to me, and therefor this can happen again in the future.)

I understand that splice-in will fix it, but that does not exist now, probably only in the far future. This means that only c-lightning users can not use lightningnetwork.plus website, a very good website to increase liquidity.

Thought?
Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants