Lightning Protocol Privacy Exploration
Speakers: Bastien Teinturier
Date: November 7, 2021
Transcript By: Stephan Livera
Category: Podcast
Media: https://www.youtube.com/watch?v=MGv8rTB63Mk
podcast: https://stephanlivera.com/episode/319/
Stephan Livera:
T-Bast, welcome to the show.
T-Bast:
Hey, Stephan. Thanks for having me.
Stephan Livera:
So Bastien, I prefer definitely having good technical discussions about the Lightning Network. And I know you’ve got a lot of things to talk about. For people who don’t know you, do you want to just tell us a little bit about yourself?
T-Bast:
Yeah, sure. I started working on Lightning a few years ago. I think it was almost two years and a half ago, I joined the ACINQ team to work on Eclair and the specification, and then I quickly spent a lot of time in the specification working with everyone. And I just love it. It’s just a great opportunity to work in that space, so I’m having a lot of fun.
Stephan Livera:
Awesome. From your perspective, do you work a little bit on both? Like, do you wear two hats in terms of Lightning protocol stuff and then also ACINQ, Eclair, Phoenix—working on those things?
T-Bast:
Yeah, I wear all those hats. I spend a lot of time on the spec. On the ACINQ team, I’m the one spending the most time on the specification. I’m trying to review almost everything that comes through the spec and sometimes giving it a go at implementing it, or asking other people on the team to implement it in Eclair. I spend also a lot of time on Eclair and also a bit of time on all our other libraries that around the Eclair ecosystem. We have a Bitcoin library, Scala, and Kotlin Multiplatform. We have actually a single Lighting implementation, Kotlin Multiplatform that is geared towards wallets called Lightning-KMP. So I’ve been spending some time on that one as well.
Stephan Livera:
Awesome. And I know you had some interesting thoughts around Lightning privacy. I know that this is an area where you’ve been focusing a lot, probably a lot at the protocol level where are the places that people might be falling down or leaking some info from a privacy perspective. So could you give us an overview? What are some of the main ways? Then we’ll dive into a little bit more detail around privacy leakages or ways that you’re leaking or doxxing things?
T-Bast:
Okay, yeah. Privacy is a topic that I’ve been very interested in, mostly because I love cryptography. I think that cryptography is one of the technologies that man has invented that can allow us to free ourselves. It’s just so powerful and so interesting. And it gives us a lot of tools to get better privacy than what we are used to. And on Lightning, we have a lot of opportunities to reach a great level of privacy. But we currently have a lot of shortcomings: there are a lot of things that we can improve. And a disclaimer is that: whenever I talk about privacy in Lightning as a code-developer guy, I tend to focus on all the things that we could be doing better, so I’m going to point to a lot of things that aren’t as great as they could. So usually at the end of my talks, people say, Oh, but privacy looks horrible in there! And I want to say that, No, it’s not horrible at all. It’s already great, but there are a lot of things that we can do better, and we’ll have ideas on how to make them better. So that’s why I think it’s important to talk about them, just so that everyone knows what the trade-offs are and what risks they are taking, if they are taking any regarding their privacy. So on Lighting, Lighting privacy is quite different from on-chain privacy. But there’s a link, because there are two main areas where your privacy might not be as good as you think: there’s one area where you want to make sure that people cannot link your on-chain activities—on-chain UTXOs—to what’s going to happen off-chain. So that’s a really important property. And currently there are a lot of areas where we do not have that in Lighting, but it’s going to get much better with Schnorr, so we’ll dive a bit into that. And then once you have broken the link with on-chain and you are living in the full off-chain world, your payments should be private: the way you pay, the way you receive payments and send payments should be private. And there are currently a lot of details where you can be less private than you would hope. So we will also dive into that. And those two are really octagonal, and they also depend on whether you are a full node or a mobile wallet, so we’ll get into the details of that.
Stephan Livera:
Yeah, gotcha. So high-level, we should think of it, like a Lightning payment—although there are ways you are doxxing things or leaking things, it’s probably fair to say Lightning payments are more private than an on-chain payment that’s broadcast out to the whole world and everyone can see that on the blockchain—but as you were saying, there is an on-chain footprint. So it’s not like people using Lightning are just never touching the chain—they are still touching the chain—it’s just that they’re doing it in terms of channel open channel close, these kinds of things. So could you tell us a little bit about the on-chain footprint for a Lightning user?
T-Bast:
Yeah, sure. So the way Lighting is done is by opening channels to people. So opening channels means you have to do an on-chain transaction that is called the funding transaction. Once that channel is open, you can start doing Lighting payments. And then at some point you may want to close that channel. You don’t need to, but you may want to close it if you just want to stop using that peer and go to another peer, just stop using Lightning, or just start with another account for privacy. So there are two ways the channel may be closed: either you do a collaborative mutual close where you both decide, Hey, we want to close, or there’s another way where one of the two parties can decide to unilaterally close. That’s very important to be able to do in case your peer just disappears—goes completely offline—and you want to get your funds back. And that will incur an on-chain transaction as well. So the transactions that we do in the mutual close case and in the unilateral case are very different, and they don’t have the same privacy guarantees. So first of all, what you want when you create your channel, you want that that funding transaction does not reveal that it is using Lightning. But right now it is, because that funding transaction is basically a Pay-to-Witness-Script-Hash output with a 2-of-2 multisig. So once you create the funding transaction—everything is okay—no one knows what that script contains so no one knows that it could be a Lightning channel open, but once you close it and you spend that output, people will see on-chain that this was spending your 2-of-2 multisig. And this isn’t that common right now in the network, so if people see a 2-of-2 multisig being spent on-chain, they know that there’s a high chance that this was a channel opening. So that’s bad, but this one is something we can very easily fix once we have Schnorr because with Schnorr we’re going to change that to—instead of being a 2-of-2 multisig—we’ll use MuSig2, which is a new protocol to make Schnorr multisignatures that look like a single signature. So people will not be able to see on-chain that it is different from just a single signature. So this is going to be great, and it’s going to be a great improvement for Lightning privacy at the channel opening level, but it only fixes the issue when there’s a mutual close and when you are going to be deciding to spend collaboratively and you will be able to create that multisignature. Because otherwise, in the case of unilateral close, since one peer needs to be able to spend on-chain alone, he will have to reveal his script, and this is going to be a non-standard script. So when you do a unilateral close, I think there’s no way we’ll be able to guarantee that this looks like a normal on-chain transaction, because—for the safety of your funds—this has to have very specific scripts to let you get back on-chain the funds that you had off-chain.
Stephan Livera:
Gotcha. Yeah, so let me just walk that through a little bit and make sure everyone’s following along. So when we set up our Lightning channel, we’re doing it in a conditional way—or we’re using Bitcoin script. And so this is where there are, if you will, different spending pathways. So what we’re saying here is: at the time that we close that channel, then it becomes recognizable because any outside observer can view that script—that was actually encoded—and see, Oh, hang on. This is actually a closing of a Lightning channel. I can tell that right now. Because—depending on how the Lightning channel and depending on the conditions—there might be some kind of CLTV or CSV condition applied to it, and I’m showing you, Here’s the script and here’s the signature in order to make this a valid Bitcoin spend. And so, because of that, now we can recognize that. But what we’re saying is: when we’re moving into the Taproot/Schnorr world, and we’re using MuSig2—for listeners, I did an episode with Jonas Nick and with Tim Ruffing talking about MuSig2—in the Taproot world, we would be doing let’s call it the key path spend, which is indistinguishable from another Taproot key path spend at least on that metric or on that count. Is that a fair summary?
T-Bast:
Yeah, exactly. And I’m really excited about MuSig2—Jonas and Tim have been doing a lot of great work and their PR is still under review. We cannot do that in Lighting until MuSig2 is completely standardized and integrated into Bitcoin. So if there are decent C programmers listening to this show, I encourage them to just have a look at that PR and help Jonas get it merged because then we’ll be able to use it in Lightning and it will be great, even though it will only protect us when we do a mutual close. When you do a non-cooperative close, then it’s always going to be a singlesig and will have to reveal one of a Taproot scripts, and then it’s going to be obvious that this was a Lighting thing. But if we can improve it for the mutual close case, it’s already a big win compared to today.
Stephan Livera:
I see, yeah. So some of that just comes down to the way Bitcoin works and the [way] scripts are working, because part of that is the channels have to be constructed in this way so that you can unilaterally recover, as opposed to being reliant on that other person. So there’s a little bit of, I guess, cryptographic magic that goes into it, but essentially that’s part of what gives Lightning network this ability to be used in a non-custodial way as opposed to trusting somebody else. And so that’s part of this idea of the open permissionless Lightning network that we’re doing. So yeah—this is kind of doing it the hard way—but it’s doing it in a way that gives people certain qualities and certain things about the Lightning Network that we couldn’t get if we’re just using Visa, MasterCard, et cetera. So that’s probably an important point to understand. And then the other aspect is that channels are advertised publicly, right? So there’s gossip data being sent. So when I spin up my Lightning node, it’s talking to the other Lightning nodes and saying, Hey, here’s what’s going on. So could you explain a little bit about that? What’s going on there with public advertisement of channels?
T-Bast:
Yeah, exactly. So once we fix the issue we mentioned previously, we will be protected from people that are only watching the chain. They won’t be able by just watching the Bitcoin blockchain to detect what is Lightning. But if they run a node in the Lightning Network, they will still be able to link some UTXOs to channels, because as you said, we just gossip every public channel that we open. We’re just going to send it to everyone in the Lightning Network. The reason we do that is to allow everyone to have locally the graph of the network to be able to find routes, because the way we do payments in the Lightning Network is that we are going to find a route from the payer to the destination, so the payer needs to have enough information about what channels exist in the graph to find the route himself in order to not have to ask someone else to find the route for him, first [by] revealing the recipient. So fundamentally I think that we will still need to be able to reveal off-chain that this UTXO was used to open a channel between this node and this node. And Rusty recently proposed something where he’d like to change this to a UTXO ownership proof. I haven’t looked at all the details yet, but I think that this cannot completely solve the issue. At least, if it solves the issue of privacy, it will have a negative impact somewhere else, because the reason we want to know which UTXO is used to create which channel is that by just watching the chain, we can also detect when a channel is closed and that this way we can remove it from the graph to make sure that we do not try to send payments through that channel that doesn’t exist anymore. So if we remove that information, we won’t be able to know that channels are closed, so payment routing will most likely fail more often than right now. So I think there’s a fundamental trade-off here between privacy and reliability. So people who are running a node off-chain are able to still link that a given UTXO was used to open a channel between two nodes. So you may think that there’s a silver lining here—that they do not know which of the nodes put that fund in the channels, [that] it gives you deniability—but actually it’s not that good, mostly because these UTXOs are likely eventually going to be reused. So if there’s a channel open between Alice and Bob, someone just watching that doesn’t know if this UTXO belonged to Alice or belonged to Bob, but if a channel is closed and then the UTXO from that channel closing is used to open a channel between Alice and Carol, then you know that this UTXO belonged to Alice. And it’s the same if Alice reuses the change output from the funding transaction—it lets anyone link those. So I think it’s really easy to be able to decide which of the nodes in the channel could be on-chain funds in the first place. The way you could work around that is by very carefully managing your coin selection to ensure that you do not reuse for another channel a coin that came from a previous channel, but that’s actually really hard. Because that means that a lot of your UTXOs—once they come from a channel that has been closed—are basically unusable off-chain. You have to only use them on-chain, and it kind of locks up a lot of liquidity that you would want to use. And you’re already locking up liquidity in Lightning. If you also have to lock up liquidity on-chain because you want to preserve your privacy, that’s a lot of coins that you just cannot use. And it’s really hard.
Stephan Livera:
Yeah. That makes it very infeasible. So again, just walking that through for listeners—the idea is: when you send a Bitcoin transaction there’s inputs and outputs. One of the key on-chain surveillance heuristics is this idea of figuring out which one was the change. So the idea is if I sent 0.9 Bitcoin to you, and that came out of a 1 Bitcoin UTXO, then people can see, Ah, 0.1 change back to Stephan—so that must be his coin. And then if I then later use that to open another channel, they can see, Oh look, Stephan is just opening another channel with that 0.1 change. But perhaps longer-term over time, if things like dual-funded channels that makes it less and less clear which one is the change if we both collaborate—and let’s say I collaborate with you on which UTXO to fund that channel with and then I later fund a channel to somebody else and I also do a dual-funded channel thing with them—again, it’s a bit more complicated and it’s a bit more difficult, but maybe that’s a longer term idea that could help make that [surveillance] less reliable.
T-Bast:
Yeah. It’s going to make it a bit better because people won’t be able to know exactly what amount you put in—they will be able to know that you put at least some amount. But actually I think there’s another good silver lining there that does a better way to at least hide partially your funds, and that’s unannounced channels. That’s something that has been incorrectly called private channels because they are not really private. They can be proved easily and we’re doxing them a lot in invoices, and we’ll cover that later. But if I open a channel to you publicly, I give that to the whole network. The whole network knows that we have a 1 Bitcoin channel between us. I can also open other channels to you, but just not announce them. So people will think that one of us put 1 Bitcoin between the two of us, where, in fact, we put like 10 or 20 Bitcoin. And whenever they route payment, since they know that there is one public channel, they will just try to route—it will always work because we actually have a lot more money between us than only the 1 we advertise. And we’ve been able to completely hide these on-chain funds. And I think that’s a great way for nodes who have at least a decent amount of a UTXOs to put in to be able to hide most of the UTXOs and completely break the link between on-chain and off-chain, because they don’t ever have to announce these channels to the network—they just lazily use them to route payments when they receive a payment that they should route, because they don’t have to explicitly route through the public channel. They can route through any of the channels they have between themselves and people won’t know which channel it went through. As long as it worked.
Stephan Livera:
I see. Would there still be a payment reliability issue or negative impact there just with a lot of private channel use, or do you think it wouldn’t be a huge deal?
T-Bast:
No, there would be absolutely no impact. That’s why it’s interesting. As long as your public channel that you open is big enough that it still attracts payments, people don’t care whether you send it through that channel or you send it through another channel you have with your peer, or you even do something completely differently than Lightning. You could even just send him a message and trust him to do it correctly. So people don’t care what happens between two points, as long as what they put in as input with what they see as output is just correct. So I think it’s a great way to hide most of your funds.
Stephan Livera:
I see. So right now it’s like unannounced channels can be more easily doxxed, but if they were to be used more widely, then that’s what you’re saying, it might be—and people don’t necessarily doxx the existence of that channel with a route hint or something like that—then that’s where the privacy benefit might come for that.
T-Bast:
Exactly. I know for a fact that it is actually used by at least a few big routing nodes, so this is already in the network and that means that people cannot know that these channels exist and [they] underestimate the actual channel capacity of the network thanks to that.
Stephan Livera:
I see. Yeah. And then there’s also this idea I’ve heard of called route blinding. So what’s that?
T-Bast:
Yeah. Perfect. I was going to come to that because it’s interesting that mobile wallets don’t have the same requirements as routing nodes. Routing nodes need to advertise at least one channel they have with that peer, because they want people to know that they can route through them. But mobile wallets are not routing payments, they are just receiving and sending payments. So mobile wallets always use unannounced channels. So if they were able to completely hide those from the payers, it would be great. It would be perfect. Right now, the issue is that they are not, because when the mobile wallet needs to be paid, they need to tell the payer how to reach them. So they currently include what we call a route hint in the invoice that contains the whole details of the channel. And that’s bad because that reveals both their channel_id and node_id, and then people can go see on-chain that, Oh, this wallet has actually put that many funds in this channel. We’d like to avoid that, and we’ve thought of a lot of ways to avoid that. Christian explored a lot rendez-vous, but the issue is that rendez-vous just doesn’t work well with Lightning because it restricts too much what the payer can do. So when we discovered that rendez-vous was not going to be a thing at this for normal payments, we will need to do something else, so I spent a lot of time figuring out what we could do. And I ended up with this proposal called route blinding, which is a kind of lightweight rendez-vous which addresses all of these issues. It’s really nice because it lets a recipient be paid without revealing neither his channel_id nor his node_id, and that’s great because revealing your node_id is also another privacy issue. If you could just be paid without revealing anything about you, it would be perfect. And that’s where route blinding comes in. The overall idea is that instead of providing a new invoice or route hint that tells exactly what your channel is, you’re going to provide an introduction node. You’re going to tell the payers, If you want to reach me, start going through Rusty’s node, for example. And then from Rusty’s node, go to that node, then that node, then that node. But instead of giving the real node_ids here, you are going to give fake node_ids that are completely unlinkable to the real node_ids. And you’re going to give cryptographic information that will let each node—when they receive a payment—be able to just unblind only the next node and then send him a payment. And that guy is going to be able to unblind the next node and the next node until it reaches you.
Stephan Livera:
So it’s sort of like the onion routing construction idea but applied to nodes as well instead of payments. So could you help us understand: what’s the difference between something like this and an earlier idea, like trampoline routing?
T-Bast:
This is [all for the] node trampoline and they combine well, as a matter of fact. They are really interesting to use together. And trampoline is also very interesting to use with rendez-vous because rendez-vous is not practical for normal payments but it becomes practical with trampoline payments—and that’s something that most people didn’t realize. And I think it’s a really interesting property of trampoline. So yeah, I think we should get into that. I just wanted to mention, while we’re talking about route blinding, that there is currently a simpler proposal that has a smaller benefit than route blinding, which is just the idea that instead of putting your real channel_id in a route payment, you could just put something completely fake. But you would have to tell your peer, I’m going to be putting this fake channel_id. If you see that, know that it’s me and relay to me. And Rusty proposed that in his current PR for zero-conf channels. So we may see that in the network soon, but the issue is that it only works for a single hub, and it doesn’t hide your node_id. So it’s not as strong as route blinding, and in fact actually Rusty proposed that already a year ago and I was not happy enough with that. I thought we could do better. And that’s why I looked into route blinding and I superseded his proposal with route blinding. But actually route blinding uses a lot of cryptography, and I’m not a cryptographer. I’m just a dev who loves cryptography. So I would love to have more reviews on the proposal. The spec PR has been out for more than a year and it’s being used. It’s a dependency of Offers and onion messages. So we are on the verge of shipping it soon, hopefully. So if people are able to review that, please review it and give some feedback before we actually ship that to implementation.
Stephan Livera:
Yeah. One other thing around route blinding: how is it that you can put out a fake node_id and the counterparty still knows where to find the real place to pay? How does that part of it work?
T-Bast:
It’s a bit similar to adaptor signatures in the sense that, as a receiver, the way you are going to do this is that if I’m Alice and I want to be paid by Eve, and there’s a route—Alice, Bob, Carol, Dave, Eve—and I want to tell to Eve, you’re going to go to reach me through Carol, but I want to hide Bob and Alice. What I’m going to do is I’m going to tell her Carol, but then instead of using Bob’s node_id, I will add a random tweak to that note ID. So it creates a completely fake node_id, but Eve is going to have information about that tweak encrypted so that only Carol can decrypt it, so that when Carol receives that message, Carol is able to get that tweak, remove it from the blinded node_id and discover that this gives her the node_id of Bob. And then she forwards, and Bob is going to have something equivalent for the tweak for Alice’s node_id.
Stephan Livera:
I see. So it’s almost like: they’ll receive this information and they’ll have this almost revelation that, Oh, actually you’re trying to pay this person. And I know that person—I can pay them. It goes step-by-step and then Bob is going to do the same thing and because he’s the final step in the journey, he would know, Oh, actually I’m paying Alice—in that example.
T-Bast:
Exactly. It happens one hop at a time where every node just discovers, Oh, the next node is actually that node—and I’m the only one to discover that. And then the next node does the same and does the same. And you can actually add dummy hops at the end so that people think that the route is longer than it actually is, and when you receive a final payment and see that you should relay it—but in fact, you’re relaying it to yourself—so you know that you’ve reached the end, and the payer thinks that the route was longer than it actually was.
Stephan Livera:
Yeah, it’s interesting. I’m wondering, could that sort of thing get DoSed? Like, could someone malicious just make up a bunch of fake routes and just send them all through the network and just push computational costs—time—onto everyone else?
T-Bast:
The cost here is not too hard. It’s just one decryption and one addition to a public key, so I think it’s okay. I think it’s not worse than what we already do for onion messages, so it wouldn’t be worse than what people can do when they just send payments for dummy payment hashes and you relay them and then they fail. So I think that the solution to that would be the same solution as we have to avoiding these fake payments.
Stephan Livera:
I see. Yeah. So it would be at a similar level to what probing is today?
T-Bast:
Exactly.
Stephan Livera:
It’s where it’s kind of already accepted by most in the network, although some people do have a privacy concern about probing, but that’s another whole can of worms—we won’t go there yet! Okay, so those are some of the first things to think about. What about other ways in which our off-chain payments can be doxxed? Or there might be some kind of privacy leakage?
T-Bast:
Okay. I think that we’ve covered most of the things that happen between the on-chain and off-chain part. And now once you’re completely in the off-chain world, one of the first things where privacy falls down is that, when you are on a mobile wallet, it’s really easy for your peer to discover that you are a mobile wallet. The way we do payments in Lightning is that we use this onion routing scheme that lets every node only know that the previous node was the one who sent them the message, and the next node is the one that they ask to relay to, but they don’t know anything more than that. So they do not know if the previous node was actually the payer or just another routing node. And they do not know if the next node is the recipient of just another routing node and the route extends after them. But when there’s a mobile wallet involved, that is not true anymore because if your mobile wallet is connected to you, it’s very easy to see because they will have unreliable connections, they will be offline most of the time, they will not have a stable IP, they will be using TOR, and you will see that they will not have a public channel with you. So you know that this guy is a mobile wallet. So when you receive a request for a payment from someone that is a mobile wallet, you know that they are the sender—they could not have relayed it from someone else. They do not relay payments. So they are the sender. And similarly, when you are asked to relay a payment to someone that looks like a mobile wallet, you know that they are the final recipient. So that breaks the onion routing guarantees. And I don’t think you can fix that, ever, because you will never be able to convince a server node that your mobile wallet looks like a server. You will not be able to keep a connection all the time to them, otherwise your battery will die. So you shouldn’t even try to hide that. The best you can hope for is to at least hide your IP address and hide your node_id, or split your activity between multiple node_ids. But there’s no way you’re going to be able to completely defend against that. So you have to accept that, as a mobile wallet, the node you’re connected to will be able to know that you are sending payment, but you want them to not be able to know who you’re sending that payment to. And when they relay a payment to you, they know that you are receiving that payment, but you don’t want them to know from whom it was coming. And that’s where it would be great to have something like trampoline. And I think it helps privacy a lot, because right now people on mobile wallets are actually depending a lot on the nodes they’re connected to for pathfinding. Because either they are asking that node directly to do the pathfinding—which is really bad because that means they are telling that node, please pay that guy, so they are completely revealing that they are the payer and who the recipient is—or even if they’re not, since they depend on their peer to relay to them the graph information, their peer could actually omit some channels and give them a lightweight version of the graph that still lets them discover who they’re paying, even though the mobile wallet thinks they are private because they are calculating the route themselves. If they are calculating a route without the full graph information, they may be revealing who they’re paying anyway. And where trampoline is really nice is that the way it works—it’s really hard to explain with just audio, but it’s really much easier with texts, so I will get into details about this in El Salvador, the Adopting Bitcoin conference with a lot of diagrams and I hope it will make sense for everybody—the way you use trampoline is that, as a recipient, if you want to be paid over trampoline, you will find some node in your local neighborhood—a trampoline node—and you will include him and a few other nodes in your neighborhood. You will include them in your invoice. And that tells the payer, If you want to reach me, find a way to trampoline to that guy. As a payer, you’re going to be looking at your own neighborhood, choose one of these trampoline nodes, and send them the payment. And this trampoline node—we are using onion routing for the trampoline path as well, so this trampoline node only knows who the next trampoline node is. They do not know if it’s the last recipient or a normal one. And in the case I described, it would not be the last recipient—it would just be another trampoline node. So at least your LSP is not learning who you pay. And when the second trampoline receives the payment, they see that it was coming from some node, but they don’t see the payer, and they may discover the recipient if they’re directly connected to them, or they may not if it’s not a mobile wallet and they are not directly connected. So at least the best a trampoline node can learn is either the payer or the recipient—but not both. And from what we’ve said before: as a mobile wallet, you cannot hope for more because the node you’re connected to will know that you’re a mobile wallet, so you are either the payer or the recipient.
Stephan Livera:
Yeah. There’s a lot there, so let’s try to walk that through. So one of the [key] ideas, as you were saying: as a mobile wallet, you will not be able to hide the fact that you are a mobile wallet. So let’s just resign ourselves to that. That’s not going to change. But then the other part we were talking about is that, as a mobile wallet, one of the challenges is you have to—well, theoretically in the Lightning Network, you want to maintain this map of the network or routing graph—because you’re a mobile wallet, you’re smaller and you won’t have as much computational power, as much hard drive, and so on. You don’t want to necessarily carry that entire routing graph inside your phone because of the battery reasons and computational reasons. So what’s happening in practice is you’re offloading some of that to somebody else. And so in this case it might be an LSP (Lightning service provider). And so what we’re talking about here is this idea that we would use a trampoline-style payment which masks who you’re actually paying to or receiving—like in the way that you’re receiving the coins. So there might be a bunch of trampoline nodes out there in the network, and they might be—as an example, the Phoenix wallet and the ACINQ node would be a trampoline node and there might be other people out there who are running a Lightning node anyway—and they sort of put their hand up and say, Hey, I’m willing to be a trampoline node as well and help other people route through me. And so it’s that similar kind of idea like you were saying, like that kind of revelation of once that payment has gone through, you see the next person who you’re sending it to. And in doing it this way, we are potentially getting more privacy for the mobile wallet users, or potentially even just a normal Lightning desktop wallet user who wants to use trampoline. Have I got you right there?
T-Bast:
Exactly. That’s exactly that. And what’s interesting is that it’s finally been—we’ve proposed trampoline more than two years ago, and it was coming from an idea from Pierre-Marie Padiou and Christian Decker. And there has been progress in that because we’re not the only trampoline node in the network anymore. Electrum is also running trampoline nodes. So this actually could be a reality to do two-trampoline hops that would help for the privacy of mobile wallets, but we just need it to be more widespread. So I’m hoping that c-lightning and LND and LDK start implementing that soon as well. We’ve discussed it recently at the LN meeting: there’s a lot on everyone’s plate right now because there are so many things happening—especially with Taproot—but I’m hoping that we will eventually get there because I’m quite convinced that the way I plan on using it is actually a great privacy improvement for mobile wallets.
Stephan Livera:
I see. I recall there were some earlier criticisms leveled at the idea of trampoline, but I think that this is one of those areas where it’s quite a technical area and people who are at a very advanced level—Lightning protocol developers and cryptographers—are able to debate these ideas out. And I suppose from a specification point of view, I mean the general rule as I understand it is: once there’s two independent implementations who’ve made it work between themselves, then it is added to the spec. And then theoretically, once something is in the spec, then all of Lightning should be implementing that. Is that right?
T-Bast:
Yeah, that’s true, even though I would not want to strong-arm other implementations because I know it takes time, and we are all lacking time in reviews and implementation. And trampoline really shines if there are a lot of trampoline nodes in the network and that lets you really hide yourself among all these trampoline nodes. So I would rather wait and encourage people to implement it than force it upon the spec. So that’s why we haven’t been aggressively pushing to actually merge this, but the proposal is still there. The spec is still ready. It’s in a PR but it’s fully specified. So people can implement it when they have time or when users request to have that feature. And then eventually it will land. And most of the criticisms I heard about trampoline were actually almost always misunderstandings about how trampoline works. It was always people thinking that, when you were doing trampoline, you were telling the trampoline node, This is the recipient—please calculate the route to them. But it’s actually not how it works at all. So I encourage people to read the proposal to see why it’s much more private than that and much better. And another of the great benefits of trampoline is that it combines well with route blinding, but it also enables rendez-vous because trampoline is kind of a more flexible routing scheme than the normal source routing that we use. So it is actually really easy to use rendez-vous with it, and it works. So I’m hoping that maybe that’s something that will help people get sold to the idea of trampoline—that we can use rendez-vous when we have trampoline.
Stephan Livera:
Okay. So just to untangle a little bit of that. As you were saying, the idea is there would be multiple trampoline nodes on the network. And so this would give people the ability to sort of bounce their payment via some of these trampoline nodes, such that you’re not reliant on one particular trampoline node. Like you were saying: trivially, it’d be a bit silly if ACINQ was the only trampoline node. Everyone would be like, Okay, obviously it’s gone through them—they know the payer, or they know the receiver. Actually, to be clear: is it that if there was only one trampoline node, would they know the payer, or the receiver, in this case?
T-Bast:
If there is only one trampoline node, they know the recipient always, and they may or may not know the payer. They would know the payer if the payer is directly connected to them, but if a payer is not directly connected to them and reaches them through a two hops, for example, then they would not know the payer. But that’s why in my ideal usage of trampoline for wallets, I would use one trampoline that’s near the recipient and one trampoline that’s near the payer so that you can choose the privacy that you have. The recipient is always hidden from the first trampoline, the payer is always hidden from the second trampoline, and depending on whether you directly connect to your trampolines or put nodes between you and your trampolines, you can hide yourselves completely or not.
Stephan Livera:
I see. Yeah. So as you were saying, in the multiple trampolines world—let’s say there’s a lot of trampoline nodes out there—then it starts to become a lot more private in the sense that there’s a chance they would know the recipient, but they probably wouldn’t know the payer in that case. That would be the case in practice, is that right?
T-Bast:
Yeah, and even the first trampoline would never know the recipient at all, which is really nice. Actually, all nodes have an incentive to do trampoline because basically being a trampoline node just means that when you are going to be relaying—instead of relaying directly to a node close to you, you just have to run your pathfinding algorithm—but that’s something everyone already has implemented, so it’s not that much more costly to run than a normal node, and it lets you attract more payments that will pay more fees. So it’s actually really interesting to be a trampoline node whenever you are a routing node.
Stephan Livera:
Yeah. Interesting. Okay. So in a way, it might potentially be killing two birds with one stone. So as an example, the initial problem was that a mobile wallet doesn’t have the routing graph and cannot calculate the route. So because—in Lightning—if you’re the one sending the payment, you have to try to construct a package that is going along a certain pathway, going from Alice to Bob to Carol, et cetera. But in this case, with trampoline, you don’t have to be able to calculate that all yourself, you only need to be able to calculate to the first trampoline node that you know—and you might know multiple trampoline nodes. In this ideal world with lots of trampoline nodes, you might pick from an array of trampoline nodes, get your package to one of them through the Lightning Network, and then from there, they’re shouldering the rest of that load. And that might then go via another trampoline node on the way to the final recipient, such that people don’t know the payer or the receiver in the ideal case. But in some cases they might know one or the other.
T-Bast:
Yeah, exactly. What’s nice with that is that: if you are okay with your trampoline node learning that you are the payer, you directly connect to them and then you don’t have to download anything about the graph. And if you want to hide yourself from your trampoline node, you don’t connect directly to them—you connect to a node that’s connected to them, and then you have to sync a part of the graph, but only a small part of a graph. You only have to sync your local neighborhood, so it’s much smaller than the entire graph. And that’s something that can run on the phone without impacting the battery and performance too much. So by syncing only your neighborhood just enough to get you to trampoline nodes, you’re still able to hide yourself from the trampoline node while not having to calculate the whole route yourself. So it’s actually a very good trade-off.
Stephan Livera:
I see. Yeah. So we’re delegating the pathfinding aspect of it, but getting a privacy benefit on the way. So you were touching on this earlier that—the incentive, the idea that you might have an incentive to actually run a trampoline node. Now obviously you’re running a business: ACINQ is going to be a trampoline node, but then even just the everyday Plebnet users out there might be thinking, Hey, if it’s like a package that I can enable or if it’s an option I can set in my Lightning client, I want to put my hand up to be a trampoline node because then I’ll receive more payments coming through me which in turn means I will receive more fees. Is that how you’re thinking about it?
T-Bast:
Exactly. And mostly it’s enabling trampoline on your node—the only thing that it will cost to your node is that it’s going to be using a bit more CPU than if you don’t use it. But actually Lightning nodes nowadays are not bound by CPU: they’re using only a tiny fraction of the CPU. It’s not the CPU that’s the bottleneck. So since you have that CPU available, just turn it on and you will use resources that are otherwise unused and it will let you earn more fees.
Stephan Livera:
I see. Yeah. So now in terms of mobile wallets, I guess to simplify the way people think about Lightning right now is that if you want to receive [payments] in Lightning, generally it’s harder for you to be private. Right now it’s easier for the person who is paying the money to be private, because it’s like, you wouldn’t necessarily know where that money came from. But if you’re receiving right now, you generally have to be putting up, Oh, hey, here’s my node_id. And potentially they might be doxxing a channel as well as part of that. Because if we look at actually what’s inside that invoice—so for listeners, when you scan that QR code or when you read that string, the LNBC1, et cetera, that’s actually doxxing the node_id—so I guess that’s probably one aspect where maybe the Lightning Network is falling down in terms of privacy, but as you were saying, potentially that could be fixed by route blinding. Do you have any other thoughts to add on that?
T-Bast:
Exactly. This issue is fixed by either route blinding or trampoline with rendez-vous. And that completely fixes the issue and gives receivers great privacy. But there’s actually another attack on privacy that’s the most obvious one that we haven’t described yet. So we need to talk about it: it’s the payment/hacker relation attack. Right now, the way Lightning works is that you are doing onion routing and sending your payment through multiple hops. But the information that they forward between these hops is always the same—it’s using your payment hash and it’s always the same along the whole route. So if two nodes in the route belong to the same person, they know that these two payments are actually the same. And fortunately, this is trivially fixed with Schnorr, because with Schnorr we’re going to be able to change that—right now we’re using a hash and a preimage, and we’re going to change that to using a point and a secret key—and with that, the HTLCs (Hashed-Time-Locked-Contracts) will then be become PTLCs (Point-Time-Locked-Contracts). And what that allows—with the construction that’s called multi-hop locks—is that every hop will use a different point, a different secret, and they will not be able to correlate that two PTLCs are actually the same payment. And that’s something that will be enabled by the Taproot upgrade, but it requires many changes. So it will take some time until we get there, but we actually know how we want to get there and we have a construction ready. We just need to make a lot of changes to actually use it.
Stephan Livera:
I see. So again, just summarizing that for people who are new. So in the Lightning Network today, we are using this idea of hash and a preimage. And the idea is: you’re sending someone that hash, and then at the end, you’re going to reveal the preimage—like once all the stages in that route are ready—then you’re revealing that preimage. And because it’s the same preimage used across every hop in that route, in the multi-hop locking process of Lightning Network today, that can potentially be used by a surveillance node, or let’s say I’m malicious, I’m running the Stephan Livera malicious node network of surveillance across the Lightning Network, and I can see, Oh, look, this guy is asking for the same preimage! Boom. I can see, Ah, it looks like this payment probably came from this particular area, at least—maybe I wouldn’t be able to get it down to the exact node, but I might know roughly within that cluster, if you will, and it’s going here because I’ve seen it went there. Is that right? And then the idea is, in the Taproot and Schnorr world, we’re going to be doing point-time-locking where instead of the preimage, it’s going to be continually changing what that is. So that aspect of what’s called payment correlation will no longer be a thing. Have I got you right there?
T-Bast:
Yeah, exactly. With PTLCs, the secrets that are revealed are going to be different at each hop in the route, and it’s going to be impossible to just link them together because they have no relation between themselves whatsoever, or neither sender knows the relation between these secrets. So no one will be able to correlate the payments anymore. And what’s interesting is that it also brings us a bigger design space for a lot of improvement. This also enables something called a stuckless payment, where once you have sent a payment, if it gets stuck at some point in the route—right now you don’t have a choice but to wait for the payment to fail. And if a node has disappeared instead of forwarding your payment, you could wait for a while. And until the payment has failed, you should not retry because you may end up paying twice. But with PTLCs, we’re able to change that so that when the payment is stuck, you can just disable it, retry, and ensure that you’re only going to be paying once. It doesn’t fix the issue of having that failed payment locked and locking some liquidity, but at least it lets you retry and finalize your payment so that you can just get it through—and you’re not completely blocked, not being able to pay the merchant that needs to be paid for his coffee or something like that.
Stephan Livera:
I see. So it might give a better experience. Because right now what people find is when they’re using Lightning, they might not understand the idea of the expiry. And so sometimes in mobile wallets or on desktop wallets, you can manually change the expiry of that invoice that you’re sending to somebody. And it might be a 15-minute expiry or 60-minutes or even 24 hours. But I guess that’s part of the reason for that, right?
T-Bast:
Yeah, exactly. And right now, to be honest, it’s actually terrible because if you’re paying with Lightning in a store, you’re buying something, you’re paying, and your payment gets stuck somewhere along the way, you just cannot do anything. You just cannot finalize that payment and you have to wait for some random node in the network to come up and decide either to fail or to forward your payment. And until then you just cannot retry. So you just cannot buy that thing. You have to stay in the shop for like hours or a day for your payment to either time-out or succeed. But with stuckless payment you’ll be able to automatically just retry right now until it succeeds. Then you get out of a shop with the thing you bought and via the ones that have been stuck, they will be eventually failed—so you’ll get back your money, and there’s no risk that they will just succeed and you have paid twice or three times the amount that you wanted to pay. So it’s actually a great improvement for real-world usability.
Stephan Livera:
I see. Yeah. And I mean, even for today, like the stuckless payment thing is one thing, but I think in practice today, Lightning nodes might have to try that payment a few times, but it’s just that if it does fail, they’ll get the failure back. So they know, Okay, I need to retry this payment. So in this case, this is specifically—as you were saying—if they didn’t forward or fail it back and they’re just stuck, that’s this case. And I think @ajtowns had an email about this as well. I’m not sure if you’ve seen that one, but I think he was trying to spell out a few ideas on what it might look like in a PTLC world.
T-Bast:
Okay. Interesting. No, I may have missed that one, but yeah.
Stephan Livera:
Okay. Yeah, no, I’m sure that’d be cool. So is there anything else from a protocol level that you wanted to talk about? Or we might start talking a little bit more about apps and Phoenix and Eclair.
T-Bast:
The protocol level, what’s interesting is that there’s been some traction around route blinding, because Rusty is pushing for Offers and Offers is great. We really should have Offers as soon as possible, so I encourage people to just push for it. Ask their wallets to implement it. And ask people to review it. Offers depends on route blinding and Offers also introduces something called onion messages. And that’s really cool because onion messages is something that uses route blinding and it’s to send messages to nodes. And the really cool part about it is that I can send you a message through an onion path—so when you receive that message, you don’t know who I am. I sent you something, but you don’t know my node_id, you don’t know anything, but I can even include a way for you to respond without learning who I am. And that’s really great because as the sender, I can get the best of both worlds. I send you messages, I’m able to get a response without ever telling you who I am. And it also works for payments. And that’s what Rusty uses in Offers for refunds, that lets people refund payers without the payers having to dox the identity. So I think it’s really great. And I think it’s one of the important things to review at the protocol level and implement. And there’s also of course dual-funding and splicing and liquidity advertisement that I would like to spend time on. But there’s just so many things that are interesting and useful. And we have only so many hours a day.
Stephan Livera:
Right, of course. You’ve only got so much time, and you’ll have to leave that for other people like Lisa, for example, to focus on that. And listeners check out the episode I did with Rusty on Offers. That’s a good overview for people who are like, What is offers? What is that? Why is it good? I’m excited for Offers. I’m hopeful to see that as well, myself. Okay. So we’ve basically been talking about your protocol hat right now, so let’s let’s change hats. Let’s talk a little bit about Phoenix wallet and ACINQ. So maybe just for people who aren’t familiar, give a bit of an overview: like what’s the latest with Phoenix wallet. I see you’ve got the iPhone version out there now and you’re getting users on that too.
T-Bast:
Yeah. So first just a bit of background about ACINQ: the first thing we were working on was several implementations. We have a full node implementation called Eclair. And our goal for Eclair is to be a very stable implementation. The goal is to have an implementation that has stable performance and that scales well. Our goal is to run very big nodes on Eclair. And we’ve been running the biggest node on the network and we haven’t had any issue for years. So it’s a good proof that our software is working quite well. And then at some point we realized that we will need to see the whole UX. So we had to implement a wallet because we wanted to see the challenges that people would see when they were not running on a server with a stable connection and all the issues that you have in the real world with unreliable connections, crappy phones, batteries dying, apps being being in the background. So we started working on Eclair mobile, which was our first attempt at a Lightning wallet. The goal was to make something really simple, but we just failed at that—it was just too hard to hide the complexities of Lightning three years ago. So it became something that was only usable for really advanced people who understand Bitcoin and Lightning. So at some point we proposed a lot of changes to the specification just in order to get to a point where we could retry to make a very user-friendly wallet. And we reached that with Phoenix. And the goal is to make it usable and completely hide the complexity of Lightning for users. They don’t see the channels, it just looks like a normal Bitcoin wallet, and they don’t think that there is any difference between a Bitcoin wallet and a Lightning wallet. The only difference is that it’s much faster and it costs less fees when everything goes well. And it’s been a very interesting experience because we’ve learned a ton of things about where the protocol actually has issues for low-end devices, which is what led us to think about trampoline because it was just infeasible for a mobile wallet to do the whole pathfinding, to sync the whole graph, to use that much bandwidth. So I think it’s really useful to have people working on wallets and giving that feedback to the protocol itself.
Stephan Livera:
Yeah, for sure. And I’ve found it really easy to—when I’m out there talking to people who are new—and if I can demonstrate Phoenix wallet for them, that’s often a very easy way to get someone started with Lightning. But I guess if you’re trying to get people onto some form of non-custodial Lightning wallet, then they’re going to have to pay channel creation fees. And so that’s just necessarily going to cost more than if they were to just do a custodial wallet setup. And so I suppose that’s probably what you’ve seen as well when you’re talking to users who are using Phoenix as well, right?
T-Bast:
Yeah. And that’s something we realized as well that it’s really hard to onboard people at scale because everyone needs a channel—and as a routing node, as an LSP, if you are providing that service to users and you have many users, that means you have to have a ton of UTXOs you need to carefully manage that you don’t have to do when you are just a routing node—and it brings a lot of complexities that we were only able to discover by running this service for users. And I think that’s something that we need to find good solutions to if we hope to onboard many people to Lightning. And we hope non-custodial people can run a non-custodial wallet because we don’t want the whole world to be using custodial wallets. So it’s good that we are tackling these issues, discovering all the pain points and slowly walking through them and learning as we go.
Stephan Livera:
Yeah. So I’m curious then: with the approach that basically every user—even on Phoenix—it might have multiple channels, right? They often do. I mean, I do on my Phoenix wallet—you often end up having multiple channels coming inbound and so on, but we know longer-term, that’s not how it’s going to go, because even if every person on earth wanted one channel to be non-custodial, it just wouldn’t be feasible. Like we literally would blow out the blockchain. And obviously these are things that we can do today because it’s early and I’m sure people 10 years on will be laughing at this idea that one guy can have like 30 channels and it’s just not going to—but you get what I’m saying, right? That’s not how this thing is going to grow really long-term. I don’t know. Maybe long-term, it’s like we get ANYPREVOUT and we have channel factories or something. But I’m wondering—do you have any thoughts on that?
T-Bast:
It’s a very interesting area of research because there are a lot of different ideas that would help us onboard many people while keeping the non-custodial part of it. There are the channel factory constructions where it stays kind of Lightning, but with multiple people in a channel, basically. And also other ideas: there’s this coin pool idea where you would build some small communities that share the ownership of a UTXO, and then you will have many of these communities that only need one UTXO per community so it can scale. And these communities would then be plugged together through Lightning. And there’s also this thing called FediMint as well: it’s kind of the same idea where you have a federated community that shares a small federated sidechain for your community where your trust comes from the fact that they are a “T out of N” signature. And then between the communities, we would use Lightning to connect them together in a trustless way. So there is a lot of research in that. I think these ideas are great solutions to scale to huge number of users. I think obviously that we cannot scale non-custodially to the whole world with just vanilla Lightning as we have today, but it’s good that we see emerging a lot of research on how to actually do that using Lightning to bridge multiple smaller communities that would do something more efficient than creating channels for every user.
Stephan Livera:
I see. Yeah. And for example, the El Zonte Bitcoin Beach idea is really kind of more like a Lightning bank, right? So it is custodial at least within a community area, but I guess the benefit is it’s at least interoperable: they can pay any lightning QR, which is anyone on the Lightning Network.
T-Bast:
Yeah, exactly. And I think that’s the important property to preserve.
Stephan Livera:
Yeah. And actually I wonder like, will it be the case that maybe 5-10 years from now, a lot of Lightning users will be custodial?
T-Bast:
I don’t know, to be honest. I’m hoping. No. I think that a lot of them will because not everyone values non-custodial self-sovereignty. A lot of people just don’t care and find it much better to have someone else custody their funds. So we don’t want to force these people to go the non-custodial way, but I’m hoping that there will be enough users that value their sovereignty, and what we need is to build the ecosystem and the tooling that lets people choose. And that makes it not much harder to be non-custodial. It will cost a bit more because you will have to open channels so you will pay more fees. But my goal is that people who want to do it the non-custodial way, just have to pay a bit more, but they have almost the same UX ,and they have something that just works great. And it’s not a pain to be self-sovereign. So hopefully we’re already kind of there. And hopefully it’s only going to get better and people will be able to choose the trade-offs that they prefer.
Stephan Livera:
With Phoenix, I know the approach taken is very much like the Electrum server model. So it’s this idea—for people who aren’t familiar, Electrum is one of the OG wallets in the space, they started in I think 2011—and the model is essentially that there are a lot of public Electrum servers out there. So you can run Electrum X, some people run Electris or Electrum Rust Server, and I think some people use Chris Belcher’s Electrum personal server. And so basically this idea is that there’s all these public servers out there—and of course, if you want to be more private, you run your own and you connect to your own. I wanted to get your thoughts on this idea with Phoenix using that Electrum server model as opposed to the compact block filters, Neutrino-style, or any of the other approaches. What’s been your experience there using the Electrum model for Phoenix?
T-Bast:
I think it’s nice because it’s the same with custodial versus non-custodial: it lets users choose their trade-offs. Users are able in Phoenix to point to their own Electrum server. In that case, it’s much better than compact block filters because they have a real Bitcoin node and no one can lie to them. So it’s better than Neutrino. And if they don’t care about that, or they don’t want to have the cost of running something themselves, they can connect to the wider Electrum list. So both trade-offs are possible and it’s just up to the users to choose what they want to use.
Stephan Livera:
Yeah I think it’s an interesting one. And in that way, you’re also leveraging what’s already out there because that’s also an interesting idea because you’re not having to go and reinvent the wheel or go and create a whole new set of servers doing just Lightning things—you’re just using what’s already out there. So for listeners who aren’t familiar, when you start your Phoenix wallet, it’ll typically give you your 12-word seed and basically it will use the Electrum server to understand what’s going on on-chain. And then obviously it will use the ACINQ node as it’s LSP (Lightning Service Provider) in terms of who it has channels with and who it’s routing the payments through. And so, as we were saying earlier, the idea is longer term, there might be lots of trampoline nodes. And so though you might be going through the ACINQ node, you might be then using multiple trampolines from a privacy point of view, right?
T-Bast:
Exactly. Yeah. And on the Electrum part, we’re really glad that it exists because it’s actually a great protocol. The Electrum protocol is really well-designed and is really a great protocol for wallets—it’s much easier for a wallet to connect to use the Electrum protocol to watch their funds, than to connect directly to a Bitcoin Core node. So it’s really nice that it was there and we could use it so easily. And if users just run their own Electrum server with their own Bitcoin Core node, I think it’s a very nice privacy trade-off and trust trade-off.
Stephan Livera:
Yeah, I see. And it is also possible to have—I know at least on the Android version, there is TOR built into the app. So that’s an interesting one as well. There is a bit of a trade-off obviously around speed and reliability, but that is another option for people out there. So let’s say they want to run one of these node implementations,like an Umbrel or a MyNode or a RaspiBlitz or one of these, and then they can connect back home, their Phoenix wallet will phone back home to their own node or to the Uncle Jim node—like your friend is running one for you and your friends—then that’s an interesting model for people as well around not doxxing your Internet or your IP out to the world when you do your payments.
T-Bast:
Yeah, exactly. The first wallet to build TOR inside the wallet was I think Blockstream Green. And that’s why when we saw that they had that we thought, Oh, we need to look into it and we need to figure out how they did it because we want the same, basically. And that’s what led us to do it on Android because they were able to do it on Android. I think that on iOS it’s a bit more complex, but I’m not sure if it’s completely—if there’s a blocking point. I haven’t been working on that part. But I think we should be able to have TOR on iOS someday too, but I don’t know the technical details of that, so I don’t want to commit to it if someone else in the team will tell me, No, it’s actually much harder.
Stephan Livera:
Yeah. You don’t want to make promises you can’t keep.
T-Bast:
Exactly, but I think we should be able to keep it.
Stephan Livera:
Yeah. So is there anything else you wanted to add in terms of things that are coming up from ACINQ or any of the ACINQ products or services?
T-Bast:
Right now I think that on Eclair and the specification, one of the things I want to [say]—we’ve been working on Offers. Basically on Eclair we have a PR that already does onion messages. And I was told today that we’ve been able to do compatibility testing between Eclair and c-lightning and onion messages. So this is great. This is making progress and I hope Rusty is going to be happy with that. And the next step is to do Offers, and we’ve been making progress on that as well. So ideally we would ship Offers in Phoenix someday soon-ish. And then we’re going to be working a lot as well on dual-funding, splicing, and liquidity advertisement, because it’s going to make the Phoenix experience much better, because instead of having all these channels that appear every time you need a new channel to receive a payment, we’ll be able to do splicing so that you only have one channel for your Phoenix payment, and that will let you also do splice out instead of swapping on-chain funds out with a swap provider that costs you a fee, you’ll be able to directly take some funds of your channel and send them back on-chain at a fee rate that you choose without paying a fee. And that’s going to be really useful for users. That will give them more control. It’s going to be hard to find the right UX around that, but it’s going to be much better control of the channels for users, and more features. It will look much more like a Bitcoin wallet because they will not even see the distinction between on-chain and off-chain and it will just work hopefully flawlessly.
Stephan Livera:
Right. So the idea is that you might have your channels, and if you need to make an on-chain payment, it’ll just splice out some of the funds out of your channel and make that as an on-chain payment. Whereas right now you’re just using the ACINQ server to do that, or with their funds. And you’re just in the background having to do that. Also right now, I guess, so Offers is coming and I know LNURL is enjoying a lot of community support, and it’s interesting as well, there are different websites which allow you to log in using LNURL. And so one example I think is LN Markets. And so, as an example, you can log in off your Phoenix wallet using LNURL, which is a pretty crazy. Do you want to tell us a little bit about the LNURL experience?
T-Bast:
I don’t know it that much. I haven’t worked at least on the implementation at all. I’ve only been a user. So I think the guys working on Phoenix in our team know much more than I do about LNURL. So I don’t think I’m the best guy to talk about it.
Stephan Livera:
Yeah that’s totally cool. I thought it was just an interesting thing that we’re seeing in the Lightning world. All right. Well, I think that’s pretty much all the key questions and probably time to wrap up anyway. So Bastien, where can people find you online?
T-Bast:
You can find me on Twitter at @realtbast. On GitHub where I’m just T-bast. So it should be easy.
Stephan Livera:
Excellent. Thank you.
T-Bast:
Thanks, Stephan.