<blockquote>
  <p>What are Channel Factories?</p>
</blockquote>

<p>In short, Channel Factories are payment channels that can be used to create more payment channels.  That sounds weird, but it's really pretty simple:</p>

<p>In a regular payment channel, you always have a transaction signed by all participating parties that's ready to commit the current channel balances to the block chain.  For example, in a channel between Alice and Bob, this transaction might have two outputs, one paying Alice 0.25 BTC and one paying Bob 0.75 BTC.  If this example transaction were broadcast, it would close the payment channel between Alice and Bob.</p>

<p>However, it's possible to format the ready-to-commit transaction as a transaction that not only closes the existing payment channel but which also opens a new payment channel.  In that case, the same security that allows the initial payment channel to have zero-conf security also extends its security to the second payment channel.</p>

<p>The key feature of a regular payment channel is the ability to securely update the state (balance) of the channel many times without creating extra on-chain transactions, so the key feature of a Channel Factory is the ability to securely create and destroy new payment channels without creating extra on-chain transactions.</p>

<blockquote>
  <p>How do they work?</p>
</blockquote>

<p>At least two people and preferably ten or more get together to create a payment channel (channel factory) deposit transaction.  This has the regular payment channel logic that allows all of the participants to spend the money if they all agree, or for a dissatisfied participant to individually withdraw his funds if the other participants become uncooperative.</p>

<p>When the deposit transaction has enough confirmations to satisfy all the participants, they update the state of the initial payment channel (channel factory) to create a bunch of non-broadcast payment channel opens between themselves.  (The channels need to be between themselves because they each need to ensure none of the bitcoins used to open the channel are spent twice, i.e. double spent.)</p>

<p>Since the initial payment channel (channel factory) already has sufficient confirmations, opening the secondary payment channels is instant.  The second payment channels can then be used like normal payment channels (e.g. for routable payments Lightning Network) except that when it comes time to close them, the participants have the option of either committing the final state to the block chain or simply updating their balances in the channel factory in order to start a new channel.</p>

<blockquote>
  <p>How does that help scale the Lightning Network?</p>
</blockquote>

<p>Let's assume we have a bunch of users who all want to open payment channels to each other.  For <code>n</code> users, they need to open <code>m</code> channels where <code>m = n(n-1)/2</code>.  For current-generation Lightning Network channel open, they'll probably spend at least two inputs and generate at least three outputs (about 240 vbytes times <code>m</code> channels).  For a channel factory, they'll have about <code>n</code> inputs (at 70 vbytes) and <code>n + 1</code> outputs (at about 25 vbytes) plus 10 vbytes overhead.  Here's the savings accounting:</p>

<p><a href="https://i.sstatic.net/sndlZ.png" rel="noreferrer"><img src="https://i.sstatic.net/sndlZ.png" alt="enter image description here"></a></p>

<p>This doesn't count channel closing costs, which are harder to calculate since channels may remain open for variable lengths of time.  Also not included is the additional savings available from Schnorr signature aggregation---if that should be activated on Bitcoin, it will increase Channel Factory efficiency moderately by decreasing the amount of space used by the inputs.  Please note, numbers used here are a rough approximation.</p>

<p>Note that although channel factories provide significantly lower costs even for small numbers of participants, where they really excel is at making it cheap to build a dense web of payment channels between users.  This will likely significantly improve the quality of service of a widely-distributed Lightning Network by ensuring most paths from spender to recipient stay short, which helps the widely-distributed network further effectively compete with a more centralized network that has short paths between large hub-like entities.</p>

