<p>This was answered by Christian Decker on Telegram.</p>
<blockquote>
<p>Just because the specification allows something doesn't mean every
implementation has to implement it and support it. In c-lightning's
case it is both an architectural choice (multiplexing multiple
channels onto a TCP connection is not trivial) as well as a conviction
(peer diversity beats doubling down on a single peer with multiple
channels, and avoids the creation of single points of failure). After
all dual funding and splicing give the same abilities as channel
multiplexing with a reduced onchain footprint as well as less
complexity and less load on the gossip network.</p>
</blockquote>
<p>Rene Pickhardt added in the comments below:</p>
<blockquote>
<p>Parallel channels might also be a challenge for
payment flows. First the computation becomes more expensive and second
the assigned liquidity is artificially split between two separate
channels. Thus one should always prefer dual funding, splicing and
rebalancing over parallel channels</p>
</blockquote>

CC BY-SA 4.0
2021-11-01T11:50:08.957Z
I want to add that parallel channels might also be a challenge for payment flows. First the computation becomes more expensive and second the assigned liquidity is artificially split between two separate channels. Thus one should always prefer dual funding, splicing and rebalancing over parallel channels
Rene Pickhardt
CC BY-SA 4.0
2021-11-01T11:10:53.370Z
2021-11-01T14:07:06.333Z
2021-11-01T14:07:06.333Z
Michael Folkson
<p>This question was asked by various individuals on Telegram.</p>
<p>The spec (<a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#channel-establishment" rel="nofollow noreferrer">BOLT 2</a>) allows for multiple channels between the same two peers:</p>
<blockquote>
<p>Note that multiple channels can operate in parallel, as all channel
messages are identified by either a <code>temporary_channel_id</code> (before the
funding transaction is created) or a <code>channel_id</code> (derived from the
funding transaction).</p>
</blockquote>
<p>The <code>temporary_channel_id</code> is unique only within a single connection hence implying the possibility of multiple channels per peer/connection.</p>
<p>As far as c-lightning goes, I get the following error when trying to fund a second channel with the same peer:</p>
<pre><code>Peer already CHANNELD_NORMAL
</code></pre>
<p>Why doesn't c-lightning follow the spec here?</p>
<p><strong>Update</strong>: Core Lightning <a href="https://medium.com/blockstream/core-lightning-v0-11-0-channel-multiplexing-a-new-api-and-much-more-5d34df8cfeb5" rel="nofollow noreferrer">v0.11.0</a> (April 2022) introduced support for opening multiple parallel channels to a single peer (channel multiplexing)</p>

<core-lightning><channels>
Why doesn't c-lightning allow you to open multiple channels with the same peer?
Michael Folkson
# Why doesn't c-lightning allow you to open multiple channels with the same peer?

(Asked by: username_0 on 2021-11-01)

This question was asked by various individuals on Telegram.

The spec ([BOLT 2](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#channel-establishment)) allows for multiple channels between the same two peers:

> Note that multiple channels can operate in parallel, as all channel
> messages are identified by either a `temporary_channel_id` (before the
> funding transaction is created) or a `channel_id` (derived from the
> funding transaction).

The `temporary_channel_id` is unique only within a single connection hence implying the possibility of multiple channels per peer/connection.

As far as c-lightning goes, I get the following error when trying to fund a second channel with the same peer:

```
Peer already CHANNELD_NORMAL

```

Why doesn't c-lightning follow the spec here?

**Update**: Core Lightning [v0.11.0](https://medium.com/blockstream/core-lightning-v0-11-0-channel-multiplexing-a-new-api-and-much-more-5d34df8cfeb5) (April 2022) introduced support for opening multiple parallel channels to a single peer (channel multiplexing)

**Tags:** core-lightning, channels


---

## 1 answers

### Answer by username_0 on 2021-11-01. Score: 9 | Accepted answer

This was answered by Christian Decker on Telegram.

> Just because the specification allows something doesn't mean every
> implementation has to implement it and support it. In c-lightning's
> case it is both an architectural choice (multiplexing multiple
> channels onto a TCP connection is not trivial) as well as a conviction
> (peer diversity beats doubling down on a single peer with multiple
> channels, and avoids the creation of single points of failure). After
> all dual funding and splicing give the same abilities as channel
> multiplexing with a reduced onchain footprint as well as less
> complexity and less load on the gossip network.

username_1 username_1 added in the comments below:

> Parallel channels might also be a challenge for
> payment flows. First the computation becomes more expensive and second
> the assigned liquidity is artificially split between two separate
> channels. Thus one should always prefer dual funding, splicing and
> rebalancing over parallel channels

> **Comments:**
> **username_1**: I want to add that parallel channels might also be a challenge for payment flows. First the computation becomes more expensive and second the assigned liquidity is artificially split between two separate channels. Thus one should always prefer dual funding, splicing and rebalancing over parallel channels  

---

