WBD102 Audio Transcription 

Christian Decker on the Tech Coming to Lightning

Interview date: Tuesday 30th April 2019

Note: the following is a transcription of my interview with Christian Decker from Blockstream. I have reviewed the transcription but if you find any mistakes, please feel free to email me. You can listen to the original recording here.

In this interview, I talk again with Christian Decker from Blockstream. This time we dig into the detail of some of the upcoming technology for the protocol.

Interview Transcription

Christian Decker: How's the King of Bedford doing?

Peter McCormack: I'm doing okay. Very strange day! You've obviously seen the news? That Binance has delisted Bitcoin SV?

Christian Decker: Yeah. Just just saw that a few minutes ago. I was walking home and I saw people saying goodbye to Bitcoin SV and I was like, "what's happening there?"

Peter McCormack: Yeah! I don't know, I'm struggling to take it all in. It's obviously a very cool move by CZ and hopefully it's the first of many! But it's also that weird thing that now he's done that, will people think they can pressure him to remove everything? I'm not sure how healthy that is myself. But I still think it's cool what's happened.

Christian Decker: Yeah, it definitely is a dangerous first precedent to set.

Peter McCormack: But this is a particularly terrible fork of the coin!

Christian Decker: Yeah. But as you mentioned, it still sets a precedent.

Peter McCormack: I think we can separate Bitcoin SV, Craig Wright, Calvin Ayre and say, "no, this is definitely different, this is super scammy", because of the point that he keeps fraudulently claiming he Satoshi and validating it as a better form of Bitcoin. I think it deserves special treatment.

Christian Decker: Well, that true. I always said that if Craig Wright turns out to be Satoshi, I will leave Bitcoin immediately! So far that's not been the case yet.

Peter McCormack: Well he's left Bitcoin himself really in working on Bitcoin SV anyway. Of course he's not Satoshi! Look, the easiest thing in the world is to prove it. With everything he does to claim he is and to a prove he is, if he just moved coins, that would be a big signal! I still don't think it proves it, but that's the biggest signal he can give and he doesn't do it because he can't and he perpetuates this minor mystery that he may be, because of that. Hopefully I'm going to end up in court with him and we'll figure this out!

Christian Decker: This is way more interesting than Game of Thrones in my opinion!

Peter McCormack: Do you know I haven't watched it yet. I've recorded it. Have you watched the first one?

Christian Decker: Not yet, but I mean this is the real power struggle here.

Peter McCormack: Well listen, look, thanks for coming back on. This is really useful. I really enjoyed our first interview in Boston. I don't think anyone could tell that I was on a table holding a tissue, with my eyes streaming! Which was an awful way to do it, but it was great to do it. Following that, I've got more questions really! Let me explain what's happened.

I came to doing this Lightning month knowing it was new, wanting to learn more about it, but I was treating it like a finished product. Even though I knew more tech is to come, I still was treating it like a finished product and finding things when I was using it, that I didn't like too much and problems. But I think that's totally wrong. I think it was Nic Carter who said to me, he said, "look, if you look at Bitcoin now. If you buy Bitcoin on the Cash app, that's an entirely different experience than you did in 2010".

So you've talked about this interesting tech that's coming. So I think it's a good follow-up to start talking about that. So the first thing I want to ask you about is splicing, because you talked to me about splicing in the first interview, and I went and read up on it and I didn't fully understand it. So I want you to talk about it in the simplest way possible.

If I get lost, I'm going to ask you again, but the impression you gave me is that you could potentially have a wallet whereby there is no separation between what is Bitcoin and Lightning Bitcoin. When you choose to make a payment, it will find the best and cheapest option, which sounds great. Where I struggle with that, is there are different formats for Lightning and Bitcoin addresses. Therefore I was struggling to understand how that would work. So the floor is yours! Tell me about splicing.

Christian Decker: Okay. For the second part of your question basically, is we do have different addresses and different sort of interactions to get payments from A to B in Lightning and in Bitcoin. So the simple answer is basically that the Lightning invoices can encode a fallback Bitcoin address. So if we can't perform a payment on Lightning or it turns out to be uneconomical, then we can just use that address and do an on-chain payment instead.

