What Bitcoin Did

View Original

Tadge Dryja on the Limitations of the Lightning Network

Peter McCormack
See this content in the original post

Where to find the show

iTunes | Google | Spotify | Stitcher | SoundCloud | YouTube | Deezer | TuneIn | RSS Feed

Your browser doesn't support HTML5 audio

Tadge Dryja on the Limitations of the Lightning Network - WBD100 Peter McCormack

Download Episode MP3 File
The file will open in a new window. Click down arrow to download the file.

Interview location: Skype
Interview date: Thursday 25th April, 2019
University: MIT Digital Currency Initiative
Role: Research Scientist

The simple promise of the Lightning Network is that it solves the scaling issues inherent with one-megabyte blocks in Bitcoin, offering users near instant and low-cost payments. Now the Lightning Network is in beta, actively being used and stress tested, questions are being asked about its limitations.

Proponents for on-chain scaling have been harsh critics of Lightning, questioning everything from the time it has taken to develop to whether it does solve high fees. Proponents of Lightning often defend it, claiming it is early, and many exciting things are being developed to address these early issues.

What is clear is that the Lightning Network has much to prove, and there are risks it will not solve all the issues with scaling and potentially becomes a tool for the Bitcoin rich.

Tadge Dryja co-authored the Lightning Network whitepaper with Joseph Poon and worked on the initial implementation. In this interview, we discuss the limitations of the Lightning, why Bitcoin might not be for everyone, alternative scaling ideas, the fee network and inflation.

TIMESTAMPS

00:05:09: Introductions
00:05:53: Background to the writing of the Lightning white paper 
00:08:16: Tadge’s perspective on the white paper and his thoughts regarding scaling
00:12:10: Discussing Tadge’s current project, utreexo and why he took a step back from Lightning
00:14:55: Delving into some of Lightning’s criticisms and hypothesising about a future two tier Bitcoin
00:18:54: Exploring the difficulties with fees and how friction from layer one can bleed into layer two
00:21:58: Tadge explaining his criticisms of the BOLT specification and the industry’s view on Lightning
00:24:40: Discussing issues surrounding the Bitcoin ecosystem and the tribalism that starting to appear
00:32:13: Delving into the difficulties surrounding having multiple cryptocurrencies
00:35:06: Tadge’s perspective on Dan Robinson’s critiques and the concept of Packetized Payments
00:37:09: Discussing Tadge’s thoughts on the Lightning network in it’s current state
00:39:40: Exploring whether Tadge would make any changes to the white paper retrospectively
00:44:07: Delving into utreexo in more depth and discussing timelines and objectives
00:48:46: Discussing the future issues Bitcoin will face with the end of the block subsidy and fees
00:51:20: Tadge’s views on whether implementing inflation on Bitcoin would be the solution
00:56:43: Exploring what Tadge believes are the most important things coming up for Bitcoin
00:57:52: Final comments and how to monitor what Tadge is up to

See this content in the original post

SUPPORT THE SHOW

If you enjoy The What Bitcoin Did Podcast you can help support the show my doing the following:

If you are interested in sponsoring the show, you can read more about that here or please feel free to drop me an email to discuss options.

SPONSORS

Patron Sponsors

And a big thank you to Rise Wallet

SHOW NOTES

THANKS

A big thanks to my WBD Maximalist Patrons for helping support the show: JP Petit, Logan Shultz, Seb Walhain, Steve Foster, Tony, Gordon Gould, David Burlington, Jesse Powell and Wiel Menger.

See this content in the original post

TRANSCRIPTION

Peter McCormack: Tadge, how are you?

Tadge Dryja: I'm good!

Peter McCormack: Finally got the sound sorted?

Tadge Dryja: Yeah, good old computers!

Peter McCormack: Well listen, thanks for coming on. I've been running a Lightning month on the podcast. I actually just missed you at MIT at the Bitcoin conference.

Tadge Dryja: Oh were you at the expo?

Peter McCormack: Yeah, I was there. So I interviewed Christian there and interviewed Jack Mallers. I tried to find you at one point and I seemed to have missed you, so apologies for that.

Tadge Dryja: Oh yeah, sorry! I was there both days. But, you know, tons of people I didn't know!

Peter McCormack: Yeah. So anyway, thanks for coming on. I've been running this Lightning month been interviewing lots of people and finding out as much as I can about Lightning. Just to prepare you, I am not the most technical person and my podcast is approached from that angle to try and learn about it. So there's been loads happening. I've got lots to talk to you about, loads of questions. But really I want to just go back a bit, because obviously you wrote the Lightning White Paper. I had a conversation with Christian about that and he had a competing white paper. Can you give me the background to how you came to actually start writing that?

Tadge Dryja: So it was with Joseph Poon and we met up at San Francisco Bitcoin Meetups in 2014. The general idea has been payment channels and stuff, but the core idea of what would then become HTLCs, was really something Joseph came up with. We were talking about it and I was like, "oh that's really cool, the idea of not using signatures, actually just use hashes and preimages, so that when you reveal it, everyone can see it."

Then once we started writing it, there were other people looking at the similar kind of things. Alex Axelrod had a paper or a page on Github with some types of similar ideas, so we talked to him as well. I don't know if Joseph really wanted to publish it, so it didn't go anywhere really. We're just brainstorming for several months. Then there was a paper from a BitPay called "Impulse".

We saw that and were like, "oh no this doesn't work at all" and Joseph was like, "okay now we have to really publish this and actually get this out there, because people are going to come up with stuff that doesn't work as well." So then we gave give a talk at SF Bitcoin Devs and had our paper out. So that was sort of the process there.

