MIT Bitcoin Expo 2021: The New Normal – What Bitcoin Did @ the Expo Part 2

Hi. Hello. Hi. Hello. Hi. Hello. Hi. Hello. Lisa how are you? Hey, Peter. I'm doing great. How are you? I'm good. We were live there
for a few seconds and I didn't even realize it. Are you in a broom cupboard? I am. Yeah. Kind of like Harry Potter,
how he lived under the stairs. It's a closet. It's nice because
there's no light that gets in from the outside so
I don't know what time of day it is in here. You haven't been in
there for days, right? You actually– you must be
aware of [INAUDIBLE] the time. I'm sorry? You haven't been in there
for a few days, right? You do understand
it's the morning.

Right. Yeah. No, it's the morning. That's right, yes. OK. Well look, good
to see you again. We're going to talk
about Lightning, OK. We're going to tell people about
what's going on with Lightning, where we're at with it. Talk about how taproot
activation relates to it. You're going to handhold me
through the more technical bits which I really appreciate. But how have you been? Are you well? I'm doing great, yeah. I'm very well. Yeah. Doing pretty good here in Texas. Yeah. Weather's been real great. It's nice. Yeah, we've got good weather
here for a rare time here. So listen, let's start
with– just let people know a bit about yourself, how
you got into being a Lightning developer. Yeah, as I got into Bitcoin– I'm going to get this wrong here
and probably, honestly, 2018– I started with the
Square's Cash App team working on their back
end so I was doing, basically, custodial Bitcoin,
wallet coding, it's all in JAVA there. And then got really
interested in kind of– I got interested in
some random thing and ended up emailing Rusty
Russell of c-lightning.

Didn't really know much
about Lightning at the time, but was kind of asking
him a different question about like a thing in– like
how a thing in like the Bitcoin protocol worked, and he
mentioned that Blockstream was trying to hire
for a c-lightning job and was curious if I was
interested in applying. And I sent him
several messages back that were like, look man I just
started this job at Square, I don't know anything about c
or anything about Lightning. I really don't think I'm the
person you're looking for, but since you seem interested,
I will definitely– I would be happy to apply. It's an application process. I will through the
application process and then give you the courtesy
of telling me no.

And they didn't
tell me no so that's how I got hired to work on
Lightning at Blockstream as no one told me no. No one told you no. Well, awesome. And what is it specifically
you've been working on with regard to Lightning? Yeah, so the project I've
been working on for the past, I guess, couple of
years at this point has been changing the spark to
add the ability to duel fund the Lightning channel at open. What does that mean? I'm sorry? What does that mean? Yeah, what does that mean? What does a duel
funded channel mean? Could you– sorry. Could you just repeat that? Sorry.

You said you've been
working on the ability to duel fund a channel. Yeah, so that has to
do with how Lightning– do we want to get into how
Lightning works right now? Let's do it. OK. Go for it. Yeah, so right now– for those of you
familiar with Lightning, you open channels between two
nodes and then once a channel is open you can
send funds between– that kind of creates
this pathway– personal pathway that two
nodes can then exchange funds. Right now the way that
the protocol is written– and a protocol is basically
just kind of step back a second when you say protocol
what am I talking about. It's a set of canned messages. It's basically like having
programmatic or automatic text set up, so when you're like
hey, I want to do xyz thing. I want to open a channel.

There's a canned set of messages
that you pull out and then those are the messages that the
two nodes send back and forth to each other and once that
canned message conversation is done– it's two robots talking
and you write out what each of the robots is going to say
back and forth and at the end of it you have everything
you need to open a channel, which in Lightning's case–
what does it mean to open a channel– It means that you
have a transaction or you have a transaction and
one of those outputs locks is a two of two output with
money from one of the nodes. So that's opening a channel
is broadcasting a transaction with a special output. So you have the– so
anyways– started– so when you're
opening a channel you start a conversation
with another node, it's a canned conversation,
and at the end of the canned conversation one
of you broadcasts a funding– a transaction
with an output in it.

