This is epicenter episode 273 with guest Christian Decker. This episode of epicenter is brought to you by top-down experience. A new way of firing has topped out delivers only the top, three percent of applicants, including highly skilled blocked and Engineers. If you're looking to scale your team with a very best talent visit top.com / epicenter, and by Microsoft Azure, do you have an idea for a blockchain at but are worried about the time and cost? We'll take 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.ms/offweb the center. Hi, and welcome to episode of my name is Ryan. Faran crane, my name is Sonia Agarwal. 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 recap of last year that I brought out with all I really want to do more Bitcoin episodes, the seems to be, it's just more momentum there. And so many interesting things happening and we have been sort of under covering Bitcoins. I'm really glad that. Now we've done another Bitcoin episode and two in a row. In fact, two in a row. Yes. Yes, yeah.
Joking. Before the episode maybe have to put the big comeback in name but no. Yeah. So I'm I feel very excited about Bitcoin and if 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 got a lot of updates on the status and development and so really great episode.
So you mentioned, you also have some announcements, may you going to give it talk tomorrow. Yeah. So there's a panel in Berkeley being held by block tonight Berkeley in order old and 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, we're going to be there talking a lot about, you
know, Venezuela and stuff. But should just overall be really interesting panel to Tomorrow, or I guess if this episode 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 will probably tweet it out from our epicenter, Twitter account, cool. And then let's go to the conversation with question.
Hi. We heard today with Christian Decker, he has been on the podcast before it was actually quite some time ago think about 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. So and 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 what kind of similar to lightning in many ways and then Christian joint shortly after we did the podcast, he joined the block stream team and he's been doing a lot of work on. I think, primarily lightning for Block stream.
So we're excited that question on today and and 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 they're mostly in 2015 so long time ago. So yeah, thanks so much for coming on kitchen. 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 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 error 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've I went to the online firms and research there and, and start discussing with people, and for a long time, it was just just sort of 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 Thing 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 set to make it blockchain and Bitcoin and sort of line up a whole slew of different topics that we might try to bring it to look at and including scalability.
And it turns out that. Yeah, the the whole scalability topic was really popular and that's what I basically did my my entire page. Jion and it ended up being being successful in 2016 and I was I was worried the first PhD in about Bitcoin and world and yeah, been working on that stuff ever since. So, you said you started the PHD in 2012 though like working on it. Yeah. And and already back, then you say, scale, Goldie was kind of a very popular topic.
Oh yeah. I mean it, it was among other things, one of the parts that I outlined in sort of my pitch to my professor, that I want of topics that I wanted to discuss the scalability topic was very much in mind. It is. I mean, we were distributed computing in distributed systems group. So scalability quite quickly comes to mind.
When 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. And that's also something that we, that we discovered while working on it that yes, scaling scaling blockchains is hard.
So, Yeah, we we ended up sort of sidestepping the entire scalability to 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 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, we you were on talking about duplex payment channels and so you were still working on your thesis back then. So. And then, you know, very soon after that episode, you decided to join block stream. How do you know what made you decide to go join them and like, instead of like, you know, any of the other companies working 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 and easy one. I mean for duplex Market premium channels, I was sort of sort of the sole person pushing for it and there's little value in in having two competing systems sort of splitting users among them the true utility from from such a payment Network come. There really comes from there, being one, big Network where everybody every participant can speak to every other purchase.
And right. So splitting, the splitting the community into into smaller. Parts is not not ideal. And secondly, they're there. Well, duplex my criminal and channels and lightning hat have really different trade-offs. I think at the time lightning had had way better trade-offs than duplex America premium channels. And that, that is a parent from from just looking at sort of the unchain footprint. That Smoked ham and channels have compared to a lightning Channels with duplex
micropayment 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 is so lightning is more complex but at the same time it 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 Mark Fuhrman channels, and that's part of what what we published last year with this L to proposal, which maybe we will talk about later. So like, you know, L2 is sort of like a lot of your duplex were kind of, like, making its way back into lightning. Is that a fair way of saying that it's heavily inspired by by the duplex micro conventional stuff?
Yes, it's 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 And sort of everything else followed naturally from there and we sort of can get back some of the nice features of a duplex microphone Channels with able to them 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, or they certainly have heard of lightning. But they may not have a good understanding of how it works now. Going into too much detail here like how you explain lightning to somebody who lets say understands Bitcoin? Well, but doesn't understand lightning.
Sure. Yeah, so like liking channels, 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 ten dollar bill on the counter and as long as this ten-dollar bill is on the counter me and the Barista, basically, we Worried that this ten-dollar bill can't move. And now it's it's all about initially.
These ten dollars that are mine and then I want to transact with the Barista and so we we incrementally decide on on how to split these ten bucks. So if I buy very cheap beer for one dollar, then sort of our agreement, is that out of these? $10 $1 is his and nine are mine. Then I buy one more and then I'm basically two dollars or his and eight are mine. Notice that the dollar bill never moves.
During all of this, all of this, I only give the Barista the assurance that if I were to, if we were to settle, then he would get his two dollars and much of the much of the complicated parts of the protocol are are about basically assuring my
counterparty that. Yes. If, if nothing goes, if in any case 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, what our latest state was basically, if I, if I promised him two dollars, then he will get two dollars 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 this and that's that sort of an old idea that we had for a long time. Basically already in 2011 we had the the Spielman a unidirectional Channel construction, which allowed us to sort of send money into this one direction and never never receive it back. With the with duplex, Mark payment channels and the lightning Network subtle.
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, we can always be sure that that will get our what is, what is due to us. Now with lightning lightning is the first part. The network part is a second
part, right? If I, if I open a Channel with the Barista can only interact with that Barista, but if, 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, a party in the network. Then we could basically say, hey I will give you one dollar if you forward this one dollar to the next person in the chain.
And next person the chain in the next person, in the chain, until we eventually reach our the or intended target and Only then we can we have this entire chain of promises that there are them fulfilled, there's ways to do that. But really those are those are two parts parts of the protocol that make up the lightning Network, the payment channels themself. And this way of sending payments over multiple hops in this network, So the lightning white paper. I'd original lightning, right?
We were so, I think around for years ago, that was, it came out. So, has this idea changed a lot since then, you know, as 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 the, the basic ideas are still there. The Revolutionary idea of constructing a payment Channel and then sort of had the way we do in validation of all states
is still very much there. What, what, what changed is basically, a lot of the fine detail in that. In a protocol, which was even 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 and 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 it's very light on the DD, act 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 than the white paper. Yeah, I do a lot of, like, Implement, you know, I keep up a lot like the plasma world.
So I can see something very similar there where the Original plasma paper from Joseph. Bun is like, you know, very interesting idea is the 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 tags 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 Couple months out for five months out, and so what happened there? Yeah. So that was a very interesting episode.
I think one of the, one of the things that nobody was expecting is that there was nobody that actually wanted to implement anything in this, so attached. 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, blog stream, had hired Rusty, Russell, my, my colleague who got started on the, on the see lightning implementation and only when people sort of showed interest in that only then Joseph and and attach decided, hey that there's, there's there's a good way to create a company out of this.
So I I think that the first part of the answer is that nobody was there to sort of actually start implementing it and sort of the was some hesitation in wanting to create this. And the second part is that right from the get-go. We had this this this desire to create a specification that was sort of implementation agnostic. And so this is this is not just one team that is trying to hack together. Other 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 that try to come up with the most efficient. And most clear way to build this this protocol and then implement it so that obviously takes time but there's there's a lot of learnings we learned along the way and there was a lot of experience there was All along, experimentation phase before we met in 2016 and 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 see lightning. And why did we decide to go down this multi implementation route?
Well, there's there's a lot to be learned from from sort of creating multiple, implementations, right? We have, we have more people that come in and look at things from it, are from a different. And angle it also forced us to have this experimentation phase before the Milan meeting where everybody just went their own way. And then sort of, 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 real specification sort of a semi clean slate and sort of yes Justice. Just this and the advantage is basically that we that we have this, 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, we have a clear, which are very much a sink with their client. There 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 their see lightning, which is mostly for aiming for power users. That, that sort of need a lot of customization customizability and so, there's different different goals we have different Target audiences, but we still have this
interoperability. A tea that gives that is given out to us by the, by the specification. That is implementation agnostic. It's also good to have the all of this written down and not in for, 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 Jameson law, but I think last week where we had some of that discussion around, you know, Bitcoin not having a specification, right in having this kind of, you know, single client. And I mean, it certainly. Yeah, I think that sounds, that sounds like a great a 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 who has an open pull requests about spelling. But that is point, really, the most of the changes that are applied to the version 1.0 are are about wording and we we hope to be able to tag version 1.0 soon.
All of the implementations that sort of Started at this, this process with us, half compatibility with version 1.0 and we are already working on on features for 1.1, but we'd like to have this version 1.0. I would 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 soon as his 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 top. Tell if you go to their trustpilot 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 bear hug That says a lot top, dog, gets all this great feedback because they focus on their clients. And their top priority is
quality. They only accept the top three percent of applicants including highly skilled blockchain Engineers. One of these Engineers is Roddick, ostrowski Roddick has experience as a lead software, engineer and data scientists for Sony and Expedia, then he discovered blockchain, and he became totally consumed with
etherium. He worked as a consultant for the firm start on chain and is time-lock tap when the top quarter consensus you Port an identity blockchain hackathon, then he expanded his reach through top towel. 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 Roddick for your team, go to top towel.com epicenter for a no risk trial a top tile.
Director of engineering will deliver your next higher in as fast as 48 hours and you'll get a thousand dollar credit when you decide to hire. We'd like to thank top towel for their support of epicenter. Okay. So we had like this slow beginning and then the specification work started in 2016 and Milan. And now it's kind of 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. So I think overall the the progress has been has been rather quick and and obstacle free. There have been a few cases where we noticed that our initial Simple Solution wasn't clever enough.
For example, one one thing that continuously comes back to haunt us is that we chose to sort of Punt on a more complex It's gossip protocol, in which we exchange information about Channel, 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 the situation, this has turned out to be a bit more complicated than we
expected. Simply because the gossip protocol is a very chatty. And especially on mobile nodes.
This, this chattiness is not desirable, but I think other than that, Most of the stuff went, went quite okay, with, I mean between between the between the start of the standardization which was in September. 2016 2 bus block stream opening the the blocks Jimmy store there was little over a year and we basically had a rewrite of the entire client and so that the other teams, so I'm 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 roll out 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's a whole block stream store and that was like, you know, the first time anyone could buy anything with lightning and like use it.
And you know, the see lightning client came out around the same time. I use that opportunity to buy the shirt. I'm wearing From the Block stream lightning store. So I was pretty excited. I got to be one of like the first early users of lightning. So, how is you know, the Roll out happened over the past couple of past year or so and how every scene like adoption. Yeah, so we get, we get asked quite a lot quite often when is lightning the network going to launch and my usual usual reply.
Is it is launched. So, we had this, we had this very slow and incremental rollout, where we basically created the client and sort of got some users on board, that, that were really Technical, and that just wanted to play. Stuff. And before, before the blocks Cream Store launched last year, we encourage everybody to basically use test net and testing it only. In fact, all of our clients are still defaulting to test net.
If you start them today, simply because we didn't, we didn't want to, to have people lose their money and sort of lose interest. Because of that, this is, this was a release early days software after all and We wouldn't feel comfortable losing user money at that point in time. It basically we had a group of people that were tech-savvy and there were sort of hacking their way around the clients himself and we're sort of experimenting
on Main and already. And at some point we just decided, hey, this is this is sort of, this is sort of getting ahead of us and yes, we'd like to open we'd like to going to shop where you can actually buy items for real Bitcoins and sort of get that feedback from Maine that users are self and sort of get gov experiences on Magnet or self 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 see lightning back end. And you could actually go ahead and buy stuff like you did, for example, and many other people did. And it was sort of this slow and incremental rollout where you actually have to know a lot of a lot of tech in order to get to get to use it. And we always accompanied this with the, with this sort of hashtag Reckless, which was, was
there to signify? Hey, by the way, this is Alpha State software. Please don't use this for any cut 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 books, we sort of we're 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 will know will not be an official launch date for lightning Network. It has been launched over a year ago and people have been joining whenever whenever I 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 made neck because of bugs in the
software? I know that there is one that I cost which is basically we had this, the 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 this these limits low enough that we could do this sort of of I buy you a beer and we're sort of even, right? 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 sort of this into the fousey azzam that I just wanted to sort of buy you a beer, because I caused the buck that lost you money and he insisting that I should get a beer instead that would do. 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 two different channels and it's good if you channels very powerful if it's connected with many, right? So you have you're going to have these hubs and then there is this process where okay I want to pay sunny but we don't have a directional right?
So we have to go through some some route and then that route you generally go through, you know, particular. Bigger hubs. And so there was this fear that okay is enlightening, any be a very centralized Network. There's going to be a few companies that will, you know, have these big hubs, everyone will go to them. Well, what are your thoughts? First of all on whether or not this is a problem, the aspect of decentralization in lightning and kind of the role of hubs. Yeah.
So that's 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's that. First of all, is a service to the to the network Itself. By by enabling this, this multi-hop routing from many points to many other points. Its first and foremost a downside because well, suddenly You become a single point of failure, if you run this up,
right? And that's, that's the thing, that that I am worried about in, with these, if the network turns out to be centralized Hub, 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 lot lot, worse than them before, but I don't think Is a big issue and, which a lot of people point to is this idea of big hubs being being able to the anonymize people and sort of profiling, their users, we have
in the in the protocol. Specification itself, we have the an onion routing protocol, which allows allows us to sort of hide the origin and the destination for for all the payments we perform in the network. All a 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 sender was because well 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, 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 road. 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 this is the only way that we currently Implement sending coins on the lightning Network. If you're using the lightning Network, you are using the onion routing protocol. And even if 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 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 well, crypto is hard. So by making it 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 has an individual user can hide in So, but what I was saying is that the so the the central Hub will not learn a lot
about you. Unless you are 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, this plausible deniability that At. 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 a lot about 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 it. This episode of epicenter is brought to you by Microsoft and the Azure blockchain workbench.
Getting your block chain from the Whiteboard to production can be a big undertaking in something. As simple as connecting your blockchain to iot devices or existing Erp. 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 Block Chain network pre-configured with all the cloud services you need for your Enterprise app. Their new development kit is the
IFTTT for blockchains. Want to collect data from someone in a remote location via SMS and half that data package in a transaction for your hyper Ledger fabric. Blockchain the development kit allows you to build this integration in just a few steps in a simple drag-and-drop interface, here is another great example, perhaps your institution, working with etherium and rely on CSV file
sent by email one. Click in the dev kit and you can parse these files and have two data embedded in transactions, whatever you're working with the dev kit can read transform Me and act on the data to learn more and to build your first application and less than 30 minutes visit aka.ms/offweb Ascender and be sure to follow them on Twitter at msft. Blockchain we'd like to thank Microsoft and Azure for their
support of epicenter. So with this onion routing, so does it like similar to how in tour? 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 Half route that we can find but the the nodes along that route. Don't know who the other participants are. Yes. So the the structure is very similar with the two exceptions. One is that in tour? You can actually select any any participants in the network to
be the next hop in your route. This is not possible in lightning. Lightning, the the Hops have to match the actual channels exist Listing. So if I, if I only have a channel open to you, then I can't sort of go around you and then sent 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 randomized routes in such a way that if there, if there is a way, if there is a shortest route, From point A, to B, we might not use that exactly because that might might leak information about who the original sender and whose were original recipient is we randomize inside of bounds.
However, so we will select. We will select routes that are up to a certain percentage worse than the optimal route. I see I guess and I guess that kind of leads into, you know, the other the next question, you know, one of the most common questions we You often hear around like lightning is this question of routing and how we can make this efficient and you know, does this mean we need Global routing tables and stuff?
So you know could you like maybe like you know address some of the concerns there and are they valid? It's just something that like you know lightning yet to be figured out or yeah. Sure. So the the current routing protocol is basically solved based routing. So what we do is we create we gossip among the It's about which channels exist and which notes exist. We exchanged messages that basically say, hey, there's a channel between me and Brian. There is a channel between me and Sonny.
And, 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, that has the huge advantage that you basically don't tell anybody who the who
the endpoints are. But it has the downside that we need, so we can do routing decisions locally, but it has a 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 To be more efficient. And these usually come down to land-based Landmark base and and Rendezvous based routing.
So, both of these basically say hey there is some very prominent no nodes in the network that everybody sort of knows how to get to and how to get from them. And let's just, 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 the first half of this route and then we can collaboratively construct.
This, this road, this has the downside of of creating these of needing these well-known points in a network and how we select these is. It's not, it's not that clear yet. But currently the sort of, everybody had a nose, 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 luxury problem if we get there and I guess we'll cross that bridge one. So I 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 We tend to announce channels that 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 allow announce them and that is something that the eclair wallet does.
It doesn't announce its its channels to The Wider public because well, they're running on a mobile and mobile phone and they might not be stable enough To actually guarantee that there are there, when users want to route through them, and the way we handle those is basically, we add some information into invoices. So that I say, hey, I'd like to be paid 10 bucks for 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 might want to use if you want to pay me. And sort of there is this, this Be well, connected and public core Network that that routes payments from everybody to
everybody else. And then there is this, this Theory network of devices that come online and go offline very quickly and are not as reliable and they sort of represent the endpoints of users that do not want to wrote, but just want to use this network as, as a client great, I would love to die in. Little bit. This is the economics of lightning Network. So in particular, in writing Bitcoin you the demand the fees you pay, you know, tends to be based on the 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 using up some Bitcoin door locked, this is different and It's going to be proportional to the amount transferred. Is that correct? Or they're like other determines that will influence transaction fees. So in the reason why we use, we use weight-based fees and Bitcoin is basically because the the contended resource, in this case, is the blog space, right?
And so users, that should that use more of. It should pay more. Basically, that's the rationale behind it in enlightening. It's the That resource is channel capacity. So if I have a 10 dollar Channel open with you and I send 9 over, then I basically unbalanced my channel in such a way that well any future payments that that I'm on a might want to pay through that channel are are at
a disadvantage. So what we do is we did we have this, we have a proportional fee that basically is denominated in millions of Satoshi /, Satoshi and sort of. So the minimum fee you can you can have is zero or one millionth of a Satoshi for every Satoshi transferred. Yes. Oh, so the, the scarce resource here is the capacity that we have in these channels themselves, give any idea how these fees are going to develop one. You know, the Network's live.
So you mentioned, okay, this is minimum default of 1 million for Satoshi, but you know, 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?
So my expectation is that the more transactions we have, the more balanced these channels become simply because of the sort of moving away from It balance channel is a random event and sort of any transaction that modifies that balance is, is sort of a random a two-dimensional random walk on that event. So my expectation is that fees will be minimal and and sort of we just there to compensate people for the capital expenditure they had to create
this channel. So if I have if I have 100 Of course, I can. I have a choice of investing that in and 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 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 helps and sort of just a little Lil Bit less than than the huge feasts. And so you create this race to the bottom for people that 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, The Hub as long as the capital expenditure is not is not a still covered by
the fees that may collect. So, I guess, We will we will go to a fee level. That is very minimal and just covers the capital expense. You have for open channel. So let's say now in the future a lot, there's a lot of sort of one of the interesting topics currently especially in the theorem right. Is it decentralized Finance or
defy and of trend right now? A lot of things that taken under this umbrella, you know, things like maker, where you can put up ether and then you can get up some out, some stable coin. And so it's generally a perception there and I think it's a correct perspective perception that there's going to be a lot of ways. To actually use crypto and like earn money. Whether that's like that you can stake it, or maybe you can use it at some sort of security Bond
or you know this. You be able to lend it. And 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. You think that's also one way to think about lightning, maybe I is a normal Bitcoin users, you know, down the line in two years or something, I'll be able to say, okay, I'm I'm taking my, I take a Bitcoin or Take 5 Bitcoins, I put it in some lightning channels.
Now, it's use is writing payment and I make like, I don't know, three percent a year or four percent a year, in terms of, you know, earning more Bitcoin for basically providing that Capital there. I don't I don't think liking channels are a good investment at all.
It's basically just if you if you look at it from an investment side then and you want to leverage higher fees, you're basically creating this island of high fees around you and people that that are happy to maybe only take two and a half percent will position 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 for your own
needs. When a as a user of the of the lightning Network, they're probably not a great business
model to make money. So I can, if I make regular user of the lightning Network, and I want to sort of reduce my my my fee expenses for payments that I perform Then, I can route payments for other people and every all the feast that I that I gather, I can then spend on my own expenses in the Latin 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.
It's a recently. There was this guy, Andreas break and I think, and, you know, he was operating lots of lightning channels and, yeah, I think it was around 50 percent of all of the Bitcoin in the lightning Network at one point and of course, lightning is very early in this, you know, there's no will. So it's may be dangerous to extrapolate from his experience to like what is lightning going to look like when when it's kind of really functional really being used but I mean, I think I guess.
That was one of two takeaways that you know he write it all of those 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 bracken's experiment was was really early on and probably you're right that that extrapolating from from his experiences is not, it's not really feasible but only recently there has been a. There has been a huge operator of lightning notes called Ellen big.com, which has opened a lot of high-volume channel to a lot of people in the network and They, they recently published an article about how many 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, the the sort of fee structure they had is suboptimal, but I think that It sort of adds adds more credibility to the fees will not
be gigantic, right? Again, these these players could increase the their local setting for fees, but that also decreases the probability of people actually routing through them. And I think, yeah, this this is sort of two separate experiences the distance of half a year that show that the fees are not are not really there. To be made. And people people find their cheap ways to to route in the in the lightning Network.
So, another question I have about routing is a few months ago, I was talking to Zuko 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 know, you can like send paint, you can send payments yourself and, you know, 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 any.
Thing. And so you know and you could just keep dosing, 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 address tissue? It is 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 Four minutes or hours, at a time, it's definitely possible
to lock up funds. It's something that that we are hoping to address by by adding fees outside of the transferred amount. So whether or not a payment succeeds, there is a fee involved, but as it as it stands currently, it's not, 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 what we do is, we include the fee, in the, in the transfer itself, meaning that if the transfer fails, then the fees will get rolled back as well. So that, that turns out It didn't 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 sending payments that are that do not match an
invoice, that is to be paid. However, the solution that we that we propose is basically, to have this fee, be should flow whether or not the success of the transactions. It's are not. So basically what we what we currently do is if I want, if I want to send 9 satoshi's to to Brian through Sunny, then I will send 10 to you with the prom. I will promise tend to you if you send the nine onwards Brian. And if that if the last top doesn't succeed, you don't get
any anything, right. You don't get your one Satoshi in fees and The, the solution that we are considering is basically that I will send you one Satoshi. I will send you 9 satoshi's and those nine satoshi's. You will get when, when, when you forward them to, to brine. So that's sort of an out-of-band fee. That allows us to have that to, to force people to pay something whether or not this this payment succeeds or not.
So would you here? Make it so that you know, let's say Sonny sonny get some fee anyway but he gets a larger fee in case he actually routes the payment or otherwise what's the incentive to yes. So 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. On one, you get a front and 10, you get, when the routing completes and then sort of heat the 10th, he only gets when routing the nine onwards.
It does sound like a pretty clean solution. Well, let's speak a little bit about sort of the technical roadmap for lightning. So you may be mentioned, briefly L2, which is kind of a proposal upgrade proposal that you worked on and published. I think last April, can you talk a little bit about what? Altitude mean for lightning. Yeah. So L 2 is sort of the 2.0 future and what we're currently working on is 1.1.
So L 2 is is it is 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 C cash. No input. Which Looks like we might get eventually. I'm not really good at making predictions when it comes to that ever since s activation. And and once we, once we have see cash, no input.
We can actually build. L2, which is this, which is this simpler construction, which we basically can say, we can say, okay, my current state is, if we go back to the Barista, my current state is, you get to and I get 8 and then we update a couple of times and then we have five and five, And we can forget all all the states we have before which is currently not possible with lightning. We're in lightning, we have to keep part of the state for oral previous States.
So we can react in a correct way to whatever or current party might do in in L2. We have this last state which basically trumps everything that has ever been before and and allows us to override, whatever, whatever or counterparty might do. With just keeping the latest State. Yeah, I add and Robinson and Lalu have a pet. I believe going on that whether Sig has no input will be in by 2021.
Oh, and yeah. Roasting also has an elbow construction, which is so, which is interesting, which is a chick sick from stock that also is a soft work. And it, we might, 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, but there there's there is quite a lot of quite a few things we can do and
hopefully see cash. 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. See, also mentioned multi-party channels, what are those And how would they change the lightning
Network? 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, 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 a need to have this reaction ready. So, if we add more Than more than one counterparty.
Suddenly we have this, this explosion of possible Miss behaviors. And and we have to keep our keep track of a lot of state with L2 having the last state, basically Trump. Everything that came before it we don't, we don't need to have a Custom, Tailor to reaction to whatever our current parties do. And this also means that we suddenly have we suddenly don't care anymore. More 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 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 snore signatures, we can we can go to arbitrary number of participants and that basically means that we D emphasize a bit, the Reliance on multi-hop payments because if if I am in a group that moves funds around often between the 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 Go over there. Go back to this example where we three now have have one channel open and I put ten dollars in and you both have zero in that. I can I can decide to send 92 sunny and 12 Brine and basically our latest state is 0 for me, one for Brian and 944 sunny. And and if we want to if we want to send back any of this money we can we can do so without ever. involving some other channel, in The Wider Network, And this creates a whole lot of interesting.
Interesting scenarios we can do we certainly can we can suddenly no longer not only transfer Bitcoins but we might be able to transfer unique assets among herself 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, Sunny and sunny 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 at your location. Your on your balance is going to be the same Bitcoin that I sent. And so, if you were to, for example, create crypto kitties on, 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 have, you know, I read about a little bit, which sounded interesting to me, were one of them was this idea that you could do a comic multi-channel sent. So let's say, I have like, you know, five channels of to 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 I will make the full payment or not. Is this something that Method right now. Or is this like a future
upgrade? Yeah. 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 well that would have postpone the release of of the spec itself. So now we dug up all of the nice features that we that we thought about. And that we know are possible right now, but haven't inspect
yet. And one of these is indeed the, the the atomic multi-party payment, the multi-part payment and, and as you as you said, it allows us to basically bundle the capacity of multiple of our channels to create to perform one big payment instead of instead of being limited by the capacity of our biggest Channel, basically. And the other one I was interested. It was splicing where it is, could 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 big meeting and it basically allows us to to close the channel and reopen it in the same transaction and sort of add new funds to it or or move funds out of the channel without the Channel, ever becoming becoming an avoid unavailable. So the idea here is basically that if we have a channel and its 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 our to the channel balances.
So that allows us to to move funds from unchain into channels that already exists and the child remains operational while we do. So and the the counterpart to, this is what we call a splice out which basically allows us to I have I have a lot of Bitcoins on my side and I'd like to for example perform and unchain payment, then we agree to perform a splice out and part of this close and Open transaction.
Is that part of the funds that were aware owned by me, will go to a new output, which is then destined for my, for my own chain on chain payment recipient. And these these two proposals, the, the, multi-part payment and the and the splicing are part of a wider initiative where we try to sort of hide many of the technical details of, of the lightning Network in such a way that That it becomes more intuitive for users to to use lightning because what what
multi-party payment? Basically allows us is a multi-part payment, I should say allows us to do is not care anymore about the elegant, how we allocated funds to a channel. If I have, if I have 10 one Bitcoin channels or have 1110 Bitcoin Channel, it doesn't make any difference for me because I have I have this, I can bundle the If you have multiple channels, so I don't care about channels anymore, and the splice
in and splice out proposal. Basically removes this barrier between unchain funds and off chain funds because all of the sudden my off chain funds that are are 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 Either. And that, that basically contains both your unchain balance as well as your off chain balance and have channels be handled automatically in the background sort of removing this, this sort of complex issue of having to explain to your users, what 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, it's a okay. How do you manage these channels or now you have this too many funds in there and now you want to take some out again into 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. Savvy users, that, that sort of want to dig into the technical details and at halftime to 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, or do I have enough? 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 that I'm not, 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 things I 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 you know, also look the statefulness of like other systems seems to like also A lot of additional functionality where you can do, you know. So there's a, there's a proposal called Sprites channels, which makes it easier to close, like defunct routes.
There's a, you know, 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. They are aware r that side chain may have more State V capabilities. Yeah, so regarding a 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. Ourself. Right, adding adding side. Chains is great for to add 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 it's it's a hurdle to get users on board, right?
Whereas Bitcoin, if you already have Bitcoin you can use lighting right now, as for the, the need for State fullness 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. Not that come from the state channels and the etherium community into into Bitcoin,
maybe in a bit more complex way. But we can, we can often do without the added complexity of, of, actually running a stateful chain such as a theorem, one of these examples for, is that I gave a lecture in Stanford last year after publishing L2 and it it and just before the, before the lecture itself, I was challenged to 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 like Raiden so suddenly suddenly we had this very roundabout way of creating something that was Made for ethereum and back ported into Bitcoin itself without all the additional costs and and sort of heaviness that comes with a theorem. I'm not going to make a lot of friends by saying this, but I consider a theorem 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 site. Merge mind chained to an
official drivetrain to bitcoin. That's, you know it's whole purpose is designed to be a lightning Network and you know, it could be in a semi official capacity and hopefully you ex can kind of like, you know, hide a lot of that away. Just so, you know, just like you mentioned you're trying to A lot of the complexity away from the users anyway, so hopefully that, that, that special drag chain can be hit at complex can also be hidden away from users as well.
I wouldn't actually be sure that that a special side chain would be more suited for for payment channels then then Bitcoin itself simply because when the way I came up with or we came up with L2, is by taking my taking a step back and looking at At what, what sort of the minimal set of features that we need from a blockchain to make to to create a block chain 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 see cash. So I'm not sure I could come up with a with a side. In or drive chain, that is better suited for payment channels than Bitcoin with C cash.
No input. For example, And this this sort of convergence between between e, theorem 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. The same result is is for me. Very much approve of that. Yeah, this 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 is seen a lot of. Well, then, you know, this really progress, there's more momentum building and now you have, you know, two million dollars or something like that, there are held worth of Bitcoins are held in lightning channels.
So what's your You know, what's your expectation about? Where will be a year from now? You know at the you know what kind of will we see no real traction with people using lightning for payment? Or what do you think is kind of the timeline that lightning and option will take? I should probably preface this by saying that I'm really bad at making predictions. And I'm, I'm always I'm always amazed about how quickly all of this has 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 very sort of self-affirming, right? 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 to see some, some real-world adoption with, with some games coming out with some, with some Merchants accepting lightning. Going with with some yeah. Just just give by a go back to this, 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 I can probably speculate a bit more.
We have this, we have this 1.1 roadmap which we are currently implementing and hopefully we will we will be able to to say in the next year or so. At 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 a predictions. I'm as I said, I'm not really good at that. Cool. Well and pasting. Thanks so much for coming on.
It was real pleasure to you know, catching up on Lightning. I think it is. Certainly something that excites me a lot to see how this is going to is going to play out and yeah. So lets you know, let's keep following it and I'm sure it's not the last episode about lightning that we've done here. There's like 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 podcast. 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 dot TV /, subscribe for a full list of places where you can watch and listen, 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 guests 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, but thanks so much and we look forward to being back next week.