Peter McCormack: I mean it's a huge white paper. I've read it. Well I would say, I attempted to read it. I'm mean not a technical person. I would say the first few pages were a lot more interesting to me than the in depth technical bits. How long did it take to pull together?

Tadge Dryja: A couple months? It was just a Google Doc kind of thing. Also we didn't agree on everything necessary, Joseph and I. So even some of the terms and diagrams are, "oh well, okay fine." So we're working on it together. But yeah, it's not the greatest paper I guess. It's good idea and it's really hard to revise, because everyone's gone their own separate ways and so it's just this paper that's mostly finished. It's on this lightning.network domain, which I don't own. I guess Joseph still has that domain, but I don't know.

Peter McCormack: I guess you therefore see the white paper really as a starting point, which is a real fair point with regards to say the arguments over the original white paper for Bitcoin. Where people have used that as a reason to stick to an original vision. You just see it as a starting point?

Tadge Dryja: Yeah. I mean it's a starting point, but also everyone involved had pretty different ideas of how it would work. So in the paper, I don't think there's anything about onion routing. I don't think there's anything about a lot of stuff! Almost all of the HTLC multi-hop stuff is just sort of hand-waves, it was, "yeah, you could make HTLCs!"

My thinking for how to actually then develop and deploy it was that we'll start with just regular channels. Start with no multi-hop functionality at all and get people using channels. Then start to extend that into multi-hop HTLC kind of stuff. That's not really what's happened! But just because the HTLC stuff was a bit less developed, in that the HTLC general structure works, but there's still all these questions about fees and about how routing is really going to work.

So I think it can work, but to me it was like, "okay, let's start with the core channels, bi-directional and indefinite duration and that stuff's really great. Then work our way from there." But that's not really what happened, I guess.

Peter McCormack: How much time did you spend wrestling with different ideas for scaling? Because one of the things that stood out in the white paper to me is that, I'm just going to quote you, it says, "while it is possible that Moore's law will continue indefinitely and the computational capacity for nodes to cost effectively compute multi gigabyte blocks, may exist in the future. It's not a certainty." So I'm guessing you wrestled with on-chain scaling?

Tadge Dryja: Yeah. The stuff I'm working on now, I'm not really actively working on Lightning and haven't been for almost six months to a year. So the thing I'm working on now, this utreexo accumulator, I guess you'd call it on-chain or layer one scaling, in that it doesn't use payment channels and it is a way to reduce the size and increase the scalability of full nodes.

So it wasn't like, "we want channels." Channels certainly have limitations in comparison with just regular on-chain transactions because you have to have these persistent relationships. But it was a general idea of... Even when we were working on it, it was, "oh, this is a little bit of a mess." This is sort of NAT for Bitcoin, network address translation on the Internet, which is kind of a hack, but it makes the internet work!

It's like, "okay, well this is a little bit of a hack." It's not the cleanest design because you've got these persistent channel relationships and routing and stuff, versus the regular Bitcoin layer one, which is just, everything can immediately and directly connect. So it's not like a ideological thing, it's just, how can we get this to scale? In retrospect the technical limitation... So Moore's law, it does seem kind of dead.

But it's not even the technical limitations, there's long term concerns with the fee market and stuff. So a lot of the debate when the block size scaling stuff was going on was about, how fast can a computer do this. But I think an even more tricky question is, let's say you have an amazing computer, there's some new discovery and computers are a hundred times faster.

Does that mean that you should say, "okay, yeah we'll have huge block size, no real limitations", because long term when the block reward disappears, there's a lot of problems that happen when there aren't fees. So I think that's an even harder concern than technical limitations.

Peter McCormack: So I've come into quite a few criticisms of Lightning as well and some of them I'm going to raise with you and it will be interesting to get your feedback. But also I wasn't aware that you are working on a separate project for an on-chain scaling thing. Can you explain what that is that you just mentioned?

Tadge Dryja: There's a Github. The paper is still not public. I need to clean it up and make the citations and diagrams. But the code is on Github, it's called utreexo. I gave a talk about it at the MIT Bitcoin expo. So there there's a little video or slides there I think. The idea is you take this hash based accumulator and instead of storing... Right now in Bitcoin, you run a full node, you download the whole Blockchain and you store the entire set of UTXOs, which are sort of where the Bitcoins live.

That's about 200 gigabytes right now. There's about 60 million different coins. You store all that on your hard drive or SSD and it's slow and it's big. So the idea of utreexo is that you don't store it at all. You store this little merkle tree representation of it and then when someone wants to spend a coin, they prove that the coin exists and then you verify that.

So you can run a full node... I'm sure with utreexo, people are going to start arguing and debating and stuff. I don't know if the Bitcoin Cash crowd will hate it, who knows! I argue that it's a full node and that it fully verifies all the signatures. It fully verifies every state transition in the system, but it doesn't have the UTXO itself. So it needs people to give proofs. That is the main downside and those proofs do take up space.

So you have to download more, but you have to store less and I think in many cases it's a lot faster and easier. So that's the thing I'm working on now. I haven't really been working on Lightning since last summer. I still sort of participate. I went to the... There's an Australian Lightning meet up, but I have my own implementation that's uses LIT and it doesn't comply with the BOLT spec, there's a lot of things that I argued against in the BOLT spec.

I was like, "no, don't do this!" In part of it is because I'm like, "I sort of made this, so I should have a say." But then there's a bunch of other developers and they're doing it their way, so it's like "all right, I don't know!"

Peter McCormack: So why did you step back from working on Lightning?

Tadge Dryja: A lot of it was just that it was frustrating and I saw that they were going with their BOLT spec and there's a bunch of teams with lots of money behind that.

