Submarine Swaps, Lightning Loop, Hyperloop
Speakers: Alex Bosworth
Date: October 24, 2019
Transcript By: Stephan Livera
Category: Podcast
Media: https://stephanlivera.com/download-episode/1595/119.mp3
podcast: https://stephanlivera.com/episode/119/
Stephan Livera: Alex, welcome to the show.
Alex Bosworth: Hi. It’s great to be on the show. Finally.
Stephan Livera: Yeah, I’ve been meaning to get you on for a while and you know, now we’re finally making it happen. So just, context for the listeners, we are recording this one in person just before the lightning conference, the inaugural lightning conference. So just a couple of days before there was lightning meetup last night. It’s been fantastic to meet a bunch of the people around Bitcoin and lightning. What was your experience like last night?
Alex Bosworth: Yeah, there’s a huge amount of people coming out for the lightning conference. Like I guess this is the inaugural lightning conference. So you know, it’s way oversold. There’s like a bajillion speakers, so I think it’s going to be a good event.
Stephan Livera: Fantastic. Yeah, so look, so today I was keen to get into some topics around Submarine Swaps, Loop, Hyperloop, as I know you’ve been doing a lot of work on these lately. Can you start with a bit of a background? I think most people know who you are, so we can just sort of jump into it. If you wouldn’t mind just giving us a bit of a background on submarine swaps and how they work for Bitcoin in lightning.
Alex Bosworth: Yeah, so initially I was working at a company called BitGo and I was working on lightning integration there and you know, one of the things that we really were thinking about and that I was thinking about is like, we’ve got this totally new system lightning and, but everybody’s really already like hooked up to the regular blockchain. They’re like familiar with the blockchain. So one thing I was thinking is like, we need some way to link these two together and submarine swaps as a way to link the blockchain, what you’re like regularly used to with the lightning network so you could make a payment enlightning and then it basically forwards onto the blockchain in a way that’s non-custodial. So uses the same principle that lightning payments use, which is HTLC the con HTLC contract.
Alex Bosworth: But in a very simplified way. I started working on that independently outside of BitGo at this website, submarineswaps.org, which is an open source project to like make a submarine swap server and kind of demonstrate the concept. As I worked on it more, I realized that there’s another, there’s, there’s all sorts of use cases that in addition to this bridging of old world to new world that relate to like capabilities. So the capabilities of lightning are somewhat limited in terms of if you need to move capital around, in lightning, you’re constricted by the existing channel capacities of your peers. So money can’t really be introduced or even really exit the system because you are locked into these channels that you created a while ago. And so the idea is that we reuse them all the time, but if you want to move the capital around in a way that is outside of the limits of those capacities, then you’re going to need another mechanism.
Alex Bosworth: And one of those mechanisms could be the blockchain. So I worked on submarine swaps for litecoin. Litecoin to Bitcoin. So I offer different pairs and that the, the direction that I implemented submarine swaps was to go from on chain to off chain. So the idea would be you could just make a regular chain payment with any kind of wallet and that payment could pay any lightning invoice that you wanted to. And then if it can go cross chain so you could use even Litecoin to pay a Bitcoin lightning invoice. So then after I worked on that, that project and that’s, that’s released, you can go check that out. I joined lightning labs and at lightning labs we worked on a similar project for submarine swaps, which is called lightning loop.
Alex Bosworth: But this time we made it go in the other direction to solve a different kind of problem. And the problem that we’re solving with lightning loop initially was that there’s an issue where people want to get inbound liquidity so that they can receive. Or if you’re a router, you want to be able to route payments. You need some capital going into you and some capital going out of you. But the way that lightning works is that if you make channels with somebody, the capital is only going from you out initially. So lightning loop as a way to kind of get that started to jumpstart that process because what you can do is you can say, I’m gonna make a lightning payment out and then I’m going to receive the same funds back on chain. And because I spent down my channel, I can now in the future receive on that channel. So that’s something that we released a while ago. And since then we’ve also added the ability to go from on chain to off chain as well.
Stephan Livera: Right? Yeah. So I guess listeners, check out the earlier episode with Joast Jager as well from the team. Where we spoke about loop in and loop out. And I guess just to recap the understanding there, you can open a channel with somebody, but because we’re single funded and because I’m opening the channel, that is all the balance all the beads in that abacus are on my side and there’s none on the other side. I’ve got no incoming capacity from that other person until I pay through that channel. And then only then I’ve actually got incoming capacity. And then, so what you’re saying here with use of submarine swaps is we can use that to change what’s in that channel because we’re using an on chain payment as our other way of moving money across that channel, if you will.
Alex Bosworth: Yeah, I mean, I wouldn’t, I wouldn’t also place the blame on single funded channels. It’s kind of a fundamental principle of lightning that somebody needs to commit capital in some direction. So it always makes sense that you can’t just go to somebody and for free demand that they commit capital in your direction because they don’t have unlimited Bitcoins. So the idea is that you can,you can,re rebalance your channel,uin a way that fundamentally changes the flow properties. Uand that’s, that’s impossible just using the lightning network by itself.
Stephan Livera: Right? Yeah. And I think that’s also capturing, I think you’ve explained it as stock to flow as well, right? That there’s the flow of incoming payments. So for example, if I’m a merchant and I’ve got all these channels, and then at the end of the day, let’s say a lot of customers bought stuff from me, so all of my incoming capacity is now exhausted because they were paying to me. Then one way to sort of push it back out is to use a submarine swap. And so in that example, you would push the, you know, the beads in that abacus to the other side and receive the Bitcoins back in an on chain payment. And so I guess that’s what a submarine swap would help the merchant achieve in that example. And I guess that would be a loop out in that scenario.
Alex Bosworth: That’s exactly right. And that’s one of the big use cases that we really thought about and we did loop out first so that you can push the balance of your channel locally out, back onto the chain. And it’s kind of a compliment to the internal mechanic of lightning, which is rewarding forwards by giving you fees. So in theory, if you’re a good merchant and you’re getting regular amounts of traffic, the people who are forwarding the traffic to you are getting paid in fees. And so in theory they should be also monitoring that, that flow and say, Oh, well I just made a bunch of money in fees sending them to the store. So I should continue to assign more liquidity in that direction. But you’re really depending on them to notice that. And you know, maybe they are not anticipating you’re doing something that’s, you know, new or maybe you’re just getting started. So they haven’t built up that reputation yet. So loop out is a kind of way to take matters into your own hands.
Stephan Livera: Right? Yeah. Let’s talk about the loop in examples. I think, maybe an example, Hey would be, I want to pay on chain and then receive it into my lightning balance.
Alex Bosworth: That’s right. Yeah. Yeah. So like one thing to think about with these, you know, with this mechanism of continually adding capital as it gets depleted, is that there’s always one side who’s sitting on this capital and they might not really want to sit on endless supplies of capital. So like, let’s say I’m a mobile wallet and I create a channel to a routing node and it’s $100. And then when I spend down my entire a hundred dollars, well, what am I going to do? I, you know, I want to spend more money. So I create a new channel that’s another, $100 and let’s say this goes on for maybe a year or multiple years and the money isn’t flowing back. It’s just sitting on that other side. So the peer is maybe not so happy about this situation. They’re just getting money that’s collecting on their node.
Alex Bosworth: And because if I’m a mobile node, if I’m not a routing node that money is not really, doesn’t have the same utility to them to spend out to the rest of the network. They can’t just offload that to an exchange. So the thing that we’re thinking about with loop in is to make it friendlier to your peers to say, we’re going to reuse this channel. So instead what you’re going to do is you’re going to create this $100 channel to your peer. And then when you’ve run that down, when, when that’s completely exhausted, you can do one on chain transaction, which is a loop in and you can go, you can go from your exchange into the loop in on chain and then loop the loop server will send you back the funds off chain and then your peer is happy with you that you’re not continually adding more capital to them that they have to now protect in their hot wallet.
Stephan Livera: Right? Yeah. That’s a really good point because for every person, let’s say you’re a merchant, you’re a service provider. You are running lightning, you’ve now got to consider that you’re keeping more in a hot wallet. So that’s one of the costs of using lightning. And so you don’t want to unnecessarily impose cost there. And I think the other point you brought up is that if you are just a mobile phone lightning user, and if you just continually open a new channel each time, then you’ll just end up accumulating all these UTXO that are just sitting there. Whereas in this model, it’s actually more efficient because you’re just reusing the same UTXO. You’re imposing less of a chain fee cost onto the service provider in this case. Because let’s say if you didn’t have some kind of loop in a loop out in this case Loop In then that the service provider in this case would have to close the channel and open a new one. Right. And that’s, again, these are all chain fees. So
Alex Bosworth: Yeah, although every loop still does involve a chain fee. So there’s ways. So one thing that we’re working on in the future is to also create like efficiencies around aggregating these multiple balanced shifts. And in that case, then we can, we can get some efficiency there. And you know, if I’m talking about like being efficient to a peer, I don’t mean like just being nice to people. I mean like just from a cost perspective they’re going to have to reflect that cost back on to you. So what we’re trying to do is to just make it cheaper,
Stephan Livera: Right? Yeah. Yeah. Because I guess fundamentally it just comes down to how many on chain fees are you doing on chain fees are you incurring and then what are some ways to batch and aggregate those such that you are reducing your on chain footprint.
Alex Bosworth: Right. And it’s really for, you know, thinking about once we get into full blocks, once we get into higher fees, just getting the most savings so that you don’t really have to think about as much, you know, being efficient with your chain fees.
Stephan Livera: Got it. So let’s talk a little bit about some of the, I guess, limitations of using submarine swaps. So one example there might be that you have to wait for on chain confirmations.
Alex Bosworth: Yeah, I mean it’s kind of a shock even doing a submarine swap because you know, if you really get into the lightning mode, you get used to it, that just everything settles very quickly and you’re not waiting for 10 minutes or 20 minutes. But once you get into submarine swap mode, then you fundamentally have to wait for this on chain settlement. I mean there’s ways that we can kind of take shortcuts around it. But I mean, the fundamental principle of the blockchain is that there’s some weight, some weight involved, there’s some proof of work that has to happen. So yeah, that, that’s kind of like the, one of the downsides to going into submarine swaps and in addition to the chain fee.
Stephan Livera: Yup. And I think in one of your talks you were also mentioning how there is some privacy implication as well, because the submarine script, the Bitcoin script is observable on the blockchain.
Alex Bosworth: Yeah. I mean there’s like privacy pros and cons with submarine swaps. One nice thing about a submarine swap is let’s say that you’re doing like a loop out. That’s where you pay off chain to the loop server and then the loop server pays on chain for you. So normally when you make an on chain transaction, you link one of your UTXOs to your spend. But with a loop out your UTXO that you’re spending is like connected to some channel somewhere and you’re using that channel then to pay to the loop server and the loop server, it makes a payment out from the loops own UTXOs from the loop servers UTXO’s. So if you actually just look at the chain, there’s no longer that link there. And even the loop server has no idea because of the lightning networks privacy guarantees it has really no idea who paid, whose UTXO was associated with paying the loop server.
Alex Bosworth: So there’s some privacy wins in that case, but there are also privacy issues where if you analyze the blockchain, you can see these special loop submarine swap scripts. And also different swaps, service providers use different types of scripts. The service, the scripts that we use @at lightning labs are different from the scripts that i made when i made the initial implementation of submarineswaps.org. And you know, there’s other wallets who have implemented their own submarine swaps. So there’s, a lot of tags on what you’re using what you’re doing. And that’s something that we want to improve. We want to get rid of those script markers on chain.
Stephan Livera: Right. I see. And so I guess putting it into practice, there will be certain distinguishing features on the scripting. So what are some of those and how would that potentially be removed as you were mentioning?
Alex Bosworth: Yeah, I mean, the script that we made is not a standard script. It’s just something that we, we created to service this need. And it’s basically a script that is kind of a simplified version of like a HTLC script that for the normal payments on the lightning network. And actually lightning transactions have a similar problem. If they can’t complete offline, or off chain. If they can’t complete off chain, then they’ll fall back onto the chain. And once they’re on the chain, they mining transactions also have a similar privacy problem because people can see how much that value was. People can see what the hash was, they can see the pre image. So you don’t want things to go onto the chain in that case, but they could. And in submarine swaps case, we always go onto the chain. It’s like a failure case every time. And that’s also the solution though, is that we want to maybe become more like channels and say we have this hidden backup script that could go to the chain. And then we don’t use that all the time. We only use that if there’s an uncooperative case, just like we do that in lightning.
Stephan Livera: Right. Yeah. And it might be good to talk that through actually just, I guess the operation of the submarine swap. So as I understand it, there’s a success pathway where, you know, as we mentioned all that stuff we mentioned before it happens, but then there’s the failure mode where if somebody, I’m getting stuck here, so can you help us, can you help articulate that failure pathway?
Alex Bosworth: Yeah. I actually, this is one of the good things about submarine swaps is that they’re they’re like a simplified version of the lightning scripts and the lightning scripts are based on this high level concept called HTLC. And HTLC has only two outcomes. So a normal payment that you would make has one outcome, which is I’ve locked this script to public key and then the outcome is I see a signature associated with that public key. And then I say, okay, it’s good to go. In the HTLC contract. It’s a bit different. There’s two different conditions which can be used for spending. And one of those conditions is I see a pre image that corresponds to a hash or I see a lock time. That means that this trade didn’t happen and it’s now timed out. Although due to the nature of Bitcoin scripting, you can’t have exclusive operations. So even if you hit the timeout the pre image, the secret reveal could still also technically be used which forces all of these swaps to they need, they need to be resolved. So they need to be swept out of that output and moved into the single key control.
Stephan Livera: Gotcha. Okay. And then, so that’s that basically, that’s the way of making it, such that you can use the submarine swaps in the atomic way rather than accidentally like losing on chain and losing on off chain balance.
Alex Bosworth: Right. I mean, it’s a principle of the lightning network where you have this like window of time where if we revealed the secret, then the funds would transfer. And if the secret is never revealed, then you’ll get your money back.
Stephan Livera: So then let’s talk a little bit about, just use of this loop in, loop out. How are you seeing that used today across the network?
Alex Bosworth: Yeah, I think you know, we’ve only really released an API of loop in and loop out. So the big step that we’re working on is to try to get it integrated more into like an end user experience. And so far I think we’ve seen the most traction, like as we expected on the loop out, which is I need to get, I have this problem that I need inbound liquidity, I need it to be, be able to change my channels so that people can pay me. So loop out is a great way to do that. And it’s non-custodial, so that means that you could like build it into your API and you don’t have to like worry about, “Oh, is, you know, am I spending too much?” Or, you know, if something fails, like am I gonna lose my money? So it’s also good for us. We don’t have the support tickets. Like, you know, if something goes wrong, well it’s on the chain, you’re going to get your money back. So I would say that loop out has been a big success. And then the things we’re working on are to try to make it more user friendly and to add a bit more features.
Stephan Livera: Right. And so putting that into practice, I guess just into an example, let’s say I’m a merchant and I’m setting up online, I want to set up to take lightning payment, but I don’t have any incoming channels or inbound capacity, let’s say that’s where I loop out, could come in and play a role and perhaps that would help new merchants on board to the lightning network and have incoming capacity from the get go.
Alex Bosworth: Yeah, I would say it’s a tool in their toolbox. So, and maybe not for the merchants themselves, but somebody who’s making a merchant solutions. Like if you were making an app to help people take payments with lightning one thing you can do is you can say, okay, how much inbound liquidity do I have? Well, I’m running low. Maybe, maybe I’ve done a bunch of sales or maybe I’m just getting started. And in that case, you know, you don’t have to really even involve the merchant in this. You can just say, okay, acquiring more inbound liquidity using lightning loop, and then in that circumstance you’ve solved the problem for the merchant. They don’t even have to worry about it.
Stephan Livera: Yeah, I guess you’re right. It’s might be more like a lightning provider or some kind of service provider who is doing that full of the merchant. Unless the merchant is really technical and wants to do all that stuff themselves. Like if they’re a Bitrefill or if they’re, you know, they’re like a bit more into lightning themselves.
Alex Bosworth: Right. Well that’s the thing about being non-custodial, like this can be inside of an open source project. So you know, this can be like embedded in kind of an open source point of sale system and there’s no need for like depositing coins and creating an account or anything. You just use API and you don’t worry about it.
Stephan Livera: Yeah, that’s really fascinating to think about. And then I guess maybe this is going into more like what are the business models around lightning, but then presumably that service provider, so let’s say this service provider is helping the merchant take lightning payment, then their fees would have to account for the different fees that they are in turn paying. So they would have to pass that onto their merchant, right? So whether that’s on chain fees to do the loops, the loop outs for the merchant to have the incoming capacity and let’s say at the end of every day or every week they would need to do another round to get a whole new fresh round of incoming capacity and send that Bitcoin payment back to the merchant on chain so that they can obviously take payment and pay their own costs and so on.
Alex Bosworth: Yeah, I mean, I’d say like, it’s like a brand new field. So I don’t know exactly how things will play out. Maybe there will be more service providers. Maybe people will want to, you know, run everything themselves. So the good thing about having like a non-custodial API is it really fits into all these different scenarios. Although it does offer the most power for people who want to do everything themselves because you don’t have to have a relationship with a company.
Stephan Livera: Right. Have you seen or heard of any cases of merchants, I guess you might’ve spoken to some people who are trying to set up lightning stores and so on. Have they had difficulty with using lightning payment or have you found they were able to work through these issues?
Alex Bosworth: I’d say that people who are well known or you know, even just making something exciting, have no problems because as soon as you announce to everybody, like, I’m doing a new store, I’m, I’m setting up a new exchange. You know, everybody is, is very anxious to forward more traffic to you. They’re going to get paid fees and you know, they’re just going to have fun. Like sending all that traffic your way. I would say the challenge is more people who are kind of unknown. So somebody who’s just setting up something like really for the very first time or people who are like experimenting with becoming a routing node in those cases, you know nobody knows that they’re going to be forwarding traffic to you. So they’re more hesitant to assign capital in your direction. And that case loop out is, has, has really offer those people a way to get started.
Stephan Livera: Fantastic. So, okay, so we’ve spoken a bit about submarine swaps. We’ve spoken a little bit about loop in and loop out. Let’s talk a bit about Hyperloop, which is another concept, a thing that you’re working on. Can you just give us an overview on that?
Alex Bosworth: Yeah, a Hyperloop is something I’m very excited about. And it really describes like a vision for lightning loop where we get more efficient about how we use chain space. And in addition to the efficiency there’s also better privacy that falls out of that. And the high level concept of Hyperloop is that when you do significant volume in your chain transactions, you get this benefit, which people call batching. And the idea of batching is that you are concentrating the bytes in your transaction on the elements of the transaction that you want to really be achieved. And you’re spending fewer bytes on the parts of your transaction that you, yourself don’t about, but everybody else needs to see like the signature. So those savings can be very, very significant. And the exciting thing about Hyperloop is that we can do something similar to batching.
Alex Bosworth: And batching is already widely used on exchanges. But we can do something similar to batching that can be done in a non-custodial way and that we can do it in a way where multiple parties who may not have enough volume themselves to do batching can all come together and cooperatively do this batching. So that’s kind of a long term vision that where we would do these, these major batches and a batch like you have to kind of understand like what the bytes are associated with in a transaction and understand why batching is like efficient. So I would say there’s like four parts to a normal transaction. You have your inputs, you’re referencing your past coin that you received and you need to assign some bites to say the past coin, and then you need to prove that you are the owner of that past coin.
Alex Bosworth: So you need to assign some bytes for the signature and then you need to assign some bytes to say, where am I sending it to? So kind of like the address you need to encode that you need to encode the value. And then the final component to a transaction is like the the overflow. So whenever you spend a coin in Bitcoin, you need to create a change address. You need to send the coin, the remainder of the coins back to yourself. So that’s a fourth component. So in a batch transaction, you can eliminate all of the components except for the one that, except for the address and the value that you’re sending to. So you can get a very high efficiency in a theoretical scenario maybe 5x. So and that would be represented to you as like a chain fee. Instead of $5, you spend $1,
Stephan Livera: Right? Yeah. Okay. And let’s put that into some practical examples. I think you’ve spoken before about how that could be done. So for example, you could do one on chain payment to refill multiple channels at one time in the loop in.
Alex Bosworth: Oh, well that’s actually where we can get into even more savings. So because of multipath payments you can say I’m going to like, let’s say I’m a merchant and I’ve been receiving funds from across 10 different channels. And I’ve, I’ve received so many funds in all of these different channels and now I need to take that money and send it to an exchange and the exchange is only accepting an on chain settlement. So what I want to get out is I want to get my money onto the exchange and I also want to reset those channels so that I have inbound liquidity again. So what I can do is using multipath payments, I can spend down all of these different 10 channels at once with 10 off chain transactions. And then they, because they’re using the same hash and the same pre image, they can be locked to one chain output. So we can get a 10X efficiency there. And then the merchant gets what they want at, you know, even without like batching transactions, just by batching those off chain transactions, we can see a huge amount of savings.
Stephan Livera: That’s really fascinating to think about because it’s just such a massive, massive saving because, you know, any merchant, if they’re like, imagine in the future they’ve got lots of different channels and they’re able to just massively replenish or get the balance in the channel back in their favor that they want it in for, for a fraction of the price that it would have cost before.
Alex Bosworth: Yeah. I mean, it’s just more about being like more efficient with the chain space. So I mean, an alternative could be that you would splice these channels. So you would say, I’m gonna like splice out the difference. But when you did the splicing, you would have to deal with 10 inputs because there’s 10 channels and that would cost you 10 times as much. So what we’re trying to do is just offer the most amount of options to you about how you can avoid paying the highest fee and do it in a way that’s that it’s like an API so it can kind of just automatically figure out what’s the best way to, you know, do what I want to do.
Stephan Livera: So let’s think about it, I guess the other way. So that’s in the merchant example. Are there any examples the other way around, like in a loop in scenario, could that be like, an exchange wants to, let’s say there’s 10 customers, have an exchange, would that, would it work like that as well?
Alex Bosworth: Yeah, yeah, for sure. And the same principle just in reverse. So what would happen is let’s say I’m a mobile wallet and I don’t have just one channel because I want some redundancy. I want like a few different routing nodes. So I have assigned my capital to all these different routing nodes and but I’ve spent everything down and we want people to use those channels efficiently. So you could do three different loop ins to refill all those channels, or you could just share the same payment hash, same secret with one on chain transaction and using multipath payments. You could refill all of those different channels just in one shot. And the same thing also like versus splicing. You can get, you know, more efficiency because you’re just using this one on chain transaction.
Stephan Livera: It’s really mind blowing. Hey, I’m trying to, I’m struggling to keep up with you Alex, but I guess in terms of what’s needed to get there. So I guess obviously AMP atomic multipath payments and I know in a LND 0.8, there was some work done on per HTLC invoice tracking, which I think is like a precursor, if you will, to having AMP. What other things are needed before we could get to that vision?
Alex Bosworth: Yeah, I mean, I would say also the loop project in general is a great way for us to play around with multipath payments and realizing the benefits of multipath payments before they may be become part of a full standard across the network. So one thing that we’ve been doing in working on LND is preparing to change how the APIs work and change how the protocol works to set ourselves up for the way that we’ve thought about how to implement multipath payments and,umultipath payments. Like there’s lots of different ways to do this and the protocol. So, there’s been a bunch of debate. Uall the different implementations have come up with different ideas. Uso the first stage is, we’re gonna change the protocol to be more flexible. So the, that’s something that, that’s, that’s, that’s already coming out in 0.8.
Alex Bosworth: The ability to kind of negotiate how many different shards of the payment they’re going to be. So give us a framework so that we can describe those types of things. And we’ve also started to change the APIs in LND where you can now see the different HTLCs that are attached to a single payment because in the current, in the previous versions ofL and D like one payment hash, one HTLC was mapped one payment. But in this future world of multipath payments, there’s going to be multiple HTLCs that are all locked to the same payment. So we need to think about how to represent that in the data model and that’s been released in 0.8 and then as we go forward, we will start to have more kind of proof of concept versions of multipath payments that people can maybe play around with in an experimental way.
Stephan Livera: Gotcha. And I think the other thing that’s coming, the other question that comes to my mind just now is this question of interoperability. So let’s say in the lightning future, there’s obviously there’s different lightning implementations. Would this vision of, you know, one on chain payment to refill five channels or that kind of thing? Would that work? Presumably that would work across software as well, right, LND and maybe some of those people are using c-lightning, some of them are on eclair, I presume that’s essentially what you’re building towards there.
Alex Bosworth: Sure. Like the thing about lightning payments is you have no idea, you know, where it’s coming from. You just see a payment arrive. So I’ve even, you know, tested myself, c-lightning with lightning loop. There’s, you know, no distinction from the server side about how it’s getting that payment. You know, obviously we’re more familiar with LND. So we’ve been building stuff that works with LND but of course it could be done with, with C-lightning or with eclair. And, the other thing that’s interesting about doing multipath payments with lightning loop is the way that we’re, implementing, atomic multipath payments in this initial stage is that they are not atomic. So, met’s say that you are receiving $10, but you’re receiving it in two parts of $5. In the initial version of multipath payments, you’ll be able to take $5.
Alex Bosworth: You’ll be able to take half of the payment so you can say, Oh well the full $10 didn’t show up and I’m going to take $5 anyway. And in the full version of atomic multipath payments that we want to get in, ultimately you won’t be able to do that. But in the case of a submarine swap, it really makes no sense for you to take part of the payment because you have already locked on chain the full amount. So if you took the part of the payment, you would just be losing out money to yourself. The other side of the party already has this contract for the full amount. So as soon as you took that $5, they’d be able to take $10 from you. So this makes it like actually much stronger in terms of guarantees versus paying somebody $10 for lunch and then they take $5 and then you have to dispute with them. This is, you know, a very well bounded problem where it really just makes absolutely zero sense for you to take like part of the payment.
Stephan Livera: Right? Yeah. And I think some of that also plays into that idea of economic yeah. Some of that plays into like multipath routing and only passing it on forward once you’ve received enough to account for that. And so if there were two, $5 payments incoming before you pass on your $10 payment to the final destination, let’s say,
Alex Bosworth: Yeah, there’s an economic part of this. I mean, even in the lightning network itself, like you need to be economically incentivized to forward an HTLC. I mean, you could technically not do that, but you should probably do it just to save yourself money.
Stephan Livera: Right, yeah. And presumably as well, there’s fees, you know, that you will get for routing it. So that’s your incentive. Right, right, right. And that’s like a market process. Yeah. Okay. I’m also keen to ask, I know Conner Fromknecht from the team has been working on this as well with 2p ECDSA. Could you give us a bit of an overview? What is that and how does that relate with lightning?
Alex Bosworth: So I wouldn’t say that we’re actively working on it for like a really soon release. But the thing that we really want to do with channels is that we want to reduce the amount of money that you pay to make a channel. And we want to reduce the privacy footprint of a channel. And so the cost associated with the channel is that you, when you close it, you need to do this multi-party signature, which means you need signatures on the chain from both parties and you have to pay for both signatures. And then once you reveal those signatures to the chain, it looks very much like a channel close because you can see, “Oh, why is this 2 of 2 sending money somewhere, it could be a channel”. So with two party, ECDSA it allows you to fold in multiple signatures into one signature and that has that advantage that you and now looks like any other payment.
Alex Bosworth: You couldn’t even distinguish like what the difference between the channel transaction and a regular payment. So that gives you a lot better privacy. And then you also pay the same amount. You don’t pay any like increase for doing multisig. And that’s not something that we have in production. We have like a working version. So Conner has, you know, created this open source version, in Go of a two party ECDSA and it has the advantage that it works right now on the, on the existing chain, you don’t need a soft fork or anything and it has a advantage that, you know, you can, you can, you can do it right now and you can make a multisig transaction, but you can save that one signature. I’d say if you want production code there’s a company called Zengo which is, you know, actually has a wallet you can download it for your iPhone that, that uses this similar technology with the ECDSA. So work is being done, you know, outside of what we’re working on. And, and the, the thing though that we’re really thinking about is we have a lot of problems to solve, in lightning. And this is just one of them and things will get a lot easier with the Schnorr taproot soft fork. So this is kind of like the backup plan for if that just takes too long or if there’s problems with that.
Stephan Livera: Gotcha. And so could you just outline for us what the difference is then with the Schnorr taproot soft fork into what the on chain transactions will look like for lightning? So one example I’m getting at here is like that idea that lightning channel open and close are more distinguishable on the chain, whereas as I understand with Schnorr and taproot, some of the differences between these single signature payments and a lightning channel open and close may look more indistinguishable.
Alex Bosworth: Yeah. well, so it’s not just the Taproot that makes it more indistinguishable. Actually initially it will make it much more distinguishable. Like, let’s say that Schnorr Taproot comes out and the people who upgrade are all the lightning people, then you’ll be able to tell pretty easily. And that’s something that is being addressed in the Schnorr taproot soft fork just for the longterm. But in the short term, that’ll be an issue. So the thing that really helps us in terms of making the payments, the channel transactions look like regular on chain normal transactions is this concept called MuSig, which is like unlocked with Schnorr. Cause it’s based on Schnorr and MuSig and two party ECDSA are pretty similar. And the exciting thing about these, this concept as well is that we can do more than just two party. We can actually have many, many parties involved in a transaction. Initially as long as it’s just everybody co-signs you can have, you know, virtually like basically unlimited numbers of people all sharing that same signature. Which I think is pretty exciting. And then there’s also being work done on creating different thresholds of signers. So you could have like three of five.
Stephan Livera: With the multisignature part of it. That’s as I understand it, that, so the people are clear or very careful to establish that difference between, I think I’ve heard it described as key aggregation, not as signature aggregation or I think a Pieter Wuille has explained it, I think he’s careful to say it’s not cross input aggregation. It’s only, in relation to one input that you can aggregate, correct?
Alex Bosworth: Right, right. I mean there’s lots of different like scenarios and one of the most exciting scenarios is that especially like if we want to do Hyperloop with loop in you could potentially take many, many different spent out UTXO’s and have one signature across lots and lots of different UTXO’s that is, that is just shared throughout the entire transaction. And that’s not something that we will have. So, you know, you don’t want to get people too excited about this, even though it’s a known possibility that we could do it. We won’t have that. So what we will have. And the same thing also with threshold signatures. We won’t, you know, we’re still, people are still working on those kinds of constructions. So the thing to really expect in the shorter term is just this aggregation between everybody is co-signing, there’s nobody, you know, there’s no threshold there. There’s just everybody signs together and yeah, I would like limit your expectations.
Stephan Livera: Yeah. Just wanted to make sure people are getting the right idea on that because I think there were some, there was some discussion that I saw that I was getting a little overly bullish, if you will.
Alex Bosworth: Well yeah, something, I mean some interesting things that you can do is, is that like we have signatures in the lightning channel graph. So every time you publish like information about your fees and stuff on lightning, we have a peer to peer network on lightning that spreads out all of these signed, you know, policy statements of my fees. So one thing we could do with signature aggregation is instead of having everybody in, who has these fees all represent their signature, we could collapse all those signatures into one signature. So, and signatures are big, right? They’re a big component of the data that is synced across the network. So we can make things a lot more efficient.
Stephan Livera: Yeah, right. There’s a lot to take in there. And maybe slightly changing topic a little bit, but around this concept of fees and mining, did you have any comments around what that would do from the amount of fees that miners would receive? But I suppose would your thought be that if we’re able to do all this stuff so much more efficiently, we’ll just see so much more use of Bitcoin and lightning such that miner fees won’t drop that much? What’s your view?
Alex Bosworth: I would say it, there is some kind of competition there. There is a competition between external settlement and the blockchain as settlement. So, you know the more efficient, the better that we’ve, we can make going out of the chain while then the, the lower price that the chain can, can demand. But by the same token, if we’re making, you know, the Bitcoin economy as a whole, much more useful then we’re growing the pie. You know, we’re bypassing those limits to growth and you know, even if this is like not something that we can really control, we can’t control this economy. So all that we can do is kind of like get to the end game faster and hopefully once we get there, we’re going to have enough fees to pay for proof of work. You know. I think we’re, we’re doing great at the moment and we still have, you know, a decade maybe of pretty okay fees, but it definitely is something to think about.
Stephan Livera: Yeah, really interesting stuff. Was there anything you wanted to mention around Hyperloop or should we discuss a little bit about lightning and business models?
Alex Bosworth: Well, just like to go outside of the lightning sphere. Like I think Hyperloop ultimately could be good for people who even have nothing to do with the lightning network itself. That, you know, there’s all of this, these fees that are being pit, being paid to make on chain transactions. And you know, that’s kind of the economy that’s been built up over the past 10 years. And with lightning network, we’re really creating a totally new economy. It’s gonna take time to bootstrap all that for people to figure out that market. So one thing I really like with Hyperloop is the idea that you don’t even need to really be involved with lightning network at all to get the benefit here because the benefits straight, like the straight benefit to you is you get cheaper chain transactions. So even if you didn’t really care about the lightning network, you could just use that to get cheaper transactions.
Stephan Livera: Right? Yeah. And for some people they may eventually end up using a service that is able to be cheaper because they’re able to use some of these features to reduce their own on chain footprint, if you will, and therefore lower their own fee usage. Speaking of fees, I know recently Rusty did an email on the lightning dev mailing list about potentially raising the default fees. Do you have any views there on what the fee situation is within the lightning world and whether fees should be higher by default?
Alex Bosworth: I’ve resisted calling it a default because it’s not that the, like sometimes you have software and you install it and then it has all sorts of settings that are supposed to be good. But in the case of LND, the approach that’s been taken is that we don’t exactly know what the, what the fees should be. So we’re, we’re leaving that to the operator. It’s kind of like in Bitcoin core, we don’t have this idea like, you should pay a certain on chain fee. Like that could be a solution, maybe like, Oh, we need to, we need to get enough fees to pay for proof of work. So why don’t we just have the core developers set a minimum relay fee that’s equal to, you know, a dollar or something. And I mean, then you’d have this problem though where maybe that’s not the right value, so you have to adjust that value.
Alex Bosworth: And I think one approach that’s been taken in LND is like not setting default. So but of course you need to have some value that’s there at the start. And that’s why like it’s difficult to say if it’s a default or not a default. I think that Rusty’s totally right, that you need to actually think about these values. And like just setting it to what you get out of the box. If you want to be a good router,uyou’re not going to have, you’re not going to be a good router out of the box with the initial initial set of values. I don’t think that it’s so simple that we can just set a rate it’s a market process. We need people to be figuring this out and in order to make it better, we need to create tools that make it easier for people to adjust their rates to what they feel comfortable with and give them that information.
Stephan Livera: Got it. And I, I, I think one thing, if you’re listening in you’re a routing node operator out there, you might be thinking, well, I’m not sure what is going to get developed and come into lightning. And that might in turn influence my own fee decision of what I set as my fees because let’s say AMP comes in in a year or two years, then that might change the way I set up my channels. I guess that might be something that has to get shaken out in terms of who’s setting up what service. If you’re running an LSP, a lightning service provider, or if you’re a routing node or if you’re a merchant trying to sell things using lightning, I guess they all sort of play into your decision on what sort of fee are you setting.
Alex Bosworth: I mean, I’d be happy if people just gave some thought to their fees because one thing that I think has been a problem is that people are not really considering their routing nodes to be a business. And since they’re not a business, they’re not reacting to market conditions. And so the service of a lot of routing nodes is subpar. So I think the, you know, before we worry about AMP, before we worry about all these technologies, we need to really think about how do we get these people to understand that they’re offering a paid service to people. They’re, they’re supposed to be making money. And that’s just something that like we need to figure out.
Stephan Livera: Yeah. Gotcha. And so they would need to start considering the different costs associated with running. You know, it’s a hot wallet. There’s a risk associated for that. You’re paying chain, you potentially are risking paying chain fees. If your channel partner let’s say opens the channel to you, or if they go stale, there’s all these sort of risks I suppose. And because of that, they would need to dial their fee settings appropriately to account for that, such that they are then profitable as a routing node.
Alex Bosworth: Yeah, I mean it’s just like any other business. So you have a certain set of costs and you have a certain amount of revenue and you need to make sure that like you’re keeping a handle on your costs. I would say that as far as features go, we want to offer more tools to people. And there’s some things that maybe even need to be changed in the protocol. Like one thing that I think is weird is that we don’t have a pairwise market. So you know, if you set your fees, you can set different fees for different destinations, but you cannot set different fees for different sources. So if I have a source, one source who is like a mobile node who is not giving me routable liquidity, and I have another source which are the routing node who I have full utility of my money there, I have to give them the same rate. Because it’s just impossible in the current fee schedule, in the current protocol to give multiple rates from multiple people. And there’s good reasons why you can’t do that. But because we have these limitations, it creates, you know, less movement for market actors to, create, you know, great fees.
Stephan Livera: Right. And let’s just walk through that example a little bit. So let’s say the mobile node is connecting to the lightning routing node in this example. And I guess the problem in this case problem quotation marks, is that this mobile routing node is likely, well, is not going to be routing payments any be further beyond themselves. They’re just paying through this lightning node, a guy. And that is inferior from this lightning node guy’s perspective because he would rather have a channel with another routing peer because that guy, so the money moving through that channel is much more free in some sense because it he could use it routing his own payments through,
Alex Bosworth: Well I don’t know if I would like say if they’re like inferior. I would say that it’s like different. So the pro of having like this mobile wallet is maybe this guy’s a spender, but you need to have some vendors to give you fees. But the downside is the more that he spends, the more capital like piles up on your side. And like if it’s a mobile wallet, by default, I would imagine all of their channels are private. So even if you wanted to like send that money out somewhere else on the network, you wouldn’t know how to get it there because the channels are private. So if you had another peer who’s a routing node, you know, all their channels are public. If money stacks up on your side, you could say, Oh well I can use that money to push it out to an exchange or something. So there’s just like that, there’s these different types of liquidity and as a routing node operator, you’re a little bit constrained in that you can’t, you have to treat them as equals.
Stephan Livera: Gotcha. And so I guess that also places some importance on your position within the, within the lightning network graph, if you will. Can you comment a little bit on how to think about that and how to position for that?
Alex Bosworth: Yeah, I mean, you could also think about it like as if there’s two different roles of routing nodes. So there’s a routing node who is a provider for people who are on the edges, like these mobile wallets and that’s kind of what they specialize in. And because we have this like system where you have this one fee rate from anybody who is coming to you, that’s like a way to work around problem. You could just say, all of my, all of my peers are mobile clients. So it makes sense that I charge them all the same rate. There is another way that you could, you could operate your node and that’s to operate as you only connect different other always online nodes, other public channel nodes together. And so you could be maybe the interior of the network. And that comes with the different operational requirements. So if you’re on the edges of the network, you need to be OK with your capital, maybe being offline being unrideable. If you’re in the middle of the network, your capital requirements are lower. So you know, that’s just something that like needs to kind of play out in terms of like business specialization.
Stephan Livera: Yeah. Really interesting to think about though. A and what about another one channel acceptance policy. So one quick example, I know, I know a Bitrefill will actually reject your channel unless it’s I think 0.4 BTC or something like that. Cause they want only the big channels. Right. And so that’s another thing that may come to lightning as well of having more specific policies on which you accept or reject incoming channels.
Alex Bosworth: Actually, that is a feature already now in 0.8. So 0.8, which was just released allows you to set an arbitrary policy so you know whatever kind of criteria you want to enforce. And one example I talked about is maybe you don’t want all these tiny channels and that’s something that I also enforce on my nodes. I don’t want these small channels because you know, people are still learning how lightning works and a lot of times people are like, I’ll make a channel for the full amount of money that I want to spend on my channel and then it will only get one payment and you won’t get the aggregation benefits. So I set a minimum channel size to kind of reinforce this idea that channels are things that you’re reusing and the reason you’re using it is because that gives you more chain efficiency and lower cost. So as an alternative to this policy, which just says you pony up $400 or you get lost, you could say, well, I will accept you at a lower amount of money if you push some funds over to my side to kind of like make it worth my while. So you could say either they put up $400 or they put up $20, but then they send me 50 cents. So those criteria are completely up to the operator now.
Stephan Livera: Right? And then how does that get negotiated between the different clients? So let’s say in that example, you’re running LND 0.8, I’m running LND 0.8, and you want to put in a policy to say, Stephan, if you want to open a channel to me for $20, I want 50 cents. How would I get notified of that? Would it, would I see an error message saying, Oh, Alex has rejected your channel. He wants you to put 50 cents on his side of the channel. How would that work?
Alex Bosworth: I think that would be an obvious easy flow. But unfortunately in 0.8, that was like a still outstanding issue of customizing the message that gets sent back. So in the current release you’d have to somehow out of band signal to the person that this is what your requirements are because the current message is just “it failed”. I’ve made an issue on the LND repository to allow you to customize that message. And you know, if people, if more use does come out of this, we could formalize it into more of a protocol that says, you know, here are the conditions and that’s something also we’ve thought about just at a high level. Just communicating your, your channel policies in some way that sync, just like all the graph data. So I’m this node and here is the type of channels that I want.
Stephan Livera: Hmm. One other question I was keen to ask you about is stuck payments. So as I understand, that’s one potential area where lightning payment user experience might be a little tricky right now. Because, for example, you might scan the QR, you might pay it and then you’re waiting and you don’t know if it’s gone through. And then if that user got impatient and then just said, ah, screw it, I’ll just, I’ll try with another wallet. At that point they might have accidentally double paid the invoice. How are you thinking through that issue and what are some ways to deal with that?
Alex Bosworth: Yeah, that is an issue where we have lots of different ways that we can address it. And also it’s an outstanding issue. So in the current LND, if you hit a stuck hop, you will potentially run into problems. I don’t think it’s like a current major issue that people are seeing. It used to be more in the past, you know, not because of any nefarious nodes, but just because the protocol wasn’t as solid as it is now. Like all of the implementations were kind of learning to work together. And in the current, in the current network, I think we rarely ever see these stuck payments. But of course it’s a possibility. I think that’s something that Joast is working on.
Alex Bosworth: And that we have in kind of a test mode at the moment of a model to deal with stuck payments and not just stuck payments or delayed payments. Like, why is my payment taking a while to get there? So we’re, you know, we’re working on a combination of pathfinding solutions to try to like make it responsive to those situations. We’re also making it like the different modes of pain. So one way that you can kind of avoid stuck payments is that you can take a look at the route that you’re going to use and before you actually commit all your money to the actual payment, you send a test payment through and the test payment can be very small,
Stephan Livera: Like a probing amount or or whatever,
Alex Bosworth: exactly like a probe. And if you don’t hear back from this probe, you can say, well, that route, you know, there’s something wrong with it.
Alex Bosworth: And if you do hear back really quickly and easily, then you can say, well, you know, I did and that payment of course can still get stuck. But if you’re just sending like a penny or something, like if it gets stuck, it’s not a big problem. And the other thing about a probe is the probe can never resolve in you losing your money because it’s, the probe is sending to a payment hash that’s a fake payment hash. It’s just a random number. So nobody has the secret that corresponds to that hash, so nobody could take that money. So it’s a lot lower risk. So one model that I also use, like when I make payments is I first send a fake payment hash to the same destination that I intend to pay. Then if that succeeds, I take the same route that just succeeded with a fake payment hash and I got a good signature from the destination and I can say, okay, now I’m going to send using the real amount of money and the real payment hash.
Stephan Livera: I guess one question that’s strikes me there is using a fake payment hash in that scenario. Is that still looking up HTLCs along the route?
Alex Bosworth: Yeah. I mean from the perspective of the network, it has no idea that there is anything different.
Stephan Livera: Right? Yeah. So it just, it might lock up a few sats along each hop on that route. But fundamentally.
Alex Bosworth: Depends how much you want to probe. So the reason you would want to probe with lower amount is just, you know, if it does get stuck while you’ve only stuck up, you’ve only stuck like a penny. You might wanna try the full amount. And in that case then you can you can get stuck with the full amount.
Stephan Livera: Okay, cool. Look so we’re coming to time, but I think probably just a final question. What are you most excited about for lightning over the next, let’s say year or two?
Alex Bosworth: While the thing that I really, want to see happen is to take all of these amazing tools that we are making. I’m on the implementation side of things and like create amazing services that really take full advantage of them. So, you know, I know a lot of companies have just received funding for building out these new services, and I think we’re still in kind of the mode of like, why don’t I just take what I was doing with Bitcoin before and just like kind of map it into the lightning world. But what I really think could be cool is like totally new possibilities that are opened up with lightning and you know, just were never possible with on chain transaction flows.
Stephan Livera: Yeah, that’s a good way to leave it. Alex, just for the listeners, I guess most of them probably already know where to find you, but @AlexBosworth on Twitter, lightning.engineering, is it? Where else can people find you?
Alex Bosworth: Yeah, I definitely I try to post regularly, you know, create content every day on Twitter. And then on the lightning Slack, the lightning community Slack, I think is a great resource to have kind of back and forth conversations. And if you are developing on lightning, it’s a great way to reach out to other people. There’s always some people there who can help you get started.
Stephan Livera: Fantastic. Well, thank you for joining me, Alex.
Alex Bosworth: Oh, it was great to be on the podcast.