Name: Christian Decker

Topic: Lightning Channel Factories

Location: Stephan Livera Podcast

Date: March 14th 2019

Audio: https://stephanlivera.com/episode/59/

# Lightning topology limitation

Stephan: Christian, welcome to the show. I’m a big fan of your work.

Christian: Thank you so much for having me Stephan. I am a long time listener and I am happy to be joining you today.

Stephan: There has been a lot of chatter in the Bitcoin community on what might happen in the future. One of the ideas you presented in one of your papers you wrote in 2016 called [Scalable Funding of Bitcoin Micropayment Channel Networks](https://nakamotoinstitute.org/static/docs/scalable-funding-of-bitcoin-micropayment-channel-networks.pdf)  That is the discussion where we are going to go. Let’s set some context. It is March 2019. People who want to use Bitcoin onchain given the fees, they can do so at low fees as long as they are willing to wait and don’t need instant confirmation. That may not hold true forever. The other contextual part is that Lightning Network as it is now would be considered a single party channel set up. That has certain limitations. From watching a roasbeef [presentation](https://youtu.be/3mJURLD2XS8?t=76) at Scaling Bitcoin in Japan he spoke of a few. He noticed there was a topology limitation. He mentioned we can’t dynamically create new channels offchain. And probably the most important one people will be interested to understand, this idea that over time not every single person in the world will be able to have a single UTXO. Do you want to add any comments on some of those limitations?

Christian: The principle one is that we have this topology limitation. If we create a Lightning channel in the current Lightning network it is just locking up funds towards one other endpoint. We can’t reallocate those funds easily to another destination should that endpoint not be able to route to where we want it to or if it turns out to be offline at points. That was the original inspiration. We want to be able to use our funds in different channels depending on what our current needs are and not what we predicted a few days before. We want to make all of these funds more flexible and be able to reallocate them among channels. The idea that there will not be enough UTXOs is quite an interesting one and one that I personally hadn’t considered for a long time. It can actually work out that we can collectively manage some funds in a group of people and these funds can be represented as a single output on the Bitcoin blockchain. We basically just then hold the splitting transaction, who owns what from this output in our backpocket. All of this is a bit of a specialization of what we call offchain protocols. It really is about flexibility and extending the reach of Bitcoin and its usability in the wider economy.

# Multiparty offchain protocols

Stephan: Let’s talk more about the general concept of multiparty offchain protocols.

Christian: The idea is pretty simple. All of these offchain protocols Lightning included are multiple parties that do not exactly trust each other. We put some money on a table and as long the money is on the table we have to agree on how we split it up. This is a very old concept that has been around since the first version of the Bitcoin client. That we want to have a way of agreeing how to split some funds and then be able to update that at a very high frequency without ever touching the blockchain itself. The way we implement the table so to speak is to have a multisignature address that requires a signature from all different parties to create an update. The main difficulty in these offchain protocols is that we now have the latest state represented as a transaction and we need to somehow update or invalidate the old state and make it so that we can’t apply it anymore. This has indeed been a very old concept going back to even the nSequence numbers in the original client. There have been different implementations and different inventions on how we can invalidate these old states. Basically all of these offchain protocols differentiate themselves through these update mechanisms. For Lightning we are limited to basically have two parties because we are reliant on this penalty mechanism where we say if you ever publish an old state then I will punish you by reacting to it by stealing your funds because you promised me that you wouldn’t use this old state. Multiparty channels where we have more than two parties are not really a thing we can do in Lightning. But we can create these offchain protocols with multiple parties quite easily with other technologies like the duplex micropayment channel proposal that I proposed three or four years ago. With our [paper](https://blockstream.com/eltoo.pdf) from last year called eltoo which really allows us to have basically an n-of-n multiparty channel where we can freely reallocate funds from one party to another without being bound to individual channels between peers. That is cool and really interesting but what it turns out to enable is we can layer multiple of these offchain protocols quite easily. These offchain protocols are built on an output. This output doesn’t have to exist at the time we want to build our offchain protocol. We just have to have confidence that it might eventually exist. That is the whole idea of channel factories. We build a multiparty channel where we have 15-of-15 parties and then we bootstrap point to point channels on top of this bigger set of 15 people. The way we do that is by having the settlement transaction include the output that would be needed to create this channel. The major advantage of this is this output not being onchain, we can go back and remove it again and build a different offchain protocol on top of it. This gives us the flexibility of creating and tearing down Lightning channels on top of a group of people without having to ever the touch the Bitcoin blockchain itself. This gives us flexibility that might be interesting for scaling and it gives us a lot of flexibility on where to send money and how to allocate these channels. 

Stephan: A couple of things that we are reliant on for Lightning Network, there are a few things around security, we are keeping the keys hot rather than cold, that is a key one that most people understand. That is a trade-off we are making in order to have access to these lower fee payments. A couple of other things that we also have to consider is in a scenario that the blocks start to become full, for me to open a channel or close a channel or even somebody is trying to cheat me, it relies on me being able to get my transaction mined into a block.

Christian: The main point is we have very strict timing constraints about when we need our transaction to be confirmed. All of these offchain protocols are built on top of timeouts. If we can’t guarantee that during this timeout the transaction would be confirmed then we are sort of luck because our security is gone. Us as offchain protocol developers and users of these protocols are very happy to overpay onchain fees and pay three times the fee for Lightning. We will make it worthwhile for miners to include our transactions. This is also something that comes up often when we talk about the extreme extrapolations of Lightning. If everybody just moves on Lightning will there be enough fees collected onchain such that it is worthwhile for miners to still secure the network. Since we have these different timing constraints we are very happy to overpay. It is not that we are paying more, it is just we get more use out of these fees. If we settle a Lightning channel we might have had millions of transfers and we aggregate the fees that we collected from these millions of transfers into what becomes an onchain fee. It is as much a transfer aggregation mechanism as well as a fee aggregation mechanism for miners. You mentioned the opposite scenario where the onchain volume becomes so high that we can’t really guarantee our timing constraints anymore. That would be really sad indeed but the usual answer is we can actually decide on these timeouts ourselves. We can tweak out these timeouts such that if we see an increase in load on the network we can actually react and instead of a day we wait like two days for this. We can make it more probable that this gets settled in time. On the other hand of course moving transactions onto the Lightning network will also reduce the load on the Bitcoin network. I think there will be a balance between onchain and offchain transfers where some real high transfers will stay onchain. Of course this is not a replacement for Bitcoin, it is a complementary system. Most of the smaller payments will definitely move onto Lightning because it is more efficient. You get this real time aspect of payments and you pay less because you are not dealing with onchain transactions that tend to be a bit more expensive. 

Stephan: Ultimately if Bitcoin’s block space is valuable people will be willing to pay for it. There is a natural trade-off that we will see over time because Bitcoin transactions are charged based on how much block space you are using, how many UTXOs are using. Whereas Lightning fees could be reflected in how much of your channel liquidity I am using up as part of my transaction. We will naturally see some equilibrium develop in terms of using Bitcoin onchain transactions versus Lightning payment. I think that is one key component. I am also curious to get your thoughts on this idea of how long channels can stay open. My understanding is that some of the earlier conceptions of Lightning had a limit but then there is this concept of a kick off transaction that enables us to have unlimited channel length. Could you comment on that?

Christian: The basic idea is that if we want to establish some sort of chain contract then one of us or multiple of us have to put in some money. If I put ten dollars on the table and you just walk away and I don’t have any way of grabbing that money back then I’m out of money without getting anything from it. Even worse you could start blackmailing me. You could come to see and say “You could get 1 dollar back if you send the remaining nine to me. Otherwise I won’t collaborate anymore.” To remove this necessity we create what is called a refund transaction. A refund transaction is a timelocked transaction that will become valid after a certain timeout. This refund transaction will take whatever we put into this offchain contract and will split it back up. This timelock is of course a limit on the lifetime of our system. If I say “In a week you can get your money back” then all you have to do is wait a week and you can get your money back regardless of what we decided in between. This is a very common scenario for all of these systems. We can sidestep by having a trigger transaction which says we add an intermediate step. We put money on the table. If we have a trigger transaction that triggers the timeout to start ticking and we have a refund transaction. The timeout does not start ticking until we get this transaction on the blockchain. From that point of time where we have the trigger transaction we can wait for the timeout to expire and then we have this unlimited lifetime of our contract. There are two downsides here. The first one is that we suddenly have increased our onchain footprint by an additional transaction. The second one is that we have to monitor this trigger transaction to be on the blockchain. If we continuously discuss on who gets the set up output and suddenly there is this trigger transaction added to it we might get detached from what we are discussing. We were expecting only the set up transaction to be there. Now there is a trigger transaction so what do we do now. This adds some complexity but it is a really clean mechanism of extending our lifetime indefinitely for these offchain contracts.

# Channel Factories

Stephan: Let’s now focus in on what Lightning Network is today versus what a possible construction might look like in a channel factory scenario. Correct me if I’m wrong. Let’s say I’m a peer and I do lncli and connect to you. I open the channel to you, that is the funding transaction. Then we exchange the states over time, changing the balance between you and me. Say I want to close that, that’s a commitment transaction, that commits to the final balance. Could you explain the difference with what the channel factories model would look like?

Christian: One small correction. The commitment transaction is representing our state. Because we need to have all means in our hand to enforce the state if our counterparty disappears. You exchange commitment transactions and then eventually one of them will make it onto the Bitcoin blockchain. That closes the channel. In a channel factory scenario we would meet as a group of people, let’s say 10. We would pool some money. We would create one big multisig where all of us add some funds. Depending on who added how much to this multisig address our initial state would reflect that. If Alice adds 3 Bitcoin and Bob adds 4 Bitcoin and Charlie adds 1 Bitcoin the initial states will be 3, 4 and 1. Our first commitment transaction would be pay everybody back whatever he got. If we want to create a channel if this channel factory, let’s say between Alice and Bob, we would split off the funds that we want to have in that channel. Let’s say Alice and Bob each agree to put 1 Bitcoin into it. Our state would be Alice has 2 Bitcoins, Bob has 3 Bitcoins and Charlie still has 1 Bitcoin. There is this fourth output which has 2 Bitcoins in it which represents the channel. We set aside some funds and we use that to create a new channel. Once we agree that this is the new state Alice and Bob can start changing their internal state on who owns what in this channel. If everything falls to pieces and the entire channel factory closes then we end up with these four outputs on the blockchain, Alice’s, Bob’s and Charlie’s funds and we end up with a fourth one which is the channel between Alice and Bob. Alice and Bob can then either continue to use it or they can settle this channel. It is really just allocating outputs and moving these outputs back. If Alice and Bob get tired of using this channel or want to change their balances somehow they say “Please fold these funds back into our direct balances.” Let’s say Alice transferred the entirety of her funds on that channel to Bob. Bob now owns 2 Bitcoins in that channel. We settle this nested Lightning channel and we add 2 Bitcoins to Bob’s balance to zero to Alice’s. Now we are back in a scenario where we have three outputs each representing Alice’s, Bob’s and Charlie’s funds. We can do this over and over again in a very flexible manner. As long as the channel factory doesn’t settle onchain all of this happens offchain and the blockchain never learns about this happening.

Stephan: This would be much better for privacy and much better from a reduced block space usage. Could you comment on block space usage in the different models?

Christian: In the full collaborative case where we create a multiparty channel and then create some nested Lightning channels and then tear them down and settle them. What you end up with is a set up transaction that for Alice, Bob and Charlie has three inputs and one output. The output is just the 3-of-3 multisig which with Schnorr will be getting much smaller because we can aggregate signatures into one single signature. For the settlement or the commitment we end up with a single transaction that spends the output from the set up transaction and splits out the funds too Alice, Bob and Charlie. We end up with a single transaction with one input and three outputs. That is sort of the ideal case where we have two transactions representing however many updates we had in between. However many channels we created or tore down or refunded or whatever. In the non-ideal scenario where we end up with a force close where one party disappears and doesn’t collaborate anymore we end up a set of transactions that look identical with a settlement transaction that looks almost identical except it has for each of the nested channels it has an additional output. Each of these additional outputs would then need to have a close transaction at the end. We would have a slightly bigger footprint but if we compare it to let’s just create all of these channels onchain we would end up with a footprint that is comparable if not a lot smaller because all of the channels that we settled offchain already do not need to have an output on the settlement transaction. Therefore we save on both blockchain space and the UTXO set that we create in the intermediate steps as well.

Stephan: One of my earlier episodes with Shinobi mentioned that one of the concerns is around not just the blockchain size but also computer being able to maintain the UTXO set. Obviously that was one concern that people who are thinking out ahead are considering. Reading from your paper from 2016 it says “For a group of 20 users with 100 intragroup channels the cost of the blockchain transactions is reduced by 90 percent compared to 100 regular micropayment channels open on the blockchain. This can be increased further to 96 percent if Bitcoin introduces Schnorr signatures with signature aggregation.” Hopefully this gives the listeners some picture on exactly how massive the savings could be.

Christian: Schnorr definitely is cool and we should get it as soon as possible. We have been itching to do it for such a long time now. We could not agree on one construction or another but we have seemed to hone in on the final and best version ever.

Stephan: Let’s talk about a channel factory being able to take someone in without an onchain transaction and take someone out without an onchain transaction. Can you explain that for the listeners?

Christian: You are referring to splicing? That sadly is an onchain transaction. The idea for splicing which we are also considering to add to Lightning itself is to temporarily close a channel and then reopen it in the same transaction. The whole security of these offchain protocols relies on the funds in that offchain protocol never being available to a single party but also being under the control of all participants in this offchain contract. If we close a channel and reopen it right away then the funds never actually are under control of a single party but always remain under the control of all parties involved. We can do this close and reopen motion without stopping updates to the channel itself and without having to wait for this splice transaction as we call it to confirm onchain. That is the basic concept of splicing. Why would you do that? For Lightning what we would like to do is be able to add funds from outside to a channel. We settle the channel, add an additional input to the close transaction and then the reopen transaction has a single output which combines the funds from both parties. If we want to look at it in a more visual way then we can think of it like me adding 10 dollars on a table and we create a channel between the two of us. Now somebody else joins the table and puts 5 dollars on a table. We wait for this 5 dollars on the table to confirm and then we decide let’s split you in. Now we have three party channel that has 15 dollars. In Lightning this joining party would need to be one of us because they are limited to two parties. With multiparty channels we can actually add or remove additional people. The reason why this is exciting for Lightning is that it allows you to add funds to an existing channel in case you start running out of money. Or what is more interesting is that we can create onchain transactions from an offchain contract. We can say “You and I have a channel open for 10 Bitcoin.” Now I have a vendor that asks me to pay 1 Bitcoin onchain. I can go to you and say “Let’s do a splice out. Let’s close the channel, split 1 Bitcoin off in the direction of the vendor I am trying to pay and then reestablish the original channel with the 9 Bitcoin that remain.” This in Lightning allows us to remove the differentiation between onchain and offchain funds because all of the funds that we have offchain are still usable onchain for transactions. This is a huge win for us because it allows us to simplify the user experience by quite a lot. With multiparty channels we can increase and reduce the set of participants in our offchain protocol quite easily by adding or removing parties. This becomes this breathing mechanism where we add and remove people as we need and as they need to join or leave our small offchain protocol. It adds a lot of flexibility to where we allocate funds and with whom we want to trade. We can do that all with a single transaction on the Bitcoin blockchain.

# Risks of channel factories

Stephan: It might be interesting to talk about the risks of a channel factory model. What about the risk that a channel factory participant goes unresponsive or offline?

Christian: The main advantage of having a channel factory is we can do offchain creation and offchain teardown of channels. But that requires every participant to be online at the same time so they can sign off on changes. If a participant in our offchain contract becomes responsive then what we can’t do anymore is create updates to this structure of channels that we have been built on top of. We can’t sign off on changes anymore. But what we retain is the flexibility to still use the existing channels and make updates there. Maybe he comes back and we can continue where we left off. If he becomes unresponsive and does not come back we can eventually settle the offchain contract onchain. By settling we also create the payment channels that were nested inside this offchain contract. We can continue using these channels as if nothing happened or we can decide to settle these channels as well. In that case we would have to settle them onchain. There is this dual closure in case of a party becoming unresponsive. We settle the channel factory and then we settle the Lightning channels that we build on top of it. That is one of the main uses for a channel factory and that is why we spin up smaller channels on top a channel factory. We don’t want a single party controlling the liveness of our contract.

Stephan: The idea is that you and I have 18 friends. We get together and form a 20 person channel factory. Then Bob is an idiot and he goes offline. You and I still have our channel going and we can still transact. That is what would happen?

Christian: You probably shouldn’t open a channel factory with people that you think might become unavailable immediately because you just went through the entire set up on only to tear it down. When you choose the other parties in a channel you should probably use people that you might know by name and can trust that they will stay responsive. Or a provider that has a reputation for remaining online. It is quite likely that if you picked random people off the network you will end up with people that run on mobile phones and disappear at a moment’s notice. 

Stephan: It relies on a vision where people do something like a Casa node, they have one at a home or some sort of set up where they have a node at home and they pair their mobile phone with their node back at home and they do a set up that way.

Christian: That is the model I am inclined to think will evolve. It gives us these very stable nodes where you plug in at home and act as a home hub. Name squatting that hub term that people seem to like about Lightning. That would give you this uptime that you require. Failures happen and these channel factories might not be online 24/7 but as long you have a channel built on top of a channel factory that you can use for your day-to-day expenses you should be fine.

# Lightning penalty mechanism and eltoo

Stephan: It is not as if you have to have perfect connectivity. Your phone could drop off and come back on later that day and you’d likely not lose funds. If you accidentally broadcast an old state and somebody punishes you, could you comment on that?

Christian: The punishment is part of the Lightning design that I am very critical of. I might be biased a bit. What we do to update our state is I promise to you that I won’t use an old state and I give you something to punish me if I ever do. In Lightning this is just a signature or a preimage that is required to steal my funds. The punishment ends up being the cheating party losing the entirety of their funds if the cheated party reacts in time before this timeout expires. This has some really nasty properties. If I promise to you that I won’t use the old state and then I forget that I promised this to you. Or if I backup my Lightning node and then restore I end up with an old state. I don’t remember that I promised to you that I wouldn’t use it anymore. I might cheat by accident and that will lose me money. This is why we tell people please don’t backup your Lightning nodes because if you try to restore it might be really painful for you. That happened to me by the way. I managed to restore an old node that I was really sure I had backed up the latest state and I wouldn’t be cheating. But lo and behold I lost the ten dollars I had in this channel. This is for Lightning, the penalty based mechanism where we ensure that all states don’t make it to the Bitcoin blockchain by punishing you if that happens. There are a number of other constructions that are a bit more forgiving. For example, our [paper](https://blockstream.com/eltoo.pdf) from last year called eltoo strings along these updates and you can override the effects of any transaction that leaks onto the blockchain with a later one. If I were to accidentally cheat by publishing an old state you would allow this transaction to be part of the blockchain, confirm it because I paid fees for it. Then  you would come along and say “Here is a newer one. Whatever you tried to do, add this update transaction to this chain of updates.” You would be overriding whatever effects I want to have. The effects in this case are I want to have this old state where I maybe had 10 Bitcoin instead of just the 5 Bitcoin I have now. You just override my 10 Bitcoin to me and 0 Bitcoin to you with a 5 and 5 that we agreed on much later. This is not a penalty based mechanism because accidents happen. You just correct my mistake. It is still not free because I am still paying fees but it is a bit more forgiving. I usually compare it to death by a thousand cuts compared to beheading right away. I think a paper cut should be painful enough for you to not try too often but it also should not be fatal. 

Stephan: It would be interesting to talk about the interaction of channel factories with some other Lightning concepts or technologies. We have spoken a little about the interaction with things like splicing. What about something like AMP? Would a channel factory construction change? For the listeners AMP is multipath routing. Could you explain what the impact might be?

Christian: The channels that we build in a channel factory are fully functional channels so there is very little that we need to consider there from a pure layering perspective. At least AMP will be perfectly usable for this kind of channel. Onion routing will be perfectly usable. There is a very clear separation and the channel factory and the channels we create on top of it. There is very little difference but what if we are sure enough that the channel factory participants are going to be online with a high reliability then these collapse the channels and this channel factory itself. This is a rather interesting concept because it allows us to not have the added complexity of actually bootstrapping channels on top of what is already an offchain contract. But we can do the updates that we want to do directly on the offchain contract that is our channel factory. If we want to go back to Alice, Bob and Charlie having an offchain protocol and each has 3 Bitcoin for simplicity. We want to transfer 1 Bitcoin from Alice to Bob. We could create a channel between Alice and Bob for let’s say 2 Bitcoin and then do the transfer on top of that channel. Or we could say “Let’s do this transfer directly on the offchain contract without creating a special channel for it first. Our next update, Alice has 2 Bitcoin and Bob has 4 Bitcoin.” We can start moving funds back and forth without having to go through this indirection of bootstrapping Lightning channels on top of the channel factory itself. This has the disadvantage that every participant in this offchain protocol needs to sign off on these changes but it has the big advantage that we are no longer allocating funds to individual pairs of participants. But we retain this freedom of moving funds from any participant to any other participant at the same speed that we would have if we were to create a channel and then send over that. We are not splitting funds into trading pairs anymore. We retain the flexibility of anybody can receive from anybody else and for the full amount that they have in this channel in the first place. If we were to go for a system that is a bit different from Bitcoin. Let’s say we have assets for example like Liquid. We have unique assets that can we send back and forth, Cryptokitties on Liquid. These can’t be traded on a Lightning system because the asset that I’m sending through different hops is not the one that will end up at the recipient. By having this freedom of reassigning ownership freely inside of our multiparty channel we can have this transfer of even unique assets between the participants without having to use onchain transactions.

Stephan: Would this construction be called something different to channel factories? Has it got a name?

Christian: I usually just refer to it as multiparty channels.

Stephan: It is a generic multiparty channel concept as supposed to the channel factory specific concept.

Christian: Yes exactly. The channel factory concept is a multiparty channel where the artifacts that are created through the offchain multiparty contract are channels. Whereas the more generic one allows you to have free reassignment of funds and tracked assets or whatever you are doing on this offchain contract in the first place.

Stephan: Perhaps we should be calling it multiparty channels, the general case then. Let’s talk about the impact of watchtowers on multiparty channels. Can you comment on that?

Christian: Watchtowers are just a mechanism for us to make sure that if somebody misbehaves the appropriate reaction is taken. This is instead us of having to directly watch the blockchain we outsource that watching to somebody else as an addition to our own capabilities. We might be running on a phone so we might not be able to react in time to our cheating counterparty. We give the watchtower the ability to react whatever happens onchain by sending our latest states to the watchtowers and saying “If you see something do something.” This general concept remains valid for both the multiparty channels as well as the Lightning channels we build on top of a channel factory for example. It is just “Here is a canned response. If you see this onchain respond with this response that I just gave you.” The complexity comes from which update mechanism we use. For the Lightning penalty mechanism we need for each state that we agree upon we need to tell the watchtower “If you see this state on the blockchain this is how you should react.” That means that for each update the watchtower has to keep a separate bundle of information. This bundle grows over time. The more we use the channel the more the watchtower has to keep in mind. With other constructions this becomes a lot easier. With the eltoo mechanism what we do is have this overriding of whatever happened before so we give the watchtower is a simple constant size bundle that can replace every update that we gave him before. It makes watchtowers a lot easier because you are not requiring it to have an ever growing set of reactions. You say “You see this reaction? It subsumes whatever happened before and you can always apply it to what you see onchain if this were to happen.”

Stephan: Let’s talk about what technology we have on Bitcoin and Lightning today versus what is required for channel factories or the more generic concept of multiparty channels. Is it SIGHASH_NOINPUT, is it eltoo? 

Christian: The simplest idea of a multiparty channel is implementable today. My [paper](https://tik-old.ee.ethz.ch/file//716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf) from four years ago called “Duplex micropayment channels” already had this idea of creating multiparty channels. The reason it was never adopted was that Lightning had more traction and the footprint of duplex micropayment channels is a lot bigger than Lightning. With eltoo we were able to grab some of these features back from duplex micropayment channels and hopefully we will be able to integrate eltoo in Lightning so we can take advantage of this as well. But eltoo requires us to have a change in the Bitcoin protocol itself. This change is called SIGHASH_NOINPUT and it allows us to have this overriding of whatever came before. What we want to do is have this one response that can be bound to whatever we have seen onchain and be able to override whatever happens there. This change allows us to rewrite the response in a very subtle way so that it can attach to whatever we want to respond to. That is currently being discussed. Just today I got a new email on how to improve the security of this because there are some security concerns. I am pretty positive that the general concept is pretty well received in the Bitcoin community and that we might soon see progress on this together with Schnorr and Taproot. Schnorr and Taproot are also interesting for us because they actually reduce our onchain footprint by reducing the number of signatures we need and by hiding the scripts that we need that would give away that we are using a channel factory or a multiparty channel by making it look like a normal transaction from one participant to another participant. Keeping my fingers crossed I am hopeful that we will see this in the near future. I’m not making any predictions on timing because SegWit taught us that lesson.

Stephan: I wasn’t going to ask that question next. I know better. But I will ask an even more crazy question. The Bcasher steelman. They pose this question or challenge. What about a future with high fees a person without a big Bitcoin stash wouldn’t be able to run a fully validating, trust minimized Bitcoin, Lightning Network stack? They may need to trust Bitcoin banks of the future. Do you believe that with technology like multiparty channels that kind of trust will not be necessary? Or maybe it is going to be more like an ecosystem. There will be multiple options. Some people just stay Bitcoin onchain and some people are somewhere in the middle and others go Lightning custodial. Do you have any thoughts on that?

Christian: I always thought that trusting a third party was the whole model of Bitcoin Cash. I don’t see that as much of a criticism as a suggestion. Running Lightning and running a full stack of a fully verifying node and the Lightning client and managing your own channels is currently quite hard. It is definitely not for the faint hearted to set up and operate. I think over time we will end up with a range of solutions that cover all of the individual requirements as well as the solutions adapted to your own skills and your will of reading into this stuff. We can’t really force people to take ownership of their own funds and take the time to invest and read up on best practices. This is for hard for people who are working on this 24/7. What we can do is create a nice and secure solution and give people the option of using it. I totally see that some people will choose custodial wallets and we should not make fun of them. We should not shame them into having to invest the time to read up on stuff and become experts in Lightning because that’s the only “true” way of using Bitcoin. For Bitcoin or Lightning to become really usable we need to make sure these options are viable and present better trade-offs than whatever solution we are competing with. If people still want to choose custodial wallets that is perfectly fine as long there is a migration path for them to take ownership. If a custodial wallet is trying to lock people into only ever using this custodial wallet I am definitely against it. But if a custodial wallet provides information and necessary data dumps to migrate to somewhere else and keep you mobile and allow you to upgrade at a later point in time it is a perfect onboarding strategy for us to pursue. Always with a warning label attached “You are trusting a third party and should maybe consider doing something more.” But we can’t really force people. As for the criticism that people might not be able to create ten cent channels on Bitcoin, I think those become viable once the Lightning Network has taken away from the overall load of Bitcoin. We have shifted this mass of tiny transactions into Lightning. We might make space and might lower fees enough so that people can use smaller channels again and also allow for people that might not have tens or hundreds of dollars to use this technology in emerging countries.

Stephan: That’s a great answer. It still comes to that question of we can’t compromise on Bitcoin security to try to make it more accessible for everyone right now. It has to be done the right way. Hopefully with this multiparty channel construction ten or fifteen years down the line this might be a more feasible way to get people using Lightning in a fully validating stack. Even if they don’t choose to use that themselves.

Christian: By having multiple people pool their funds you make this much more affordable to the individual by splitting the cost of managing one of these multiparty channels or channel factories over the now bigger set of users that can participate to pay for the onchain fees.

Stephan: In a world where the blocks do start to become full. Is the overall ecosystem in such a world dependent on there being enough full node runners and self sovereign people to try to maintain the overall system health?

Christian: I think that should always be our goal. We should always allow people to independently verify the blockchain. Keeping this load doable even for low powered devices and two generations old laptops. That should be doable. I think that is not a question of should it be allowed but what can we do to enable that? It is about personal freedom of being able to choose to do this and to verify the entire blockchain and be able to set up your stack. We are working hard on enabling people to do that and be as self sufficient as possible. This is not a choice of should we allow it but so much as how do we do it.

Stephan: Tell the listeners how they can find you and if you have any closing comments on what they look for coming out from you guys at Blockstream or anything you’ve got coming up.

Christian: There is so much coming up for Lightning. We just visited your home country in Australia last year to talk about all of this. The ideas we have on the roadmap are so fantastic. They include splicing, multiparty channels, the introduction of Schnorr signatures. There is just so much going on. I probably would miss 90 percent of the stuff. Keep your eyes peeled on what is coming up. There is some huge stuff in there. People can find me at snyke on Twitter and I am cdecker on GitHub. If you have questions I am always happy to talk about this cool technology.