#273 Christian Decker: Lightning Network - The Road to Scaling Bitcoin

7 Feb 2019 · 1:21:41

Christian Decker, a core engineer at Blockstream working on its Lightning Network client, joins Epicenter to trace the protocol's path toward scaling Bitcoin. He covers how the Lightning Network evolved since its 2015 conception, progress toward a finalized 1.0 specification, why centralization concerns around routing hubs are often overstated, and what the eltoo proposal could mean for the network's future.

Speakers

Topics

Transcript

[Music] this episode of epicenter is brought to you by top-down experience a new way of firing as top tail delivers only the top 3% of applicants including highly skilled blocking engineers if you're looking to scale your team with the very best talent visit top.com slash epicenter and buy microsoft azure do you have an idea for a blockchain app but are worried about the time and cost it will take develop the new asher 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 akms slash epicenter hi and welcome to episode my name is Ryan Faran crane my name is sunny auger raw so we're here today with Christian Dekker he's been on the podcast before and you're gonna 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 office oh I really want to do more Bitcoin episodes this used 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 we're joking before the episode maybe we have to put the big comeback 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 liking 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 me you're gonna give it talk tomorrow yeah so there's a panel in Berkeley being held by blocks at

Berkeley in order Holden 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 are gonna be there talking a lot about you know fairness weather and stuff but it should just overall be a really interesting panel to me tomorrow or I guess if this episode coming out tomorrow today on the 6th February sixth 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 Christian hi we heard today with Christian Decker he has been on the

podcast before it was actually quite some time ago being about three years three and a half years ago where we did an episode with him about a paper he had written called a 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 the 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 joined 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 streams so we're excited application on today and and to have a chance to dive into lightning where I think so much has happened and of course yeah and we've done a few episodes but actually they're mostly in 2015 so a long time ago so yeah thanks so much for coming on fishing yeah thanks so much for having me Oh 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 ever on the topic I was doing Master in distributed computing and distributed

systems back in 2009 and I stumbled over this strange small page and I thought wait this is this is interesting and so I've well I went to the online forums and registered there and and started 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 believing that Bitcoin might still be around in three years time

which is the usual time year it takes for a PhD to complete I was was careful to serve to make it blockchain and Bitcoin and sorry doff line up a whole slew of different topics that we might try to 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 PhD on and then ended up being being successful in 2016 and I was was awarded the first PhD in about Bitcoin in the world and yeah been working on that stuff ever since

and so you said you started the phd in 2012 though like working on it yep and and already back then you say scalability was kind of a very popular topic oh yeah I mean it it was among other things one of the parts that I outlined and sort of my pitch to my professor that I was topics that I wanted to discuss and the scalability topic was very much in mind it is I I mean we we were distributed computing an instrument assistance 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 discussion and and going for systems that squeeze more out of the the resources that we have and that's where basically payment channels and duplex micro payment 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 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 payment channels I was sort of

sort of the sole per in 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 um it really comes from there being one big network where everybody every participant can speak to every other participant right so splitting the splitting the community into into smaller parts is not not ideal and secondly they're there while duplex micro payment channels and lightning had have really different trade-offs I think at the time lightning had had way better trade-offs and and duplex mariko payment channels and that that is apparent from

from just looking at sort of the unchained footprint that the duplex merriman channels have compared to lightening channels with duplex micro payment channels we had tens of transactions that we needed to settle in a certain period of time whereas enlightening we just have to settle one transaction that is so lightening 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 Merryman channels and that's that's part of what what we published last year with this l2

proposal which maybe we will 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 lightening is that a fair way of saying that it's it's heavily inspired by a buy the duplex micro internal stuff yes it sort of is going back one step and looking at how we would stretch your 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 LF duplex micro and channels with l2 then later

so now this is maybe a tricky task but yeah III 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 without going into too much detail here like how do you explain lightning to somebody let's say I understand Bitcoin well but doesn't understand lightning Sharia so like a lightning 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 that I go to a bar and I put a $10 bill on the counter and as long as this $10 bill is on the counter me and the barista basically we we assure that this $10 bill can't move and now it's it's all about initially these ten dollars are mine and then I want to transact with the barista and so we we we incrementally decide on on how to split these ten 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 then I buy one

more and then 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 in any possible outcome he will get his money and I will get mine and that we can't sort of renege on what or what our latest state

was basically if I if I promise 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 these and that's that sort of an old idea that we had for a long time basically already in 2011 we had 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 market women channels and the Lightning Network sudden we have a construction where we can send that 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 what is what is due to us now with lightning lightning is is the first part the network part is the second part right if I if I open a channel with a breeze that can only interact with that arista 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 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 for a person in the chain and next person in the chain and the next person in the chain until we eventually reach our or intended target and only then we can we we have this entire chain of promises that there are def fulfilled there's ways to do that but really those are those are it took power 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 they're

