Episode 273

Lightning Network – The Road to Scaling Bitcoin

Christian Decker

When the Lightning Network (LN) was conceived in 2015, it was quickly embraced by the Bitcoin community as the way to dramatically scale Bitcoin’s capacity. There was an expectation of LN being available quickly. Instead, development proceed more slowly in the background with different teams contributing to a standard specification. That spec is now almost ready and last year interest and early activity on the LN increased dramatically.

We were joined by Christian Decker, a core engineer at Blockstream, where he works on their LN client. We discussed the history and progression of the LN and what remains on the road to scaling Bitcoin.

Topics discussed in the episode

  • How Christian ended up writing the world’s first PhD on Bitcoin
  • The vision of the Lightning Network
  • How the Lightning Network evolved in the last 4 years
  • Approaching the 1.0 specification
  • The current state of the network
  • Why centralization concerns around hubs are often misguided
  • eltoo and the future of lightning network
  • The case against other chains being better layer 1 networks than Bitcoin

Brian Fabian Crain: Hi, we are here today with Christian Decker. He has been on the podcast before it was actually quite some time ago, maybe around three years three and a half years ago, where we did an episode with him about a paper he had written called duplex payment channel. So if you want to check out that episode that’s number 106 and he’s been working on Bitcoin for a long time. He was the first person to do a PhD about Bitcoin and then he did a bunch of academic papers including this work on payment channels, which was very much related to kind of similar to Lightning in many ways. And then shortly after we did the podcast he joined the Blockstream team and he’s been doing a lot of work on I think primarily Lightning for Blockstream. So we’re excited to have Christian on today and and have a chance to dive into Lightning where I think so much has happened and of course we’ve done a few episodes but actually the mostly in 2015 so long time ago.Thanks so much for coming on Christian.

Christian: Yeah. Thanks so much for having me excited to be back. It’s been a while.

Brian: Yeah, it has been a while. So people should go to the last episode in here this more detail, but maybe we can just briefly recap. So how did you originally get into Bitcoin? And how did you end up doing like the first PhD ever on the topic?

Christian: I was doing a masters in distributed computing and distributed systems back in 2009 and I stumbled over this strange small paper and I thought wait this is interesting. And so I went to the online forums and registered there and and started discussing with people and for a long time it was just just this thing that was in my in the back of my mind and then at some point in 2012, it was about time to to choose a topic for my PhD and I decided that Bitcoin might be worth giving it a shot and since nobody was believing that Bitcoin might still be around and three years time which is the usual time it takes for a PhD to complete I was was careful to make it blockchain and Bitcoin and sort of line up a whole slew of different topics that we might try to look at including scalability and it turns out that yeah, the whole scalability topic was really popular and that’s what I basically did my my entire PhD on, and it ended up being successful in 2016. And I was worried the first PhD about Bitcoin in the world and have been working on that stuff ever since.

Brian: So you said you started the PHD in 2012 though, like working on it?

Christian: Yes

Brian: And already back then you say scalability was kind of a very popular topic?

Christian: I mean it it was among other things one of the parts that I outlined in my pitch to my professor of topics that I wanted to discuss and the scalability topic was very much in mind. We were distributed computing in distributed systems group so scalability quite quickly comes to mind when when you’re talking about this kind of system and from just looking from the outside it was pretty clear that this will not scale to infinite transactions and infinite participants in at least in its current form. That’s also something that we discovered while working on it that yes scaling blockchains is hard. So we ended up sidestepping the entire scalability discussion and going for systems that squeeze more out of the resources that we have and that’s where basically payment channels and duplex micropayment channels and Lightning came from. Basically using the resources that we have in a more efficient way.

Sunny: Very cool. And so the last time you were on the show, you were talking about duplex payment channels and so you were still working on your thesis back then and very soon after that episode you decided to join Blockstream. What made you decide to go join them instead of any of the other companies working the space and how did you shift your work from your duplex work into Lightning specifically?

Christian: the idea to join the Lightning effort an easy one. For duplex market channels I was the sole person pushing for it and there’s little value in having two competing systems splitting users among them. The true utility from such a payment network really comes from there being one big network where every participant can speak to every other participant. So in the splitting the community into smaller parts is not ideal. And secondly, well duplex micro premium channels and Lightning hat have really different trade-offs. I think at the time Lightning had had way better trade-offs than duplex micro premium channels and that that is apparent from from just looking at the unchained footprint that duplex micro channels have compared to Lightning Channels. With duplex market payment channels we had tens of transactions that we needed to settle in a certain period of time whereas in Lightning we just have to settle one transaction. That Lightning is more complex but at the same time it sort of uses the scarce resources a bit more efficient. That is not to say that that we can’t claw back some of the good parts of duplex micropayment channels, and that’s part of what we published last year with this L2 proposal, which maybe we will talk about later.

Sunny: So L2 is sort of like a lot of your duplex work making its way back into Lightning is that a fair way of saying that?

Christian: it’s heavily inspired by the duplex micropayment channel stuff. It is going back one step and looking at how we would structure blockchain if we wanted to have native payment channels on top of it and then basically realizing that the stuff that we just need to change in Bitcoin is really tiny and everything else follows naturally from there and we can get back some of the nice features of a duplex micro-premium channels later.

