Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Christian Decker: Lightning Network – The Road to Scaling Bitcoin

Episode Date: February 7, 2019

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 covered in this 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 Episode links: Lightning Network Whitepaper Christian Decker - Scaling Bitcoin with Duplex Micropayment Channels Joseph Poon & Tadge Dryja - Scalability and the Lightning Network Blockstream - Lightning Network A Simplified Update Mechanism for Lightning and Off-Chain Contracts Lightning Network Specifications on Github Thank you to our sponsors for their support: Simplify your hiring process & access the best blockchain talent . Get a $1,000 credit on your first hire at toptal.com/epicenter. Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks. More at aka.ms/epicenter. This episode is hosted by Brian Fabian Crain and Sunny Aggarwal. Show notes and listening options: epicenter.tv/273

This is Epicenter, Episode 273 with guest Christian Decker. This episode of Epicenter is brought you by TopTal. Experience a new way of hiring as TopTal delivers only the top 3% of applicants, including highly skilled blockchain engineers. If you're looking to scale your team with the very best talent, visit TopTal.com slash Epicenter. And by Microsoft Azure. Do you have an idea for a blockchain app but are worried about the time and costs it will take to develop?

The new Azure blockchain dev kit is a free download that brings together the tools you need to get your first app running in less than 30 minutes. Learn more at aka.m.s. slash epicenter. Hi, and welcome to Epicenter. My name is Ryan Farman-Krain. And my name is Sunny Otherall. So we're here today with Christian Decker. He's been on the podcast before and we're going to speak a lot about the Lightning Network. So this is really exciting. I think one of the things when we did our kind of, kind of, recap of the last year that I brought up is, oh, I really want to do more Bitcoin episodes. It seems to be, it's just more momentum there and so many interesting things happening.

And we have been sort of undercovering Bitcoin. So I'm really glad that now we've, we've done another Bitcoin episode. Two in a row, in fact. Two in a row. Yes, yes. Yeah, we were joking before the episode. Maybe we have to put the Bitcoin back in the name. But no.

Yeah. So I'm, I feel very excited about Bitcoin. and I thought it was a great conversation to learn a bit about lightning. Yeah, definitely. You know, lightning is such a big project, and, you know, we haven't actually done a lightning episode on Epicenter since, like, 2015. So this is really good because it's not a lot of updates on the status and development, and so really great episode.

So you mentioned you also have some announcements to me. You're going to give a talk tomorrow? Yeah, so there's a panel in Berkeley being held by Blockchain at Berkeley in order, an organization I used to be part of. It's called Blockchain for Social Impact. And so it should be a very interesting panel talking with a bunch of different people, some people from the Open Money Initiative

who are going to be there talking a lot about, you know, Venezuela and stuff. But it should just overall be a really interesting panel. It's going to be tomorrow, or I guess this episode is coming out tomorrow, today on the 6th, February 6th in Berkeley, California. And if you can't make it out, you know, the recording will be available

and we'll probably tweet it out from our epicenter Twitter account. Cool. And then let's go to the conversation with Christian. Hi, we're here today with Christian Decker. He has been on the podcast before. It was actually quite some time ago, I think around three years, three and a half years ago, where we did an episode with him about a paper he had written called the Duplex Payment Channel. So if you want to check out that episode, that's number 106.

So, 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, you know, very much related to, or kind of similar to Lightning in many ways. And then Christian joined shortly after he 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 yeah, we're excited to have Christian on today and and to have a chance to dive into Lightning where I think so much has happened. And of course, yeah, we've done a few

episodes, but actually we're mostly in 2015. So a long time ago. So yeah, thanks so much for coming on, Christian. Yeah, thanks so much for having me. Excited to be back. It's been a while. Yeah, it has been a while. So people should go to the last episode and hear 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? I was doing a master in distributed computing and distributed systems back in 2009 and I stumbled over this strange small paper and I thought, wait, this is this is interesting. And so I went to the online firms and registered there and and started discussing with people and for a long time it was just sort of this thing that was in

the back of my mind. And then at some point in 2012, it was about time 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 in three years' time, which is the usual time it takes for a PhD to complete. I 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 and including scalability. And it turns out that yeah, the whole scalability topic was really popular and that's what I basically did my entire PhD on. And it ended up being a... being successful in 2016 and I was awarded the first PhD in about Bitcoin in the world.