lightning whitepaper ideational about 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 the basic ideas are still there the revolutionary idea of of constructing a payment channel and then sort of had the way we we do invalidation 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 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 it in the white paper is still still valid and is still there however the actual implementation and the actual protocol as it is right now I would probably not try to infer from that from that paper because it's it's very light on on the d/dx 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 with like the plasma world so you know I can see something very similar there where the original plasma paper from Joseph hoon is like you know very interesting idea as the very light on the details and so then that's where like you know if 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 tad back in 2015 and then we also had one with Adam back in 2015 and

he was pleased 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 one of the things that nobody was expecting is that there was nobody that actually wanted to implement anything in this so Taj and and Joseph basically wrote this paper and and then only much later decided to create a company Lightning labs to actually go ahead and implement this and in the meantime block 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 untouched decided hate that there's there's there is a good way to create a company out of this so I think the 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 in and 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 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 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 we learned along the way and there was a lot of X there there was a lot a long 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 in to 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 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 from a different angle it also forced us to have this experimentation phase before the Milan meeting where everybody just went their own way and then sort of we came back and 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 the advantage is basically that 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 there's nothing well whereas with the current ecosystem we have we have a clear which are very much a sync with their client it clear which are very much focused on on mobile clients we have lightning labs that are with their lnd are very much focused on on desktop their users and their see lightning which is mostly for a mning for power users that sort of need a lot of customized a customized ability and so there's different different goals we

have on different target audiences but we still have this interoperability that gives a that is given up to us by the by the specification that is implementation agnostic it's also good to have that all of this written down and not infer in the form of an implementation otherwise it gets really hard to reason about right that's interesting I mean we just said we didn't episode we like Jameson lop I think last week where we had some of that discussion around you know big coin not having a specification right and 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 request about spelling but at this point really the 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 that sort of have started this this process with us have 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 out out of the gate and sort of be able to concentrate on the next big thing that that we might want to build in there so not yet but soon 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 top down if you go to their trust pilot page you'll see that of the hundreds of people that have left reviews over ninety eight percent were four or five star ratings including one guy who wants

to give his developer a 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 blocks and engineers one of these engineers is Radek Ostrovsky Radek has experience as a lead software engineer and data scientists for Sony and Expedia then he discovered blockchain and he became totally consumed with aetherium he worked as a consultant for the firm start on chain and his time lock tap when the top quarter consensus you port and 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 tile comm slash epicenter for a Norris trial a top tile director of engineering will deliver your next hire in as fast as 48 hours and you'll get $1000 credit when you decide to hire we'd like to thank top towel for their support of epicenter ok so we had like this slow beginning and then the specification work started in in 2016 in Milan and now it's kind of at the point of coming into closure if you look overall at the history of work on lightning where 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 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 gossip protocol in which we exchange information about channel and existing channels and existing nodes because we wanted to have we said ok we want to have a simple version person and 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 now it's this this chattiness is 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 Timber 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 that 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 or about like you know last spring and you know there was 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 used that opportunity to buy the shirt I'm wearing from the block stream lightning store so I was pretty

no excited I got it we wanted lucky the first early uses of lightning so how is a you know this role that would happen over the past couple 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 use of a usual reply is it is launched so we had this we had this very slow and incremental rollout where we we basically created a client and sort of got some users onboard that that were really technical and that just wanted to play with this stuff and before before

the bloodstream store launched last year we encouraged 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 day software after all and we wouldn't feel comfortable losing user money at at that point in time it basically we had a group of people that were tech savvy and that were sort of hacking their way around the clients himself and we're sort of experimenting on maintenance

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 open a shop where you can actually buy items for real bitcoins and sort of get that feedback from a net users or self and sort of get gather experiences on main at ourself by operating the store and so in I think it was January 16th we basically published that we have the running version of WooCommerce with a lightning with the see 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 so this slow and incremental rollout where you actually had 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 cuts or 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 we're also able to increase our confidence in to 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 that we wanted and it's been working great so far so there will will note 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 they feel like investing a bit of time and eventually we hope to make it easy enough for just everybody to to be able to to to come and play with it are there any known cases of anyone losing any money on made net 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 data 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 these limits low enough that that we could do this sort of I buy you a beer and were sort of even right and now we we've had a lot of luck with with the