Cool. OK so right now the way that
canned conversation works, only one of the nodes can put
money into that transaction. Only one of the nodes
builds that transaction that you end up
broadcasting that's the funding transaction
for the channel, kind of starts the whole ability
to have lightning payments. So my project has been taking
that canned conversation that these two robotic
nodes have with each other and changing the conversation.

So we're rewriting
the script for how these nodes talk to each other. And then what we're– the
goal of rewriting the script– why would you sit down
and rewrite the script– the goal of rewriting
the script is that at the end of it
instead of one node adding funds to the
channel at the beginning both nodes would be able to
put money into the channel. So kind of what this means
is they're collaboratively building a transaction
and at the end of it you end up with a
transaction that has inputs and outputs
that belong to both nodes, and in addition
to that, you also have the special
output that just so happens to open a channel. So what's cool about that is
that currently any channel that you open at
lightning, any channel, only has funds for one
party at the very start.

So if you want to send money
in the other direction, you're out of luck. You can't do it. Duel funded channels, if
you go through this process of building the
transaction together, means that both
channels, both sides have the opportunity to start
with funds in the channel so it's more balanced to begin
with so payments can flow both directions just out of the
gate which is really exciting. Is it one of those
things whereby I as just a standard user
won't know what's going on? This is just stuff you
built in the background to make it all easier
for you developers and so money can
flow better, and I've got no idea what's going on.

That's pretty much right. Brilliant. Yeah, exactly. Like I said, they're
canned conversations between two robots and if the
conversation works out the way that it is at the
end of the day, you end up with an open
channel if you're lucky, or hopefully it's got
money in both directions so people can send you money
and you can send out money all on the same
channel and it was just the same normal
opening process that you normally go through. OK, great. So what is the general status
of Lightning at the moment? We hear lots of
different things. It's still very
early, it's still beta you should still treat
it like cautiously don't put any money in it that you
don't want to lose, but be a little bit reckless. Like where are we right
now with Lightning? Yeah, I'm going to be honest. I hate this question. I know, but I love asking it. Yeah. I hate it and the reason I
hate it is like ready for who? Who are we talking about? Me.

For you? Is it ready for Peter?  
00:07:29,373 –> 00:07:30,540
This is like– I'm kind of– I want to be like
I don't know Peter like are you ready
for Lightning? I think I am. Well, OK. So I think stuff like– so I
think kind of like if you look at stuff like Strike–
so I think strike– which is the wallet
that's made by I think– Jack Mallers –Jack Mallers. I always want to call him Zach
because his first thing was Zap and so it's– I think we also have to
mention Rockstar Dev as well. He's been heavily involved. And Rockstar Dev. It's a collaborative
project, anyways, but I think the thing about– so the thing about
Strike and the reason I bring it up when people
are like is Lightning ready is because I think Strike is
doing the right thing for– I'm going to– I don't really know
you that well, Peter, so I hate to make
assumptions but I'm going to assume for people
like yourself– in that it uses Lightning as a payments rail.

It makes it possible
to send payments really quickly and fast but
it hides the whole part about how they're getting sent
and who is managing the money and how it got from
point A to point B. All you know is that
you're able to send payments around the globe very
quickly, right, which I think is kind of one of the
promises that lightning makes and as far as the fact that
Strike exists and you can use it today, I think that
Lightning is ready for that because it exists, right. So I think– so then you can
end up on a spectrum of OK are we ready for people to build
consumer-grade projects that use Lightning network, it
seems like Strike already exists and is doing
that so to some extent I'm like yes that
seems like a thing that it's reasonable to expect
on the Lightning network these days.  
00:09:13,350 –> 00:09:17,850
But the– what do you call it– but then I think I don't know
if that's exactly what you mean like is Lightning ready or– I think of what I mean is like I
have no fears of using the base chain, so if I was like
off the session, I'm like, well, Lisa's so cool, I'm
going to send her a Bitcoin.

I'll be like Lisa
give me address I'll send you a Bitcoin. I've got no fear, no worries. I don't think, I just know
it's going to get to you. But if I was like I've got a
Bitcoin in my Lightning wallet I was like I'm going
to send it to Lisa, I'm not sure it'd get there. I'm not sure I could
send that much. I'm not sure if
things could go wrong. That's what I mean. I'm just I have that 100%
confidence in the base chain, but with Lightning there's
like a little bit of doubt.

There is doubt, yep. And that's great. And maybe we should talk about
why there's doubt, right. Yeah Yeah, and I think–
so I think there's a couple of reasons
why there's doubt. I think one, the first
reason is that a lot of the– I think Lightning is fairly
complicated as a payment rail, kind of like I
was talking about, kind of have to make sure
balances are in the right ways so you can send money and if
they're not in the right way or you don't have enough
capacity through the network, it'll fail. Part of the problem
is the lightning just in general is that we
have kind of have no idea right now if a payment will
succeed until we try it. So until you walk up, and
you push the button, and say, hey, I want to send
one Bitcoin to Lisa please figure out how to do
that, the network doesn't know if that's possible
until it tries. So that is like– that introduces a certain amount
of failure because we don't– you can't know until
you try it sort of thing is great for I think a
certain amount of science but with payments people want
zero question to whether or not this payment is going
to go through, right.

It's just like I want to walk
up to the ATM or whatever, and push the button, and have
the money come out or go in, and I don't want to have to
ever think about it, right. It's kind of like the thing. So I think that to a
certain extent getting Lightning to a point where every
payment that you make always goes through every time is
going to require a little bit more infrastructure and that's
going to look a little bit– and by infrastructure I
don't mean necessarily on the base level. I don't think that's something
we can ever really get rid of in the protocol, at the
protocol level because in order to do that it trades off.

The trade off that
you're looking at there is privacy or
reliability, right. So because we've given
people a lot of privacy we can't guarantee
reliability and I think at the base level
that's not going to change. Unfortunately what that
means to some extent is there's almost like this
little middle layer that's, I wouldn't say missing, that
hasn't been totally solved yet, is how to figure out a way
to keep track of the network or something or have
enough of your own like, I don't know if trusted,
but routes that you know and manage that always work,
that allows some third party to patch that gap– I don't know if patch that
gap's the right word– but like sort of abstract
over the unpredictability of the underlying network in
such a way that you as a user don't ever see it.

And we've had some I
think really good progress towards making this more
of the reality with MPP which is multi-part payments. So this means– it
used to be there had to be a single path
of like one Bitcoin. If you wanted to
send me a Bitcoin we needed a single path
that had the entire Bitcoin available along the whole way. MVP allows us to
instead of having– maybe you don't have one
whole Bitcoin as a whole path but you have four
paths and each of them has a quarter of a Bitcoin, I
can send a quarter of a Bitcoin through four different
paths at the same time.

So MVP gives us that. So the main issue is the
liquidity through the channels. Could you repeat that. I'm really sorry. That's OK. So the main issue. The main reason a
transaction might fail is there's not enough
liquidity through the channels That's right. But that will improve
with time, right? As more people go
onto the network. I think it'll improve with time. I think it'll improve as things
like this duel funding proposal channels start opening with more
capacity in both directions, which means that at start
you can send payments a lot more places. I think also stuff such as
slicing will help a lot. I think that– so
this is kind of like the problem like the
general umbrella of liquidity management as a problem, right. And I think that is something
that's an active place that tools are being developed. Like lightning pool is, I
think, pretty good for that also because it
allows people who care about managing their
liquidity the opportunity to go and source it in kind of a
marketplace sort of thing.

So I think we're still– and
that just launched in November. I mean that's, I guess,
that's like five months ago at this point but
it's still really new. So I think we're– [INTERPOSING VOICES] Do you want to explain
what lightning pool is so people understand. Yeah. I can understand– yeah
I can totally explain it. So the general idea
with Lightning pool is that you have– again so this goes back to
the problem of liquidity. When I open a channel all
of my funds on one side and if I wanted to send
payments in the other direction you're just out of luck. So the idea was
Lightning pool is that– oh and so it's really hard if
you're a node, all you can do is open channels
to other people.