CC BY-SA 3.0
2018-01-02T09:00:13.983Z
Thanks for the explanation. The paper also says: "The new layer addresses the scalability problem by enabling trust-less off-blockchain channel funding.". What do they mean by "off-blockchain channel funding"? To my understanding, funding a channel can also happen off-blockchain currently: if your channel is exhausted, you can "refund" it by simply getting paid (buying from an exchange on the LN).
Luca Matteis
CC BY-SA 3.0
2018-01-02T12:46:43.363Z
@LucaMatteis I believe it means that you can be added to an existing channel factory with no new on-chain transactions required.  For example, imagine Alice, Bob, and Charlie start a channel factory.  Now they can open any payment channel they all agree upon---including opening channels for Dan who was not part of the original set.  This does require allocating to Dan some of the BTC that was used to create the channel factory, but that just means Dan bought the BTC from (say) Alice.  Once Dan's channel is open, his funds are secured by the ability to commit on-chain if necessary.
David A. Harding
CC BY-SA 3.0
2018-01-02T13:22:53.397Z
So new users would be able to join the network without creating a blockchain transaction? That's interesting. Thanks!
Luca Matteis
CC BY-SA 3.0
2018-01-02T14:39:40.510Z
@LucaMatteis Sorry, on reflection, I don't think what I described previously is secure: you need your pubkey to be part of the multisig set used to open the channel factory in order to securely use channels created by it.  I now think the clause you quoted refers simply to the ability to trustlessly create and destroy channels within a single factory's set of users.  E.g. Alice initially opens a 1 BTC channel to Bob and 2 BTC channel to Charlie; later she closes those channels and opens a 1.5 BTC channel to each, all done off-chain.
David A. Harding
CC BY-SA 3.0
2018-01-02T19:48:22.637Z
What are the disadvantages?
Uncooperative users more dangerous?
Giovanni Di Stasi
CC BY-SA 3.0
2018-01-02T23:38:22.460Z
@DavidA.Harding You say "the same security that allows the initial payment channel to have zero-conf security". What zero-conf security are you referring to? How is it that zero-confirms are secure?
almel
CC BY-SA 3.0
2018-01-03T13:55:19.263Z
@GiovanniDiStasi I can't think of any new security risks.  An uncooperative participant can prevent new channels from being created by the channel factory at any time, but can't otherwise affect any already-established channels besides his own, so basically the same security as LN.  Participants in a channel factory may gain more information about each others' balances than in pure LN, but there's even less data going to the public block chain, so channel factories seem privacy neutral or slightly privacy improving.
David A. Harding
CC BY-SA 3.0
2018-01-03T14:03:01.303Z
@almel All payment channels I've heard described (Spillman, CLTV, HTLC, Duplex) use some variation on multisig security.  Alice and Bob each deposit 0.5 BTC into a 2-of-2 multisig address that requires both of their signatures to spend.  They wait for this to confirm.  Now Alice can sign a transaction spending from that address giving Bob 0.75 BTC and returning 0.25 BTC to herself.  Bob can securely accept that transaction immediately without seeking confirmation because the transaction also requires his signature to be complete, so there's no way Alice can take back the 0.25 BTC she paid him.
David A. Harding
CC BY-SA 3.0
2018-01-04T18:29:49.790Z
@DavidA.Harding: I think you should clarify that your mention of "zero-conf security" refers to the commitment transactions created by updating the channel, not the initial funding of the transaction.
Murch
CC BY-SA 3.0
2018-01-02T01:39:15.740Z
2018-01-02T01:39:15.740Z
David A. Harding
<p>One of the open research questions for Lightning Network is that it will take a massive amount of on-chain transactions to create enough payment channels for all the Lightning Network users. Lately, I've seen the term &quot;Channel Factories&quot;¹ pop-up in this context.</p>
<p>What are Channel Factories? How do they work? How does that help scale the Lightning Network?</p>
<hr />
<p><sup>¹ Apparently, the term was introduced by the paper <a href="https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks.pdf" rel="nofollow noreferrer">Scalable Funding of Bitcoin Micropayment Channel Networks</a> by C. Burchert, C. Decker and R. Wattenhofer</sup></p>

<scalability><terminology><lightning-network><channel-factories>
What are Channel Factories and how do they work?
Murch
# What are Channel Factories and how do they work?

(Asked by: username_0 on 2018-01-01)

One of the open research questions for Lightning Network is that it will take a massive amount of on-chain transactions to create enough payment channels for all the Lightning Network users. Lately, I've seen the term "Channel Factories"¹ pop-up in this context.

What are Channel Factories? How do they work? How does that help scale the Lightning Network?

---

¹ Apparently, the term was introduced by the paper [Scalable Funding of Bitcoin Micropayment Channel Networks](https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks.pdf) by C. Burchert, C. Decker and R. Wattenhofer

**Tags:** scalability, terminology, lightning-network, channel-factories


---

## 1 answers

### Answer by username_1 on 2018-01-02. Score: 64 | Accepted answer

> What are Channel Factories?

In short, Channel Factories are payment channels that can be used to create more payment channels. That sounds weird, but it's really pretty simple:

In a regular payment channel, you always have a transaction signed by all participating parties that's ready to commit the current channel balances to the block chain. For example, in a channel between Alice and Bob, this transaction might have two outputs, one paying Alice 0.25 BTC and one paying Bob 0.75 BTC. If this example transaction were broadcast, it would close the payment channel between Alice and Bob.

However, it's possible to format the ready-to-commit transaction as a transaction that not only closes the existing payment channel but which also opens a new payment channel. In that case, the same security that allows the initial payment channel to have zero-conf security also extends its security to the second payment channel.

The key feature of a regular payment channel is the ability to securely update the state (balance) of the channel many times without creating extra on-chain transactions, so the key feature of a Channel Factory is the ability to securely create and destroy new payment channels without creating extra on-chain transactions.

> How do they work?