And yeah, I've been working on that stuff ever since. So you said you started the PhD in 2012 though, like working on it. Yeah. And already back then, you say scalability was kind of a very popular topic. Oh yeah, I mean it was a, it was a much, among other things, one of the parts that I outlined and sort of my pitch to my professor of topics that I wanted to discuss. The scalability topic was very much in mind.

It is, I mean, we were distributed computing and distributed systems group. So scalability quite quickly comes to mind when you're talking about this kind of system. And from just, 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 and that's also something that we that we discovered while working on it that yeah scaling scaling blockchains is hard so yeah we ended up

sort of sidestepping the entire scalability discussion and 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. Very cool. And so the last time you were on the show, you were on talking about duplex payment channels. And so you were still working on your thesis back then. And so and then, you know, very soon after that episode, you decided to join Blockstream.

How did, you know, what made you decide to go join them and like, instead of like, you know, met any of the other companies working in the space. And how did you shift your work from your duplex work into Lightning specifically? The idea to join the lightning effort was pretty, pretty an easy one. I mean, for Duplex Market Permin channels, I was sort of the sole. pushing for it and there's little value in having two competing systems, sort of 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, right? So splitting the, splitting the community into smaller parts is not ideal.

And secondly, there are, well, duplex micropayment channels and lighteners, and lighten had have really different trade-offs, I think at the time, Lightning had had way better trade-offs than Duplex Market Appraignment channels. And that is apparent from just looking at sort of the on-chain footprint that Duplex Market Appearment channels have compared to Lightning channels. With Duplex Market Appearment channels, we had tens of transactions that we needed to settle in a certain period of time, whereas in Lightning, we just have to set up. one transaction. That is, so 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 we can't claw back some of the good parts of duplex market payment channels, and that's part of what we published last year with this L2 proposal, which maybe we'll talk about later. So, like, you know, L2 is sort of like a lot of your duplex work kind of like making its way back into lightning. Is that a fair way of saying that? It's heavily inspired by the duplex micropayment channel stuff, yes. It sort of 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, yeah, the stuff that we just need to change in Bitcoin is really tiny. and sort of everything else followed naturally from there. And we sort of can get back some of the nice features of duplex microcone channels with L2 then later. So now this is maybe a tricky task, but I think I suspect a lot of listeners are familiar with lightning on this kind of very abstract level. They certainly have heard of lightning, but they may not have a good understanding of how it works. Now, without going into too much detail here, like how do you explain lightning to somebody who, let's say understands Bitcoin well, but doesn't understand lightning? Sure, yeah.

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 a certain balance. So the usual example I give is that I go. 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 basically, we 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 10 bucks. So if I buy a very cheap beer for, $1, then sort of our agreement is that out of these $10, $1 is his and nine are mine. And then I buy one more and then basically $2 are his and $8 are mine. Notice that the dollar bill never moves during all of this, all of this. I only give the Borisi assurance that if I were to, if we were to settle, then he would get his $2.

And much of the complicated parts of the protocol are about basically assuring my counterparty that, yes, if nothing goes, if in any possible outcome, he will get his money and I will get mine. And that we can't sort of renege 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 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 sort of an old idea that we had for a long time, basically already in 2020. 2011 we had the Spielmann unidirectional channel construction,

which allowed us to sort of send money into this one direction and never receive it back. With the with duplex market payment channels and the lightning network, suddenly we have a construction where we can send money back and forth in both directions in a secure way such that we can always be sure that we'll get our, what is due to us. Now, with lightning, lightning is the first part. The network part is the second part, right? 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, hey, I will give you $1 if you forward this $1 to the next person in the chain and the next person in the chain and the next person in the chain until we eventually reach our intended target. And only then we have this entire chain of promises that there are then fulfilled. There's ways to do that. But really, those are two 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. So the lightning white paper, the original lightning right, it was, I think around four years ago that it was, it came out. So has this idea changed a lot since then? You know, as people work, maybe some of things turned out wrong or like, how current is the white paper from back? then. It's very much the same and completely different at the same time. I think that the basic ideas are still there. The revolutionary idea of constructing a payment channel and then sort of the way we do invalidation of all states is still very much there. What changed is basically a lot of the fine detail in that in that protocol, which was either not in the white paper itself or was later changed because, well, we found more efficient ways to do it.

