<p>Today transaction throughput on the Lightning Network is mostly limited by available liquidity, network topology and direction of payments. It is possible longer term if Lightning becomes widely adopted that block size/weight and onchain transaction fees will add an additional constraint as you do need an onchain transaction to open or close a channel. However, today blocks mostly contain single signature transactions rather than Lightning channel opens and closes and so that constraint isn't being hit today.</p>
<p>To briefly explain liquidity, network topology and direction of payments. If you want to route a 10,000 BTC payment on Lightning you are going to struggle because there isn't sufficient capacity in channels to route such a large payment. If you want to make a payment to a very poorly connected Lightning node at the edge of the network you may struggle to find a route to that destination. And if all Lightning payments are being sent in one direction and Lightning channels become highly unbalanced then you may encounter a lot of routing failures if you try to make a payment that is also going in that same direction. All of these can be addressed using onchain transactions to open more channels, add more capacity to channels or rebalance channels but could pose difficulties in the short term.</p>
<blockquote>
<p>My current understanding is that the number of channels is limited by the tx throughput of the main chain (2 tx per channel setup).</p>
</blockquote>
<p>Every new channel needs a single onchain transaction sending Bitcoin to a 2-of-2 multisig address.</p>
<blockquote>
<p>So for N==1000000 that is 1000 blocks (~1 week)...But once those channels are initiated, the network forms a mesh and transactions are only limited by deposit levels.. Do I have this ~correctly?</p>
</blockquote>
<p>Yes, block space provides an upper limit on how many channels can be opened and closed but that limit is not close to being hit at the time of writing (September 2022). Once channels are opened the transaction throughput is theoretically infinite. For example we could send a payment back and forth in a channel an infinite number of times and technically that would be an infinite number of transactions. In practice you wouldn't want to do that but other variables come into play (liquidity, network topology, direction of payments etc) other than merely block space.</p>
<blockquote>
<p>Perhaps that allows key holders within the app to somehow nominate channel operators to act on their behalf?</p>
</blockquote>
<p>There are different models for delegating responsibility either in trusted setups or more trust minimized setups. Obviously you could pay to use a channel operated by a company rather than opening your own channel but that is entirely trusted. If you want your own channel and not to have to trust a third party you can't get around the requirement for an onchain transaction. Longer term there are proposals for channel factories etc where a single UTXO is backing multiple channels but they are not spec'ed and implemented at the time of writing (September 2022).</p>

CC BY-SA 4.0
2022-09-05T10:42:08.990Z
2022-09-05T10:56:00.330Z
2022-09-05T10:56:00.330Z
Michael Folkson
<p>One to many transactions on the main chain are <a href="https://bitcoin.stackexchange.com/questions/29786/what-is-the-maximum-number-of-output-addresses-i-can-send-to-with-one-bitcoin-tr?rq=1">limited by the block size/tx limit size</a>.</p>
<p>Does the same limitation apply on the Lightning Network?</p>
<p><strong>What would be the best approach for 1-N transactions on the Lightning Network</strong>?</p>
<ul>
<li>a. open N channels with individual 1-1 transactions</li>
<li>b. create a huge 1-N tx</li>
<li>c. combination of above</li>
</ul>
<p><strong>Is there a practical limit to N (order of magnitude; 10s 100s,1000000s?)</strong></p>
<p>My current understanding is that the number of channels is limited by the tx throughput of the main chain (2 tx per channel setup). A rough working assuming 2000 channel initiation transactions per block on main chain means that 1000 channels per block can be created. So for N==1000000 that is 1000 blocks (~1 week)...But once those channels are initiated, the network forms a mesh and transactions are only limited by deposit levels.. Do I have this ~correctly?</p>
<p>If above is correct, does a compromise approach for a lightning app exist? Perhaps that allows key holders within the app to somehow <strong>nominate channel operators to act on their behalf?</strong></p>