So having this downgrade of protocol in the background without having to ask a user, "hey, can you maybe ask your vendor for a new address because this doesn't work." We can just give that information with the invoice itself and then do a downgrade as we need it. For splicing itself, that's a bit more complicated and I usually start my explanations with this usual setup that I've also done last time. The Lightning channels, nothing else and us putting a few bucks on a table between us and then deciding how to split these funds.

If I only have money on the table and I don't have any more in my pocket to do off-chain payments, then the natural way of doing this would basically be, "hey, I need my money on-chain. Let's close this channel." I get my share of this channel. I can then go and pay somebody else on-chain and we can then meet again and open a new channel. So what we could do there is basically, we close the channel, I do my on-chain payment, and then we re-open this channel again. That's very inefficient.

That's three on-chain transactions just to perform one on-chain transaction and re-establish the old state. So what we can do, is we can smash this close transfer and re-open transaction into one single transaction. So what we do is basically, I come to you and say, "hey, I need to pay Amazon for five bucks and I don't have any funds left in my pocket, let's pay this out of our channel."

Then we collaboratively build this close transaction, that is then used to close the channel, send $5 off towards Amazon and then re-open this channel at once. So this basically combines these three transactions into one transaction that closes, sends off and reopens the channel. Now the interesting part is that the reason why we put the money on the table in the first place, is so that neither of us can run away with the funds and the other one holds them back. 

So if we combine these transactions into a single transaction, then there is no opportunity for any of us to run away in some intermediate state and we can continue working on the newly re-established channel right away, without having to wait for it to confirm. So what we can do, is we can do this in a zero downtime scenario where the channel remains operational throughout this operation, but we still can splice out some funds to a third party. Then there is the counterparty, which is called splice in, but it's basically just a mirror image of splice out.

Peter McCormack: So that's like a scenario. Say I've got a channel open with you and I've got $15 capacity on my side and I want to release $5 for Amazon. That's in that scenario.

Christian Decker: Yeah, exactly.

Peter McCormack: Okay. Just want to go back a step. When you talked about the downgrading of addresses, that's all automatically done. But at the same time, if I'm trying to make a payment via Lightning and it chooses to downgrade, the payment's going to take longer?

Christian Decker: Absolutely. That's definitely a kink that we need to work out in the UX, because as you mentioned, it is also a downgrade of the user experience. So you might get a pop up that says, "hey, we can't do this immediately. Shall we try again? Or shall we just go the slow way around?"

Peter McCormack: Right. But you don't imagine it's going to say, "would you like to pay via Lightning or via base chain?" You don't think that's going to be the option stated.

Christian Decker: I hope we don't go that way, that you are presented by default with both options because well, one is that it becomes really strange for users to have to select a payment method when they were expecting to do a Lightning payment and suddenly "hey this guy also accepts on-chain payments. Do you instead want to have a slow on-chain payment?"

Peter McCormack: So it would be offered when it's a better scenario. For example, let's say in the future, it's quite a big payment, right? So large payments on Lightning can actually be more expensive than on-chain, because they charge in a different way. So it may come up as an option that says, "look, if you were to do this as a on-chain payment, it will take longer, but it's going to cost you less. Would you like to do that?"

Christian Decker: That's definitely something that we need to consider at some point. Currently we sort of have the luxury of having small payments only. So we sort of defer those design decisions for a later point in time.

Peter McCormack: How does everybody ensure they have a fallback on-chain address? Will that be part of wallet design or is that protocol design? Where does that happen?

Christian Decker: That's, that's pretty much the wallet design of the implementation you are using. Practically every single implementation, be that C-Lightning, LND or eclair, all have built in wallets that will accept on-chain payments as well as Lightning payments.

The reason for that is we need to actually have the ability of receiving on-chain funds, in order to get funds to create channels with, in the first place. So that's sort of something that we're currently doing anyway. So it's not that big of an issue currently. It's just not exposed as being a classical Bitcoin on-chain wallet currently.

Peter McCormack: Right, okay. Then if we move back to where you were talking about, say we have a channel between us, I want to release some funds to make a payment. Is that something I communicate with you or do I just do it and you are not aware? Can I just release some funds out of it, in that single transaction?

Christian Decker: Ah no, that actually requires a lot of interaction and we are currently specifying what kind of interaction that needs. But you will have to co-operatively create that transaction, that close and re-open transaction with the splice in or splice out with your counterparty as well. So you need to have interaction with your peers.