Brian: So now this is maybe a tricky task but I suspect a lot of listeners are familiar with Lightning on this kind of very abstract level or they certainly have heard of Lightning, but they may not have a good understanding of how it works. Now without going in too much detail here, how do you explain Lightning to somebody who lets say understands Bitcoin well but doesn’t understand Lightning?

Christian: Sure. So a Lightning channel is basically construction of a payment channel and the payment channel is nothing else than a relationship between two endpoints basically deciding on how to settle certain balance. So the usual example I give is that I go to a bar and I put a $10 bill on the counter and as long as this $10 bill is on the counter me and the barista are sure that this $10 bill can’t move, and now it’s all about initially these $10 are mine and then I want to transact with the barista and so we incrementally decide on how to split these ten bucks. So if I buy very cheap beer for one dollar then our agreement is that out of these $10, one dollar is his and nine are mine. Then I buy one more and then basically two dollars are his and eight are mine . Notice that the dollar bill never moves during all of  this. I only give the Barista the assurance that if we were to settle then he would get his two dollars and much of the complicated parts of the protocol are about basically assuring my counterparty that yes, in any possible outcome, he will get his money and I will get mine, and we can’t reneg on what our latest state was. Basically if I promised him $2, then he will get $2 and we can’t go back to a previous state where I had nine and he had only had one. So this is basically just the idea of a channel where we have some funds that are locked up or allocated to our channel and now we discuss repeatedly on how we want to settle these and that’s an old idea that we had for a long time basically already in 2011 we had a unidirectional channel construction which allowed us to send money into this one direction and never receive it back. With the with duplex micropayment channels and the Lightning network suddenly we have a construction where we can send back the money back and forth in both directions in a secure way such that we can always be sure that that we will get what is what is due to us. Now if I open a Channel with a barista I can only interact with that barista, but if we were to create a network of these payment channels and make sure that through a transitive relationship I can reach any other party in the network, then we could basically say I will give you one dollar if you forward this one dollar to the next person in the chain and the next person the chain in the next person in the chain until we eventually reach our intended target and only then we can we have this entire chain of promises that there are then fulfilled. There’s ways to do that but really those are two parts parts of the protocol that make up the Lightning network, the payment channels themselves and this way of sending payments over multiple hops in this network.

Brian: So the original Lightning white paper, I think around four years ago that it came out, so has this idea changed a lot since then, as people work, maybe some of things turned out wrong, or how current is the white paper from back then?

Christian: It’s very much the same and completely different at the same time. I think the the basic ideas are still there, the revolutionary idea of constructing a payment channel and then the way we do in validation of all states is still very much there. What changed is basically a lot of the fine detail in a protocol which was either not in the white paper itself or was later changed because we found more efficient ways to do it. So I think the basic idea that was presented in the white paper is still still valid and is still there. However, the actual implementation and the actual protocol as it is right now, I would probably not try to infer from that from that paper because it’s very light on the details that you need to implement stuff. So for that I would definitely suggest people go and read the specification that we wrote up during the last two and a half years now and while that’s still very technical it’s way more complete than than the white paper.

Sunny: Yeah. I keep up a lot in the plasma world so I can see something very similar there where the original plasma paper from Joseph Poon is very interesting ideas, but very light on the details. And so then that’s where we have all this implementation work still to do and spec work to do. And so I guess when we had this episode with Joseph Poon back in 2015, and then we also had one with Adam Back in 2015 and we were talking about Lightning and he basically mentioned that like, oh, you know Lightning is a couple of months out, so what happened there?

Christian: Yeah that was a very interesting episode. I think one of the things that nobody was expecting is that there was nobody that actually wanted to implement anything in this so Tadge and Joseph basically wrote this paper and then only much later decided to create a company Lightning Labs to actually go ahead and implement this and in the meantime Blockstream had hired Rusty Russell, my colleague who got started on the c-lightning  implementation and only when people showed interest in that only then Joseph and Tadge decided hey that there’s there’s a good way to create a company out of this. So I think that the first part of the answer is that nobody was there to actually start implementing it and there was some hesitation in wanting to create this and the second part is that right from the get-go we had this this desire to create a specification that was implementation agnostic. And so this not just one team that is trying to hack together a client as quickly as possible and taking shortcuts on the protocol side, but this is very much a community effort where we have multiple implementations that try to come up with the most efficient and most clear way to build this protocol and then implement it, so that obviously takes time but there’s a lot of learnings we learned along the way and there was a long experimentation phase before we met in 2016 in Milan for the first spec meeting where we said yes we want to create a cohesive specification and we want to put that effort into actually making this multi implementation network rather than everybody just going their own way.

Sunny: So what was some of the design choices around deciding to go with this multi implementation model instead of everyone kind of focusing their efforts on c-Lightning  and why did we decide to go down this multi implementation route?

Christian: Well, there’s a lot to be learned from from creating multiple implementations. We have we have more people that come in and look at things from a different angle. It also forced us to have this experimentation phase before the Milan meeting where everybody just went their own way and then we came back and merged all of our lessons that we learned along the way and then we threw everything away and then just started with the real specification a semi clean slate and sort of yes, just this. The advantage is basically that we have this very cohesive specification that comes out of it. And the other side is that having a single implementation you have a single implementation tries everything and does nothing well, whereas with the current ecosystem we have Eclair which are very much async with their client Eclair which are very much focused on mobile clients. We have Lightning Labs that are with LND and are very much focused on desktop users and their c-Lightning  which is mostly aiming for power users that sort of need a lot of customizability. And so there’s different different goals we have, and different target audiences, but we still have this interoperability that is given out to us by the specification that is implementation agnostic. It’s also good to have the all of this written down and not in the form of an implementation otherwise, it gets really hard to reason about.

Brian: Right, that’s interesting. I mean we just did an episode with like Jameson Lopp last week where we had some of that discussion around Bitcoin not having a specification and having this single client and I mean I think that sounds like a great path to take. Now you mentioned the specification is that specification finished or is it still something that’s being worked on?

Christian: We’ve been wanting to tag version 1.0 for the last three months. I think it’s not been done so far because there’s always somebody who has an open pull request about spelling but at that is point really the most of the changes that are applied to the version 1.0 are about wording and we hope to be able to tag version 1.0 soon. All of the implementations that have started this process with us have compatibility with version 1.0 and we are already working on features for 1.1. But we’d like to have this version 1.0. out of the gate and be able to concentrate on the next big thing that we might want to build in there. So not yet. But soon as is two weeks.

Brian: Okay, so we had this slow beginning and then the specification work started in 2016 in Milan and now it’s at the point of coming to closure. If you look overall at the history of work on Lightning where has progress been fast and good and what have been maybe some obstacles that ended up taking a lot of time?

Christian: So I think overall the progress has been rather quick and obstacle-free. There have been a few cases where we noticed that our initial Simple Solution wasn’t clever enough. For example, one thing that continuously comes back to haunt us is that we chose to punt on a more complex gossip protocol in which we exchange information about existing channels and existing nodes because we said, okay we want to have a simple version first and then we will revisit that once we have gathered enough information about the situation. This has turned out to be a bit more complicated than we expected simply because the gossip protocol is very chatty, especially on mobile notes. This chattiness is not desirable, but I think other than that most of the stuff went quite okay. I mean between the start of the standardization which was in September 2016 to Blockstream opening the the Blockstream store there was little over a year and we basically had a rewrite of the entire client and so did the other teams so I’m quite happy with the progress we had so far now, there’s quite a few people who say this isn’t going fast enough, but you always have these people right?

Sunny: so could you tell us a little bit about this, you know this roll out phase that happened for Lightning now, so I remember I was in Berlin about last spring and there’s a whole Blockstream store and that was the first time anyone could buy anything with Lightning and use it and the c-Lightning  client came out around the same time. I used that opportunity to buy the shirt I’m wearing from the Blockstream Lightning store. So I was pretty excited I got to be likely the first early users of Lightning. So how is this rollout happened over the past year or so and how have we seen adoption?

Christian: Yeah, so we get asked quite often when is Lightning the network going to launch and my usual reply is it is launched. So we had this very slow and incremental rollout where we basically created the client and got some users on board that were really technical and that just wanted to play with this stuff and before the Blockstream store launched last year we encourage everybody to basically use Testnet and Testnet only in fact, all of our clients are still defaulting to Testnet if you start them today simply because we didn’t want to have people lose their money and sort of lose interest because of that. This was a release early day software after all and we wouldn’t feel comfortable losing user money at that point in time.  Basically we had a group of people that were tech-savvy and there were hacking their way around the clients themselves and were experimenting on Mainnet already and at some point we just decided ‘hey, this is getting ahead of us and yes, we’d like to open a shop where you can actually buy items for real Bitcoins and get that feedback from Mainnet users ourself and gather experiences on Mainnet ourself by operating the store and so in I think it was January 16th we basically published that we have the running version of WooCommerce with a c-Lightning back end and you could actually go ahead and buy stuff and many people did since and it was this slow and incremental rollout where you actually had to know a lot of tech to get to use it and we always accompanied this with this hashtag Reckless, which was there to signify. Hey, by the way, this is Alpha State software. Please don’t use this for any real money just for whatever you feel okay losing if the software is broken, for example, and while we were gathering more and more feedback and we’re fixing more and more books we were also able to increase our confidence into the implementations themself, and so over this time we started making it easier and easier for users to get started on Lightning and this is all part of this slow and incremental rollout that we wanted and it’s been working great so far, so there will not be an official launch date for Lightning Network. It has been launched over a year ago and people have been joining whenever they feel like investing a bit of time and eventually we hope to make it easy enough for just everybody to be able to come and play with it.

Sunny: Are there any known cases of anyone losing any money on Mainnet because of bugs in the software?

Christian: I know that there is one that I cost which is basically we had this the situation where a user of ours reacted to cheat attempt from his counterparty and we ended up with this very strange situation where he got the other person’s money, which is expected. He tried to cheat so I steal his money basically, but he didn’t get his own money back which turns out I forgot to add a field to a database. So I tried to buy him a beer for those 10 euros that he lost and instead he insisted on buying me a beer because he had a lot of fun with playing and while he still lost some money we kept this these limits slow enough that that we could do this sort of, I buy you a beer and we’re sort of even, and now we’ve had a lot of luck with with the community members. Nobody really lost a lot of money and everybody just played along very nicely and this enthusiasm that I just wanted to buy you a beer because I caused the bug that lost you money and he insisting that I should get a beer instead, that is something that is very representative for the feeling in the community currently. It’s very collaborative.

Brian: now I remember in the past one of the concerns that people had about Lightning was that there was the idea you’re going to have these different channels and it’s good if the channel is very powerful, if it’s connected with many. So you’re going to have these hops and then there is this process where okay, I want to pay Sunny but we don’t have a direct channel so we have to go through some route and then that route we generally go through, you know particular hops. And so there was this fear that isn’t Lightening going to be a very centralized network. There’s going to be a few companies that will have these big hops, everyone will go through them. But what are your thoughts first of all on whether or not is a problem or the aspect of decentralization in Lightning and the role of hops?

Christian: so that’s a point that comes up rather often and I often get the feeling that people are scared of centralization, but for the wrong reasons because if we have a participant in a network that a lot of channels open and that has sort of a lot of liquidity in his channels and therefore connects a lot of people in the network then that first of all is a service to the network Itself by by enabling this this multi-hop routing from many points to many other points, it’s first and foremost a downside because suddenly you become a single point of failure if you run this up and that’s the thing that I am worried about with these if the network turns out to be centralized hops gather a lot of responsibility on their shoulders and if they go down then suddenly the network is a lot worse than before. What I don’t think is a big issue and which a lot of people point to is this idea of big hops being being able to the anonymize people and profiling their users we have in the protocol specification itself the an onion routing protocol which allows us to hide the origin and the destination for all the payments we perform in the network. So all a big hop sees is that I got the payment from the left I decrypted and I have my instructions from that packet and I know where to forward it on my right. They don’t learn anything about who the original sender was because he only learns who the next the previous hop from the left was and he will not learn anything about the actual recipient of the payment because all he learned was who the next guy is. It could be the next guy is the recipient but he doesn’t learn anything about that. He doesn’t learn his position in the route, he doesn’t learn how many people are before him or after him.

Brian: Quick question on that. So is this onion routing something that all of the clients do by default or is that something you have to optionally choose if you care about privacy a lot?

Christian: no this is the only way that we currently implement sending coins on the Lightning Network. So if you’re using the Lightning Network you are using the onion routing protocol and even if you have a direct connection to your our recipient he will not learn that you are the original sender. So we decided to to make the onion routing mandatory exactly because if it’s an opt-in feature, then people might might not know that they should use it or they might opt out from using it because crypto is hard. So by making it mandatory, every client has to implement it and every client will use it for every single payment there is and this creates a bigger set of users in which an individual user can hide in. But what I was saying is the central hop will not learn a lot about you unless your only connection is going to be the hop because then you can’t say hey, I got this from some guy that sent it to me, but they will know that it’s you, which is why we encourage people to actually open multiple connections at least to have this plausible deniability that yeah, I’m not the original sender, I received it from some other guy further down the line. So the hop doesn’t learn a lot a lot about privacy information but it does concentrate a lot of connections on it and it represents a single point of failure, which is what I care about. There are reasons for helps to emerge and there’s reasons for hops not to emerge. Maybe we can go into that later if you if you want to.

Sunny: So with this onion routing is it like Ture where we select a bunch of extra random nodes to also send to as part of our path or do we just take the most efficient path route that we can find but the nodes along that route don’t know who the other participants are?

Christian: Yes, so the the structure is very similar with the two exceptions, one is that in Ture you can actually select any participants in the network to be the next hop in your route. This is not possible in Lightning. In Lightning the hops have to match the actual channels existing so if I only have a channel open to you, then I can’t go around you and then send back to you. So our onion routing hops have to coincide with actual channels existing and as for your question about whether we choose always the most efficient route, we do randomize routes in such a way that if there is a shortest route from point A to B, we might not use that exactly because that might leak information about who the original sender and who the original recipient is. We randomize inside of bounds however, so we will select select routes that are up to a certain percentage worse than the optimal route.

Sunny: And I guess that leads into the next question, one of the most common questions we often hear around like Lightning is this question of routing and how we can make this efficient and does this mean we need global routing cables etc. Could you address some of the concerns there and are they valid, is it something that is yet to be figured out?

Christian: Sure, so the the current routing protocol is basically source based routing. So what we do is we create we gossip among the nodes about which channels exist and which nodes exist. We exchange messages that basically say, hey there’s a channel between me and Brian, there is a channel between me and Sunny, and by gossiping we incrementally learn about which channels are in there and so we create our local view of the network and based on this local view we can then select a route from A to B without involving any third party. That has the huge advantage that we basically don’t tell anybody who the who the endpoints are, so we can do routing decisions locally, but it has a downside where we actually have to maintain this local view of the network. There is a few different constructions that are under consideration or were under consideration for how we can improve this to be more efficient and these usually come down to landmark base and and who based routing. So both of these basically say there is some very prominent nodes in the network that everybody knows how to get to and how to get from them and let’s just meet at this very well known location in network and I will tell you how to route from that point to me and you know how to create the first half of this route and then we can collaboratively construct this this route. This has the downside of needing these well known points in a network and how we select these is not that clear yet, but currently everybody knows the internet work seems to be working well and Rusty had a few numbers, I think that up to million channels we should be able to sort of squeeze that in a few hundred mix of data. So not a huge problem right now. It’s actually a luxury problem if we get there and I guess we’ll cross that bridge once we’re there. One thing that we might add here is that not all channels and not all nodes are public, so we tend to announce channels that might be used for routing for other people but if we are just an end device that is a client to the rest of the network then we will not allow announce them, and that is something that the Eclair wallet does, it doesn’t announce its its channels to the wider public because they’re running on a mobile phone and they might not be stable enough to actually guarantee that they are there when users want to route through them. The way we handle those is basically we add some information into invoices so that I say I’d like to be paid $10 by you and here’s how you can reach me. Basically just giving them what’s called a route end to tell them ‘Hey, there’s a channel you might might want to use if you want to pay me; and  there is this this very well connected and public core network that routes payments from everybody to everybody else, and then there is this this auxiliary network of devices that come online and go offline very quickly and are not as reliable and they represent the endpoints of users that do not want to route but just want to use this network as as a client.

Brian: I would love to dive in a little bit to the economics of Lightning Network. So in particular, in writing Bitcoin the amount of fees you pay tends to be based on the size of the transaction. So the size in terms of the data not in terms of the value. Now in Lightning, because you’re using up some Bitcoin door locked this is different and it’s going to be proportional to the amount transferred. Is that correct? Or are there other determines that will influence transaction fees.

Christian: So the reason why we use weight-based fees and Bitcoin is basically because the the contended resource in this case is the block space. And so users that should that use more of it should pay more. Basically that’s the rationale behind it. In Lightning it’s the contented resources channel capacity. So if I have a $10 channel open with you and I send $9 over then I basically unbalanced my channel in such a way that any future payments that I might want to pay through that channel are are at the disadvantage. So what we do is we have this we have a proportional fee that basically is denominated in 1/millionth of Satoshi / Satoshi and so the minimum fee you can have is 0 or 1 millionth of a Satoshi for every Satoshi transferred. So the scarce resource here is the capacity that we have in these channels themselves.

Brian: Do you have any idea how these fees are going to develop once the network’s live. So you mentioned, this is minimum default of 1 millionth of a Satoshi. Is it going to be that the more transactions take place the lower the fees will be or how do you think it’s going to play out?

Christian: So my expectation is that the more transactions we have the more balanced these channels become simply because of us moving away from it. Balance channel is a random event and sort of any transaction that modifies that balance is a random two-dimensional random walk on that event. So my expectation is that fees will be minimal and and be just there to compensate people for the capital expenditure they had to create this channel. So if I have if I have $100 I have a choice of investing that in stock or I can forego that option and create a channel instead. So there is some cost to operating a node and that cost should be compensated by users taking advantage of this cost. I don’t think that there will be big hops that can leverage higher fees because it’s very easy to create alternative routes around these hops and and be just a little bit less than than the huge fees and so you create this race to the bottom for people that want to leverage high fees, and we’d like to actually encourage people to look for these kinds of strategic positions where they can open a channel and just undercut the hop as long as the capital expenditure is still covered by the fees they may collect. So I guess we will go to a fee level that is very minimal and just covers the capital expense you have for opening the channel.

Brian: There’s a lot of one of the interesting topics currently, especially in Ethereum, there is this decentralized finance or, DeFi trend right now, and a lot of things that are taken under this umbrella, things like Maker where you can put up Ether and then you can get out some stablecoin. And there’s generally a perception there and I think it’s a correct perception that there’s going to be a lot of ways to actually use crypto and earn money whether that’s that you can stake it or maybe you can use it as some sort of security bond or you’ll be able to lend it and now presumably that’s also going to happen in Bitcoin where you can maybe lend Bitcoin and they have different ways of earning some money on it. Do you think that’s also one way to think about Lightning, maybe I is a normal Bitcoin user down the line in two years I’ll be able to say, I take a Bitcoin or take 5 Bitcoins, I put it in some Lightning channels, now it’s use is routing payment and I make maybe 3% a year or 4% a year in terms of earning more Bitcoin for basically providing that capital there.

Christian: I don’t think Lightning channels are a good investment at all. It’s basically just if you look at it from an investment side and you want to leverage higher fees, you’re basically creating this island of high fees around you and people that are happy to maybe only take 2.5% will position himself right next to you and sort of undercut you. I think these should mostly be thought of as amortization for your own investment, for your own needs when as a user of the of the Lightning Network. They’re probably not a great business model to make money so if I make regular user of the Lightning Network and I want to reduce my fee expenses for payments that I perform then I can route payments for other people and all the feasts that I gather I can then spend on my own expenses in the lighting Network. So it’s more of an amortization of fees that I incur as a user rather than I put some money in there and then I pull it out again and then suddenly it’s been multiplied.