CC BY-SA 4.0
2022-09-05T10:29:32.347Z
Channel Factories: https://wiki.ion.radar.tech/tech/research/channel-factory
Lee
CC BY-SA 4.0
2022-09-06T09:40:30.177Z
https://bitcoin.stackexchange.com/questions/67158/what-are-channel-factories-and-how-do-they-work
Lee
<transactions><lightning-network>
One to many transactions on the Lightning Network, practical approach/limits?
Lee
# One to many transactions on the Lightning Network, practical approach/limits?

(Asked by: username_0 on 2022-09-05)

One to many transactions on the main chain are [limited by the block size/tx limit size](https://bitcoin.stackexchange.com/questions/29786/what-is-the-maximum-number-of-output-addresses-i-can-send-to-with-one-bitcoin-tr?rq=1).

Does the same limitation apply on the Lightning Network?

**What would be the best approach for 1-N transactions on the Lightning Network**?

* a. open N channels with individual 1-1 transactions
* b. create a huge 1-N tx
* c. combination of above

**Is there a practical limit to N (order of magnitude; 10s 100s,1000000s?)**

My current understanding is that the number of channels is limited by the tx throughput of the main chain (2 tx per channel setup). A rough working assuming 2000 channel initiation transactions per block on main chain means that 1000 channels per block can be created. So for N==1000000 that is 1000 blocks (~1 week)...But once those channels are initiated, the network forms a mesh and transactions are only limited by deposit levels.. Do I have this ~correctly?

If above is correct, does a compromise approach for a lightning app exist? Perhaps that allows key holders within the app to somehow **nominate channel operators to act on their behalf?**

**Tags:** transactions, lightning-network

> **Comments:**
> **username_0**: Channel Factories: https://wiki.ion.radar.tech/tech/research/channel-factory  
> **username_0**: https://bitcoin.stackexchange.com/questions/67158/what-are-channel-factories-and-how-do-they-work  

---

## 1 answers

### Answer by username_1 on 2022-09-05. Score: 2 | Accepted answer

Today transaction throughput on the Lightning Network is mostly limited by available liquidity, network topology and direction of payments. It is possible longer term if Lightning becomes widely adopted that block size/weight and onchain transaction fees will add an additional constraint as you do need an onchain transaction to open or close a channel. However, today blocks mostly contain single signature transactions rather than Lightning channel opens and closes and so that constraint isn't being hit today.

To briefly explain liquidity, network topology and direction of payments. If you want to route a 10,000 BTC payment on Lightning you are going to struggle because there isn't sufficient capacity in channels to route such a large payment. If you want to make a payment to a very poorly connected Lightning node at the edge of the network you may struggle to find a route to that destination. And if all Lightning payments are being sent in one direction and Lightning channels become highly unbalanced then you may encounter a lot of routing failures if you try to make a payment that is also going in that same direction. All of these can be addressed using onchain transactions to open more channels, add more capacity to channels or rebalance channels but could pose difficulties in the short term.

> My current understanding is that the number of channels is limited by the tx throughput of the main chain (2 tx per channel setup).

Every new channel needs a single onchain transaction sending Bitcoin to a 2-of-2 multisig address.

> So for N==1000000 that is 1000 blocks (~1 week)...But once those channels are initiated, the network forms a mesh and transactions are only limited by deposit levels.. Do I have this ~correctly?

Yes, block space provides an upper limit on how many channels can be opened and closed but that limit is not close to being hit at the time of writing (September 2022). Once channels are opened the transaction throughput is theoretically infinite. For example we could send a payment back and forth in a channel an infinite number of times and technically that would be an infinite number of transactions. In practice you wouldn't want to do that but other variables come into play (liquidity, network topology, direction of payments etc) other than merely block space.

> Perhaps that allows key holders within the app to somehow nominate channel operators to act on their behalf?

There are different models for delegating responsibility either in trusted setups or more trust minimized setups. Obviously you could pay to use a channel operated by a company rather than opening your own channel but that is entirely trusted. If you want your own channel and not to have to trust a third party you can't get around the requirement for an onchain transaction. Longer term there are proposals for channel factories etc where a single UTXO is backing multiple channels but they are not spec'ed and implemented at the time of writing (September 2022).


---

