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.