So I think the basic idea that was presented in the white paper is 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 paper because it's very light on the sort of 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 the white paper. Yeah, I do a lot of like implement, you know, I keep up a lot with like the plasma world. So, you know, I, I, I, I can see something very similar there where the original plasma paper from Joseph Poon is like, you know, very interesting ideas, but very light on the details.

And so then that's where like, you know, we have all this implementation work still to do and spec work to do. So very cool. And so, you know, I guess when we had this episode with Joseph Poon and Tadge back in 2015 and then we also had one with Adam Back in 2015, and he was, you know, we were talking about lightning. and he basically mentioned that like, oh, you know, lightning is a couple months out, four or five months out. And so what happened there? Yeah, so 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 Tadj 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 sea lightning implementation. And only when people sort of showed interest in that, only then Joseph and Tatch decided, hey, there's a good way to create, create a company out of this. So I think the first part of the answer is that nobody was there to sort of actually start implementing it and sort of 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 sort of implementation agnostic. And so this is not just one team that is trying to hack together a client as quickly as possible and sort of 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 lot of, there was a lot along experimentation phase before we met in 2016 in Milan for the first spec meeting where we said, okay, yes, we want to. We want to create a cohesive specification. And we want to make, we want to put that effort into actually make this multi-implementation network.

rather than everybody just going their own way. So what was some of the design choices around, like, you know, deciding to go with this multi-implementation model instead of, like, you know, everyone kind of focusing their efforts on sea lightning. And why did we decide to go down this multi-implementation route? Well, there's a lot to be learned from sort of creating multiple implementations, right? We have more people that come in and look at things from a different angle.

It also forced us to have this experimental phase before the Milan meeting where everybody just went their own way. And then we came back and sort of 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, sort of a semi-clean slate and sort of, yes, just this, the advantage is basically that we have this very cohesive sort of specification that comes out of it. And the other side is that having a single implementation sort of, you have a single implementation that sort of tries everything and does nothing well. Whereas with the current ecosystem, we have Eklare, which are very much async with their client,

Eclare, which are very much focused on mobile clients. We have Lightning Labs that are with their LND are very much focused on desktop users, and there's 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 to us by the specification that is implementation agnostic. It's also good to have all of this written down and not in the form of an implementation. Otherwise, it gets really hard to reason about. Right. That's interesting. I mean, we just said we did an episode with like James and Law. I think last week, right, where we had some of that discussion around, you know, Bitcoin not having a

specification, right, and having this kind of, you know, single client. And I mean, it certainly, yeah, 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? 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 this point, really, 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 sort of have started this process with us have compatibility with version 1.0

and we are all already working on features for 1.1, but we'd like to have this version 1.0 out of the gate and sort of be able to concentrate on the next big thing that we might want to build in there. So not yet, but as the same goes as two weeks. Hiring is stressful. Let's face it, it's a long process of sifting through resumes and interviewing candidates without any guarantee of quality.

But it doesn't have to be. this way. Companies all over the place are experiencing a new way of hiring with TopTal. If you go to their trust pilot page, you'll see that of the hundreds of people that have left reviews, over 98% were four or five-star ratings, including one guy who wants to give his developer a bear hug. That says a lot. TopTal gets all this great feedback because they focus on their clients, and their top priority is quality. They only accept the top 3% of applicants, including highly skilled blockchain engineers. One of these engineers is Rodak Astrovsky. Roddock has experience as a lead software engineer and data scientists for Sony and Expedia.

Then he discovered blockchain and he became totally consumed with Ethereum. He worked as a consultant for the firm StartOnChain and his time-locked app won the TopCorder Consensus Uport and Identity Blockchain Hackathon. Then he expanded his reach through TopTal. He worked with a bunch of clients on projects such as smart contract development and a POC that leverages blockchain. If you want to hire engineers like Rodak for your team, go to TopTal.com. slash epicenter for a no-risk trial. A TopTile director of engineering will deliver your next hire in as fast as 48 hours,

and you'll get a thousand dollar credit when you decide to hire. We'd like to thank TopTal for their support of Epicenter. Okay, so we had like this slow beginning and then the specification work started in 2016, in Milan, and now is kind of at the point of coming into a 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? 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 clear.

