-
Notifications
You must be signed in to change notification settings - Fork 881
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
Comments
There are a number of decisions that drove us to postpone multiple channels per peer:
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? |
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. |
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. |
This is driving people away from c-lightning towards lnd. |
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 |
@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 🙏🏼 |
Thanks to @niftynei's efforts we have an experimental implementation of dual-funding (compile with |
@cdecker Just to understand the state of things; if we compile with |
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. |
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. |
Guys @cdecker and @rustyrussell, @ZmnSCPxj this thing really fu**ed me... 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? |
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.
The text was updated successfully, but these errors were encountered: