WBD099 Audio Transcription 

Dan Robinson on Why HTLCs are Harmful

Interview date: Tuesday 23rd April 2019

Note: the following is a transcription of my interview with Dan Robinson from Paradigm. I have reviewed the transcription but if you find any mistakes, please feel free to email me. You can listen to the original recording here.

In this interview I discuss with Dan why he believes that HTLCs are harmful, the problems they cause with Lightning and why he believes that packetised payments are the solution.

“There are much better ways to do atomic exchanges across payment channels than having these ledger enforced HTLCs”

— Dan Robinson

Interview Transcription

Peter McCormack: Hi Dan, how are you?

Dan Robinson: I'm great. Thanks for having me on.

Peter McCormack: Thank you for coming on! So when I picked Peter Rizun to interview, I got a lot of stick, but two or three people got in touch with me and said, "you really need to speak to Dan" and then you ended up following me on Twitter and a couple of weeks later here we are. So thank you for this. I'm doing a whole series about Lightning, a whole month on Lightning, a whole bunch of interviews.

But I do want to have a balanced look. I do want to look at some of the criticisms as well as, talk to people who are supporters of Lightning. So it's great to have you on. I've seen a couple of your presentations. Thank you for sending me those. I think it would just be helpful, can you just give a background of who you are, what you know about the tech and why you're useful for this conversation.

Dan Robinson: Sure, yeah. So to be clear, I consider myself both of what you were saying, which is someone who has I think a lot of criticisms of Lightning and also a supporter of the technology and someone who is ultimately routing for Lightning to succeed. My name is Dan Robinson. I'm a research partner at Paradigm, which is a crypto asset investment firm. I'm here though representing my views and not those of the fund.

Previously I worked at Chain and then later at Interstellar when Chain was acquired. Before that I was a securities lawyer in New York. I've been, for most of my tech career, a Blockchain protocol researcher and I've worked on generally a lot of scalability solutions, a lot of smart contracts, scripting virtual machine, higher level languages and some cryptography and confidentiality. Just sort of the gannet of Blockchain protocol research.

Recently a lot of that has been around second layer scaling, including Lightning, but also including a couple of projects, Interledger and Plasma, which are two that I think sometimes that can show ways that maybe that Lightning can be improved. Then there's another, which I recently came out with a paper on, called the Rainbow Network, which is another sort of alternative layer two scaling solution.

Peter McCormack: Okay. Plasma is what's being worked on for Ethereum?

Dan Robinson: That's right. I think, when you think of it as a general category, it's a slightly different way of doing layer two scaling that currently isn't possible on Bitcoin and would require some protocol upgrades and I could talk a little more about that to actually get some of these advantages on Bitcoin. It isn't what you would say, just like Lightning on Ethereum. It's a different structure and it has different tradeoffs.

Peter McCormack: Okay. Rainbow is something you're working on for which protocol?

Dan Robinson: So Rainbow Network is a sort of a general idea. So right now it's just a paper and I'm not planning to implement it myself, it's just sort of an idea I'm putting out there. It can be implemented more natively on Ethereum or other equivalent Blockchains. But there's actually a way, and it's described in the paper, of implementing a limited version of it, on top of Lightning.

Peter McCormack: I'd also think it's useful just to put it out there, is that you're not a big blocker looking for faults in Bitcoin and you are a fan of Bitcoin. But you are also interested in other protocols. You're not just here to pull it apart.

Dan Robinson: That's right. So yeah, I consider myself generally sort of a part of the Bitcoin community broadly speaking and one of the big projects I've worked on in the past was a Bitcoin smart contract language called Ivy. I'm also part of the Ethereum community and that's something that... I've spent a lot of time working with the Plasma community and then I've worked tangentially on some other projects including Interledger. Then of course, I also consider myself part of the Steller community and I'm friendly with those people.

Generally, I don't consider myself a Bitcoin Cash person because like you said, I think I generally consider myself a small blocker I guess. But I'm friendly with a lot of those people and I think most of the stuff I've worked on has involved drawing lessons from something I've learned in one Blockchain or one community or one set of ideas and trying to apply them in another area to kind of get an idea arbitrage.

A lot of good ideas in the space come from importing something that is maybe even like common knowledge in one area and applying it to another area, where maybe it's not as familiar.

Peter McCormack: So you have friends in different coins, different protocols and you're not out there fighting everyone! Are you some kind of freak?