So if you're a
node operator it's really easy to open
channels to other people and be able to
send payments out. It's hard to convince someone
else to open a channel to you with money in it, right. So this is a general
problem that we're trying to solve with pool. So pool is basically
a way– if I'm a node and I want channels sending
money in my direction. I want people to open channels
to me with money on their side already so that
people who aren't me can send money through
them to get to me, right. So pool is basically it
creates a marketplace and it's got a nice
auction mechanism that allows people to establish
a price that they're willing to open a channel
to me putting money, basically committing
funds, in my direction so I can get payments into me. So basically this allows– a node in the past
so like I said, I can control pretty
easily the money going out.

It's harder for me to
get money coming back in, so pool gives me a place that
I can go to a marketplace and bid basically on
people to create channels to me for different
amounts of stuff. And they've done a nice
job of building contracts kind of like in the
options market place. So I recently got
into like how options work in the stock market. One of the really– one of the really
nice things that makes the options
market possible is that they've
standardized the contract. So every options contract for
equities, which is stocks, is about 100 pieces of
that, 100 shares, right. So when you buy one
options contract it's always 100 shares. There's only a certain
number of dates that those options can expire on
and those are kind of set by– I'm not really sure
who those are step by, but basically when
you're buying and selling a contract for options they're
standardized contracts.

Lightning pool has done a
similar thing for this– is we call it
inbound liquidity– so by creating a marketplace and
an auction they also have like, OK, I'm going to buy– and I
can't remember how many blocks it's for. I'm going to guess. I'm guessing here. I think it's like 4,000
blocks– so the person who's you're paying them to open
this channel with you and put let's say one Bitcoin in it– so
one Bitcoin inbound liquidity– and that contract
that you pay them for is like 4,000
blocks or whatever. Right. How does taproot change
things for Lightning? Obviously I've been
talking to Andrew about that about the
activation the drama that's been involved in that. Is there a lot of
extra side work that has to be done within
the Lightning protocol to– which has to be built alongside
taproot because I'm not sure if taproot like screws
things up for Lightning.

Obviously, I'm not
developer so I don't know. What's the deal there? Yeah. So taproot. Taproot is a big
opportunity for Lightning to become more private
and better hide the fact that you're using
Lightning in the Bitcoin blockchain. I think there's other
big things that we're going to get by adopting
Schnorr signatures which isn't necessarily taproot
and it's not really related to the main chain, but
for reasons related to just kind of wanting to be
standardized around whatever it is that the taproot
stuff adopts, we've been waiting until that
landed until we update some of our other stuff, like
other signature stuff, which isn't necessarily related
to the Bitcoin blockchain but we'll use some of
those same primitives and Schnorr
signatures for example to make certain
kinds of gossip stuff a lot more compact
and easy to verify. That sort of thing. But like I can talk more
about the privacy implications of taproot– Please do, yeah. –why it's OK. Yeah so I think there's
two things that I'm aware of– and I'm sure there's
more that I'm missing– but I think there's
two big things that are pretty exciting about
taproot for Lightning.

The first one is that right
now when you make a Lightning transaction, like the
open transaction that creates this two of two output
and goes on chain to open a channel, right now
when that channel closes you have to publish the script
that originally opened it, if that makes sense. This is how P2WSH works. So right now after that
we've closed the channel, anyone can go through and see
what we're Lightning channels and it's very easy to figure
that out based on chain, just like footprint of them. Taproot, tapscript–
I'm not really sure what the right word for
it is– will allow you to hide that fact
because with taproot or tapscript a lot of
what ends up on chain looks like any other signature. So instead of looking like– so right now like
Lightning outputs are fairly complicated script. They've got a decent
amount of logic in them. Actually smart contracts on
Bitcoin is like Lightning. So these are like you can
see the logic of the script is when the channel closes.

When we move to
tapscript it will just look like any other normal
signature signed transaction. So it had like– it had like a pub
and private key. It just looks like a pub
key private key signature thing normally. So I think that's pretty cool. So on chain footprint
will hopefully largely disappear so it'll
just look like normal chain transactions. You won't be able to tell if
someone's opening or closing Lightning transaction. That's the first part. The second thing I
mentioned about– so the second thing
that's pretty cool has to do with
the way that funds are moved through Lightning,
like from Lightning node to Lightning node. So when you pass a little
onion ball down the Lightning– little onion– when you pass a
little onions down the channel stuff to make a payment that
basically involves updating a bunch of transactions
along the way so there's a bunch of
little Bitcoin transactions that get changed and updated
between each of the little hops as the onion rolls
through all the nodes to get to its destination. There's little Bitcoin
transactions getting updated at every spot, right.