Peter McCormack: It sounds kind of an odd scenario that I would want to perhaps release $5 from a channel to go and make an on-chain payment with Amazon. I guess the example just sounds odd.

Christian Decker: Yeah, I struggle to see Amazon accepting Bitcoin in anytime soon, but it was the first thing that came to mind. But we sort of need to have this flexibility in keeping on-chain payments a viable option as well as Lightning, because people will be upgrading really slowly to this. I mean somebody congratulated one of the exchanges today for implementing SegWit finally!

Peter McCormack: Finally!

Christian Decker: We need to have an easy way to upgrade and downgrade funds that we have on-chain or funds that we have off-chain and this flexibility is what is needed to get the network started in the first place. So the counterpart is of course splice in, where you have on-chain funds and you'd like to top up your channels. That's sort of the same mechanism, but it's upgrading and downgrading your funds from off-chain to on-chain and back again basically.

Peter McCormack: Yeah. So I understand the reason why you'd want it. I guess what I would need to think about is the economics of it, because an on-chain transaction still could be $1, $2, maybe $5 in the future. So it really is only going to make sense maybe in a scenario where you've got quite a large amount within a channel.

Christian Decker: Well that obviously depends on the fees, that you are paying and the amount. I'm not really good at making any predictions in that direction. But if you compare that to having just on-chain funds, I mean that $1 in transaction fees, you're going to pay anyway. Now you can try to pay it through Lightning and maybe it succeeds and then you've won something or you can then drop back on-chain and you haven't lost that much compared to keeping your funds on-chain all the time.

Peter McCormack: Yeah.

Christian Decker: It's just extending the reach of the funds that you have towards applications that currently aren't really doable and you probably wouldn't fall back if you're trying to transfer a 5 cent amount and the on-chain fees turn out to be like $1.

Peter McCormack: Okay. That comes to another point that's come up in a couple of my interviews that I've been trying to figure out, is that if you're going to start using Lightning and you've got a channel open, you have to use it a few times to justify the economics of it. If you were to open up a Lightning channel and do one payment, you might as well have gone on-chain unless you were desperate to make a very quick purchase.

Christian Decker: Absolutely. This is the importance of selecting whom to open a channel with and selecting the size of the channel. It's definitely not trivial because, well, the big savings come from you using a channel over and over again and possibly in both directions.

So it definitely is not an easy problem to solve and we are working on ways to help users select or maybe even auto select some of these parameters, whom to open a channel with and what capacity to assign, with the entire effort of creating autopilots. But I wouldn't say it's a solved problem as of now and if you were to do just one off payments, I would definitely recommend you stick to on-chain payments, because well, it's just easier!

Peter McCormack: Yeah and that's one of the things I've started to realize, is that we are so early, but if you consider where Lightning maybe in a couple of years where we'll all have probably a few channels open, maybe one of those is connected to a hub of significant size, that actually it's going to be less of an issue. The problem is now that it's still very early and there aren't enough people with enough channels open, connected to each other with enough capacity on the network. But this is just like a...

Christian Decker: It's bootstrapping the network basically.

Peter McCormack: Exactly.

Christian Decker: It's one of the classical problems in game theory, is that if you have a network and the actual value comes from the network being completed, it's really hard to incentivize people to actually go and create that network. So we have a whole section of game theory that only tackles the issue of network formation games and those are hard.

Now we are in a lucky position that we have a lot of enthusiastic users, that are willing to dig in, start learning and invest the time and money to actually build this network from the ground up. Hopefully we will get there, that we end up with a fully usable network that connects every single person in the world with any other person in the world. But I wouldn't say it's a given that this is actually how it's going to work out and there is a lot more work needed and lots of people investing more time in it.

Peter McCormack: Yeah and that's another part of it that made me realize... Look, I've got my Casa nodes actually behind me here that's not set up. I need to set it up, I need to open some channels and I think the enthusiasts actually have to be part of it, to help with the bootstrapping.

Christian Decker: Yeah!

Peter McCormack: Okay. So one thing that came up that I didn't realize at the time, when I had my Blue wallet set up, I didn't realize I had a custodial wallet. I'll be honest, the user experience of having a custodial wallet was great, it solves so many problems for me. But when I interviewed Jack Mallers, he was very, very against custodial wallets because he thinks it's misleading people because it goes back to "not your keys, not your Bitcoin", which I totally agree with. But for the sake of a few Dollars here or there, to test in a wallet, I wasn't too bothered. Where are you with the whole custodial versus non custodial in Lightning?

