One of the biggest inherent limitations to the Lightning Network is the limited number of channels that can be opened or closed per block given the blocksize limit. Regardless of how many transactions can occur off-chain how cheaply, this is a fundamental bottleneck restricting how many people could actually realistically use the Lightning Network. Even the Lightning Network whitepaper went through in the conclusion that in a scenario where the entire world’s population of 7 billion was using Lightning, with only two on-chain transactions a year per person, Bitcoin would require 133 MB blocks for Lightning to work. This isn’t some out of left field problem, or unpredictable issue, it was a limitation of the protocol design fully understood from day one.

Part of the plan to address this issue has always been the idea of channel factories, i.e. a type of channel that more than two users participated in. This was always the direction things would have to go in order to scale Lightning and Bitcoin without a blocksize increase, but the issue is that solving the problem of on-chain footprints introduces a whole host of other problems. First of all, nothing fundamental changes about the requirement to enforce intermediate states if a counterparty becomes non-responsive. This has implications for the value-add. The entire point of a channel factory is that, for example, twenty people can share one UTXO and rearrange the liquidity inside with the other twenty people however they want. Once someone closes out on-chain non-cooperatively this starts to interfere with that goal.

If I close out my channel inside a channel factory, I drag a bunch of people with me out of the factory. Think of a factory like a merkle tree, there’s one UTXO at the top, and that splits in half off-chain, and those split in half, etc. until we get to everyone’s individual channels. Once I peel my channel out of the factory, everyone on my side of each split that goes on-chain is now cut off from everyone else in the factory. They can no longer reorganize their liquidity into that part of the group if everyone cooperates.

Another big issue is that even to start one you need to have everyone online at the beginning to pre-sign all the transactions. If you want twenty people in a factory, everyone needs to be online to start it. If you want a thousand people, a thousand people need to be online, etc.

This makes channel factories a big design space full of lots of problems to solve. So we solve an existing problem for Lightning, but make a bunch of new ones. Sounds like engineering to me.

Timeout Trees

John Law’s recent proposal, Timeout Trees, attempts to offer a solution to the one core issue of channel factories. I wouldn’t quite call a timeout tree a channel factory, more of a “proto-factory,” but it offers a potential solution to the issue of opening and closing massive amounts of channels without introducing the problem of non-cooperative closes ruining the use of the factory for other users. It requires CHECKTEMPLATEVERIFY (CTV) and a Lighting Service Provider (LSP) in order to work functionally.

A Timeout Tree is essentially a channel factory guaranteed by covenants, with no ability to change how the liquidity is reorganized off-chain after it is made, with a special escape clause. An LSP, we’ll call them Bob, plays the role of bridging casual users into the wider Lightning Network. Bob can take coins he controls and create a CTV tree that creates a single UTXO unfurling to open channels to any arbitrary number of users of his LSP service. The nice thing about CTV is it enables this to be done without everyone being online at the same time. Bob can simply get everyone to sign their initial channel state one at a time and hold onto them until everyone has set up the channel, and just spend the funds into the CTV tree when he has channels set up with every user.

This addresses the problem of everyone having to be online at the same time in order to set up the “factory” and start using Lightning. Because of CTV, once Bob spends coins into the tree setting up everyone’s Lightning channels, there is no way for him to back out and take the coins (yet). With that first UTXO in the CTV confirmed on-chain, everyone can treat their channels as open and there is no risk of them being doublespent.

Now the last part, closing the channels. Even though opening them only requires a single UTXO on-chain because of CTV, closing them still would require the entire CTV tree to unfurl on-chain so everyone can submit their channel states, right? Wrong. This is the Timeout part of Timeout Trees. Every branch in the Timeout Tree has a script branch where Bob can sweep all of the funds after a timelock.

Now I’m sure you’re thinking “what!?” This is the real genius of how this proposal works. Because Bob can sweep the on-chain UTXOs himself without anyone else after the timelock, these channels all have an expiration date unless users actually unfurl the whole tree and confirm the real channel funding on-chain. This allows Bob to do something neat: when that timelock is coming up, he can open a brand new Timeout Tree with all the users of the current one, and have them move all of their funds from the expiring tree into the new one entirely off-chain on Lightning and then sweep the single on-chain UTXO of the last tree.

This allows for efficient closing of all these channels on-chain. The only problem left now is enforcing an HTLC on-chain if the other party stops cooperating. Well…that isn’t really an issue in this case, or rather it’s an all or nothing issue. The reason channels have to be closed to enforce an HTLC is if the other party of the channel stops responding in the middle of routing it. In a Timeout Tree every single user’s counterpart is Bob. So if Bob, as long as he is being honest, is not responding to update a failed or successful HTLC for one user, he’s not responding for any other user either. In that case everyone can still close out their channels on-chain before the timeout and stop using Bob’s LSP.

Wrapping Up

Users will still have to pay fees for on-chain interactions, there is no way around that, and an entire Timeout Tree closing out on-chain non-cooperatively would be a large and expensive on-chain footprint, but this is ultimately an issue any multiparty channel system will have to address. Timeout Trees however does have compelling solutions to the cooperative case of both opening and closing a massive multiparty channel without degrading the trust model of the system to something custodial.

John has even in his most recent version of the paper proposed a scheme where users could be penalized for non-cooperative closures enough to cover Bob’s cost for eventually sweeping a bunch of fragmented tree UTXOs after the timeout. Potentially there are ways to do the reverse if Bob’s inactivity or dishonesty is the cause for users having to non-cooperatively close their part of the tree.

At the end of the day though, this is a very concrete and specific proposal for a channel factory design that actually attempts to address the real issues of use and implementation instead of a half-defined and vague concept. That is massive progress in terms of addressing Lightning’s long-term scaling limitations.