Dan Robinson: We'll see if I can maintain that once all the Blockchains [Inaudible 08:33]. But look, I think right now I think there's a lot more to be gained from learning from people in other protocols and in fact people are working often on the same problem. So I really do think there's a lot to be gained from knowing a lot of people and being friendly with people in a lot of different communities.

Peter McCormack: Yeah, I heard it from one person that's maximalists shouldn't be so scared of other protocols because Bitcoin actually benefits from ideas being tested out on other protocols.

Dan Robinson: Yeah, I mean that used to be the Bitcoin line, which was no other coin can succeed because Bitcoin would be able to import any ideas that they come up with and that they add. Bitcoin would be able to just add as a future or as a side chain or something like that. You don't hear that as much anymore, in part, and I think it's a shame because Bitcoiners don't seem as interested in changing the protocol, even again through soft forks, even through relatively safer mechanisms.

Even relatively conservative changes like some of the ones I might talk about. So I think they just don't think there's necessarily as much as much to learn and partly out of, I think this kind of hostility. So no, I definitely think that Bitcoiners and people from every community should be interested in and learning from people working on similar problems in other ones.

Peter McCormack: Well, let's get into Lightning. What does Lightning actually mean to you as a technology?

Dan Robinson: So the way I like to think about Lightning and I feel like not everybody necessarily thinks of it this way, is it's a composition of two technologies. One of them is payment channels and that's a way of doing off-chain ledgers. So these off-chain bilateral ledgers between two parties.

The other is a way of having atomic updates between those payment channels and that's to allow someone who has... If I have a payment channel with Peter and then Peter has a payment channel with with Alice, I guess I can pay Alice through Peter, by making a payment to Peter and then having him make a payment to Alice.

So the second part of this is having a way to do those updates atomically. So if you separate these out, I think there's a lot of ways that the payment channel side can be made better and there's especially a lot of ways that the atomicity mechanism, in my view can be improved.

Peter McCormack: Okay. So I'm still at the stage where I don't fully understand it all because I never do. It's always technical, but I gradually get there piece by piece. So one of the things that I don't fully understand is and you can help me understand this. If I want to make a Lightning payment to you, I have to have a channel open with you?

Dan Robinson: You have to have a channel open with me or a path to me.

Peter McCormack: Yes or a path to you. So as long as there is a connection somewhere in the network between me and you could be through a bunch of people, that can happen?

Dan Robinson: As long as there's sufficient capacity on those channels.

Peter McCormack: Yes. Is there a limit to the number of hops one has to take or is there an instance where if it's over a certain number of hops, there's a certain time delay?

Dan Robinson: Yeah. So in theory and in the code, I think Lightning, the protocol supports maybe 25 hops. It maybe 20 or maybe 25. It's sort of an absurd number and nobody really thinks that any payment that has to take 20 hops would be a good idea. The more hops you have, the more fees you're paying and the payment will take slightly longer.

But the big problem is that you end up locking a lot of liquidity up, along the network, during the pendency of that payment. If the payment completes normally as payments typically do, then that isn't a big concern because it's only locked up for maybe less than a second.

But if you're attacking the network, and this is one of my big criticisms of HTLCs, if you're attacking... HTLCs are the way that Lightning currently achieves this kind of atomicity that was I talking about between payment channel updates. If you attack the network by not completing that payment, then all of that liquidity along that entire path is locked up for, I think by default is 24 hours.

Peter McCormack: Right, okay. So we'll get into that. Just a couple more questions first. So, I understand with Bitcoin, that there is a ledger, it's on old nodes and there are tens of thousands, whatever, hundreds of thousands of copies around the world and that's how we maintain decentralization. How does that work the same with Lightning? Is it just Lightning nodes and they're exactly the same and they all carry a same copy of the ledger?

Dan Robinson: No. So the idea of Lightning is that each Lightning node should only have to have information about the history of the channels that it opens. That means that they only learn about transactions that they, either are an end point on, or that they participate in the routing of. So, if Lightning works, ideally you should gain some privacy. Although again, I think there's a lot of misconceptions on both sides about how much privacy Lightning actually gives you in practice and how much state has to actually be stored.

Peter McCormack: Okay. So the way I'm starting to see Lightning is that Lightning really is just a balancing system. I think of it almost like a series of tubes and each tube has some water in and I as I pour water from one tube into the other, they just kind of balance each other out, like a money balancing system. I know it sounds weird!