clever enough. For example, one thing that continuously comes back to haunt us is that we chose to sort of punt on a more complex gossip protocol in which we exchange information about existing channels and existing nodes. Because we wanted to, we said, okay, we want to have a simple version first, and then we will revisit that once we have, once we have gathered enough information about this. the situation. This has turned out to be a bit more complicated than we expected, simply because the gossip protocol is very chatty. And especially on mobile notes, this chattyness is not desirable. But I think other than that, most of the stuff went quite okay. I mean, between the start of the start of the standardization which was in September 2016 to bus block stream opening the the block stream 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 So could you tell us a little bit about this, you know, this rollout phase that happened for lightning now? So I remember, you know, I was in Berlin about like, you know, last spring and, you know, there was a whole Blockstream store. And that was like, you know, the first time anyone could buy anything with Lightning and like use it. And, you know, the Sea 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, you know, excited.

I got to be one of like the first early users of Lightning. So how is this rollout happened over the past couple, past a year or so, and how have we seen like adoption? Yeah. So we get, we get asked quite often when is lightning in the network going to launch. And my usual reply is it is launched. So we had this very slow and incremental rollout where we, we basically created the client and sort of 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 encouraged 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 really 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 that were sort of hacking their way around the clients themselves and we're sort of experimenting on Mainnet already. And at some point, we just decided, hey, this is sort of getting ahead of us. And yes, we'd like to open a shop where you can actually buy items for real Bitcoins and sort of get that feedback from Mainnet users ourselves and sort of get a gallows.

and sort of get gather experiences on Mainnet ourselves 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 lightning, with a sea lightning backend. And you could actually go ahead and buy stuff like you did, for example. And many other people did since. and it was sort of this slow and incremental rollout where you actually had to know a lot of tech in order to get to get to use it. And we always accompanied this with this sort of hashtag reckless, which was there to signify, hey, by the way, this is alpha state software. please don't use this for any sort of real money just for just for what every year feel okay losing if the software is broken for example and while we were while we were gathering more and more feedback and

we're fixing more and more bugs we sort of were also able to increase our confidence into the implementations themselves 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 roll-up 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. Are there any known cases of anyone losing any money on Maidenet because of bugs in the software?

I know that there is one that I cost, which is basically we had this situation where a user of ours was reacted to a cheat attempt from his counterparty. And we ended up with this very strange situation where he got the other person's money, which is what is expected, right? 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 while playing. And while he still lost some money, we kept these limits slow enough that we could do this sort of,

I buy you a beer and we're sort of even, right? And no, we've had a lot of luck with the community members. Nobody really lost a lot of money. and everybody just played along very nicely and sort of this enthusiasm that I just wanted to sort of buy your beer because I caused the buck that lost you money and he insisting that I should get a beer instead.

That's something that this happens that is very sort of representative for the feeling in the community currently. It's very collaborative. Now, I remember in the past one of the concerns that people had about lightning was that there was the idea, okay, you're going to have these different channels, and it's good if you, a channel is very powerful, if it's connected with many, right? So you're going to have these hubs. And then there's this process where, okay, I want to pay Sunny, but we don't have a direct channel, right? So we have to go through some route. And then that route would generally go through, you know, particular, you know, particular. particular hubs. And so there was this fear that, okay, isn't lightning going to be a very centralized network. There's going to be a few companies that will, you know, have these big hubs. Everyone will go through them. But what are your thoughts, first of all, on whether or not this is a problem

or the aspect of decentralization in lightning and kind of the role of hubs? Yeah. 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 has 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 enabling this multi-hop routing from many points to many other points. And it's first and foremost a downside because, well, suddenly you become a single point of failure if you run this hub, right? And that's the thing that I'm worried about in with these, if the network turns out to be centralized hubs sort of gather a lot of, 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 hubs being able to de-anonomize people and sort of profiling their users. We have in the protocol specification itself, we have an onion writing protocol which allows us to sort of hide the origin and the destination for all the payments we perform in the network. So all Big Hub sees is that, okay, 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 center was because, well, he only learns who the previous hop from the left was. And he will not learn anything about the actual recipient of the payment because, well, all he learned was who the next guy is.

It could be the next guy is a recipient, but, well, 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. Quick question on that. So is this onion routing? That's something that like all of the clients do by default, or is that something you kind of have to, you know, optionally choose if you care about privacy a lot?

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, to your recipient, he will not learn that, you are the original sender. So this is, we decided to make the onion routing mandatory

exactly because if it's an opt-in feature, then people might not know that they should use it or they might opt out from using it because, well, 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 this creates a bigger set of users in which we in which is an individual user can hide in so but what i was saying is that the so the the the central

hub will not learn a lot about you unless you your only connection is going to be the hub because well 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 hub doesn't learn 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's reasons for hubs to emerge, and there's reasons for hubs not to emerge. Maybe we can go into that later if you want to. This episode of Epicenter is brought to by Microsoft and the Azure Blockchain Workbench.

Getting your blockchain from the whiteboard to production can be a big undertaking. And something as simple as connecting your blockchain to IoT devices or existing, AARP systems is a project in itself. Well, the folks at Microsoft had you covered. You already know about the Azure blockchain workbench and how easy it makes bootstrapping your blockchain network

pre-configured with all the cloud services you need for your enterprise app. Their new development kit is the IFTTTT for blockchains. Suppose you want to collect data from someone in a remote location via SMS and have that data packaged in a transaction for your HyperLedger Fabric blockchain. The development kit allows you to build this integration in just a few steps in a simple drag-and-drop interface. Here's another great example. Perhaps you're an institution working with Ethereum

and rely on CSV files sent by email. One click in the DevKit and you can parse these files and have the data embedded in transactions. Whatever you're working with, the Devkit can read, transform, and act on the data. To learn more and to build your first application in less than 30 minutes, visit AKA.ms. And be sure to follow them on Twitter

at MSFT blockchain. We'd like to thank Microsoft and Azure for their supportive epicenter. So with this onion routing, so does it like similar to how in Tor, do we like select a bunch of extra random nodes to also send to like is part of our path? Or do we just like, you know, take the most efficient path route that we can find? But the nodes along that route don't know who the other participants are. Yes. So the structure is very similar with the two exceptions. One is that in Tor, you can actually select any participants in the network to be the next hop in your route.

This is not possible 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 sort of go around you, 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, 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's original recipient is. We randomized inside of bounds, however. So we will select routes that are up to a certain percentage worse than the optimal route. I see. And I guess that kind of leads into the next question.

One of the most common questions you 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 tables and stuff. So could you like maybe like, you know, address some of the like concerns there and are they valid? Is it something that like, you know, like you yet to be figured out or yeah. Sure.

So the current routing protocol is basically source based routing. So what we do is we create, we gossip among the notes 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 Sonny. 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 you basically don't tell anybody. who the endpoints are, but it has the downside that we need, so we can do routing decisions locally, but it has the downside that we actually have to maintain this local view of the network. There is a few different constructions where we, that are under consideration or we're under consideration for how we can improve this to be more efficient.

And these usually come down to land-based landmark based and rendezvous based routing. So both of these basically say, hey, there's some very prominent notes in the network that everybody sort of knows how to get to and how to get from them. And let's just meet at this very well-known location 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 route. This has the downside of creating these, of needing these well-known points in a network and how we select these is not that clear yet. But currently the sort of everybody knows the entire network seems to be working well. And Rusty had a few numbers. I think that up to a million channels,

we should be able to see. sort of squeeze that in a few hundred mecks 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. That is to be said, 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 sort of is a client to the rest of the network, then we will not announce them. And that is something that the Eclare wallet does. It doesn't announce its channels to the wider public because, well, 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.

And the way we handle this. those is basically we add some information into invoices so that I say, hey, I'd like to be paid 10 bucks by you and here's how you can reach me. Basically, just giving them a what's called a route hint to tell them, hey, there's a channel you might want to use if you want to pay me. And sort of there is this very well-connected and public core network that routes payments from everybody to everybody else. And then there is this auxiliary network of devices that come online and go offline very quickly and are now that's reliable and they sort of represent the endpoints of users that do not

want to route but just want to use this network as a client. Great. I would love to die in a little bit the sort of the economics of Lightning Network. So in particular, in Bitcoin, the amount of fees you pay, you know, tends to be based on the size of the transaction. So the size in terms of the data, you know, not in terms of value. Now in Lightning, right, because you're using up some Bitcoin that are locked, this is different and it's going to be proportional to the amount of transfer.

Is that correct? or are there like other determinants that will influence transaction fees? So the reason why we use we use weight-based fees in Bitcoin is basically because the contended resource in this case is the block space, right? 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 resource is channel capacity. So if I have a $10 channel open with you and I send nine over, then I basically unbalanced my channel in such a way that, well, any future payments that I might want to pay through that channel are at the disadvantage. So what we do is we have this, we have a proportional fee that basically is denominated a millionth of Satoshi per Satoshi.

and so the minimum fee you can have is zero or one millionth of a Satoshi for every Satoshi transferred. Yeah, so the scarce resource here is the capacity that we have in these channels themselves. Do you have any idea how these fees are going to develop once, you know, the network's life? So you mentioned, okay, there's this minimum default of one 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 this is going to play out? So my expectation is that the more transactions we have, the more balance these channels become simply because of us sort of moving away from it.

Balance channel is a random event. And sort of any transaction that modifies that balance is sort of a two-dimensional random walk on that event. So my expectation is that fees will be minimal and sort of be just there to compensate people for the capital expenditure they had to create this channel. So if I have $100, I have a choice of investing that in stock, or I can forego that option and create a change. channel instead. So there is some cost to operating a node and that cost should be compensated by

users taking advantage of this of this cost. I don't think that there will be there will be big hubs that can leverage higher fees because it's very easy to create alternative routes around these hubs and sort of be just a little bit less than than the huge fees. And so you create this race to the bottom for people that leverage that leverage 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 sort of just undercut the hub as long as the capital expenditure is not 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. So let's say now in the future, right, there are a lot of sort of one of the interesting topics currently, especially in Ethereum, right, is this decentralized finance or defy kind of trend, right? There are a lot of things that are taken under this umbrella, you know, things like Maker where you can put up ether and then you can get

out some stable coin. And so there's generally a perception there and I think it's a correct perception that, you know, there's going to be a lot of ways to actually use crypto and like earn money, whether that's like, you can stake it or maybe you can use it at some sort of security bond or, you know, you'll be able to lend it. Now, presumably that's also going to happen in Bitcoin, right, where you can maybe lend Bitcoin and, you know, they have different ways of earning some money on it. Do you think that's also one way to think about lightning? Maybe I as a normal Bitcoin users, you know, down the line in two years or something, I'll be able to say, okay, I take my, I take a Bitcoin or take five Bitcoins.

I put it in some Lightning channels. Now it's routing payments. And I make like, I don't know, 3% a year or 4% a year in terms of, you know, earning more Bitcoin for basically providing that capital there. 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 fees should mostly be thought of as amortization for your own investment or your own needs as a user of the Lightning Network.

They're probably not a great business model to make money. So if I'm a regular user of the Lightning Network and I want to sort of reduce my fee expenses for payment, that I perform, then I can route payments for other people and every all the fees that I gather, I can then spend on on my own expenses in the Lightning 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. So recently there was this guy, Andreas Brecken, I think. And, you know, he was operating lots of lightning channels.

And yeah, I think it was around 50% of all of the Bitcoin in the Lightning network at one point. And now, of course, lightning is very early and there's, you know, there's no will. So it's maybe dangerous to extrapolate from his experience to like what is Lightning going to look like when it's kind of really functional really being used. But I mean, I think, I guess that was one of the takeaways that, you know, he readed all of those people. payments and he made like a fraction of a dollar. Are there any other kind of 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?

I guess, I guess Andreas Breckin's experiment was really early on and probably you're right that extrapolating from from his experience is not, it's not really feasible. But only recently there has been a huge operator of lightning notes called lnbig.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 so well or that 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, right? 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, yeah, this is sort of two separate experiences at a distance of half a year that show that the fees are not really there to be made. and people find the cheap ways to route in the lightning network. So another question I have about routing is a few months ago I was talking to Zucco, 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 to 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 know, you never have to pay any fees for this or anything. And so, you know, and you could just keep dossing the Lightning Network and causing people to do lockups and then just like failing the transaction. So is this a legitimate concern or is this like an addressed issue? 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 certainly possible to lock up funds. It's something 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 been addressed. How would that outside of the payment amount, like fee payment be done? Like, how would that happen technically? So the reason why this griefing attack is free currently is that basically what we do is we include the fee in the, in the transfer itself, meaning that if the transfer fails, and the fees will get rolled back as well.

So that turns out it enables a number of nasty things. One is the griefing attack and the other one 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 be should flow whether or not the success the transaction succeeds or not so basically what we what we currently do is if i want if i want to send uh nine satoshes to uh to brian through sonny then i will send ten to you uh with a prom i will promise ten to you if you send the nine onwards to brian uh and if that if the

the last top doesn't succeed, you don't get anything, right? You don't get your one Satoshi in fees. And the solution that we are considering is basically that I will send you one Satoshi. I will send you nine Satoshes and those nine Satoshes you will get when you forward them to Brian. So that's sort of an out-of-band fee that allows us to have that to force people to pay something whether or not this this payment succeeds or not so would you hear make it so that you know let's say sunny sunny gets some fee anyway but he gets a larger fee in case he actually

routes the payment or otherwise what's the incentive to to yeah so so my example was flawed because i started with 10 and 9 and didn't have any room to split that one. But yes, of course, it would be, it should be 11, one you get up front and 10 you get when the routing completes and then sort of the 10th he only gets when writing the 9 onwards. That does sound like a pretty clean solution. Well, let's speak a little bit about sort of the technical roadmap for Lightning. So we mentioned briefly L2, which is a kind of a proposal, 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?

Yeah, so 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, in fact, to the duplex micropayment channel idea. I say 2.0 because we actually require a change to the Bitcoin scripting language called Ccash, no input, which looks like we might get eventually. I'm not really good at making predictions when it comes to that ever since Seguid activation. And once we have Ccash no input, we can actually build L2, which is this, which is this simpler construction, which we basically can say, okay, my current state is,

is if we go back to the barista, my current state is you get two and I get eight. And then we update a couple of times and then we have five and five. And we can forget all the states we had before, which is currently not possible with Lightning. Where in Lightning, we have to keep part of the state for all 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. Yeah, Dan Robinson and Laloo have a bet, I believe, going on that whether SIGHash, no input will be in by 2021. Oh, man, yeah. Roseby also has another construction, which is interesting, which is CzechSig from Stack. That also is a soft fork and we might end up compete with two competing proposals again and then sort of 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 Sikash no input 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. You also mentioned multi-party channels. What are those? And how would they change the Lightning Network? Yeah. So the current construction basically is with the 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 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 corner parties do. And this also means that we suddenly have, 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 the sudden it becomes possible for us three on the on the on the on the on the on the chat basically have one shared channel and we can freely move move funds from anybody to anybody else on the same channel so and we have constructions where we can go to 15 or 15 or once we have once we have schnor signatures we can we can go to arbitrary number of of participants And that basically means that we de-emphasize 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 three now have one channel open and I put $10 in, And you both have zero in that. I can decide to send nine to Sunny and one to Brian. And basically our latest state is zero for me, one for Brian and nine 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. And this creates a whole lot of interest interesting scenarios we can do, we suddenly can we can suddenly no long, not only transfer Bitcoins, but we might be able to transfer unique assets among ourselves. Because one of the 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 one Bitcoin to Sonny and Sonny forwards it to you, then

then the coin that you receive is not the one that I sent, right? Whereas in a multi-party channel, we can actually handle unique assets among ourselves. So I can actually send you one Bitcoin, and the one that is going to arrive on your balance is going to be the same Bitcoin that I send. And so if you were to, for example, create crypto-kitties on one 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. Two of the features I've, you know, I read about a little bit, which sounded interesting to me,

were one of them was this idea that you could do atomic multi-channel sense. So let's say I have like, you know, five channels of two 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. And so either make the full payment or not. Is this something that's implemented right now, or is this like a future upgrade? Yeah. So that's part of the one point one 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, well, that would have postponed the release of the spec itself. So now we dug up all of the nice features that we thought about and that we know are possible right now, but haven't been spec yet. And one of these is indeed the atomic multi-party payment, the multipart 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, basically. And the other one I was interested was splicing, which can you maybe describe that? And is that also in this like 1.1 spec? Oh, definitely.

Splicing basically is an idea I had a few during the first spec meeting. and it basically allows us to close the channel and reopen it in the same transaction and sort of add new funds to it or move funds out of the channel without the channel ever becoming unavoid unavailable. So the idea here is basically that if we have a channel and it's really on balance 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 exist and the channel remains operational while we do so. And the counterpart to this is what we call a splice out, which basically allows us to, I have a lot of bitcoins on my side and I'd like to, for

example, perform an 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 own chain, on-chain payment recipient. And these two proposals, the multi-part payment and the splicing are part of a wider initiative where we try to sort of hide many of the technical details of the lightning network in such a way that it becomes more intuitive for users to to use lightning because what what multi-party payment basically allows us is multi-part payment i should say allows us to do is not care anymore about about how we allocated funds to a channel.