Peter McCormack: Do you mind if we talk about this?

Tadge Dryja: Sure, yeah!

Peter McCormack: So I've interviewed a couple of people who've had criticisms. One of them I took a lot of stick for, but I interviewed Peter Rizun. The reason I interviewed Peter Rizun is despite what everyone says about him, I don't believe it's binary, that 100% of what he says is wrong. Also I wanted to hear from somebody who I feel wants Lightning to fail, so they're really going to look at it.

I also spoke to Dan Robinson, I think somebody who is a bit more respected and rational. They both came with a lot of criticisms, which I find it hard to technically argue against, but at the same time concerned me. So I'm going to jump forward a bit. Let's talk about some of those things. Firstly, one of the things that Peter talked about was that Lightning scales transactions and not users.

He has a problem that if you're scaling transactions and not users, if Bitcoin was to rapidly grow, you will still have a problem on boarding enough people, because say the limit is 250,000 people a day and there was a sudden influx, that's going to push up the network fees. So he said that doesn't solve that problem at all.

Tadge Dryja: Yeah, I mean it helps a lot. I don't think you can claim... So the problem with Lightning... So when we did Lightning Labs and we're pitching to VCs, for me, from my perspective as an engineer, I mainly focus on the limitations, because that's what engineering is, it's the trade offs and limitations.

I'm not good at pitching it and being like, "hey, this is going to solve all the problems!" That was a source of tension when Joseph would say, "this can scale to billions of transactions a second." I'm like, "dude, come on! No, it can't. Where are you getting that number?" Maybe you could come up with ideas where it does, but it doesn't seem realistic.

So I would never want to pitch Lightning as, "oh, this will scale, this solves everything," and I'm pretty sure there's a video of me giving a talk at SF Bitcoin Devs in 2015 fall I think, where I was sort of saying that in the future if you have these, 1mb whatever restricted block size and Lightning network, rich people and companies can all use Lightning, but the average user probably can't. So I don't think you can just say, "okay, we have Lightning, we're done," at all!

Peter McCormack: Right, okay. So then that echoes another point or concern I've had, whereby it feels like potentially Bitcoin becomes a two tier system where the base chain is for the Bitcoin rich or people that have invested early who have a lot of Bitcoin or companies, yet say somebody new wants to start using Bitcoin in 10 years or 20 years, they probably can't afford to use the base chain because the fees might be too high and therefore they're forced to use Lightning only.

Also if they're only using Lightning, are Lightning Bitcoins different from base chain Bitcoins? Are we saying the base chain is more secure? So I got wrapped up in that. Is that kind of your thinking too?

Tadge Dryja: So those parts I don't have as much concern about. I don't think it's realistic that you'll have like, "oh, I have this Lightning channel and I'm stuck in it and I can't use it and switch to something else", because your fees may become significant and it may be the equivalent of... We saw $20 fees a year and a half ago.

So then you'll have people who have channels open who do transactions and it could be a pain point, but I don't think you're ever going to have a channel where you're really stuck in it and you can't move to another provider. It may be a pain and it may be costly. But I think it's more likely that if someone's like, "look the fees for this are really expensive.

I'm just not going to use Bitcoin or Lightning at all", because because if you don't have Lightning, it seems like it's going to be even worse. It moves a lot of transactions onto the Lightning network, which then makes room for higher value transactions, such as opening channels on the main network.

Peter McCormack: Well, that goes onto the other point, is that Peter was saying that friction from layer one bleeds onto layer two. So if we get to the point where we have high transaction fees on the base chain, then you're going to have high fees for opening up a channel. Obviously you have two transactions or is it three transactions to open a channel, I can't remember.

Tadge Dryja: To open, should just be one. But to close is another and potentially more than one.

Peter McCormack: So say if you open up a channel and it's a $20 fee, you have to do enough transactions in that to cover $20 to make it efficient. You also run the risk that somebody closes that channel on you and you lose your fee. He also said the other thing is that, as fees go up, your channel balance will go down because it has to cover the fee for if the channel closes?

Tadge Dryja: Potentially, yeah. So actually in the Australia meeting, it was just all about fees. Well I think it was Chatham House rules, so I shouldn't say who said this, but it was kind of funny. Someone would just be working on their laptop look up, "oh, are we still talking about fees?" And just go back! So the problem is it's quite complex to deal with fees.

I would say that Lightning only matters really when you have significant fees, because if fees are basically nothing, just use the main chain, it's free. Yeah you have to wait 10 minutes. Well I wouldn't say that... I think the really interesting thing is there are really good use cases for payment channels, even when fees are extremely low. They're not quite super low right now, but they're variable right now and sometimes they're very low and sometimes they're not. So such as an exchange.

To me that seems like the first real great use case, where you don't even need HTLCs. You just say, "I'm going to open a payment channel with Gemini and my coins are on my side of the channel and when I sell them, they go onto your side of the channel", so if Gemini gets hacked, I don't care. I have custody of everything that's on my side of the order book.

You don't even need HTLCs for that necessarily and that takes a lot of the risk. So I know Arwen is a company that Ethan Heilman is doing with Sharon Goldberg and that's in Boston. They're doing something sort of like that, but for cross chain swaps. But I think even before cross chain swaps, it's just like, why is there a deposit button? There should be a channel button.

A deposit is already an on-chain transaction and the withdraw is going to be another on-chain transaction. There's almost no increase in size for that kind of thing. So that seems like the first real easy use case. That's a total win and I don't really see any exchanges using that. So who knows, maybe they will soon!