community members nobody really lost a lot of money and everybody just played along rate very nicely and sort of this into the fuzzy azzam that I just wanted to sort of buy you a beer because I calls the buck that lost you money and he insisting that that I should get a beer instead now that's something that that this happens that is very sort of representative for the good a 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 gonna have these different channels and

it's good if you general is very powerful if it's connected with many all right so you have you're gonna have these hubs and then there's 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 we generally go through you know particular legal hubs and so there's this fear that okay isn't lightning any be a very centralized network there's gonna be a few companies that will all you know have these big hubs everyone will go through them but what are your thoughts first of all on whether or not is a problem or the aspect of decentralization enlightening and kind of the role of hubs yeah so that's that's a point that comes up read

often and I often get the feeling that people are scared of centralization but for the wrong reasons because if 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 its channels and therefore connects a lot of people in the network then that's for that first of all is a service to the to the network itself by Allah 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 ace if if the network turns out to be centralized help 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 lower a lot worse than than before what I don't think is is a big issue and which a lot of people point to is is this idea of big hubs being being able to be anonymize people and sort of profiling their user we have in the ended 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 so all a big hub sees is that ok I got a 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 only 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 as 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 so 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 we decided 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 way 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 that it's you which is why we encourage people to actually open multiple connections at least to have this 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 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's

reasons for helps to emerge and there's reasons for helps not to emerge maybe we can go into that later if you if you wanted this episode of epicenter is brought to you by Microsoft and the azure blockchain workbench getting your block ting from the white board to production can be a big undertaking and 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 blockchain network pre-configured with all the cloud services you need for your enterprise app their new development kit is the IFTTT for blockchains suppose you want to collect data from

someone in a remote location via SMS and have that data package in a transaction for your hyper ledger fabric block team 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 etherium and rely on CSV files sent by email one click in the dev kit and you can parse these files and have two data embed it in transactions whatever you're working with the dev kit can read transform and act on the data to learn more and to build your first application in less than 30 minutes visit AKA OMS slash epicenter 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 path route that we can find but there the nodes along that route don't know who the other participants are yes so the the structure is very similar with 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 enlightening for lightening the the hops have to match the actual

channel's existing so if I if I only have a channel open to you then I can't sort of go around you and then send back to you so our Onion Routing hops have to coincide with actual channels existing and as for your question about whether we choose always the most efficient route we we do randomize routes in such a way that if there if there is a word 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 into the original recipient is we randomized 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 okay and I guess that kind of leads into you know the other the next question you know one of the most common questions we often hear around like lightning is this question of routing and how we can make this efficient and 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 is it something that like you know lightning yet to be figured out or yeah sure so the the current routing protocol is basically sauce based

routing so what we do is we create we gossip among the nodes about which channels exists 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 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 that 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 were under consideration for how we can improve this to be more efficient and these usually come down to land based landmark based 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 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 route this has the downside of creating these of needing these well-known points in a network and how we select these is not it's not that clear yet but currently the sort of everybody had knows the entire network seems to be working well and rusty had a few numbers I think that a two million channels we should be able to sort of squeeze that in a few hundred

mix of data so not a huge problem right now it's actually a luxury problem if we if we get there and I guess we'll cross that bridge once a while once we're there that is we say one thing that 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 clear wallet does it doesn't announce it's it's channels to

the wider public because well they're running on a mobile 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 we handle those is basically we add some information into invoices so that I say hey I'd like to be paid ten bucks by you and here is 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 very well-connected and public core network that that routes payments from everybody to everybody else and then

there is this this ciliary Network off of devices that come online and go offline very quickly and are another's reliable and and they sort of represent the endpoints of users that do not want to Revit but just want to use this network as as a client right I would love to dive in a little bit they're sort of the economics of lightning networks so in particular in writing Bitcoin you the amount of fees you pay you know tends to be based on the size of the strings are so the size in terms of the data you

know not in terms of value now enlightening or 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 are there like other determinants that will influence transaction fees so in the reason why we use we use weight based fees in Bitcoin is basically because the 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 enlightening its the continent resources channel capacity so if I have a 10 dollar 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 that I might want to pay through that channel are at a disadvantage so what we do is we do we have this we have a proportional fee that basically is denominated in millions of Satoshi pursue Toshi and sorry so the minimum fee you can you can have is zero or one millionth of a Satoshi for every Satoshi transferred yes so so the the the scarce resource here is the capacity that we have in these channels themself if you have any idea how these fees are going to develop

once 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 this is gonna play out so my expectation is that the more transactions we have the more balanced these channels become simply because of the US are sort of moving away from it balance channel as a random event and sort of any transaction that modifies that balance is is sort of a random walk a two-dimensional random walk on that event