Brian: So recently there was this guy Andreas Brekken and he was operating lots of Lightning channels. And I think it was around 50% of all of the Bitcoin in the Lightning  Network at one point. And of course Lightning is very early so it’s may be dangerous to extrapolate from his experience to what is Lightning going to look like when it’s kind of really functional, really being used, but I mean,  I guess that was one of two takeaways that he did write it all of those payments and he made a fraction of a dollar. Are there any other interesting takeaways or lessons that you felt like I was kind of learned by people like him that are operating Lightning  channels today, in terms of how it’s going to play out once there is real adoption?

Christian: I guess Andreas’ experiment was really early on and probably you’re right that extrapolating from his experiences is not really feasible. But only recently there has been a huge operator of Lightning  nodes called ellenberg.com, which has opened a lot of high-volume channel to a lot of people in the network and they recently published an article about how many transaction fees they have gathered and how many I think they also expose how many transactions they have forwarded and it turns out they didn’t make a lot of money from it. Now that could be that they’re not positioning themselves as well or that the the sort of fee structure they had is a suboptimal. But I think that sort of adds more credibility to the fees will not be gigantic, again these players could increase their local setting for fees, but that also decreases the probability of people actually routing through them and I think this is 2 separate experiences – the distance of half a year that show that the fees are not really there to be made, and people find their cheap ways to route in the Lightning Network.

Sunny: Another question I have about routing is, a few months ago I was talking to Zooko Wilcox about some Lightning  stuff and one of the points he brought up to me was that he believes that there’s a griefing attack possible where you can send payments yourself and cause a lot of people along the route to lock up some capital and then you suddenly decide to not send any payments and you never have to pay any fees for this and so you could just keep dossing the Lightning  Network and causing people to do lockups and then just failing the transaction. So is this a legitimate concern or is this an addressed issue?

Christian: it is definitely a concern that we have. It’s possible to lock up funds for certain periods of times. If you do it too long, then your channel will shut down which is going to cost you some money, but for minutes or hours at a time, it’s actually possible to lock up funds. It’s something that that we are hoping to address by adding fees outside of the transferred amount. So whether or not a payment succeeds there is a fee involved, but as it stands currently, it’s not it’s not been addressed.

Sunny: How would that payment, outside of the payment amount fee, be done? How would that happen technically?

Christian: So the reason why this griefing attack is free currently is that basically what we do is we include the fee in the transfer itself, meaning that if the transfer fails then the fees will get rolled back as well. So that turns out it enables number of nasty things, one is the griefing attack and the other one is is basically free probing of the network by sending payments that do not match an invoice that is to be paid. However, the solution that we propose is basically to have this fee should flow whether the transaction succeeds or not. So basically what we currently do is if I want to send 9 Satoshis to Brian through Sunny then I will send 10 to you with the promise, I will send to you if you send the 9 onwards to Brian and if the last thop doesn’t succeed you don’t get any anything. You don’t get your 1 Satoshi in fees, and the solution that we are considering is basically that I will send you 9 Satoshis and those 9 Satoshis you will get when you forward them to Brian. So that’s an out-of-band fee that allows us to force people to pay something whether or not this payment succeeds or not.

Brian: So let’s say Sunny get some fee anyway, but he gets a larger fee in case he actually routes the payment or otherwise, what’s the incentive?

Christian: So my example was flawed because I started with 10 and 9 and didn’t have any room to split that 1. But yes, of course it should be 11 and 1 you get up front and 10 you get when the routing completes and then the 10th he only gets when routing the 9 onwards.

Brian: That does sound like a pretty clean solution. Let’s speak a little bit about the technical roadmap for Lightning . You mentioned briefly L2, which is an upgrade proposal that you worked on and published I think last April. Can you talk a little bit about what L2 would mean for Lightning .

Christian: L2 is sort of the 2.0 future and what we’re currently working on is 1.1. So L2 is a new construction of payment channels that is much simpler and reconnects infact to the duplex micropayment channel idea. I say 2.0 because we actually require a change to the Bitcoin scripting language called SIGHASH NOINPUT which looks like we might get eventually. I’m not really good at making predictions when it comes to that ever since the second activation. And once we have SIGHASH NOINPUT, we can actually build L2 which is this simpler construction which we basically can say, okay, my current state is, if we go back to the barista, is you get 2 and I get 8 and then we update a couple of times and then we have 5 and 5. And we can forget all the states we have before which is currently not possible with Lightning . In Lightning we have to keep part of the state for all our previous states so we can react in a correct way to whatever our counterparty might do, In L2 we have this last state which basically trumps everything that has ever been before and allows us to override whatever our counterparty might do with just keeping the latest state.

Sunny:  Dan Robinson and Olaoluwa who have a bet I believe going on that whether SIGHASH NOINPUT will be in by 2021.

Christian: Roasbeef also has another construction which is interesting which is a CHECK_SIG_FROM_STACK. That also is a soft fork and we might end up with two competing proposals again and then hash it out which one is the cleaner and which one is the more flexible one. But yeah there’s quite a few things we can do and hopefully SIGHASH NOINPUT is less controversial than some other stuff that has come before and I’m pretty sure it is because I wrote a proposal and it’s seriously like three lines of code. It’s really simple.

Brian: You also mentioned multi-party channels. What are those and how would they change the Lightning  Network?