Christian Decker: I used to be quite strict on, "custodial wallets are the devil's work!" But I've since come around. I would say custodial wallets are a great option for onboarding people that do not have the luxury of investing loads of times and loads of money and maybe cannot run their own node. I know this is heresy in the whole space, but there are such people!

Ever since I tried explaining Lightning to my parents and my brother, I now know that there's people that just don't care! For those people, a custodial wallet is definitely a good onboarding experience. It gives them a stake in the system as such. What I do think is always a good thing to have, is give people the option of then upgrading to a more sovereign solution. Give people the option of taking your custodial wallet and just export it to a full node and have it run there, from then on.

So I think there is a certain fluidity in your wallet choices as well. If you choose a wallet initially, because it makes stuff just easy, it just clicks, it works. Somebody else has taken care of it for you, then why not? I mean that's a good user experience and it also amortizes some of the work, that we as developers or the Blockchain as such has to do.

But we should always give users the option of then going and digging in and sort of learning about this stuff and then maybe experimenting with it. So I'm definitely not opposed to custodial wallets. I think there a good onboarding experience, but we should also make it much, much easier to have the sovereign version in a much easier way as well.

Peter McCormack: Yeah, I think I agree. I think it really comes down to UX again of actually signposting and letting people realize what they're using, whether it's custodial or non-custodial and what it means. I also don't think many people are going to be getting themselves set up with nodes like a Casa node. I just think whilst it's cool and I love the idea of everyone having a little box in their house, which is their identity into a network and their ability to hold and manage their Bitcoin and their Lightning Bitcoin, I actually think for a lot of people, that might be a step too far.

I think for some people, having something like a Nano or a Trezor is great, but perhaps a mobile wallet... So I talked to somebody about Neutrino, actually I talked to the Blue wallet guys about Neutrino and it seems like that's going to be a big step for some people to be able to have a non-custodial mobile solution.

Christian Decker: It will definitely reduce the need for running a full Bitcoin node, because you can now have the Bitcoin backend, sort of be a very lightweight system that doesn't have to verify the entire chain and so on and so forth. That's definitely a great step towards being more open and being easier to set up. But yeah, there's a few other solutions as well.

So my favourite solution is... I mean everybody sort of has a friend in their surroundings that will sort of dig into all of this and maybe they can run a custodial solution for their friends. So my usual go to example is the home hub, where a family shares a full node and just one of us has to really maintain it and operate it. The other one is that between fully custodial and fully decentralized, there's always sort of different shades of grey.

So one of the things that I want to eventually implement as well, is having a sort of headless node for C-Lightning, where all the key operations are done on your phone and you just have the C-Lightning Daemon that does not have any access to funds and does not have access to keys, run on a hosted infrastructure. So you still use your phone to sign off on anything that happens on the channel and the C-Lightning Daemon that is hosted by a third party, is basically there to sort of keep it up to date, keep it running and monitor your channels and so on so forth.

Peter McCormack: Somebody was saying to me that, I think it was the Blue wallet guy, that they want Neutrino to be part of the Bitcoin core protocol. Is that something that's planned? They seem to imply that it relies on it being included, but there's no timeline or confirmation of when that will or won't happen.

Christian Decker: I can't really speak to what what Bitcoin Core does. But it would definitely be nice to have support for it at least in Bitcoin as well. I think the major pushback currently is that it sort of makes it easier for people not to run full nodes, which is the whole point of it! But yeah, these discussions usually tend to be quite long and I really like the idea of Neutrino... Roas Beef was really clever in proposing Neutrino, by making it optional.

So we've talked about UTXO commitments for a long, long time and all of them ended up in this sand bunker and never got out of there, because they needed to have this commitment to the UTXO set. Neutrino came along and was like, "we can have this separate structure, we could commit it, but it's not central."

So by making it this optional addendum, you basically sidestep this whole issue of everybody coming in and this is starting to discuss how to optimize it even further. So hopefully Neutrino will make it in. I don't know what the current state is, but I actually would like to work with Neutrino as well.

Peter McCormack: So something else that's come up when I talked to Peter Rizun. He talks about sub dust levels of Bitcoin and he talks about the fact that if you've got sub dust levels, you can't close a channel, well you can, but everything is lost in an on-chain transaction. Therefore the use of channels within Lightning is dependent on whatever the base chain on-chain fees are?