so my expectation is that fees will be minimal and and sort of be just there to compensate people for the capital expenditure they have to create this channel so if I have if I have $100 I can I have a choice of investing that in stock or I can forego that option and 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 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 at that leverage that want to leverage high fees and we'd like to actually encourage people to 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 still covered by the fees that may collect so I guess we will we will go to a 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 a lot of sort of one of the interesting topics currently especially in here is this it decentralized finance or defy kind of trend right 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 up some out some stable coin and so there's generally a perception there and I think it's a correct perspect 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 that you can stake it or maybe you can use it as some sort of security bond or you know this you'll be able to lend it now presumably that's

also gonna 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 is a normal Bitcoin users you know down the line in two years or something I'll be able to say okay I'm taking my I take a Bitcoin or take 5 bitcoins I put it in some lightning channels and how it's used is routing payment 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 I don't think lightning channels are a good investment at all it's basically just if you if you look at it

from an investment side then and 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 itself 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 as a user of the nura 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 fees that I that I gather I can then spend on on my own expenses in in the Lightning Network so it's more of an emerges Asian 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 it's been multiplied so recently there was this guy andreas Brecon I think and you know he was operating lots of lightning channels and yeah I think it was around fifty percent of all of the Bitcoin in the Lightning

Network at one point and I of course lightning is very early in this you know there's no real so it's maybe dangerous to extrapolate from his experience to like what is lightning gonna look like when when it's kind of really functional really being used but I mean I think I guess I was wanted to takeaways that you know he righted 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 feel 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 experience is not it's not really feasible but only recently there there has been a there has been a huge operator of lightning notes called Alan be calm 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 sort of fee structure they had is a suboptimal but I think that 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 showed that the fees

are not are not really there to be made and people 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 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 to 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 anything and so you know and you could just keep tossing the lightning Network and causing people to do lock ups and then just like failing the transaction so is this a legitimate concern or is this like an addressed issue it is it is definitely concerned 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 be shut down which is going to cost you some money but four minutes or hours at a time it's certainly 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 the payment succeeds there is a fee involved but as it as it stands currently it's it's not it's not been addressed how would that outside of the payment amount like the payment be done like how would that happen technically so the 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 enables a number of nasty things one is the griefing attack and the other

one is it's 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 this exaction succeeds or not so basically what we what we currently do is if I want if I want to send nine Satoshi's to to Brian through Sonny then I will send ten to you with a prompt I will promise ten to you if you send the nine onwards Brian and if that if the

last hub 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 nine Satoshi's and those nine satoshis you will get when when when you forward them to 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 here make it so that you know let's say Sonny Sonny gets 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 my example was flawed because I started with ten and nine and didn't have any room to split that one but yes of course it would be it should be eleven one you get a front and ten you get when no in the routing completes and then sort of heat the tenth he only gets when when routing the nine 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 you mentioned ppl - 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 and what we're currently working on is 1.1 so l2 is is it is a new construction of payment channels that is much simpler and reconnects in fact to the duplex micro payment 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

every since sacred act evasion and and once we once we have C cash no input we can actually build l2 which is this which is this simpler construction in which we basically can say we can say ok my current state is if we go back to the barista my current state is you get 2 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 had before which is currently not possible with lightning we're enlightening we have to keep part of the state for all previous states so we can react in a correct way to whatever our karna 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 our counterparty might might do with just keeping the latest state yeah dan Robinson and lalu have a bet I believe going on that whether sig has no input will be in by 2021 oh and yeah roasty who also has an algo construction which is so which is interesting which is check sick from stock that also is a software and it we might we might end up compete with two competing proposals again and then sort of hash it out which one is is the cleaner and which one is

the more flexible one but yeah there there's there's quite a little quite a few things we can do and hopefully Sukesh know input is less and 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 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 or

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 I need to have this reaction ready so if we add more than more than one counterparty suddenly we have this explosion of possible misbehaviors and and we have to keep a keep track of a lot of state will l to having the last state basically trump everything that came before it we don't we don't need to have a custom-tailored so the reaction to whatever our karna 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 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 seen or signatures we can we can go to arbitrary number of participants and that basically means

that we de-emphasize with 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 we 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 nine to sunny and one to Brian and basically our latest state is zero for me one for Brian and nine for for 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 in the water 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 yourself because one of the one of the principle 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

sunny and sunny forwards it to you then then the coin that you receive is not the one that I send right whereas in a 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 look at your on your balance is going to be the same Bitcoin that I sent and so if you were to for example create crypto carries on on one gigantic payment channel we could actually send these unique assets among herself without ever involving the blockchain without ever involving any party outside of the

