<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><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><p>Let's assume we have a bunch of users who all want to open payment channels to each other. For&nbsp;<code style="color: var(--black-800); background-color: var(--black-075);">n</code>&nbsp;users, they need to open&nbsp;<code style="color: var(--black-800); background-color: var(--black-075);">m</code>&nbsp;channels where&nbsp;<code style="color: var(--black-800); background-color: var(--black-075);">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&nbsp;<code style="color: var(--black-800); background-color: var(--black-075);">m</code>&nbsp;channels). For a channel factory, they'll have about&nbsp;<code style="color: var(--black-800); background-color: var(--black-075);">n</code>&nbsp;inputs (at 70 vbytes) and&nbsp;<code style="color: var(--black-800); background-color: var(--black-075);">n + 1</code>&nbsp;outputs (at about 25 vbytes) plus 10 vbytes overhead. Here's the savings accounting:</p><p><a href="https://i.stack.imgur.com/sndlZ.png" target="_blank" style="color: var(--theme-link-color);"><img src="https://i.stack.imgur.com/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>