Christian Decker: So there is definitely a point of truth in there and that is that we can't really create outputs that are sub dust. Now there is no real connection between dust and fees though. Dust is a fixed parameter that is fixed on the protocol level. Whereas fees fluctuate depending on the demand of block space that we have in the network.

So I don't see the connection with fees. I do however, see that there is an issue that we can't create sub dust outputs. Now we actually use milli-Satoshis internally as a unit of account, which also can't be represented on the Bitcoin Blockchain and the dust limit is even higher with 546 Satoshis below which you can't really create an output. I'm calling this a unit of account because that's exactly what it is. It's not the minimum amount we can pay out, but it's the minimum amount we can keep track in our channel.

So if I were to do, let's say 601 Satoshi transfer to you, I could all of the sudden represent that as an output, that can go to you. So we keep track of amounts that are not representable on-chain, but by aggregating them, we suddenly have amounts that we can represent on-chain. The usual hand wave argument for what happens to the funds that we do not reach this sort of maturity level, such that they can be represented on-chain, well those are usually so small that you shouldn't really care about them. I'm not sure what 500 Satoshis will get you today, but it's sort of nothing.

So the reason why we have this unit of account that is smaller than what we can represent is that by aggregating them, these amounts actually matter, but the individual transfer does not. So that's the main argument basically, that if if you do enough payments, all of the sudden these matter and if you don't do enough payments, then well it's just not worth keeping track of it. Keeping in mind that the dust limit was introduced in order to sort of put the limit onto the cost that individual funds can have. If didn't have the dust limit all of the sudden, well, we would be paying more to store this UTXO entry, rather than what is actually represented there.

Peter McCormack: Okay. Another thing you mentioned in our interview again, which I still didn't fully understand, you talked about eltoo. Can you tell me about that again?

Christian Decker: So eltoo is an alternative for us to make sure that we don't renege on our agreement. So when we open a channel, we put some money on it and then we start negotiating between the two of us, how to split this money. At any point in time we do have valid transaction, that sort of would enforce this agreement between us on-chain.

So if one of us disappears, then you could... If I just go away or I die, then you can take the last transaction that I gave to you and you could go to the Blockchain and say, "Hey, dear Blockchain, this is our latest state. Please give me my money back." Now, since only at this last state, the Blockchain is involved, we might have superseded different versions of the state along the way. So let's say I have an initial state where I've $10 and you have zero.

That means that I have a transaction that gives me $10 and you zero. You have the same as a copy. Then we transfer something and we have $5 and $5. So I have a transaction that gives me $5 and you $5, and you have a copy of that. Now the problem is that if you just go away, then I might be tempted to just use the old one. So which gives me $10 after all.

So we need to have a mechanism for updating this in a way where the Blockchain can judge whether this is the last state or not and the usual way we do this is by having, by the court of the Blockchain, basically opening a trial and saying, "hey, I've heard this from Christian and now you have 24 hours to say your part of the story" and then Blockchain will make this decision, which one is the one to go for.

Now for Lightning, the way we do this, is basically the proof that you show to the Blockchain, is basically stealing all of my funds. So that's what we call a penalty or punishment. Eltoo is a bit different. So with eltoo, this ensuring that only the last state is actually enforceable, is done by you then coming along and saying, "hey, no! We agreed on something different than what Christian just said. Here is a newer state where I get $5 and you can get $5".

What the Blockchain then does, is basically just say, "okay. Peter's is now the latest state that I've seen and I will enforce that." So what we do basically is, my transaction made it in, but the effect of me getting $10 and you getting zero was not activated yet. You have this 24 hours, to show your transaction and now we've ratcheted it up a bit and now we are at the stage where you get $5 and I get $5.

Now I could come along again, but I don't have anything newer and so this will be the state that it's finally settled. So the difference between the penalty mechanism and eltoo is basically that in the penalty mechanism, any old state will result in me getting punished. But you also having to keep in your back pocket, all of the punishments that you might need. Whereas with eltoo, what we do is basically instead of punishing, we override the effects and that can be done in such a way that all you ever need to remember is the last date itself.