Dan Robinson: I think that's right. One thing that's important to understand about Lightning is that, when we're talking about a payment moving across the network, you shouldn't think of it as water being poured from one channel into the next and the next. It's more like a wave that transmits. Now this is something interesting that I remembered learning in high school physics, is that when you see a wave in the ocean, maybe you think of it as water from out there in the ocean, that is coming all the way to us.

What's actually happening is, the water all stays in roughly the same horizontal location and it just moves up and down during the wave. What's actually being transferred is just energy. No water particles are coming all this way. So it's like if you pull on a rope, the rope only moves a little, but this kind of wave moves all the way along it. A Lightning payment is much more like a wave, than it is like a particle being moved.

So when you have these channel updates happening in sequence, it's like each channel is a pool with some fixed amount of water in it and the water's all on one side or the other of it. Then when the payment happens, in each of the pools that this travels across, the water moves from one side to the other. But water can't move from one pool to another, at least not, not with a Lightning network payment, that would have to happen on-chain.

Peter McCormack: Okay. On the Bitcoin base layer we have UTXOs. What do we have in Lightning that's equivalent?

Dan Robinson: So you could think of HTLCs as being kind of... They literally are UTXOs, in the sense that if you close a Lightning channel while there's an HTLC pending, it gets its own UTXO. So an HTLC is the Hash Time Lock Contact, it's like I said the mechanism that's used to enforce atomicity across different channels in Lightning. But I wouldn't necessarily say it's the primitive, at least as far as when you are thinking about payment channel networks.

The primitive is really these connections, these edges on the graph of Lightning network nodes, that are these connections between routers and some amount of money in them. That's the channels. So each channel is really kind of the primitive and then in the channel, each side has a balance and money can move between the two parties in that channel in that balance. That's really what I'd say is the primitive, the core primitive of the payment channel network.

Peter McCormack: Right, and is there any possibility in the future or anything being worked on that means a payment can go from one person to the other, without a channel open? Or is that a core fundamental requirement of the system?

Dan Robinson: So there are ways, right now on Lightning, to do payments to or from parties that don't currently have a channel open with anyone. I think it's sometimes called Submarine Swaps. That's basically where one of the parties enters into the same contract, but they do it on-chain. I think it's sort of a core idea here.

If you think of it just abstractly, this is just a payment network and you can have these connections between two nodes, be that they have a payment channel with each other. But if you wanted to think a little more abstractly, you can say that I have a way to pay you, in a way to enter into HTLCs with you and that could be on the Bitcoin main chain. So to sort of answer your question, I think you can do it as long as it's a way to make a payment to somebody and to have it be in an HTLC.

Peter McCormack: Okay. Fantastic. So this is really interesting. It gives me a better picture. So you've been playing with Lightning.

Dan Robinson: Yep!

Peter McCormack: What's your overall experience so far? Good and bad.

Dan Robinson: Yeah. So I think there's a lot of good. I think there are some fantastic teams working on it and a lot of people building products on top of it. There are some technical design decisions in it that I think are mistakes. I think that they can be fixed potentially in future versions of Lightning and sometimes you can actually just work around them with Lightning as it currently exists. But that I sort of have been considering it my job, to try to escalate a little.

So one of those problems... So I mentioned that there's the atomicity layer of Lightning and there's the payment channel layer of Lightning. The one that I focus on and that I think my biggest critique is about, is about the atomicity layer and that's about how they use HTLCs. So HTLCs are a way of doing this two phase commit type protocol, for updates of ledgers. This is a protocol invented by TierNolan, I think many years ago and it was originally designed for doing cross ledger atomic updates.

So like a Bitcoin/Litecoin atomic swap. When Joseph and Tadge came out with the Lightning network paper, they adapted this. The brilliant idea there is to move this HTLC primitive and put it within... So that it's not enforcing atomic updates of main chain ledgers, it's enforcing atomic updates of payment channels. The thing is, when you're in a payment channel, there's actually much better ways to do the kind of fair exchange, the atomic exchange across multiple payment channels, there's better ways to do it than having this ledger enforced HTLC.

I'm not sure I have enough time to go into the full details of it. I'd recommend definitely anyone who is interested in learning more about it, to check out my talk at the Stanford Blockchain conference in January called "Are HTLCs considered harmful?" Where I go into how HTLCs work and what I think the problems with them are. But the high level on the problems that they cause, is one, this griefing attack that I mentioned before, where a party can refuse to complete an HTLC that is currently locking up liquidity across a multi-hop payment.