channel itself two of the features I you know I read about a little bit which I was on interesting to me where one of them was this idea that you could do atomic multi channel send so let's say I have like you know five channels of to Bitcoin each but I'm trying to send ten Bitcoin I can somehow have a system in which I can atomically send all of them uh and so either make the full payment or not is this something that's implemented right now or is this like a future problem 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 postponed the release 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 having inspect yet and one of these is indeed 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 was splicing which is can you maybe describe that and is that also in this like 1.1 spec oh definitely a splicing basically is an idea i had a few during the first big meeting and it basically allows us to to close a 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 unavailable so the idea here is basically that if we have a channel and

it's really unbalanced and you own all the funds but i want to use this channel to send you some money then i can basically take some other coins i have lying around on chain we can agree to perform a splice and i can add these funds during this close and open operation to the channel balances so that allows us to to move funds from unchain into channels that already exist and the channel remains operational while we do so and the the counterpart two days 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 an unchain time and then we agree to perform a splice out and part of this close and reopen transaction is that part of the funds that work our own money 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 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 the allaha we allocated funds to a channel if I have if I have ten one Bitcoin channels or I have one one ten Bitcoin channel it doesn't make any difference for me because I have 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 Unchained funds and off chain funds because all of the sudden my off chain funds that are are that are allocated to it a lighting 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 that basically contains both your on chain balance as well as your off chain balance and have channels be handled automatically in the background so 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 for any details that users currently have to deal with that sounds really fantastic actually I think that was always a little bit my a concern I had you know so okay how do you manage

this channel so now you have just too many funds in there and and now you want to take some out again into close to 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'm not I haven't done too much Bitcoin development but I've done I've done a couple of payment channel implementations on aetherium and on the cosmos SDK and so one of the things 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 like the statefulness of like other systems seems to like also add 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 like 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 they are where that side chain may have more stateful 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 that are the most utility from and that's where we want to use it ourselves 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 it's it's it's a hurdle to get users on board right whereas Bitcoin if he if you already have Bitcoin you can use slighting right now as for the the

need for statefulness and the need for more advanced smart contracts we find time and time again that it turns out that we can back poured a lot of stuff that that come from the state channels and the etherium community into into Bitcoin maybe in a bit more calm flex way but we can we can often do without the 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 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 light rate and so Sun suddenly we had this very roundabout way of of creating something that was made for aetherium and back poured it into Bitcoin itself without all the additional cost and and and sort of heaviness that that comes with a theorem I'm not going to make a lot of friends by saying this but I consider a theorem a great estimate for a Bitcoin

yes that makes sense like no I I was just really thinking that you know I I really how I see like you know what my vision would be like I really want to see a special sidechain that's designed for lightning and state channel networks just be deployed as soft worked in as an official merge mind chained 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 could be in a semi official capacity and you know hopefully UX can kind of like you know side a lot of that away just know just like you mentioned you're trying to hide a lot of the complexity away from the users anyway so hopefully

that that that special drive chain can be hid that complex can also be hidden away from users as well I wouldn't actually be sure that that a special sidechain would be more suited for for payment channels than than Bitcoin itself simply because when the way came up with or we came up with l2 is by taking by taking a step back and looking at what what's sort of the minimal set of features that we need from a blockchain to make to to create a blockchain that is purpose-built for payment channels and it turns out this the the the difference between this idealized payment channel enabling

blockchain and the currently deployed Bitcoin network is really just this one sake hash so I'm not sure I could come up with a with a side chain or a drive chain that is better suited for payment channels than Bitcoin with say cash no input for example and this this sort of convergence between between a theorem where you actually have all of the all of the flexibility and where where you have where people have come up with Radin and l2 which count comes from this more constrained version of 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 this sort of 2018 reviews you know lightning was often coming up and say okay lightning has seen a lot of development you know this really progress there's more momentum building and now you have you know 2 million dollars or something like that that 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 you know real traction with people using lightning for payment or what do you think is kind of the timeline that a lightning adoption will take I should probably preface this by saying that I'm bad and 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 it's been a very frightening ride but

also 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 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 with with some yeah just just give back go back to this to this use of Bitcoin as a 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 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 fix the next roadmap but yeah that's that's probably all I can say when when it comes to a prediction sign as I said I'm not really good at they're cool well um Kirsten thanks so much for coming on it was real pleasure - you

know catching up on lightning I think it is certainly something that excites me a lot to see how this is gonna I was gonna play out and yeah so let's you know let's 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 released 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 TV slash subscribe for a full list of places where you can watch and listen while you 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 but thanks so much and we look forward to being back next week [Music] [Music]