So you don't have to keep for the entire history of our interaction. You don't need to have something matching whatever I could do, but you just spray out this information of, "hey, this is the last state" and it will just magically override whatever I did while misbehaving, so to speak.

Peter McCormack: How much of this stuff do you have to consciously think about in using Lightning or are you explaining something that is automated?

Christian Decker: Oh, this should all be automated and it is for the current implementations as well.

Peter McCormack: Yeah, because these things are often explained, as if you and I are making decisions together and I have 24 hours or whatever. Sometimes I think that this is too much to think about for me.

Christian Decker: Oh yeah. I mean that's also something that is often misunderstood is that, I as an operator, need to understand the protocol to have the correct reactions. It's more like I run some software, it watches the Blockchain on my behalf and I don't have to make a conscious effort to maintain the state.

That also comes back when people, say that "yes, but Lightning you have to be online 24/7." That's not exactly true. If you have set the parameters accordingly, you can be offline for a week and then your wallet will check in once a week and make sure that nothing bad happened and it can go back to sleep. So we are automating a lot in the background and you don't actually have to know all of this stuff as well.

Peter McCormack: How much of that is related to watch towers?

Christian Decker: So yeah, watch towers would be one example of software that would automatically check in with the Blockchain and see if something nefarious has happened and would then react automatically. So if you squint at it, watch towers are part of a wallet extracted in a separate process or separate server somewhere. Then there's different models for who operates that server as well. 

So many ideas about how we could implement a watch tower currently revolve around some third party that you give this information to and they would watch the Blockchain on your behalf and then react on your behalf. But it could also be your phone that just basically is a secondary device that can check in every once in a while and see that everything is still good and go to sleep after that again.

Peter McCormack: All right, cool. So, again, you mentioned it before, but I know this is something you've kind of worked on, is channel factories. This seems to be a very important piece to come to Lightning because one of the things I was thinking about is that every time I open a channel, I do have a cost and I don't want to open lots and lots of channels, have lots of channels to manage and lots of on-chain fees to worry about. But channel factories are a potential solution to this?

Christian Decker: So channel factories are an application of something that I like a lot, which is basically that you just have an off-chain contract that involves more than two parties. Basically what happens with Lightning is that the penalty mechanism that we have in Lightning very much limits us to having two parties only, because if some somebody misbehaves, then I need to know who I'm punishing. 

With eltoo or duplex micropayment channels, which is what we talked last time about, which was part of my doctoral work, does away with that limitation. It allows you to have a group of 5 or 10 or 15 people that all manage collaboratively some funds and they can basically do whatever they want with these funds that they collaboratively manage. That includes also creating channels inside of this off-chain contract.

So we could for example, be a golf club and all the members pool their money inside of this golf club and we could then collaboratively decide on how to move or reassign these values between ourselves. Then let's say we are in the same group of people and now we can say, "I don't want to involve the entire group of 20 people every time that we, between the two of us, do a transfer."

So what we do is we create a channel inside of this off-chain contract and we split off some funds that are now collaboratively managed only by the two of us. Then we can transfer back and forth between us and then basically go back to this off-chain contract, settle our agreement in this off-chain contract and this off-chain contract itself could eventually be settled on the Blockchain.

So we can start layering these off-chain contracts in a pretty neat way where we can have a temporary relationship between the two of us or between any pair of parties in this channel factory and just open and close channels between them in any way we want.

Peter McCormack: Are there are any risks within a channel factory of a rogue nefarious person who's part of that? Can they do anything to disrupt the channel factory?

Christian Decker: So yes, that's one of the downsides of having these huge off-chain contracts, is basically that everybody needs to sign off on everything that happens in a channel. So if you have one party that just refuses to sign an update, then you're basically stuck and you need to drop to the Blockchain. So if somebody becomes uncooperative because they... Well, they just drove into lake and their computer just died.

Then we have very little other options than to basically take the last state we agreed on, basically settle that on the Blockchain and then do whatever we want from there. So you can have a short term corruption where this off-chain contract can't proceed anymore, but you can always back out into on-chain transactions again. The important part here is that if we have an off-chain contract between five of our friends and we have created a channel between the two of us and now one of these other parties disappears and becomes unresponsive, then we can drop the the channel factory onto the Blockchain.

 But the channel between the two of us still remains operational because what we do with the settlement of the off-chain contract is basically anchoring our channel between the two of us, on the Blockchain itself. You should probably not open a channel factory with hundreds of people that you don't know if there will be around in 10 seconds time. But if you have reasonable expectation that these people will stick around and sort of sign off on stuff as well, then it's a great way for you to amortize your on-chain costs as well.