Therefore, this causes all this liquidity to be locked up for say 24 hours, without even paying a fee. This is something that someone would do intentionally if they want it to attack the Lightning network and reduce the available liquidity there. Another problem is that HTLCs inherently provide this free option to the end recipient, to complete or cancel the payment and they need some amount of time to do that for this construction to be secure.

If it's a multi-asset payment, you end up getting what's called the free option, like a financial free option, whether to complete a payment that you can choose whether to complete it, based on the price changes of the assets that are being traded. The final complaint and this is maybe one that I think gets more to your question, which is about my personal experience working with it. I was working on implementing a Lightning payment channel network for Stellar when I was in Interstellar and that's called Starlight and you can check out a demo of that online.

One thing I've found with trying to do HTLCs is that they're pretty complicated. Certainly doing HTLCs depends very heavily on the details of the base ledger that you're trying to implement this network on. It depends heavily on the details of the payment channel implementation that you're trying to use. Generally again, I think it requires a lot from the sort of substrate that you're building it on.

The alternative that I talk about in the talk, is what I consider a very elegant mechanism called Packetized Payments. That was developed by the team at Interledger, which like I've said before, I think is a fantastic project and that was developed by some people at Ripple.

Peter McCormack: So a griefing attack, as I understand it, is that I can lock liquidity up on the network by creating payments but not completing them?

Dan Robinson: That's right.

Peter McCormack: How do I create a payment but not complete it? How does that actually happen?

Dan Robinson: So you would probably have to write custom software to actually do this attack or maybe strategically bring your Lightning node offline within a couple of seconds because this is obviously not something that the Lightning network protocol software is designed to do.

But it's definitely something that's possible within the protocol and you'd basically do the first half of receiving a Lightning payment and maybe just, you're sending this payment to yourself and routing it across a bunch of different hops. But you don't do the second half.

Peter McCormack: Has it been seen done?

Dan Robinson: It's a great question. I don't know if it's been done, it's very possible it's happened accidentally. I doubt that anybody's doing it now necessarily. But it's something that could potentially lock up a lot of liquidity on the network and really sort of annoy people who are putting liquidity on it.

Peter McCormack: So if somebody wanted to attack the network, they could quite simply create a whole set of different nodes, which are their own, write custom software to send payments to themself. But as it's hopping through the network and they don't confirm the payments, they're locking up other people's liquidity. It's almost like a DDOS attack.

Dan Robinson: That's right. It's a denial of service attack.

Peter McCormack: So that's an obvious risk. Is there anyone who's talked about it with you? Is anyone talking about potential solutions to it? Because that sounds like something that isn't too hard to actually go and do.

Dan Robinson: So I didn't come up with this attack. I'm not sure if he came up with it, but I heard about it from Evan Schwartz at Ripple. I think it's something that a lot of people, who work on Lightning considered and they're aware of it and they have been aware of it for a while. I think they consider it not necessarily a big threat, in part because it requires... It's just a griefing attack, it's just a denial of service attack.

It isn't something where you can necessarily use it to steal money. What I've heard them talk about for solutions to it, generally involve reputation. I think that's a very challenging way to try to solve this problem, in part because it undermines potentially the privacy of the network and in part because the reputation that would be required, it isn't just local reputation. It isn't just who I choose to open a channel with.

It's anyone down the line from me can potentially grief me in this way. If I'm routing a payment that I didn't create, I didn't initiate the payment, I'm not receiving it, I'm just routing it, any of the parties downstream from me, can grief me in this way. That means I potentially need to evaluate their credibility and that's something that I think is maybe inconsistent with an open and private network.

Peter McCormack: I guess if it was reputation based, then it wouldn't be a trustless network?

Dan Robinson: That's what I think, yes!

Peter McCormack: Okay, so the second is the free option. That was something else I found kind of interesting, very interesting in cross chain atomic swaps because you've got 24 hours to make a decision based on price, that's still relevant within Lightning because the price of Bitcoin might move.

Dan Robinson: It's not relevant if for a Bitcoin transfer where the sender is sending Bitcoin and the receiver is receiving Bitcoin and it's just Bitcoin in all the hops along the way. That in fact is generally the Lightning...

