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?

  • 5
    The term was apparently introduced in this paper by C. Burchert, C. Decker and R. Wattenhofer Scalable Funding of Bitcoin Micropayment Channel Networks – Murch Jan 1 at 18:18
  • A @cdecker highlight would be useful :) – Luca Matteis Jan 1 at 19:52
  • After briefly reading the paper, sounds interesting, but can't we already refund channels, by simply getting paid (via an exchange exposed on LN)? – Luca Matteis Jan 2 at 0:39
  • @LucaMatteis: Rest assured that I pinged him in chat right after posting this question. ;) – Murch Jan 2 at 4:21
up vote 44 down vote accepted

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

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.

  • 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). – Luca Matteis Jan 2 at 9:00
  • 2
    @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 Jan 2 at 12:46
  • So new users would be able to join the network without creating a blockchain transaction? That's interesting. Thanks! – Luca Matteis Jan 2 at 13:22
  • 2
    @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 Jan 2 at 14:39
  • What are the disadvantages? Uncooperative users more dangerous? – Giovanni Di Stasi Jan 2 at 19:48

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.