Peter McCormack: Yeah. So that makes sense. But when I start to think about in terms of say, a store wanting to sell a whole bunch of things, I start to think, well am I going to be doing that many purchases? Do I need my channel open for that long? Also in terms of the store, they have to have liquidity, they have to actually lock up liquidity to support people and I'm starting to think, "hmm, that doesn't make sense." Then if the fees go up on the base chain, I don't know, it starts to become a problem for me. The place I've seen it, that I did quite like it and it's a custodial solution, but tippin.me?

Tadge Dryja: Yes.

Peter McCormack: So that's quite neat. So for my work, I get people giving me tips. Over the last two months, I've had say $400 in tips. Now, some of them break down to 100 sats or 1,000 sats, but they all add up. At the end of each month, I can withdraw.

Tadge Dryja: That's one of my big problems with the BOLT specification and the implementations in that you can't actually do 100 Satoshi HTLCs! I generally like the people working on these things and I understand why, but I feel like it's dangerous because I saw this in Bitcoin in 2013/2014, mostly 2013, where you got a lot of hype and people thought it could do everything.

People were saying, "Bitcoin, it's trustless, it's free, it's instant. Everyone in the world can use it and do send money anywhere instantly!" The actual people working on it, the engineers are like, "whoa, it's not free. It's not instant. Here's all these restrictions." But that gets drowned out by the sort of euphoric, "this is amazing!" You don't want to be the rain on people's parade and I worry about that with Lightning where you're saying, "oh, we can send one Satoshi anywhere," and it's like, well wait, there's a qualitative difference in sending 0.5 Bitcoin payment through these channels and these really small ones that are sort of trimmed and you can't actually make HTLCs that small.

So you end up trusting... It's a different way of trust. I don't know. So that's sort of something that's weird. People on Twitter have little Lightning stuff in their name and it's just weird! Yes, Lightning is really cool, it's really powerful technology, I've been working on it for years, but at the same time it's just weird seeing it become this hype thing and I don't want to be hyping it that way.

Peter McCormack: So you think it's over hyped and it's almost just like a tool? A much smaller part of the ecosystem with smaller edge cases than people are expecting?

Tadge Dryja: I mean, yeah. I think it can be very useful for a lot of things, but not everything. It's not a silver bullet. There's still plenty of issues. Even if Lightning works great, there's tons of issues left to solve in Bitcoin. It's still great to work on and I don't want to discourage it or say bad things about it of course and I definitely don't want to play into the story... It's just gotten very tribal kind of thing, where, "oh, these people like Lightning and these people like this other thing," and it's like, "wait!" So it's weird!

Peter McCormack: Well, I get it, it is weird. So I got a lot of stick for agreeing to do the interview with Peter Rizun and the tribal thing does come into play, because what happens is that I come across difficulties in Lightning and I start to monitor other criticisms and I see a real firm defense of the criticisms. I don't see much open kind of acceptance that maybe some of the criticisms are correct and it comes with insults and attacks.

I started to have a little bit of sympathy with some of the people who are proponents for on-chain scaling and again I see all the criticisms for that. Trying to navigate between the two and have sympathy for both sides and try and understand their perspective becomes really difficult. I'll just add one more thing is that, I do not believe that every single person who is a proponent of on-chain scaling, and by the way, I don't own any Bitcoin cash, but I don't believe they are all scammers and I don't believe they are all technically incompetent.

I believe they think they have a solution and I have those sympathies. But trying to express those sympathies usually comes with some form of attack that you're technically incompetent or you don't understand economics. Do you understand that?

Tadge Dryja: Yeah. So that is a big part of the problem, is that it's become people just yelling and insulting each other and not like... Even the people who I work with mostly are Bitcoin core developers, Cory Fields works at the MIT DCI, the lead maintainer of Bitcoin core Wladimir he's an employee of DCI, we don't interact with him that much. He's sort of off in Europe and he does his own thing and manages it.

But I generally agree with these people and yeah, the goal is... It's tricky though because I've talked to Peter Wuille and he's like, "yeah, I don't think everyone can use Bitcoin. We don't know how to make that happen. We want to, but there's a lot of issues and problems." The general thing is, it's preferable for it to be this small thing that still maintains the security, than for it to become this big thing that loses those properties and becomes more diluted, into something like Paypal.

So that's sort of the choice. But I think most people agree and want more people to use it. I think a huge argument is a lot of people paying small fees, feels a lot more sustainable than a few people paying large fees. That seems like a much better system. But there's technical issues, which utreexo, the thing that I'm working on now, I'm not going to argue to anyone that, "hey, now you can increase the block size because look, it's totally feasible to have a giant UTXO." 

I'm not going to start that argument of course. I think it may long-term lead to that where it's like, "hey look, our computers are better. there is robust transaction demand and we've got these scaling solutions. So yeah, increase the block size." Or hard forks are tricky, so maybe some kind of extension block. But yeah, I think these all have to happen in concert.

I think most of the Bitcoin core developers have have said that. It's weird that it became this very polarized thing and I sort of have ideas of why this happened, but initially a lot of people who are still working on Bitcoin core have said, "yeah, we should do a block size increase". Then with SegWit it was a block size increase, but then wasn't seen as one.

I remember Peter Wuille's talk at scaling Bitcoin in Hong Kong and that was this sort of SegWit reveal, where it was kind of a mic drop thing where he said, "hey look, we fixed malleability, we increase the block size and it's a soft fork and it has all these amazing properties. Done, problem solved!" I was sitting next to Joseph actually and he was like, "this is great", I'm like, "yeah, but oh, this is going to be a mess!"