Peter McCormack: So it's like a trusted part of the network? You have to trust the people you're creating this channel factory with?

Christian Decker: Yeah, I would say it's a trusted group and that you trust them not to become unresponsive and sort of making your funds unavailable until the channel factory settles. But it's not trusted as in, they can actually steal your money. So it's a different trade off I would say.

Peter McCormack: Okay. The last thing I wanted to ask you about, that seems kind of interesting, is submarine swaps, the Alex Bosworth work. Because what seems interesting about that is, when I wanted to populate my Lightning wallet, I still had to wait for the transaction from my SegWit wallet to my Lightning Wallet to confirm and it took an hour and a half. This is a way of essentially buying Lightning capacity for your wallet by doing a submarine swap for somebody else, right?

Christian Decker: Yep!

Peter McCormack: You'll probably explain it in a much better way than I've asked it!

Christian Decker: Well it depends on how technical we want to go.

Peter McCormack: As little technical as possible!

Christian Decker: So it basically is a two legged process. You have one leg which is on the Lightning network and the other leg which is on the Bitcoin network and it uses the same mechanism that we use for end to end security in Lightning transfers. Namely, I promise to you that you get some funds, if you can give me the result of a riddle.

If you are the party doing the swap with me, then you will basically turn around and send an on-chain payment to me and say, "hey, these funds are yours. If you can tell me the secret to this riddle" and I being the person that initiated this swap, I can then release the secret to you, grabbing my on-chain funds and you can turn back to me and say, "hey, here's the secret. Now give me my off-chain funds." So that's basically the gist of it. It's basically just doing on-chain part of the Lightning network and it works kind of nicely.

Peter McCormack: All right, cool! Well, listen, this is super useful. Is there anything I should've asked you about? Any other cool tech that I should be aware of?

Christian Decker: Oh, there's way too much to describe! We're actually having our specification meeting later today and quite a few things that I definitely want to discuss!

Peter McCormack: What's top of the list for you?

Christian Decker: Top of list for me is definitely the new onion construction, which we've already mentioned last time. But we got some new features with it as well. There is now the proposal by a Pierre-Marie, to do what's called a trampoline payment and that basically is the major issue that we currently have with Lightning, is that every end point needs to have a view of the network in order to find a path from himself to whoever he's trying to pay.

That's sort of burdensome if you run on a mobile phone. You whip out your mobile phone at the point of sale and you will just want to pay, but first needs to download like minute or two minutes of the network and do updates so that can actually find a path. Now with trampoline, what we can do is basically delegate the task of finding a path to somebody in the network. So what we do is we initiate a payment, to some of our neighbours and we know that this neighbour supports this protocol.

So we just need to know our direct neighbourhood and in the payment itself, we encode, "hey, by the way, this is destined for Peter. Now I don't know how to reach it, but I know how to talk to you, so I'll just delegate this pathfinding task to you" and then he will go out and find a path to Peter and perform the payment on my behalf. That's a really cool feature that I definitely want to get in as soon as possible. That and [Inaudible] payments and string payments and rendezvous routing and all of that fun stuff!

Peter McCormack: Well, I think we're probably just going to have to do this every couple of months and just get an update then!

Christian Decker: Oh, absolutely. I'm loving these audiences with the king of Bedford!

Peter McCormack: God do you know what, it's so embarrassing. It's just a joke! It's so embarrassing!

Christian Decker: I'm loving it!

Peter McCormack: Well, let's see. I'm slightly worried about how this is all going to play out. But it'll be all fun. I appreciate your time again Christian. I'm going to get this out in the next couple of days. People really enjoyed the first interview, so I'm sure they'll enjoy this as well. Thank you for coming on again!

Christian Decker: Yeah, thanks so much for having me and let me know if I can help anytime.

Peter McCormack: Yeah. I might just need a hideout at some point.

Christian Decker: Oh, Switzerland is great for hideouts!

Peter McCormack: Well yeah, hiding people and money!

Christian Decker: Yeah, exactly.

Peter McCormack: But listen, take care. Good luck with your meeting later.

Christian Decker: Yeah, see you, bye bye!