If I have 10-1-bitcoins channels or I have 10-bit-coin channel, it doesn't make any difference for me, because I have this, 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. because all of the sudden my off-chain funds that are allocated to a lightning channel, I can still use to make online on-chain payments.

So the ultimate goal for us is to basically create a wallet that displays one balance to you, whether there, 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, sort of removing this sort of 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.

That sounds really fantastic. Actually, I think that was always a little bit my concern I had. You know, so, okay, how do you manage this channel? So now you have just 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. Yeah, it's, I mean, it's, 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, that sort of want to dig into the technical details and that have time to, to dedicate to researching these issues and these topics.

But the end goal, it 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 or do I have enough channels, 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. So I'll say this. I haven't done too much Bitcoin development, but I've done a couple of payment channel implementations on Ethereum and on the Cosmos SDK. And so one of the things, the questions I have is like how much of the complexity of, you know, lightning development is

coming from like limitations in the Bitcoin state machine. And like for my and like, like, you know, also like the statefulness of like other systems seems to like also add a lot of additional functionality where you can do, you know, there's a, there's a proposal called Sprites, which makes it easier to close like defunct routes. There's a, you know, I think it's easier to make much more powerful watch towers and stuff. So even when it comes to Bitcoin, what, 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 side chain may have more stateful capabilities? Yeah. So regarding the second point,

why deployed on the Bitcoin main chain is, well, basically, our users are there. That's where people get the most usability, the most utility from, and that's where we want to use it ourselves, right? 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, right? Whereas Bitcoin, if you already have Bitcoin, you can use Lightning right now. As for 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 come 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 like 20 lines of code. And the code actually looks a lot like Raiden.

So suddenly we have this very roundabout way of creating something that was made for Ethereum and backported into Bitcoin itself without all the additional cost and sort of 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. Yes, that makes sense. Like, you know, I was just really thinking that, you know, I really, how I see like, you know, what my vision would be like 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 merge mind chain to an official drive chain to Bitcoin that's you know its whole purpose is designed to be a lightning network and you know it can be in a semi-official capacity and you know hopefully ux can kind of like you know, 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 be hit. That complex can also be hidden away from users as well.

I wouldn't actually be sure that a special side chain would be more suited for payment channels than Bitcoin itself, simply because when the way I came up with or we came up, with L2 is by taking by taking a step back and looking at what what sort of the minimal set of features that we need from a blockchain to make to to to create a blockchain that is purpose built for payment channels and it turns out this the the difference between this idealized payment channel enabling blockchain and the currently deployed Bitcoin network is really just this one C-cash. So I'm not sure I could come up with a with a side chain or drive chain that is better suited for payment channels than Bitcoin with Secahsno input, for example. And this this sort of convergence between Ethereum, where you actually have all of the, all of the flexibility and where you have 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, yeah, this is the functionality we need. We don't need more. So let's wrap up and, well, before we wrap up, briefly look out a little bit. Now, I think currently, when people were writing these sort of 2018 reviews, you know, lightning was often coming up and say, okay, lightning has seen a lot of development, you know, there's really progress, there's more momentum building. And now you have, you know, $2 million or something like that that are held worth of Bitcoin. They're held in Lightning channels. So what's your, you know, what's your expectation about where we'll be a year from now, you know, at the, you know, what kind of will we see, you know, real traction with people using lightning for payment or what do you think is kind of the timeline that lightning adoption will take?

I should probably preface this by saying that I'm really bad in making predictions. And I'm always 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 sort of self-affirming right 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 I would love to see some real-world adoption with some games coming out, with some merchants accepting lightning, with some, yeah, just give back to this use of Bitcoin as a currency and

sort of opening up new use cases as we go along. On the spec side, I can probably speculate a bit more. We have this, we have this one point one roadmap which we are currently implementing and and hopefully we will we will be able to to say in the next year or so that that we accomplished every single point of that and then that we now need a new meeting to to fix the next roadmap but yeah that's that's probably all i can say when when it comes to predictions i'm as i said i'm not really good at that Cool. Well, Christian, thanks so much for coming on. It was a real pleasure to catching up on Lightning. I think it is certainly something that excites me a lot to see how this is going to play out. And yeah, so let's keep following it. And I'm sure it's not the last episode about Lightning that we've done here.

Thanks so much. Sure. No problem. Pleasure being here. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, the guest or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes.

It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.