People were like, "what are you talking about? This is awesome." But it was the way he said it. It sort of seems like, here's this guy works at Blockstream, but then again, Peter is the nicest, smartest guy! He's the biggest asset to Bitcoin development I think. He was really excited about it. He was just like, "this is amazing. We figured out the best way to do it and I do think that it is the best way to do it."

But the way it was sort of like, "oh, I'll figured it out guys. All done! The conference is over", and it was on the first day in the morning. So everyone else there, I think who made it, for example Roger Ver was there, all of these people probably felt like, "what the heck? This guy just thinks he solved it. But I didn't even get to talk. We didn't even go through anything?" All of the core developers are like, "oh, okay, we're done." I think that was one of the real things that divided people...

Peter McCormack: Wow.

Tadge Dryja: ... And I don't know how you stop that. Especially with the, "hey, we figured it out! Great, we got it!" It's just politics and stuff. So yeah, it's weird right now, but I hope that eventually people can work together. I don't know!

Peter McCormack: So I kind of put out a tweet storm recently. At risk, I kind of said, the shouting at each other isn't working. It's just not working. Bitcoin cash is not going to go away. They're not given up and despite everything you think, they're not going to go away. I think it would be a net benefit to all, to stop arguing and let people work on their own chains.

One of the reasons I kind of thought about that is, I've never really talked about this, but I went down the Bitcoin maximalism path once, got there, didn't feel comfortable, and then also got to that point where I was thinking, "well, perhaps this can't scale, perhaps there's an impossibility to scale in the way people want, where billions of people can use it and it's affordable."

Tadge Dryja: Yeah that's hard!

Peter McCormack: Yeah, it is! So I imagined, do we have a scenario where we have multiple currencies and the reason we have multiple currencies is we have ones that take the stress off the main chain. So you have Bitcoin or you have another Bitcoin say Bitcoin cash, which has a different bunch of users. Is that such a bad scenario? Do we have to have one cryptocurrency?

Tadge Dryja: Yes, it'd be better if you could have one that supports everything and everyone uses it because that's a lot less sort of friction and to me the whole point of money is taking sort of an N-squared problem and making it into an O&N-problem where if you've got a million different kinds of money, and we sort of saw this with all these ICOs, "this is money for taxi rides" and it's like, "well, I don't want to have money for taxi rides!"

The whole point of money is that I can trade hamburgers for money and then money for taxi rides and I don't have to barter with burgers for taxi rides, which if every different asset in the world has its own currency associated with it, we're basically right back to barter. So yeah, taking that to the extreme, one currency for everything is very efficient in that sense. But yeah, I don't know if we're going to get there.

I think there's even bigger incentive reasons why that's not happening in that, you can work on Bitcoin, I think it's really fun, it's cool and MIT does pay me to work on Bitcoin, which is cool. But it's not like ICO money! That's why we see so many of these ICOs where people make new currencies, because then they get rich and you don't really get rich coming on to work on Bitcoin.

I think it's a problem. Even where I work, a lot of our funding comes from rich guys. People who have a lot of Bitcoin or companies and it's not an unsustainable funding model, there's things that have been like this for a long time, but it's a big difference between that and a regular startup or a for profit company.

Peter McCormack: Yeah!

Tadge Dryja: So it's the general open source sort of funding problem where you have billions of dollars riding on open SSL and it's one guy in Germany making it work or something!

Peter McCormack: Okay. Just back to Lightning. Have you looked much at Dan Robinson's critique of Lightning?

Tadge Dryja: David Robinson? Yeah, he did that talk about whether HTLCs are considered harmful. Many of his criticisms are true. I don't think that the, "well let's just not use HTLCs at all", is a real solution! So yeah, I've talked to him and many of the things he says are like, "yes, these are problems." So I agree with a lot of that. I don't necessarily agree with his solutions.

Peter McCormack: So you don't agree with the Packetized Payments, the Interledger thing?

Tadge Dryja: His idea of just sending it optimistically and then trust... Send it optimistically and hope it doesn't go bad and then when it does go bad, well you're only out that little part. That can work for some things, but I think there's a lot of issues with it. So for any kind of larger payments or his Rainbow Network thing, where you don't really have a third party oracle and then any kind of volatile asset, as soon as there's a big dislocation, one party just disappears.

So I have another paper called "Discrete Law Contracts", which builds off of Lightning and actually a lot of the Lightning design was when I was thinking about how to do these smart contracts, because I remember talking to people in Ethereum and I'm like, "wait, can't Bitcoin do a lot of that?" So Discrete Law Contracts uses channels. It does not use HTLCs, but uses the same channel structure to have derivatives or smart contracts, I guess between different assets and you need a third party oracle.

The nice thing is the oracle has no idea the contract's happening and stuff. But yeah, if you have these sort of, "I'll trust you for a little bit", there are cases where that works, but then there's a lot of problems with accountability, especially multi-hop HTLC style things. When you're just saying, "oh, I'll optimistically send a little bit and hope it gets there", to get accountability is very difficult in that kind of scenario.

Peter McCormack: All right, well let's take a look at Lightning. So it is out there, it's in the wild, it's being used. You've obviously seen the work, you've obviously had a play with it. What's your general view on it as you look at the network now, what are you impressed by? What are you concerned by yourself?

Tadge Dryja: I think it's still sort of... It's on main net, but it still feels a little test-net like, in that it's not people using it for real transactions. They're not buying goods on Newegg or whatever. It's still mostly playing around, which makes total sense. I hope that the next phase of adoption is that exchanges will start using this. I don't know if they will, but it would be really cool and I think a lot safer if Coinbase, Gemini, Kraken, whatever, they're like, "hey, we support Lightning. We don't even necessarily support routing and things like that, but you can open a channel with us and you can send payments to us very quickly."