Peter McCormack: Are you sure? Think about it like this. Say I'm making a payment to you. The price of Bitcoin in Dollar terms shoots up. I think, "oh, I'm going to cancel that, I want that Bitcoin back." So actually it's still relevant?

Dan Robinson: Well, if you're the sender, you can't cancel a payment. So it's the end recipient, who can choose to cancel or not.

Peter McCormack: Oh okay!

Dan Robinson: And generally if you're receiving a payment, you'd rather have Bitcoin, than no Bitcoin.

Peter McCormack: But at the same time, say the price of Bitcoin dropped heavily, I might not want to receive it?

Dan Robinson: Why wouldn't you want to receive? Your alternative is receiving zero.

Peter McCormack: Well, no. Say I've got a store that's accepting Lightning payments and I'm selling something that costs $50 and I have a price that comes in a certain amount of Bitcoin, but the price of Bitcoin drops during that time, say something disastrous happens and the price drops 20%. I could cancel the payment and say payment not received and then reissue the invoice, but the invoice would now be higher. Most people charging in things like Lightning and Bitcoin, they're using the Dollar as the unit of account. Do you see what I'm saying?

Dan Robinson: That might be true I think, but that's between you, the shirt vendor and whoever's buying it from you. You may have agreed at the time, before they sent the payment, that this payment is considered final now, so they could rightly complain to you, even if you have potentially this capability of waiting to complete the payment.

The transaction is already completed as far as between you. So I think it's a bigger deal when the atomicity is really only enforced on-chain, within the Lightning network, where all the hops in this payment are supposed to be enforced by the network itself. As opposed to when, with a t-shirt, you're also already relying on the person to actually send the t-shirt. But, so this is the Lightning network people's general response to this and it's I guess a fine position as far as it goes. It's just the Lightning network really is only for Bitcoin. It's only a single asset payment network.

Peter McCormack: Well that's what I was going to say. So when you talked about the problems with say Bitcoin to Litecoin, I would have thought most Bitcoiners would go, "well, we don't care because everything else is a shitcoin."

Dan Robinson: Yep, that's right. So I think if that's all you want your payment network to be, I think the free option problem isn't really a big problem. I think there's actually a lot of potential in having a cross asset payment channel network and that's what Interledger was really designed at its core to provide, to be sort of a much more layer one agnostic platform. But yeah, I mean if you really only want it to be a single asset being traded across, the free option isn't a problem, I definitely grant that.

Peter McCormack: Another thing you said as part of the presentation, you said that smaller payments are not actually economical?

Dan Robinson: So smaller payments. You can definitely do them on Lightning and people do these one Satoshi payments. They're not enforced on-chain exactly and what I mean by that is, to do a payment with an HTLC, each of these parties has to actually update their payment channel to include this new UTXO in the commitment transaction of their Lightning channel.

If they were to close out this channel while a payment is pending, that means that there's an extra UTXO there and then this has to be settled through an extra transaction. So the actual cost of settling an HTLC on-chain, I've estimated to be like maybe around 50 cents, depending on again, what your fees are and what the price of Bitcoin is. But that's just much too expensive. It's not worth it if your payment is less than 50 cents.

So if you do a smaller payment, you could still do it on Lightning, but each of the parties that is routing the payment, ends up trusting their counterparty, with sort of an informal HTLC. It says like, "we agree that if we were to close this network now, we would settle it based on what it should settle at", but the ledger is not going to enforce that.

Peter McCormack: Okay. That's quite interesting. I didn't know about this!

Dan Robinson: This is something that I think, Tadge who was one of the co-creators of Lightning, has complained a little about it, that it's not transparent. Ultimately I don't think it's a big deal, because this is something that you only trust your immediate counterparty for. You can only sort of grief your counterparty and the details here, are actually that during the pendency of these HTLCs, the pending payment goes to miner fees.

So it means that either party, by closing at the right moment and cheating their counterparty in particular way, can cause their counterparty to lose a little money. Since it's less than 50 cents, and this is a channel that you've agreed to enter into with some particular party, basically they say, "I'm trusting this person who I've entered into a channel with, for up to 50 cents" and I think that's fine. I just think they should be more transparent about it.

Peter McCormack: The first time I heard about it was with your presentation. So you said your presentation was that HTLCs are harmful. I mean, that's quite a spiky statement!