So those transactions very
rarely end up on chain. You don't want them to
end up on chain, whatever. So it's not really– anyways. But one of the cool
things is right now when your little onion ball
hops from like node, to node, to node through all the
channels to like ends up at the last place and
drop off the pavement. As it rolls through at each
hub there's something called– leaves something called a hash. So it's that HTLC is
hash time lock contract, I think– hash time
lock contract– yeah. So the idea is that
you'll be able to move– so hash basically that hash is
the same at every little node. So every little
jump from channel to channel when the
transactions changeover at each spot, each of them
is the same hash right now. So if someone for
some reason was able to see each
of these changes they would be able to track
where a payment is going.

As it's very hard to do. I don't even think
it's like, I can't think of a way that's
technically possible but if for some reason
all of these channels ended up needing to go to chain
all at the same time because of some terrible
event then people would be able to see
where your payment had gone if for some reason they
go to chain or whatever. Schnorr taproot stuff
lets us move to something called PTLC is my understanding.

I think there's other
ways to accomplish this that people are working on but
I think that tapscript makes it very easy is that it lets you–
so the P stands for point time lock contract. Instead of hash we're
moving to a point. So instead of using
a hash to unlock each of the things each way– sorry– each individual
little hub in the path can use a unocorralatable,
very distinct point. So each of these
sections, instead of being able to tie them all
together because they have the same piece of data between
each one, now each of them will have its very own
separate little point that they're using at each hub.

So you won't be able to tell
if for some reason all of these ended up on chain,
there's no way to look at everything
that's on chain and say, oh, these were the
same payment because they're using a different point
instead of the same hash. OK. I think it's also
like Schnorr thing. Are there any other benefits
that Lightning network will be gaining from
taproot outside of privacy? Outside of privacy? I think it's like– I think there's certain savings
and I'm not the right person to ask this exactly. I think other people can
give you better answers. Based on what I've heard
I think there's certain– there's some amount of space
savings somewhere maybe, but I'm totally talking
off the cuff here. That's fine. I've got some questions
from people coming in. So I'm going to read
those to you as well. OK.

Is there any missing
feature in Bitcoin core that would help Lightning
development evolution? This is a good question
and it's not something I've, again, kept up with. I think the thing that one of
my teammates, Christian Tucker, talks about or what
I think of when I think of this as like the– we're still– I don't know if
waiting is the right word– but looking to get the I
think it's the script SIG– SIGHAS– no input. I think it's been
renamed something else. So basically there's a
proposal for something called L2 Enlightening.

This will change the way
that punishment works. So it basically has to
do with how much backups do you need to save
for your Lightning node and kind of solve
some of the problems that Lightning
nodes have around– you can't lose any
information ever, right now. So this is like– so the
problem it's trying to solve is that Lightning nodes have
to remember a lot of stuff and if you lose that stuff you
could lose all of your money in Lightning channels possibly.

So anyways. But this like adding
this certain SIGHASH flag to the core will let us
upgrade the mechanism we use for commitment
transactions such that– what do you call it
commitment transactions– such that the state that you
save can be compacted a lot. So it's a lot less stuff
and if you, for some reason, your hard drive gets corrupt
and you lose your Lightning database, your
recovery from a backup isn't as devastatingly bad
in terms of monetary loss. In terms of a Lightning
node– because I've recently– I know it's late and I get
a lot at stick for this, but I've recently finally got
myself my node fully synced– and my basic understanding
of how it works is it sort of downloads
the blockchain and the blockchain itself
is what, 350 gigabytes, but I think of it
in terms of blocks. So in terms of Lightning in
my lightning node, what do I think of in terms
of the data that's storing because it can't
be in terms of blocks. It must be in terms
of something else. That's a good question. It depends on what
your node is doing.