You can even make it pretty easy UI wise, where it's like a meta withdraw where you're like, "look, you open a channel with us and you can then deposit and withdraw to us instantly. So when you're done trading for the day, take all your money back onto your side of the channel" and we don't consider that your deposit with us. Then when you go to start trading, you deposit it or something. So I think that would be really useful for a lot of people, because right now, one of the big problems in Bitcoin is that there is so much Bitcoin on these exchanges.

You talk to people and they're just like, "yeah, I have a lot of Bitcoin" and they've never installed any software. They've never downloaded a block. They don't have a private key. They just use exchanges. So getting from that to okay, at least they have a channel and then it may be SPV, or something. But yeah, I think that'd be a big improvement. I hope to see that, but we'll see!

Peter McCormack: So single channels, you're kind of a big fan?

Tadge Dryja: Okay. Many of the problems are from doing multi-hop payments. A lot of the difficulty and complexity is that when you only do a single channel, so many things get so much easier. But much less functionality! The Lightning network, you want to be able to say, "yeah, we can do these routed payments. They're much more powerful."

But that's at the cost of complexity and in some cases a lot of security and sort of trust issues. But if you're just like, "hey, I'm connecting with my exchange. I don't even care about multi-hop, I just want to quickly with deposit and withdraw." That's a solved problem.

Peter McCormack: Cool. Okay. If you were going to go back then and re-design the white paper and you were in control, what are the main changes you would make? I know big question!

Tadge Dryja: I wonder sometimes if we just never mentioned fees at all, if you could just sort of like be, "oh, there's no fees in Lightning." I don't know and that might stick because the idea of fees and I think that was a little tricky, is that people think, "oh, I'm going to run a Lightning node and make a bunch of money off of routing payments and taking fees."

I don't know how that's going to work, I don't think it will. It might be just that you don't have fees and there's a little bit of altruism, but it's tiny and the way BitTorrent works where there's no fees, no-one makes any money, but somehow you can download all the movies for free! But other than that, we wrote what we could do at the time. So there are definitely things that have changed in the actual op-codes used and I don't think there was anything about watch towers, things like that, but the general idea, it was okay!

Even today it's not super clear how to easily improve on it. There's definitely other constructions. There's eltoo, there's other types of adapter signatures and stuff and those are really cool, and potentially more powerful, but they're also complex. So I think part of it is, keep it simple and then build complexity. If you start everything, it gets really hard to build.

Peter McCormack: Well that was a thing. So when I caught up with Christian Decker again, we talked about how they're going to solve some of the problems. He talked about eltoo, he talked about watch towers, he talked about splicing, he talked about channel factories and I'm not a technical person, but when he was talking through this, I was just kind of just like, "huh?"

Tadge Dryja: Oh yeah, some of this stuff is really complex! Even the people working on it, when we were in Australia, it was like, "oh man, this?" So it's not that it's not doable. It's just that it might not be... it's a really complex problem. This world has lots of complex solutions. We're talking on a computer right now that's got 20 nano... It's doable!

But that's taken thousands and thousands of people doing all this research. So some of these things, as they get more complex, need a lot more resources and time and effort to do. If it were up to me, I'd be like, "okay, start with the simplest part and then try to build out", because there is the tendency, even on the stuff I do and the stuff everyone here does, is that you want to work on the cool hard cryptography projects and then refining something that it's not actually that interesting, it's like, "oh, well we know how to do that, that's just an implementation thing."

But actually refining it and getting it really working well and people using it, it's harder to get people excited about that sometimes.

Peter McCormack: Do you think it's almost like people feel they've gone too far now, that they can't step back and go, "okay, I think we've kind of screwed up. We've got too complicated. We need to step back. We need to simplify this." Do you think it's too difficult to do that?

Tadge Dryja: I don't think so because a lot of the really complex stuff has not made it into any of the implementations. It's still sort of testing. So the current implementation with HTLC and stuff, I think it's definitely retractable and that can be refined and made better. Some of the more complex stuff going forward, yeah, it's tricky. But I think try it out. People are developing it, so that's good.

Peter McCormack: This wasn't the call I expected Tadge. I don't know why, but I expected a very pro Lightning, this is what's happening, here are the solutions to the problems, but I feel a sense of dejection from you?

Tadge Dryja: Well, so I do want to make clear that I think it's really cool. I want people to use it. I want people to research it and develop this stuff. I think it's a really great solution for a lot of problems, but I've seen like sort of a weird tribal... Everyone's like, "oh, Lightning, it's going to be the best thing ever."

It's like, "wait! It can't actually do that." So that's why I'm sort of hedging, in that I think it's a part of a scaling solution, but I think there's other stuff and the stuff I'm working on now is a totally different way to help scaling.

Peter McCormack: So what's the timeline for this thing you're working on?

Tadge Dryja: So the code is out. I need to get this paper finished hopefully in the next couple of days and then get it on ePrint or something. Then get a wallet working with it. I hope to be able to do that sometime this summer. First on test net, but it shouldn't be too bad because most of the code, most of the sort of tricky part and novel part of the code is out there and it's on Github and people are looking at it and programming with it.

Peter McCormack: Sorry, just to understand, because again, as I said to you, I'm not the most technical. Does it optimize block space?

Tadge Dryja: Okay. It actually makes blocks bigger. So if you have a 1mb block, it retroactively, it adds these proofs onto that block, so now the block is a little over, it's 1.3mb or something, which is bad in a sense, because it's bigger. But what it does, is it means you don't have to store any of this stuff. So right now in Bitcoin, people can do pruning.