Dan Robinson: Yeah, perhaps. There's a famous article called, "Go To Statement Considered Harmful" from a few decades a go. So that's a format for making provocative statements of this sort and what it really means is that this as a design pattern, I think people should be considering alternatives to it.

Peter McCormack: Okay. But that would be quite a big change for Lightning to not be using HTLCs.

Dan Robinson: It might be. So what Lightning currently does for these sub dust limit payments, these really small payments that aren't economical to settle with an HTLC on-chain. That's what I actually want them to do for every payment and the way that you would send a payment, without increasing the trust requirements for these nodes, and this is this Packetized Payment method that was developed by Interledger.

The idea is we do that method, which is basically the same method as Lightning does with sub HTLC dust limit payments. But if you want to send a larger payment, you do that over and over again until you've sent the full payment. So if you send, say 50 cents at a time, then nobody has to trust their channel counterparty for more than 50 cents at any particular time.

But you can eventually make as large a payment as you want. These payments, when they complete, are relatively fast. So that's the core idea of the Interledger method for atomicity, which is called Packetized Payments.

Peter McCormack: Packetized Payments comes from, it's an original Internet concept right?

Dan Robinson: Yeah, that's right. So part of the metaphor there, I think is that this is in some ways analogous to how the Internet routes data, is that rather than forming these sort of large chunky connections between two nodes on the Internet to send data between them, they chunk it into packets and then sort of send those packets potentially through different routes and potentially in different orders. You just make sure that eventually at the end, all the packets make it there and are reconstituted into one payment.

Peter McCormack: As a concept, has it been stress tested? All there were any flaws in it you're aware of?

Dan Robinson: So there's a few flaws in it. Certainly the biggest is that it increases the latency of large payments. So it means that potentially a very large payment being made over this over this network, would take time proportional to the size of the payment. I don't think that's necessarily a big problem and part of that is I think people have started to recognize that Lightning isn't necessarily well suited for very large payments anyway.

I personally think for Lightning, the real killer use case of it is for micropayments and relatively small payments. But if you have a really large payment, your fee on Lightning's going to be proportional to the size of the payment, at best, if you can even complete it at all. Whereas if you were to go on-chain, you're essentially paying this constant fee for it. So I think, above a certain payment size, it's going to make sense to make this payment on the main chain anyway.

Peter McCormack: Okay. Again, that's another thing I wasn't actually aware of, about the proportional size of... Or is that only in the case of Packetized Payments?

Dan Robinson: No. So in Lightning right now, the larger the payment you're making, the harder it is for you to find a path and potentially the more you're going to have to pay for it, because your paying essentially for the worst case scenario, which is that you do this griefing attack and that everybody's liquidity is locked up for a day. Even if you don't do that, by making this large payment, you're really shifting around the liquidity on the whole network. So it's harder to find potential capacity for that and it's a bigger change, so you pay a larger fee for it.

Peter McCormack: Okay. Let's move on to payment channels, because there's certain issues you've noticed with those. You think they're limited by the base chain?

Dan Robinson: That's right. So I think Lightning's payment channels are not bad and it took a really heroic effort by Bitcoin core developers to get SegWit included, which was what was needed to really enable the payment channels that they have now. But I think you can still do a lot better. Some of these changes don't require upgrades to Bitcoin scripts and I think are going to be a part of upgrades to Lightning, but some do.

So some of the problems right now are, in Lightning as it's currently designed, there's some data that is more than just the information in your wallet. Where if you lose it, you lose the ability to receive money out of your channel, even if your counterparty is honest. I think at least some parts of that can be fixed without Bitcoin protocol upgrades and are probably going to be fixed in a new version.

But I know people that it's really sort of "bitten", because you can have data corruption issues that cause you to lose your money. Even if your counterparty is honest. I think the big problem is the way that fees are committed to right now in payments and Lightning payment channels, because you basically have to decide on the fee that you're going to pay and commit to that particular fee, at the time that you update the state of the channel, rather than at the time that you're trying to close the channel.

So if there's congestion on the main chain, that could be a problem. So you generally need to set relatively high fees for that, which may not end up being necessary. So there are ways to fix some of these problems and I think there's an improved design called eltoo that Christian Decker and Lalou from Lightning Labs came out with. I think they're very valiantly pushing to get an op-code included in an upgrade of Bitcoin, a protocol upgrade called SigHash NoInput. 