At least two people and preferably ten or more get together to create a payment channel (channel factory) deposit transaction. This has the regular payment channel logic that allows all of the participants to spend the money if they all agree, or for a dissatisfied participant to individually withdraw his funds if the other participants become uncooperative.

When the deposit transaction has enough confirmations to satisfy all the participants, they update the state of the initial payment channel (channel factory) to create a bunch of non-broadcast payment channel opens between themselves. (The channels need to be between themselves because they each need to ensure none of the bitcoins used to open the channel are spent twice, i.e. double spent.)

Since the initial payment channel (channel factory) already has sufficient confirmations, opening the secondary payment channels is instant. The second payment channels can then be used like normal payment channels (e.g. for routable payments Lightning Network) except that when it comes time to close them, the participants have the option of either committing the final state to the block chain or simply updating their balances in the channel factory in order to start a new channel.

> How does that help scale the Lightning Network?

Let's assume we have a bunch of users who all want to open payment channels to each other. For `n` users, they need to open `m` channels where `m = n(n-1)/2`. For current-generation Lightning Network channel open, they'll probably spend at least two inputs and generate at least three outputs (about 240 vbytes times `m` channels). For a channel factory, they'll have about `n` inputs (at 70 vbytes) and `n + 1` outputs (at about 25 vbytes) plus 10 vbytes overhead. Here's the savings accounting:

[![enter image description here](https://i.sstatic.net/sndlZ.png)](https://i.sstatic.net/sndlZ.png)

This doesn't count channel closing costs, which are harder to calculate since channels may remain open for variable lengths of time. Also not included is the additional savings available from Schnorr signature aggregation---if that should be activated on Bitcoin, it will increase Channel Factory efficiency moderately by decreasing the amount of space used by the inputs. Please note, numbers used here are a rough approximation.

Note that although channel factories provide significantly lower costs even for small numbers of participants, where they really excel is at making it cheap to build a dense web of payment channels between users. This will likely significantly improve the quality of service of a widely-distributed Lightning Network by ensuring most paths from spender to recipient stay short, which helps the widely-distributed network further effectively compete with a more centralized network that has short paths between large hub-like entities.

> **Comments:**
> **username_2**: Thanks for the explanation. The paper also says: "The new layer addresses the scalability problem by enabling trust-less off-blockchain channel funding.". What do they mean by "off-blockchain channel funding"? To my understanding, funding a channel can also happen off-blockchain currently: if your channel is exhausted, you can "refund" it by simply getting paid (buying from an exchange on the LN).  
> **username_1**: @username_2 I believe it means that you can be added to an existing channel factory with no new on-chain transactions required.  For example, imagine Alice, Bob, and Charlie start a channel factory.  Now they can open any payment channel they all agree upon---including opening channels for Dan who was not part of the original set.  This does require allocating to Dan some of the BTC that was used to create the channel factory, but that just means Dan bought the BTC from (say) Alice.  Once Dan's channel is open, his funds are secured by the ability to commit on-chain if necessary.  
> **username_2**: So new users would be able to join the network without creating a blockchain transaction? That's interesting. Thanks!  
> **username_1**: @username_2 Sorry, on reflection, I don't think what I described previously is secure: you need your pubkey to be part of the multisig set used to open the channel factory in order to securely use channels created by it.  I now think the clause you quoted refers simply to the ability to trustlessly create and destroy channels within a single factory's set of users.  E.g. Alice initially opens a 1 BTC channel to Bob and 2 BTC channel to Charlie; later she closes those channels and opens a 1.5 BTC channel to each, all done off-chain.  
> **username_3**: What are the disadvantages? Uncooperative users more dangerous?  
> **username_4**: @username_1 You say "the same security that allows the initial payment channel to have zero-conf security". What zero-conf security are you referring to? How is it that zero-confirms are secure?  
> **username_1**: @username_3 I can't think of any new security risks.  An uncooperative participant can prevent new channels from being created by the channel factory at any time, but can't otherwise affect any already-established channels besides his own, so basically the same security as LN.  Participants in a channel factory may gain more information about each others' balances than in pure LN, but there's even less data going to the public block chain, so channel factories seem privacy neutral or slightly privacy improving.  
> **username_1**: @username_4 All payment channels I've heard described (Spillman, CLTV, HTLC, Duplex) use some variation on multisig security.  Alice and Bob each deposit 0.5 BTC into a 2-of-2 multisig address that requires both of their signatures to spend.  They wait for this to confirm.  Now Alice can sign a transaction spending from that address giving Bob 0.75 BTC and returning 0.25 BTC to herself.  Bob can securely accept that transaction immediately without seeking confirmation because the transaction also requires his signature to be complete, so there's no way Alice can take back the 0.25 BTC she paid him.  
> **username_0**: @username_1: I think you should clarify that your mention of "zero-conf security" refers to the commitment transactions created by updating the channel, not the initial funding of the transaction.  

---