You have to download 240 gigabytes or so and by default it stores those 240 gigabytes, but you don't have to, you can go into config and say pruning equals 5,000 or whatever. Then you throw away all the old blocks and you just keep the current state of the system. So that is somewhat used. Then this is an even more powerful version of that where you say, "I'm actually throwing away all the old blocks and I'm throwing away the entire state of the system.

I'm just keeping this 1kb little image of the system and that's enough that I can verify everything." So you'll be able to run, sort of the cliché, like you can run a full node on a Raspberry Pi. Well actually in this case you probably probably can. In many cases when you're running a full node, the bottleneck is your hard drive where a block comes in and you've got to read 10,000 different spots on the hard drive and that takes a long time. This will make it so you get it in over the network and you're all set.

Just what's in RAM is enough to verify. So this is a problem, like in Ethereum, it's a huge problem where you cannot run Ethereum on a hard drive. You even need an MVME SSD because there's so many different disk seeks. So this would help in Ethereum, but it doesn't apply to Ethereum because of the way Ethereum is designed, which is too bad for them I guess. But maybe some techniques similar to this would be applicable in Ethereum, but it works great in Bitcoin. So I'm pretty excited about it. 

I think it has downsides, but the downsides are fairly limited in that unless your Internet connection is really slow, your bottleneck is not download. But then again, I've argued with people who work on Bitcoin. I talked to Greg Maxwell on IRC and he thinks... Well he thinks lots of things are dumb! He didn't say it was dumb, but his goal is reducing bandwidth and some people think, "oh, the problem with Bitcoin is you got all this storage space and you got all the CPU" and other people think, "no, the problem is it's downloading too much."

So this actually makes the downloading worse, but makes the CPU and disk access better. So it depends. Some people are pretty enthusiastic about it that I've talked to. Some people think it's not important or actually it makes things worse, but it's optional. It's not even a soft fork. It's just another thing you can do. So hopefully it's another tool to use. I think Lightning is the same way, where it's applicable, use it. Where it's not, don't.

Peter McCormack: What's Gregory's take on Lightning? Because I've never actually spoken to him.

Tadge Dryja: I haven't talked to him much about it. I do remember when we're doing the whole Lightning Labs thing and talking to VCs, I did go through and try to get all of the people's comments and Greg did say some good things about it, in IRC or Bitcointalk or somewhere. So I remember copying, pasting, getting a list of like, "here, see all the people that think we're good!"

So I do vaguely remember him saying positive things and most of the other developers have too, but the sort of general Bitcoin cash versus Bitcoin thing where Bitcoin Cash people think it's all about Lightning, most of the core developers have very little interaction with Lightning at all. So if you, if you talk to most of the people working on Bitcoin core, they're like, "oh yeah. Blue Matt is writing a Rust Lightning implementation." But most of them haven't really looked at it or they're sort of aware of it but aren't really keeping track much.

Peter McCormack: Well they're all old school Bitcoiners, they can afford the base chain!

Tadge Dryja: Yeah! But yeah, fees, who knows!

Peter McCormack: That fee thing is the one thing I've never found a solid answer for. I've wrestled with it again and again, I keep speaking to people. The problem I'm coming into is the block subsidy will go and the block subsidy helps miners secure the network. If the block subsidy goes, it needs replacing by fees.

Therefore, it needs either lots of small fees or small, big fees, but it's going to rely on that, or we're going to lose security. I'm yet to find somebody who can give me an answer to that conundrum and it's kind of like, "well, it's 20 years away or 30 years away. We don't have to worry now," but I'm kind of worried!

Tadge Dryja: Oh no. I think that's an important... So there's a paper, actually that we were talking about the other day here, "Bitcoin is Unstable Without The Block Reward" by some people at Princeton, 2 years old or so. I have some problems. There's some interesting things in the paper, but I think their premise is sort of messed up in that they assume unlimited block size in their model.

It's like, "well no. Wait! That was sort of the whole argument. You can't just assume this and then make the argument." But anyway! I think that's a sort of scary thing and we don't have a good idea of how it works long term in the future. The ideal is that, yeah, there's a lot of demand for block space, people pay significant fees and that's enough to keep the miners running and that the mining keeps chugging along, with maybe an occasional re-org for a few blocks here and there, but long-term it works.

But it would be cool to have a really nice paper, analyzing all the different long-term scenarios and getting a good idea and a good argument for how this can really work, in a sort of mathematical model. I haven't seen that paper yet. I've seen paper is doing the opposite. There's a paper by Eric Budish and the Princeton people. So I've seen papers that are sort of the opposite saying, "hey, this this stuff doesn't work as well without this block subsidy," and that's probably true.

But I don't think it's impossible. I think it's quite possible that there is a future where we have this sort of constrained block reward or people have talked about soft forks where you can make the miners have to do more work... There were some talks at Scaling Bitcoin about these kinds of things. So there are ideas, but I don't think we have a solution of here's how it's going to work.

Peter McCormack: Have you ever wrestled with the idea that there may be a change where there will be some form of even small but permanent inflation and a permanent subsidy?

Tadge Dryja: Oh yeah. That would be so much easier.

Peter McCormack: But you're not allowed to talk about it!

Tadge Dryja: From a programming point of view, It'd be so easy.

Peter McCormack: But from an economics point of view, you're not allowed to discuss this!

Tadge Dryja: Yeah! To me personally cool part about Bitcoin isn't necessarily that there will only be 21 million. If there was a fixed inflation schedule, where even if Satoshi just said, "look, every block, you get 100 Bitcoins forever", that would still be a really cool system. But you can't go back to that I think. Yes, the early people get rewarded because there's fewer then and then the difficulty goes up.