I'm not sure when that's actually going to get added and how long it will take to really adapt Lightning to use that, but one thing I've noticed is despite how much Bitcoin core developers and Bitcoin users really care about Lightning, there doesn't seem to be a huge political constituency for pushing forward changes like this or others that would really improve it. I find that frustrating just because I would really like to see a lot of the Bitcoin script upgrades and I haven't really yet.

Peter McCormack: From what I understand that people talk to me about the scripts, is that there is a significant difference between say, Bitcoin and Ethereum because is Turing complete, Bitcoin isn't. You wouldn't be pushing for Bitcoin to become Turing complete right?

Dan Robinson: There is just miles between where Bitcoin is and Turing completeness! I think what I'm pushing for really is, something that's much closer to just very incremental steps. I think you get a lot from Turing completeness. I will say that I think there's a lot that people can design in Ethereum, that people frequently do, that would maybe blow the minds of some people who are used to just thinking about payment channels entirely in terms of pre-assigned Bitcoin transactions.

But that said, I love the Bitcoin model. Again, I helped design a smart contract language for Bitcoin called Ivy. This would all fit within Bitcoin's current model for how transactions work. It's just literally a matter of adding a couple of op-codes to it. So for example, the ability to concatenate two byte strings that are on the stack, the ability to just concatenate two strings is a really simple op-code. It was in Bitcoin originally and Satoshi disabled it for reasons that I think aren't really relevant anymore.

The core developers are relatively reluctant to add that back in. The other is the ability to check a signature on data on the stack, rather than just a signature on transaction data and these could enable, especially together, a lot of cool protocols including potentially Plasma and doing Plasma on Bitcoin. But there's really sort of a lot of resistance to that and that's something that I think a lot of people have just recognized as maybe just core to where Bitcoin's goals are right now.

Peter McCormack: Are script updates dangerous at all? Do they present any inherent risks, any unknown unknowns?

Dan Robinson: Every protocol upgrade is dangerous. I think adding an op-code to Bitcoin script, is probably one of the safer upgrades that we would know how to do. You can either add it by overriding one of the no-ops or by doing a SegWit script version upgrade.

So SegWit actually put in a pretty clean upgrade protocol for scripts, but it hasn't been used yet. I think these could be done either way. Often what annoys me is that people are very concerned about what could be done with these upgrades and that they don't like the applications that they could be used for. 

So there's another technology called Covenants, which is the ability for a script to essentially read the outputs of the transaction that it is being verified in. That provides a lot of really cool features and actually could enable some upgrades to how Bitcoin does payment channels. But people are concerned about it for reasons that I find kind of perplexing.

Peter McCormack: Okay. So just a couple of last points that you discussed, capital inefficiency. So in some ways inherent to payment channel networks, you talked about this?

Dan Robinson: Capital inefficiency. So any network that's just a payment channel network is going to have this problem that a lot of capital needs to be locked up for there to be sufficient liquidity on this network, more than the amount of payments that can be done on it. There's a lot of imbalance also in the directions that these payments naturally flow, such that right now it's hard for someone to get, for example, receiving capacity on Lightning.

I think right now you might be able to buy receiving capacity. I think you have to pay something like 3% - 8% of the amount, which would be relatively high as a transaction fee and that's even before you have Lightning transaction fees on it. So the part of the problem is that people have to lock up a lot of capital in payment channels and part of it is, that the direction and the current capacities in each side of these payment channels matters a lot for that.

So it's something that's hard to get around for this. There's a couple possible solutions for it. One is that I think Plasma actually provides a way to improve this. So Plasma is a technology that again, right now is currently being only developed on Ethereum because it requires much more scripting than Bitcoin has. But in the context of Lightning network, what it would basically allow you to do, is transfer a channel to somebody off-chain without having to do a full transaction on the main chain for that.

That's kind of the TLDR maybe of how I think Plasma could be adapted to improve the Lightning network. That would require a couple of upgrades to Bitcoin script. I think it would require some that would be considered significantly more out there, than even the ones I was mentioning before. So it's not something that I think is probably feasible in the near future. But I think it does show that there's ways to do layer two scaling that maybe can be better and be more capital efficient, at least a little easier than Lightning does.

The other is that we don't necessarily need to have every payment channel, every edge on the Lightning network be backed specifically by a payment channel. I mentioned before that I think Lightning kind of tightly couples these different layers of how HTLCs work on and payment channels and also that it's specifically on Bitcoin. So for example, when I was working on implementing "Lightning" on Stellar, there's very little of the BOLTS-spec, the specification for Lightning that I would be able to really use for that, because a lot of it refers very specifically to the Bitcoin transaction format and depends on that.