The thing is– Does it have the whole state?  
00:26:32,800 –> 00:26:35,470
So there's like– for every
channel that you have open right now it has to
save at least one– I have to save basically
a Bitcoin transaction. So the data that a Bitcoin
transaction is composed of, which is like bytes, right,
like hundreds of bytes. Yeah. It's on the order of hundreds
of bytes for a channel. I think is that right? I think there's
some other metadata you might need to keep
in terms of keys, which key you've used for that channel
for example to unlock things. You also have to save– so you have to save, it's on the
order of like maybe a kilobyte. I'm going to get that
wrong and someone else is going to say Lisa
that's terribly wrong and here's why and here's all
the extra data that you have to keep also, but from a state
perspective you have to keep– you have to keep the
current transaction and you really also want to
keep– based on the current way that stuff works–
you also want to keep this kind of a list
of revocation keys that your peers have given you.

But that's– I don't
know how big a key is, like 33 bytes or so times
however many times you've had that channel change. So it's within like,
I would say it's in the kilobyte
range per channel. So it's on a channel basis. So you think about it on
a how many channels do I have or have I had that I
need to keep state around for. OK. OK. So we might have time for
one, maybe two questions but we'll go with one for now. What, who is the main
competitor to Layer 2 Scanning in Bitcoin, if any,
and what is the dev position overall on Lightning
network in general. I think you've kind of answered
to the second part already. OK. But what other competitors
for Layer 2 Scanning is there? Yeah. I don't know, let's
say wrap Bitcoin right you can do it on– [CHOKE] Yeah, so, I actually I gave a
talk I think at some conference last year about Lightning and
comparing it to liquid and– I hate saying liquid of
course because then I feel like I'm shilling
for blockstream but, yeah liquid of course.

Kind of, not really. It really depends on what I do. I think that– so wait,
are we talking about– and maybe like–
so I think, when you talk about
competitors Lightning, what are you talking about? Are you talking
about with other– I think competitors
the wrong word, really. I mean I'm reading their
question says competitor but I'm just– I think there's just
multiple scaling options of which Wrapped
Bitcoin is a scaling option. We can't deny. Liquid is a scaling option. Lightning's a scaling option. Are there ones that we
should be aware of and yeah– And so I think a good
way to think about so– sorry I'm kind of like a
first principles person, so I want to talk about
like– when you talk about– like so when you're talking
about competitors usually then you want to look at what's
like doing a similar thing.

And the core thing that
both liquid and Lightning and Wrapped Bitcoin all have in
common is that they build pools of Bitcoin that are then
kind of kept in multi-sig– they're kept in multi-sig
UTXOs on the main blockchain and then because you
have that Bitcoin locked in that multi-sig
UTXO thing, they build a second
accounting layer that keeps track of who owns the
money inside that Bitcoin pool, right. This is how any layer two
stuff works, basically. Enlightening the accounting
is these little Bitcoin transactions that
you keep off chain and you trade back and forth. It's kind of like
Pokemon cards, whatever. The accounting system in liquid
is a whole other blockchain, it's a liquid blockchain. But it's basically the
accounting for liquid Bitcoin is just like who
owns what portion of this locked pool that's
like a multi-state contract. Wrapped Bitcoin
is the same thing except the accounting mechanism
is on Ethereum, right. So I think when you're
looking at– when you're looking at L2 things
or you're evaluating what do I think of this
scaling option, it's who are the
most participants for that pool of Bitcoin
that you're creating? Do you trust them? Do how to get your
money out of it? And two, the other
thing then is like how what do you think of
the accounting system? Is it a good accounting system? Does it seem like that
accounting system will keep track of who, and what,
and how much Bitcoin you are owed in that leg pool? So.

Fair enough. Well, we've come to
the end of our session. I've learned more. I learned more about Lightning
since I did 35 minutes ago, so thank you Lisa. Hopefully we'll have a
chance to catch up soon. And, yeah. I think it's now time
for the morning break, but thank you for
your time Lisa. Cool. Thank you. Awesome conversations. Awesome conversations. Very interested to know
what's coming on taproot and also these cool technical
things on lightning network. Yeah. Thanks Peter, Lisa, and Andrew. We're going to
have a brief break and we will resume
in 10 minutes. So take this opportunity
to join us on this Court and also on [INAUDIBLE]. We'll be back at 11:00 AM..

You May Also Like