Christian: Yes so the current construction basically is, with Lightning channels we have only two party channels meaning that I can only trade my coins with one other person and we have to settle our state among ourselves. This is due to the construction of Lightning  which basically means that for every state that the counterparty might publish I need to have this reaction ready. So if we add more than one counterparty suddenly we have this this explosion of possible misbehaviors, and we have to keep track of a lot of state. With L2 having the last state basically trump everything that came before it, we don’t need to have a custom-tailored reaction to whatever our counterparties do and this also means that we suddenly don’t care anymore about which counterparty misbehaves, we can just use our trump card which is the latest state and just override whatever happened in between. So all of a sudden it becomes possible for us 3 on the chat basically have 1 shared channel and we can freely move move funds from anybody to anybody else on the same channel. And we have constructions where we can go to 15 or 15 or once we have schnorr signatures we can go to arbitrary number of participants. And that basically means that we de-emphasized a bit the reliance on multi-hop payments because if I am in a group that moves funds around often between its own participants, we don’t need to leave the boundaries of our single channel, but we can adjust balances just by us. So if we go back to this example where we 3 now have have 1 channel open and I put $10 in and you both have 0 in that, I can decide to send 9 to Sunny and 1 to Brian and basically our latest state is 0 for me, 1 for Brian and 9 for Sunny. And if we want to send back any of this money we can do so without ever involving some other channel in the wider network. This creates a whole lot of interesting scenarios. We suddenly can not only transfer Bitcoins, but we might be able to transfer unique assets among ourselves because one of the principal assumptions in the Lightning network is that it doesn’t matter which coins you get exactly, all coins are fungible so if I send 1 Bitcoin to Sunny and Sunny forwards it to you, then the coin that you receive is not the one that I sent, whereas in a multi-party channel we can actually handle unique assets among ourselves so I can actually send you 1 Bitcoin and the 1 that is going to arrive on your balance is going to be the same Bitcoin that I sent. And so if you were to, for example, create CryptoKitties on 1 gigantic payment channel, we could actually send these unique assets among ourselves without ever involving the blockchain, without ever involving any party outside of the channel itself.

Sunny: 2 of the features I read about a little bit which was an interesting to me, one of them was this idea that you could do a comic multi-channel send. So let’s say I have 5 channels of 2 Bitcoin each but I’m trying to send 10 Bitcoin. I can somehow have a system in which I can atomically send all of them. Is this something that’s implemented right now or is this a future upgrade?

Christian: So that’s that’s part of the the 1.1 push that we started in November during our second spec meeting. This basically gave us a chance to pull up all the features that we thought about but didn’t want to have in the first version because that would have postponed the release of of the spec itself. So now we dug up all of the nice features that we thought about that we know are possible right now, but haven’t been spec’d yet. And one of these is indeed the the atomic multi-part payment and as you said it allows us to basically bundle the capacity of multiple of our channels to perform one big payment instead of being limited by the capacity of our biggest channel.

Sunny: And the other one I was interested was splicing, can you maybe describe that and is that also in this 1.1 spec?

Christian: Oh definitely, splicing basically is an idea I had during the first spec meeting and it basically allows us to close the channel and reopen it in the same transaction and add new funds to it or move funds out of the channel without the channel ever becoming unavailable. So the idea here is basically that if we have a channel and it’s really unbalanced and you own all the funds, but I want to use this channel to send you some money, then I can basically take some other coins I have lying around on-chain, we can agree to perform a splice and I can add these funds during this close and open operation to the channel balances. So that allows us to move funds from on-chain into channels that already exists and the channel remains operational while we do so. The counterpart to this is what we call a splice out which basically allows us to, say I have a lot of Bitcoins on my side and I’d like to, for example, perform and on-chain payment then we agree to perform a splice out and part of this close and reopen transaction is that part of the funds that were owned by me will go to a new output which is then destined for my on-chain payment recipient. And these 2 proposals, the multi-part payment and the splicing, are part of a wider initiative where we try to hide many of the technical details of the Lightning Network in such a way that it becomes more intuitive for users to use Lightning , because what multi-part payment allows us to do is not care anymore about how we allocated funds to a channel. If I have 10 x 1 Bitcoin channels or have 1 x 10 Bitcoin Channels, it doesn’t make any difference for me because I can bundle the capacity of multiple channels, so I don’t care about channels anymore and the splice in and splice out proposal basically removes this barrier between on-chain funds and off-chain funds. All of a sudden my off-chain funds that are allocated to a Lightning  Channel, I can still use to make on-chain payments. So the ultimate goal for us is to basically create a wallet that displays 1 balance to you and that basically contains both your on-chain balance as well as your off-chain balance and have channels be handled automatically in the background, removing this complex issue of having to explain to your users what channel is and how to best open and create and how to allocate them and all of these thorny details that users currently have to deal with.

Brian: That sounds really fantastic. Actually I think that was always a little bit of a concern I had, how do you manage these channels if there are too many funds in there and now you want to take some out again, you have to close the channel, but that sounds like a very clean way of managing that.

Christian: Yes, it’s still early days and so all of these technical details are really hard to explain to users which is why we currently concentrate mostly on tech savvy users that want to dig into the technical details and that have time to dedicate to researching these issues and these topics, but the end goal really is to create a software that takes care of all of these details for you and all you have to care about is basically do I have enough money to buy my coffee, whether that’s on-chain or off-chain, that should all be handled in the background without you ever having to learn about it. If you want to that’s great, but you shouldn’t have to.