If you had a protocol that was, and this is what Interledger aspires to be, is a protocol that's more agnostic as to what the base layer is. Interledger with this Packetized Payment method can be done over... So Lightning can be done over any payment method that supports HTLCs. Interledger can be done over any payment method that supports just payments. If you can make a simple payment to somebody, then you can be an Interledger peer with them and that payment doesn't have to be in a payment channel. It doesn't even have to be on a Blockchain.

This could be like if you make a Venmo payment to somebody, you could potentially route Interledger payments through that connection. If you're going to make an on-chain payment to someone, if you just throw pennies across the Grand Canyon, you can implement Interledger on top of that. That's not true of the HTLC method and it's just generally not the philosophical approach that Lightning has taken. They care a lot about embedding this in Bitcoin specifically and so why this matters I think is that, one way to reduce the capacity problem would be for some of the channels in the Lightning network to be backed by credit rather than fully collateralized.

That doesn't mean that you as a Lightning network user have to trust anybody. This would only be a concern of the two parties that are directly involved in a particular channel. So Coinbase and Kraken to take an example. It would be very expensive maybe for them to have a huge Bitcoin payment channel open between them. But if they could just sign a contract that says that, "we agree that we'll only have $1 million in flight at any particular time and then we'll just settle with main chain Bitcoin payments." They wouldn't need to lock up any collateral, because they're willing to trust each other up to this certain amount and then just settle relatively infrequently.

If Lightning could just seamlessly route over that hop, as if it was a payment channel hop, it wouldn't affect the security of other users or of those payments at all. It's only entirely the local concern of Coinbase and Kraken. But the problem is that the Lightning network is not designed in this kind of layer one agnostic way, so they sort of have to hack around this.

Also HTLCs are not designed to support this kind of base layer where it's like a legal contract between them. So if someone was trying to do a really large HTLC payment on that, it has to be completed entirely atomically or not. The contractual agreement between Coinbase and Kraken just isn't necessarily a great substrate for that.

It isn't programmable in the same way. So that's why I think having one that's more flexible that allows... If I can make payments to you or if we can just update a balance between the two of us, we can do Interledger payments on it. I think that maybe provides one way out of some of the capital problems that Lightning has.

Peter McCormack: What I would take from this, my summary from all the points you've made is that there's nothing disastrous here. They're more just things that you think can be improved? You're not coming here saying like, "Lightning's a disaster." It's just these are design improvements that you think will significantly improve the performance of Lightning.

Dan Robinson: Yeah, absolutely right. My number one preference definitely would be for Lightning to adopt some of these changes and then succeed wildly.

Peter McCormack: Okay. How much have you discussed this with people? How much push back has there been received? Has anyone criticized your recommendations? Has it had been some kind of warm acceptance?

Dan Robinson: I think I'm friendly generally with a lot of Lightning people and I think we mostly disagree about the size of the problems. Once we have gone down to the details and they've actually informed me about ways that I was mistaken about some of the criticisms I was previously making about them. Once we've really discussed this in depth, I think they're very open to it.

I think they think that these aren't as big problems. Partly they're just not as concerned about it being a Bitcoin only network. Partly they think that, again, that some of these denial service attacks, no one's going to be incentivized to do them. I think these are empirical questions. I also think they're very focused on, and as it should be, on the problems that people are facing right now.

My concern mostly, is I just want to really be raising the profile of these issues, so that if this kind of problem ever occurs, we know that Lightning isn't screwed. We can make these particular changes to it.

Peter McCormack: Okay, fantastic. This has been really useful! I expect when it goes out that people will be very interested because there's a critique. I'd be interested to see what other people think actually because you've raised some things I wasn't aware of at all, so that will be very interesting. I hope there's no people coming at you for it. So thanks for coming on Dan! How do people stay in touch with you and keep an eye on your work?

Dan Robinson: My favourite venue generally is Twitter and so you can follow me @danrobinson on Twitter, my DMs are open if you want to complain to me about anything I've said or certainly correct me if I mischaracterized anything. I would love to hear from people and happy to correct it on Twitter.

Peter McCormack: Fantastic! Thanks for coming on Dan.

Dan Robinson: Thanks for having me!