I think that would still be almost, they may be as interesting as a system, because the properties that to me are interesting about Bitcoin are that it's kind of permissionless, it's sort of anonymous, you get this privacy and that's kind of cool. The hard money, "okay, there's never going to be more than this," semi-deflationary kind of thing, that's okay. I have no real problem with it. So if you can get it to work technically, sure. But it makes it harder from a technical point of view and Satoshi made the software, disappeared and everyone else has to deal with this 40 year problem. He doesn't!

Peter McCormack: No, he's back because he's suing me!

Tadge Dryja: Oh, right!

Peter McCormack: Yeah. When I spoke to Peter Todd, he said that if you can't handle say a 1% inflation annually, what's wrong with your life? I would prefer 21 million, but does the thought of inflation scare me? It doesn't. Does the thought of trying to talk scare me? Yes, it does.

Tadge Dryja: There's the idea that you don't want to pull the rug out from under people. This is why hard forks and a lot of the people, a lot of the core developers don't like the idea of hard forks. They think it's bad. Technically there have been hard forks and there was one in October, from a technical point of view.

Peter McCormack: Was there?

Tadge Dryja: Yeah. So there's this bug.

Peter McCormack: The CV bug?

Tadge Dryja: Yeah. Technically a hard fork!

Peter McCormack: Really? Sorry, this is the first time I've heard this.

Tadge Dryja: It was not exploited, so there's no chain split. But when that bug was introduced, the software with the bug would accept blocks that would not have been accepted by previous software, which from the letter reading of the definition of hard fork, that's a hard fork. It was then a soft fork fixing the bug, whatever! So it was unintentional. I don't think there's been an intentional hard fork, but there have been, I guess two-ish unintentional ones that in retrospect are like, "oh, that was definitely a hard fork!"

But it wasn't exploited of course. But so I do agree that trying to pull the rug out from under people and people have definitely bought into the "there's only 21 million" and so you really don't want to change that. I would say you can't change that without calling it something else. It's not necessarily Bitcoin at that point. If on the other hand, it's not a stable system and we can't make it work, maybe call it Bitcoin 2, maybe call it Bitcoin Inflation, whatever, but say, "okay, we've got this hard fork.

It's a different coin, but it has one coin per block, indefinite inflation, but it works better and you that's the best we could do." Hopefully we can make it work with the 21 million limit. It's not a subject of intense research because people have been like, "yeah, this is a problem we have to deal with 10, 20, 30 years from now", but I think it would be cool to look at and see if we can make it work.

Peter McCormack: Well, I think another thing the prevents it being discussed or people aren't keen on, is it affects the value of their Bitcoin, the Bitcoin they're holding. If Bitcoin was changed to have some kind of inflation, it would devalue their Bitcoin. I guess there are a lot of people who have very strong opinions and have a voice, who hold a lot of Bitcoin.

Tadge Dryja: Yeah. To some extent I agree. But at the same time, I think the uncertainty... I guess the issue is there's a lot of people who buy Bitcoin and value Bitcoin and they don't know about all the uncertainty about all the long-term problems. The idea that, "okay, we've got it all solved", but all the people working on it, we don't know what's going to happen!

We don't have solutions for these things. And same with Lightning! You go to the Australia meeting with Rusty and all the people working on Lighting, it's like, "oh yeah, we need to figure this out." Or the core developer meetups that we have and there's one in Amsterdam in a month or two. There's all these things, we're like, "yeah, we got to figure that out!" So it's not like these are solved problems.

There's still open questions and I think if we do solve it... Either way, if someone comes out with a paper, hey, maybe I'll work on a year or two, here's why it really can't work with just a fee model, here are these inherit instabilities. Or on the other hand, here's how you can make it work here. Here are the scenarios where yeah, it can work. Fix the issuance, goes to zero and it's sustainable and it's stable because of this. I think that'd be really useful to know one way or another, to have better research on that stuff.

Peter McCormack: All right man. Well listen, I'm conscious of your time and we started a little late. Just to finish off, for you in Bitcoin right now, what are the most important things you think are being worked on and most important things that you want to see solved?

Tadge Dryja: So short term, I think Taproot and the Schnorr signature stuff, getting that in would be really cool. It also gives people a good idea because then you can do a soft fork again! We haven't done one for two years and it's sort of, getting that in and be like, "oh cool we can still make some, some soft fork progress on these things."

I think privacy is one, that I'm not personally doing a lot of research on, but I hope for there to be better privacy technologies that can get implemented in Bitcoin. There's cool research going on with Mimble Wimble, Zcash, things like that. But Bitcoin itself, I think to me, it'd be really cool to see, improved privacy things. It's not my focus, but I talk to people a lot. So Madars Virza who works on Zcash, he's also the DCI and we talk about stuff like that. So that's an interesting research area.

Peter McCormack: All right man. Well look, this was an amazing way to do my 100th episode. How can people keep an eye on your work and monitor what you're doing?

Tadge Dryja: So there's Github, github.com/mit-dci. The utreexo code is in there. Some people have been looking at it. It's pretty ugly and so I want to clean it up and make it so that people can test it out. Some other students at different universities have been looking at it and stuff. So there's that.

It's not super easy to read, and then I'll have the paper out soon and there's a video from the Bitcoin Expo. So if people are interested in that, cool! Talk to me about it. Then the DCI in general, there's a lot of people, not a ton of people, it's like six or seven people, but doing cool research on this stuff. And if you're in Boston, swing by, we're friendly!