Sunny: So I haven’t done too much Bitcoin development, but I’ve done that a couple of payment channel implementations on Ethereum and on the Cosmos SDK, and so one of the questions I have is how much of the complexity of Lightning development is coming from limitations in the Bitcoin state machine and also look the statefulness of other systems seems to also add a lot of additional functionality, so there’s a proposal called Sprites channels, which makes it easier to close defunct routes. I think it’s easier to make much more powerful watchtowers and stuff. So even when it comes to Bitcoin, what is the benefit of deploying a Lightning  Network on the main chain versus for example, creating a side chain to Bitcoin and deploying the Lightning Network there where that sidechain may have more stateful capabilities.

Christian: So regarding your second point, why deploy on the Bitcoin main chain, basically our users are there, that’s where people get the most utility from and that’s where we want to use it ourself. Adding side chains is great to add special functionality that you can’t do in Bitcoin or that we haven’t figured out how to do in Bitcoin itself just yet but it’s a hurdle to get users on board. Whereas Bitcoin if you already have Bitcoin you can use lighting right now. As for the the need for statefulness and the need for more advanced smart contracts, we find time and time again that it turns out that we can backport a lot of stuff that comes from the state channels and the Ethereum community into Bitcoin, maybe in a bit more complex way, but we can often do without the added complexity of actually running a stateful chain such as Ethereum. One of these examples is that I gave a lecture in Stanford last year after publishing L2 and just before the lecture itself I was challenged to see if I could implement L2 in solidity and it turns out it’s something that we can do in 20 lines of code and the code actually looks a lot like Raiden, so suddenly we had this very roundabout way of creating something that was made for Ethereum and backported into Bitcoin itself without all the additional cost and the heaviness that comes with Ethereum. I’m not going to make a lot of friends by saying this but I consider Ethereum a great test net for Bitcoin.

Sunny: Yes, that makes sense. I was really thinking what my vision would be. I really want to see a special side chain that’s designed for Lightning  and state channel networks just be deployed as soft worked in as an official drive chain to Bitcoin, where it’s whole purpose is designed to be a Lightning  Network and it could be in a semi official capacity and hopefully UX can hide a lot of that away, just like you mentioned you’re trying to hide a lot of the complexity away from the users anyway, so hopefully that special drive chain can also be hidden away from users as well.

Christian: I wouldn’t actually be sure that a special side chain would be more suited for payment channels than Bitcoin itself, simply because the way we came up with L2 is by taking a step back and looking at what sort of minimal set of features that we need from a blockchain to create a blockchain that is purpose-built for payment channels, and it turns out this the difference between this idealized payment channel enabling blockchain and the currently deployed Bitcoin network is really just this one SIGHASH. So I’m not sure I could come up with a with a side chain or a drive chain that is better suited for payment channels then Bitcoin with SIGHASH NOINPUT for example. And this sort of convergence between Ethereum where you actually have all of the flexibility and where people have come up with Raiden and L2 which comes from this more constrained version of a blockchain where we don’t have all of this flexibility and we still have very much the same result, is for me very much a proof of that  this this is the functionality we need, we don’t need more.

Brian: So before we wrap up, briefly look out a little bit. When people were writing these 2018 reviews, Lightning  was often coming up and they were saying Lightning has seen a lot of development, there is real progress, there’s more momentum building and now you have 2 million dollars or something like that worth of Bitcoins are held in Lightning  channels. So what’s your expectation about where it will be a year from now. Will we see real traction with people using Lightning for payment or what do you think is kind of the timeline that Lightning adoption will take?

Christian: I should probably preface this by saying that I’m really bad at making predictions and I’m always amazed about how quickly all of this has materialized. I would not have expected to have 20,000 channels and 600 Bitcoins in the Lightning  Network at this point. It’s been a very frightening ride, but also a very self-affirming ride for me so far and as for predictions, I would probably guess it’s more of the same. I’m hoping the network will continue to grow at the current pace. It doesn’t have to accelerate in my opinion and I would love to see some real-world adoption with some games coming out with some with some merchants accepting Lightning, just go back to this use of Bitcoin as a currency and opening up new use cases as we go along. On the spec side I can probably speculate a bit more. We have this 1.1 roadmap which we are currently implementing and hopefully we will be able to say in the next year or so that that we accomplished every single point of that and now need a new meeting to fix the next road map. That’s probably all I can say when when it comes to a prediction. As I said, I’m not really good at that.

Brian: Christian thanks so much for coming on, it was real pleasure to catch up on Lightning. I think it is certainly something that excites me a lot to see how this is going to play out. Let’s keep following it and I’m sure it’s not the last episode about Lightning  that we’ve done here.

Christian: No problem, pleasure being here.


  • Microsoft Azure

    Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks. More at aka.ms/epicenter.
  • Toptal

    Simplify your hiring process & access the best blockchain talent
. Get a $1,000 credit on your first hire at toptal.com/epicenter.

0:00:00 | -:--:--

Subcribe to the podcast

New episodes every Tuesday