How many people can use Bitcoin and Lightning today? Severin Buhler from Synonym joins me to talk about the LSP spec as well as lightning development. We talk about how the new LSP spec will enable more wallet builders, and more user choice, as well as smoothing the process for LSPs to compete: 

• What is an LSP
• A marketplace of LSPs
• Competition between jurisdictions
• Wallet of Satoshi news
• How many people can use lightning? 
• LSP business models
• LSPS1 and 2
• JIT Channels
• Asynchronous payments
• Blocktank

Links:

• X: @SeverinAlexB 
• X: @lnrouter
• Site: lnrouter.app 
• Site: Synonym.to

Sponsors:

• Swan.com (code LIVERA)
• CoinKite.com (code LIVERA)
• Mempool.space

Stephan Livera links:

• Follow me on X @stephanlivera
• Subscribe to the podcast

Podcast Transcript:

Stephan (00:00.872)
Hi everyone and welcome to the Stephan Livera podcast, a show about Bitcoin and Austrian economics brought to you by swan.com. Today we’re talking about Lightning, LSPs and more with Severin Bueller from Synonym. So first off, Sev, welcome to the show.

Sev (00:17.625)
Hey Stephan, nice to be here.

Stephan (00:20.476)
Great. And so yeah, thank you for joining me. And we’re going to get into a lot of interesting stuff. But yeah, just take a minute. Just give us a bit of your background for people who don’t know you.

Sev (00:30.982)
Yeah, sure. So I’m Severin. I work at Synonym and I’m building the LSP block tank there. And I’m a digital nomad into Bitcoin now since 2016, but only actively started to work on Bitcoin in 2020 basically. So…

Three years now basically. And yeah, now back in nice Switzerland. We have a very snowy week. Freezing outside, but it’s good. It’s nice to be back here.

Stephan (01:04.52)
Right. And so you mentioned LSPs. I think this is a big topic that we’re going to get into today and working on the LSP spec. So I guess just to help define terms for people who aren’t familiar, what is an LSP and what are maybe some of the different kinds of LSPs?

Sev (01:22.842)
Yeah, sure. So LSP, some people say it’s a lightning service provider. Other people are talking about a liquidity service provider. The basic definition is it is your gateway to the lightning network. If you are a non-custodial lightning wallet user, you somehow need to get lightning channels and to receive funds and also to send funds.

To get that, you need a partner with Bitcoin that puts funds into these lightning channels and the LSP will do that for you. It will basically do everything for you so you can just onboard to the lightning network without any friction and just start transacting. It’s, yeah, so simple.

Stephan (02:14.676)
Great. And so I think for a lot of users, if you’re a more casual user, maybe you don’t really need to think about some of this stuff. Like the idea is it’s in the background of your application and it’s kind of managed for you. But some of this stuff will be interesting and relevant for people who are developers, builders, and people who want to know a bit more about exactly what’s happening under the hood per se. And so you have been working on the LSP specifications with a bunch of other people.

And so this is maybe something might be interesting to get further into. So we’ve explained what an LSP is. What’s the point of these LSP specifications? What are they hoping to achieve with that?

Sev (02:59.075)
Yeah, sure. So the LSP specification is a collection of APIs, standard sized APIs that every wallet can talk to and integrate. And the goal is that we can abstract away like the LSP and basically create a market of LSPs. And as a wallet provider, you can just choose whatever LSP you want.

and talk to these LSPs in the standardized way and yeah, make everything happen. Because the problem right now of today is every wallet, say Breeze, Bitkit or Phoenix, they have their one single LSP behind. They have their own way of communicating with this LSP and you’re kind of locked in there.

Kind of like, maybe the good comparison is a SIM-locked phone. You have this LSP, and if you want to switch the LSP, you can’t just do it. You need to also switch the app. So if I really like the Breeze UI, or the Bitkit UI, I need to switch the whole app, move all my funds over to accomplish the switching of the LSP. And we want to make this better.

We want to create an LSP market there, and we want to make the experience for the user way better. This is, like has multiple advantages. For Bitkit, at the moment that we can’t, the Blocktank LSP, the one I’m working on, we don’t serve US users from a legal point of view. And if we have an LSP market,

where the user can just decide which LSP to take. We can also serve, USU as a bit kit can also be used with a US LSP that’s just not our own. And yeah, there’s a lot of more advantages I can get into.

Stephan (05:09.836)
Yeah, so at a high level it’s a way to make it programmatically easy for a Lightning wallet to plug into multiple different LSPs. And I guess some of the Lightning wallets and applications that exist today, they’re at varying levels in terms of allowing you to do this. So for example with Breeze, I believe you can have channels that are not just with the Breeze LSP, but it’s kind of more technical and it’s not really something that most users would use.

In an LSP spec world, it would be a lot easier for people to do that. And of course, with Bitkit or with, you know, potentially with Phoenix or Blikst or various other, Zeus and Mutiny and all the other Lightning apps that are out there. And so summarizing some of the benefits, as you said, it may allow more fine-grained control in terms of which LSP’s serve which users from which jurisdiction. So that’s the legal aspect. There might be an angle of.

privacy that you might want to have multiple LSPs, like you might have your lightning wallet, but it actually connects out to multiple LSPs, giving you maybe some privacy benefit. Maybe there’s also an element of reliability there too, because maybe if you’ve got multiple LSPs, maybe if one LSP is down, but the other one is, or this other LSP is more well connected, and maybe it’s also an angle of competition on fees. So maybe one particular LSP is charging you 0.5% fee, and another one is charging you 0.4% fee.

So there’s a fee competition aspect there also. Do you see any other elements there that they are? I guess, let me put this into a question. What ways are LSP is going to compete?

Sev (06:50.231)
Yeah, it’s basically you create a market of LSPs and we know what some elements they’re going to compete with, as you said, like reliability and fees is 100% one thing, like cheap liquidity and all these things. And there will be ways they will compete. We don’t know yet as of today. That’s just what we think what we already know.

At the end, competition should create good service, especially competition in such an easy way with standardised API. And yeah, that’s the goal. It’s to have a good LSP marketplace. Also in the future, we’ll probably see that LSP’s might get regulated or some will get regulated at some point. And I think there’s also going to be a market…

competition between regulated and unregulated LSPs. I hope, for example…

Stephan (07:50.92)
So let’s talk a little bit about that. What do you think it would look like if there are some LSPs who are regulated? For example, let’s say there’s an LSP serves in the US and an LSP who’s set up outside of US, whether that’s in El Salvador or somewhere else. What do you think that would look like?

Sev (08:09.966)
Good question. I think at some point countries, like specific countries might regulate LSPs. I really hope not so. I always hope we can, there was always an angle of I just use an El Salvadorian LSP and then it’s no issue anymore. But who knows, maybe the US will start regulating their LSPs and want…

Daryl’s piece to follow some rules, but I really hope, don’t hope so. But we’ll see what the future brings.

Stephan (08:45.988)
Of course, yeah. And so I can understand where, of course, I’m anti this regulation as well myself, but I could see a scenario where this kind of thing happens, where maybe some compliance department in a bank that serves a particular Bitcoin business says, we don’t want to serve you unless you are blocking OFAC-sanctioned transaction somehow. But that doesn’t really exist in the same way that it does on chain because it’s in Lightning.

then it’s more like, would you have to try to censor payments to particular node public keys or… it becomes very challenging.

Sev (09:20.878)
Yeah, even that doesn’t work because as soon as we have route blinding both sender and receiver are completely anonymous And this yeah, then you have no way to censor. So i’m actually more optimistic with lightning being censored um, the way it’s going to be censored in my opinion is Um, you are only allowed to open a channel with somebody that you know And that actually behaves

There you also know the node ID, and you could probably sensor a node ID, so you’re not allowed to open a channel to this node ID. But that’s not so easy to do, like it creates a lot of overhead and bureaucracy for LSP node operators, and also it’s not so easy to do from a regulation point of view. So yeah, I still hope for the best for the Lightning Network, let’s say like this.

Stephan (10:15.364)
Yeah. And even there, like, it’s kind of parallel to how certain Bitcoin addresses would be listed on the OFAC censorship list. But then people can generate new addresses. So in the Lightning context, it could also be a similar kind of whack-a-mole game of people would just shut down that node and spin up a new node. And now, yes, there’s a cost to that. You can’t just like instantly do that. You still have to set up new channels and things. But…

Fundamentally, yeah, people could just shut down a Lightning. Imagine even if a Lightning node pub key is added to some kind of censorship list, they could shut that down, go to another jurisdiction, set up a new one, and they’re back up and running. And so, yeah, it’s kind of a complicated question. I guess, yeah, go on.

Sev (11:00.154)
not be surprised if a lot of capital would end up in El Salvador. If they have good regulations, they secure or guarantee the security of the capital and then everything would flock to El Salvador.

Stephan (11:14.82)
Yeah, so it’ll be interesting to see what happens there. And, you know, imagine in this next, you know, bull run, bull cycle, more nations kind of copy the lead of El Salvador. Maybe there’ll be other nations who are competing and vying for the same, you know, market in terms of being open to Bitcoin and Bitcoin businesses. So, yeah, it’ll be interesting to see what happens there. Um, I guess while we’re on this topic, it might be interesting just to kind of get your thoughts on what happened recently with wallet of Satoshi. Now.

This is a custodial application coming out of Australia. And they recently made the announcement that they do not want to serve US users. And so they’ve, now they are allowing them to off board and saying, hey, take your coins off. And so, I don’t have insight into that, but my speculation would be that this is based on, not government regulation in the US and KYC and AML and sanctions laws. And so,

I’m curious if you have any reaction on that, whether you think that is a trend that will continue, or do you think maybe that’s more restricted to the US case?

Sev (12:23.162)
It’s going to be very hard to do custodial lightning or custodial Bitcoin without KYC at the end. The US has a lot of power to pressure other countries into doing what they want, especially when it comes to money. Me as a Swiss, we saw this with the Swiss bank in the 2008 crisis, where at some point I had to go down to a bank,

bank here in the town and sign that I’m not affiliated with any US citizen or US resident and I don’t have money for them on my bank account. And that’s in Switzerland. So the US has a lot of power with Swift and with their banking system. And I believe custodial lightning will be very hard to do. KYC3 maybe somewhere in Russia or who knows.

that is far apart from the Western influence. But yeah, and at the end, it’s either be non-custodial or KYC custodial. But I’m not so much against KYC custodial. What do I care about pocket money where I pay with my coffee? I personally don’t care that much. It’s just for somebody that is more exposed.

For example, if you’re very rich and you’re more in this power influence sphere, it will be better to have everything non-custodial. But then this goes to the question, how do we scale Bitcoin better? How do we scale Lightning? Which we will probably talk also here in a second.

Stephan (14:04.304)
Yeah, well, I know what we should talk about that a little bit. So, um, there are questions being raised around, okay, exactly how many people could Bitcoin and lightning scale to today in a non-custodial way. Um, it’s, uh, it’s a topic of debate. Yeah. Sorry, go on.

Sev (14:21.102)
20 million a year. So OK, you can do all the numbers. You have a certain amount of block space. You need to onboard new users. You need an on-chain transaction. Sometimes they need to close this channel. Maybe you do a swap once or twice a year. There’s a lot of things. And with this limited amount of block space, you can make. So in an EDA ideal scenario,

You can maybe do 100 million a year to onboard on Lightning. In a more realistic scenario, I would say 20 million something. And it gets more crowded with time. So you have a fixed limit of people that you can onboard to Lightning. It’s not going to be enough for the whole planet. Definitely. Yeah, and how this will show itself is with rising on-chain fees.

So the global south will be priced out earlier. And then maybe in the US and in the richer parts of Europe, we will feel this later. But we definitely have a problem there. And now, how do we solve this? We somehow need to scale lightning. And there are different methods to do that. I personally think we can probably increase the block size by times 2 times 4.

That’s one way. We had a lot of growth in SSD storage space. You can get storage way cheaper. But times two times four will not bring us to the numbers that we need. You will also need to look at alternative methods of scaling. One interesting example is ARC from Burak. We have channel factories that just recently, in the last month, there were a lot of interesting papers coming out.

that show how to make it better based on the original idea from Christian Decker. And then there’s also some interesting methods. BitVM, who might turn out, we can do something in a 1 to n case and do some scaling there. There’s a lot of things going on in the last year or two which are very interesting. I don’t think we should rush the scaling debate there.

Stephan (16:47.948)
Right, and so, yeah, just to summarize a few things. I think there’s a lot of discussion about different pathways, like you’re saying, whether that’s to have CTV, Check Template Verify, and other related ideas that may help us sort of batching and get more for less. And so maybe we can have this kind of multi-party channel construction idea, LN symmetry with any prev out. And some of these other ideas, people are talking about some of these ideas and maybe in the future.

there would be enough support to get something like CTV or APO and other related ideas. I am not sure what will happen with block size. I think it’s likely that we won’t get a block size increase, but I guess it’s possible, but I think it’s unlikely. Yeah, of course. And obviously, it’s going to redo the whole 2017 debate all over again. And maybe that’s kind of people are not going to be open to have that conversation at least for another 10, 15 years. But

Sev (17:28.879)
contentious topic.

Stephan (17:44.408)
I think if we had to sort of ballpark estimate kind of that on the numbers today with the technology we have today without a soft fork, do you think it’s fair to say somewhere between 10 to 100 million people can use Bitcoin and Lightning today? And then if we want to get higher than that, that’s where we might need CheckTemplateVerify or something to sort of go above that in terms of self-custodial users. Would you say that’s a fair number roughly?

Sev (18:10.55)
Yeah, I would say close to 100 million if we onboard them relatively slow. If you want to have 100 million tomorrow, it’s an issue.

Stephan (18:21.752)
Yeah, right. And then I guess the question, and again, this is kind of like a, how long is a piece of string question, because it all, there’s so many different factors that could change and move here. But do you believe that if we were to get some of these different technologies, that would take us fully to 8 billion? Or maybe it’s more like it takes us to like maybe one more order of magnitude, like maybe 800, you know, a billion people.

Something like that.

Sev (18:52.35)
Yeah, I believe every so we will not have this one scaling solution that will bring us to exactly 8 billion. We will have a little sprinkle of this, a little sprinkle of this, and we will slowly be able to increase the amount of people on the blockchain. And that will hopefully bring in I hope in five years, we’ll be able to do.

1 billion, that would be really nice. And then we’ll see. Maybe there is so much technological research and progress in the making that, like two years ago, I didn’t know how to scale lightning, but there has been so much happening in the last two years. It’s great. And it’s gonna still happen in the next two years. I’m optimistic.

Stephan (19:48.112)
Right. And so I think that will also turn on how many people are comfortable with, let’s say, having a soft fork to introduce something like CTV or APO and some of these ideas. Do you see it as there would be enough support or, you know, people are going to build up enough support for that kind of thing? Do you see any strong sectors of Bitcoin’s ecosystem who would be resistant against that?

Sev (20:18.202)
I mean there’s definitely resistance to any unchanged change. It’s obvious. We will need a big discussion and this discussion in my opinion will happen in this next bull market because in the next bull market fees will go insane. We already see it right now. We are not even in a bull market yet and the fees are

relatively high from time to time. We’re talking, what did we see recently? 250 Satoshis per VBITE or something. And.

Stephan (20:51.576)
Yeah, yeah, something in that range. And as I, as we speak now, it’s around 54 sats per V byte or in Fiat terms, just under $3 to get next block confirmation, just for context.

Sev (21:02.662)
Yes, and if we use this calculation, if we will create a channel right now, let’s say it’s $5 per channel to create one because the transaction is a little bit bigger. Let’s do 250 Satoshi per Vbyte. That’s times five, that’s 25 bucks for a channel. That’s already for most people, it’s a decent amount of money.

money if you just have your non-custodial wallet on your phone here. And let’s say we do 500 Satoshi per VBite, then it’s 50 bucks. And that’s only opening a channel, and you also need a transaction to close the channel at some point. So you can basically double this amount. So you see that channel opening and channel closes in the Lightning Network is going to be pretty much expensive in this bull market.

This will 100% trigger a discussion about lightning and Bitcoin scaling.

Stephan (22:09.712)
Right. And so the other question, obviously, we’re talking about LSPs as well, is there batching that can occur at an LSP level? So for example, the LSP might be able to batch on their side. Let’s say there’s, you know, 100 new users who are all coming on board. Can the LSP batch some of those things into one transaction at the LSP level and then arguably share some of those savings, those cost batching savings amongst the users?

Sev (22:37.394)
Yeah, it is to a limited amount. So the biggest problem right now with batching is all the users that do the batch basically need to be online at the same time. It gets very difficult if you want to do a batch with a turbo channel. So a turbo channel is a channel that is available instantly to you and can start transacting without the block confirmation. And these turbo channels are even more tricky.

to batch, there are thoughts and ways to improve this, but this would require a protocol change. You basically want to swap out the transaction for this turbo channel and replace it with the batched transaction at a certain time point, point in time. So it is possible, but we just need to put some more law into these techniques.

And yeah, it will save some, let’s say it will save 50% maybe, if you’re lucky, which is good, but it doesn’t bring us to a billion, unfortunately. Billion people.

Stephan (23:48.496)
Yeah, of course, yeah. But it’ll get us a little bit there. And it may be a case where some users, in the same way that when you’re doing a withdrawal from an exchange now, now of course, Swan has free withdrawals, but there are other exchanges where maybe you can set your fee rate and you can sort of say, I want it now and I’m willing to pay more, or I’m willing to wait. And so maybe it’ll be a similar case with LSP setup where maybe people say, hey, I’m willing to wait and you can batch my channel open. And so I can have it cheaper. And so maybe there’s kind of, there’s something there.

But again, at the same time, you’re balancing that aspect of how complex is this thing and how easy is it for new users? Because when a new user is coming on, they don’t have a concept of like, what is inbound liquidity? What is the channel? Obviously, that’s a bit more challenging. But I think it’s fair to say, if you were earning and spending with Bitcoin and like your whole salary was coming in over Lightning, then maybe it’s worth your while, right? Like maybe it is worth your while. Like let’s say you’re earning, you know, you’re an average…

person earning in the Western world. And this person in the Western world might be earning 40K per year, 80K per year, depending where they are. And for them, a monthly pay might be, you know, at least a few thousand dollars. And so would it be worthwhile for them to have even a $25 open channel open fee, but they’re gonna actually use it? Like they’re actually gonna earn on that and spend out of that. And only periodically, they might need to

splice or kind of go to chain maybe once a month, something like that. Like in that context, we could support more users, right?

Sev (25:25.578)
Yeah, yeah, 100%. So the channel cost that you have consists of two things. It consists of first, on-chain costs to actually create the transaction. But second, it also consists of liquidity costs that the LSP provides to you. And there, it’s very hard to guess what the liquidity costs of Bitcoin are going to be in the future. It’s

Let’s say you have a $1000 channel, if you have 1% liquidity cost per quarter, that would make $10 per quarter on top. That’s a bit of different costs because it’s recurring over time. If you just create a Lightning channel on chain, it’s open transaction, you can have it for 10 years, whatever, no issue.

But with this liquidity cost, it’s a little bit more tricky. So just opening a big channel towards you that gives you a lot of inbound liquidity and can just keep filling up and filling up is a good thing for on-chain. But you will have the costs of the liquidity that the LSP needs to provide. So we are in a bit of a pickle there. But we will figure this out as well at some point.

Stephan (26:49.233)
Yeah.

And even there, it turns on what is exactly the business model, right? As some LSPs may take a model where they charge you on the outgoing fee, and others may treat it more like a channel rental fee, right? This kind of idea of whether you spend out of this channel or not, I need to charge you whatever it is, $10 a month, $20 a month, whatever it is. And then at that point, it’s more like it’s a cost of doing business, right? It’s a cost of being able to access Lightning for that user.

because maybe he earns on Lightning and can spend out of Lightning. Other users, maybe they’re more casual and they’re not really spending out of Lightning that much. So for them, they just kind of only keep a small amount there in Lightning and just keep most of it. Most of their savings is on-chain in a hardware wallet, multi-sig, et cetera, right?

Sev (27:34.87)
Yep. Yep, exactly. I’m still thinking about this example where if you are a merchant, you choose your wallet size. Let’s say, OK, let’s make an example. I’m a restaurant owner. And I get $20 transactions the whole night. And my revenue is, I don’t know, $2,000 for an evening. And it’s $2,000.

I, what I want to do as a restaurant owner, I want to choose a channel size, wallet size of maybe 2,000 bucks or 3,000, 4,000 bucks. So I can do all the revenue for an evening in this wallet. Exactly.

Stephan (28:15.876)
Right, inside that one, yeah, without having to continually add to the channel size, right?

Sev (28:21.194)
Yes, and that’s the whole controversy that, or controversy, the whole discussion we have with Phoenix right now, where they open a new channel relatively quickly because there is the gap, like the inbound liquidity, they don’t give a lot there. Yeah, let’s see how the UX will evolve in these Lightning Wallets.

Stephan (28:45.2)
Right, and part of it, I think, is choosing the right tool for the job, right? Because if you are a merchant, maybe at least Phoenix as it currently is, I think that they might try innovating and doing something new too, but as it currently is, I wouldn’t tell a merchant, you know, if you are going to be mostly receiving and not spending out, it might not be the right choice for you. Maybe something else is a better choice for you to get proper channels or set up your own node or use a merchant solution. So that way you’re getting a big enough inbound channel.

And I think Phoenix would make more sense for the user who is spending. So then if you’re earning and spending out of it, you’ll sort of naturally have inbound because every time you spend out of that channel, you’ve got some inbound capacity. So I think maybe that’s one angle to this, but yeah, this did recently come up. So I think, as you were saying, so I think Brad Mills recently tweeted this out and there were people who were sort of seemingly up in arms.

about this, whereas I was saying, no, I think it’s just a matter of choosing the right tool for the job, because he was, in his case, I think he was trying to onboard somebody to Lightning, and in his mind he was saying, yeah, look, Phoenix, non-custodial, get someone onto that, but he didn’t also think through, you know, he didn’t understand that point at that time, that this user was just going to be continually receiving, and therefore every time they’re going to have to hit the chain, which means at the time, every time it’s four or five dollars to hit the chain.

and it just doesn’t, it wasn’t very practical. And it would have been more practical if you’d had one big inbound channel that which you can receive on. And so that would be a different context where I know you guys with Bitkit have a slightly different model where you can actually select a larger inbound. Now you pay for that, but you can have a larger inbound. So I guess different models, different products, right?

Sev (30:32.19)
Yeah, exactly. We just need to iterate a little bit more on the UI UX part, and then we can solve this. It’s not rocket science there.

Stephan (30:44.968)
Right. And so, so we’ve been talking a little bit about, I guess, from the user perspective, like these are the fees that they’re going to pay. What about from the LSP side? Because from the LSP side, you’re thinking, I need to lock up a certain amount of capital with that customer, with the end user of that LSP. And you need to obviously make back enough either on kind of channel rental fees, I guess, I don’t know the right term for that. I’m just going to call it channel rental. And then

Sev (31:12.002)
Yeah.

Stephan (31:14.6)
transaction fees, right? Because if they’re transacting a lot and you can charge them on that, then that’s a model. Or the other side is the channel rental side of it.

Sev (31:22.622)
Yeah, the cost equation on the LSP side is relatively clear. It is on-chain fees, and it is liquidity costs and your operational costs, whatever you want to put on top. There are multiple ways. So far, there are multiple ways that emerged how to get the money back from the user. One way is the zero fee routing way, as you remember a year ago.

What he innovated on was he charged all the fees at the beginning when you purchased the channel or the user purchased the channel and then put all the fees to zero, all the routing fees to zero. And this was very attractive from an, for example, for an exchange point of view or from a business point of view. It’s

You can compare this to your mobile phone subscription. You pay once and can use it as much as you want. And then there is the other way that you’ll have mobile wallets are using right now is they subsidize the channel opening a bit and then you pay transaction fees, like routing fees on each transaction. And at the end, I believe it’s gonna be a mix. It’s…

We were even thinking about stuff like, if the user transact enough, then we will lower the routing fee to zero. And then you just have a fee budget, or like an internal budget that covers the channel fees, everything, and over time. And then you can also extend the lease on the channel. That will be a very great idea. But that’s for in the future.

Stephan (33:16.476)
Gotcha, okay, yeah, and I think it’s just a very nascent space because right now, it’s just still so early in terms of how many people are really day-to-day users of Lightning. Now, I am a day-to-day user myself, but it’s still a while before we see meaningful numbers of users who are actually day-to-day users of Lightning. So I guess let’s talk a little bit about sort of

Sev (33:36.031)
Yeah.

Stephan (33:46.356)
Zooming out and just looking at lightning Experience more broadly. What would you say? It’s like for a newer user right now Like do you think it’s like we’ve reached a point where you know a new user can onboard to this thing or do they? Do they still need to be a little bit savvy with lightning and Bitcoin?

Sev (34:06.01)
If you’re lucky and you choose the right wallet, I believe it works pretty decently. You don’t have these experiences anymore like you had two, three years ago where you send a payment and it takes like 20 seconds until this payment arrived. I run AllenRouter, which is a service that does

Stephan (34:27.474)
Right.

Sev (34:32.95)
payment speed measurements in the Lightning Network. And I did a blog post one and a half years ago and measured the payment speed in the Lightning Network to a lot of different nodes. And it was really slow from time to time. Like these Tor nodes that were very common two years ago, they really slowed down the network. And…

a lot of these things got better. I believe there are less torn nodes in the network now. I believe LSPs choose their channel partners more wisely. And also, people moved over to the better wallets. And that helped a lot. And from a user point of view, the network’s

wide okay, you still have some failure rates with payment failed or you have still the occasional very slow payment, so that’s good. But if you look at it from a merchant point of view, I’m still relatively skeptical that the experience is good. Because from a merchant point of view…

A lot of users come to you with all their different wallets, sometimes with home setups and everything. And as a merchant, if you create an invoice and the user tries to pay and it doesn’t work, it’s really hard to figure out like, why is it not working? Is it the Lightning Network? Is it me? Is it the user that just tried to pay me? It’s this insecurity in this process, which is very anxiety inducing.

I just saw a payment, Phoenix to an El Salvadorian hotel. There was a video going around on Twitter two weeks ago. And it was a great video. The guy paid like 1200 bucks like USD or so. Really a high amount. Phoenix showed the payment confirmation within two seconds. But the hotel owner, until he saw the payment confirmation…

Sev (36:53.662)
It took like 10 seconds or so. And these are like the exciting, do you see seconds where like, hey, I sent a payment, but it looks like it didn’t arrive on yours. What’s going on? And like everybody gets nervous. And it will be really good if we can make this flawless because it would improve the user experience so much.

Stephan (37:17.604)
Yeah, and in fairness, I mean, there are times, like I would say when you are comparing with fiat credit cards and fiat debit cards, there’s some times where it will take long, it might take 10 seconds, but maybe it might happen less often than today with Lightning. Again, depending on which wallet, which service you’re using, I think if you’re talking about using the sort of very high reliability wallets, something like a Phoenix as an example.

and you’re paying into some of the more reliable or well-known merchant providers, then it tends to be very, very good because they’ve got, maybe they even have direct channels or they just have very good liquidity and sort of high level infrastructure. But then in other cases where maybe the guy has DIY channels, maybe there’s less likelihood there that everything just happens in a very reliable way. So I’m curious then.

I guess the next question would be, do you believe that it can be improved or do you think that there are some fundamental hurdles here?

Sev (38:22.142)
No, it can 100% be improved. You can improve the payment, the route finding algorithms. You can improve the apps in itself. So everything gets more, gets better basically. There are some bugs. Every wallet has some bugs at the moment. Just sometimes it doesn’t work unfortunately. But these are just little things that we need to work on a little bit more.

and at the end, lightning, we will have a good payment experience. I’m 100% convinced about that.

Stephan (38:57.636)
Yeah. And so just to give people, I don’t know if you have any numbers or even just ballpark, can you give people some ballpark numbers on things like payment reliability or payment timing? Do you have any stats like that or no?

Sev (39:11.234)
I have it in my blog post, which is an Allen router. From top of my head, the blog post was from one and a half years ago, so improved definitely. So from top of my head, it’s something between two, three seconds per payment, an average payment. And payment reliability, they’re usually payments work, but the problem is,

Stephan (39:14.373)
Okay.

Sev (39:38.994)
The higher you go with the amount in the payment, the more difficult it gets. I was surprised this $1200 USD payment came through on Phoenix so quickly, to be honest. So we are definitely making progress there, and it will only get better over time.

Stephan (39:58.832)
Right, I see, yeah, I see here you’ve got here, 50% of all Lightning payments take more than 8.6 seconds. There’s something on their website. But I mean, these are improving over time, and it also, I think, to what you were saying earlier, I think in earlier days of Lightning, there were a lot of Tor users, and then a lot of the Tor users were sort of slowing down the responsiveness in terms of the network and the reliability. Whereas if you were just using a typical consumer grade wallet and you were paying a consumer grade Lightning merchant,

Sev (40:03.484)
Ah, okay.

Stephan (40:29.66)
that was working fine. So it’s kind of like your experience really will vary and that’s why some people are sort of saying, oh wow it’s not working for me and other people are like hey it’s working for me, I haven’t noticed any issues. So it’s a strange thing but I guess yeah it really will vary and hopefully it keeps improving, which it has done.

Sev (40:50.094)
Please guys, don’t run Tor Routing Notes. Don’t do it. It really doesn’t serve us. I know being anonymous is great. And I know there’s a need there. But a routing note, Tor, is just not optimal at the moment. You can always run an Tor End Note, and like a Lightning Note with Tor, last mile, your last channel. So because that’s just, it will impact you.

and will give you privacy, which is good. But in between routing nodes, it’s difficult. Use a VPN or so, way better.

Stephan (41:28.948)
Okay, great. So let’s dig a little further into some of the LSP spec ideas. So you gave us a bit of an overview earlier, but I think it would be good to maybe dig into some specific things that are happening at the LSP spec level around specific features. So I think probably a good example might be what’s known as a JIT channel or J-I-T, Just In Time Channel. So can you explain a little bit, what is a JIT channel and how is the LSP spec

Sev (41:59.422)
Yeah, sure. So with Lightning, you have a bit of a problem. You are a new user to Lightning, you don’t have any funds, you don’t have on-chain funds and you don’t have Lightning funds and you don’t have a Lightning channel. So to first receive your first Lightning Bitcoin, you need to have a channel, but at an LSP you need to pay for this channel.

So you have this circle which you can’t resolve. And you basically, it’s a problem onboarding new users. And now there is a technique which we call just-in-time channels, chat channel. And this just-in-time channel is, if somebody sends you a Lightning payment, the LSP will open a turbo channel instantly towards you.

and will forward this payment and the channel is going to be paid by having a bigger routing fee on this payment there. So you solve this problem onboarding issue you have and the only thing that you need to be aware of is that the payment that you receive is at least as big as the channel fee that you’re going to pay. And

Yeah, it’s a great technique to actually onboard new users to Lightning.

Stephan (43:30.408)
Great, and so I guess the main downside, and this comes back to what we were talking about earlier in terms of on-chain fees. So it makes more sense to do this for larger amounts, so that way you can amortize that channel cost across a bigger amount. So I think the ideal case for a lot of users, maybe in the future, is if they can take their pay in Lightning, and it’s like a bigger amount, like even if they’re taking like a thousand dollar payment and they’re paying, you know, a three dollar channel fee,

then that makes a lot more sense and it feels a lot more kind of rational, uh, rather than people who are taking like a $20 fee and paying a $3 channel fee, then it sort of feels a bit, oh, wow, okay, I’m paying, you know, whatever. 15% of the actual payment amount is just to set up the channel. And then I think for newer users as well, maybe they don’t understand that this is like, no, you need like a one-time channel set up with this capacity. And once you’ve got that and you’re spending an earning out of it, you don’t have to hit the chain that often. But.

It comes down to these factors of channel sizing, how are you using it, in terms of what makes sense for people. And so again, it comes back to choosing the right tool for the job.

Sev (44:40.434)
Yeah, exactly. I think we need to solve this somehow with a better UI and also with a little bit of user education what this means when you onboard a new user, but that’s a very tricky question. You can’t just put a blob of text that educates the user if you just have somebody that downloaded your app. So I don’t know yet how to solve it, but it will be solved somehow.

Stephan (45:06.48)
Right. And I think the other aspect is when somebody gets onboarded and maybe they take their first funds on chain, and then now the question is, okay, I need to open a channel. And I’ve seen in the Bitkit, the UI there is more like you take, you know, you fund the wallet on chain or you can do this, and then you can choose to open the channel. And then at that point in Bitkit, it can sort of show you, okay, how much inbound do you want? How much are you willing to pay for that? So I guess that’s one approach that you can take, right?

Sev (45:35.782)
Exactly. So we’re trying to innovate on solutions there. In Bitkit, as you said, we have a slider where you can go back and forth and see how much you want to move over. You see how much inbound you will get. But again, I believe there needs to be some more innovation. And I’m not sure how yet. Maybe you should interview our designer, Aldert. He can tell you probably more. Ah.

Stephan (46:00.668)
Haha, yeah. I briefly met him. Yeah, he was the one I met in Lugano. Plan B Lugano, yeah.

Sev (46:04.574)
Yeah, OK. So yeah, that’s not really my strong suit. I just pushed this problem to him.

Stephan (46:12.824)
Fair enough, fair enough. Okay. And so what else is there from an LSP spec perspective that you wanna get into? Like we’ve spoken about JIT channels. Oh, one other idea is maybe around understanding the rates. So I think people have spoken about this concept as like rate cards. What does that look like in an LSP world? So as in how much…

Sev (46:21.846)
Yep.

Sev (46:35.143)
Can you elaborate a little bit more on Ray Cards?

Stephan (46:37.54)
Is it how much is the percent fee going to be and how much is it to open? Um, I think some people were talking about this. Maybe this is more applicable in like a liquidity ads context. Maybe that’s not as much of an LSP context. That’s maybe more like lightning protocol level, but I wonder if there’s something parallel happening at the LSP spec level.

Sev (46:49.077)
Ah.

Sev (46:57.406)
I mean, you will have a… So when you… Okay, LSPS-1 is another specification. So we have LSPS-2, which is the channel specification. We have LSPS-1, which is a channel purchase specification, which is very similar to liquidity ads. It has some advantages over liquidity ads, that you can also pay a new channel with Lightning. With liquidity ads, you can’t.

And we also defined how are the rates there, how are the fees that you need to pay for this channel. But it’s basically just the LSP indicating, hey, if you want a channel this size, this is the base cost, this is the variable cost. I believe liquidity adds does something similar or exactly the same. So I’m…

Oh, rate cards is this proposal from Nifty, I believe, that she proposed, I believe, half a year ago or a year ago, but I don’t believe it actually is going into liquidity ads, might be wrong.

Stephan (48:08.456)
Right. Okay, gotcha. Maybe that was my confusion. I think I might have heard that idea from Lisa and then thought it got in when it didn’t. But I guess that’s interesting as well, because it’s sort of, you’ve got almost like a sort of competition between what’s happening at Lightning Protocol level and then what’s happening at LSPS-1 Channel Purchase level. And they’re sort of competing with each other, but not exactly.

Sev (48:31.678)
Yeah, I mean, let’s say a year ago we all thought liquidity ads is basically debt. It was a great approach, I really like liquidity ads, but nobody really worked on it anymore. I guess everybody was busy, and now it looks like it gets picked up again. Yeah, I’m looking forward to another protocol and hope a wide adoption in the Lightning Network.

Stephan (48:56.604)
Great, okay, so are there any other LSP spec items that we’ve missed here that you wanna get into here?

Sev (49:02.726)
Yes, so there’s LSPS 4, which is probably going to be an upgrade to the Chit channel LSP 2 spec. And then there is LSPS 5, which is something completely different, which is right now in a very early proposal stage. You’re just about to dig into it deeper. But it is solving a problem in the Lightning Network that when you want to receive

a payment on your mobile phone, the problem is you kind of need to wake up the app to actually receive. So in the Lightning Network you need to be online to actually receive a payment to sign the new channel update. And if you have a mobile phone, this is very difficult to do because the mobile phone puts the app in the background, puts the app to sleep and you don’t get any CPU time to actually do something.

LSP S5 is a proposal so the LSP can send a mobile notification to the app and actually wake up the app and when you get a mobile notification you get depending on the operating system and whatever you get around 30 seconds of CPU time.

which is plenty to actually receive the payment and then at the end show a notification, hey, you got a notification and a payment here. And that’s LSPS 5. And I believe this will solve the problem of receiving funds on a mobile app, at least partially, not 100%, because there’s still flight mode and sometimes you don’t have a connection, but most of the time it will.

Stephan (50:57.132)
Interesting. And so this relates to asynchronous payments as well, right?

Sev (51:02.01)
Asynchronous payments is another puzzle piece there, which is not the same as this mobile notification approach. But as soon as we have asynchronous payments and this mobile notification approach, then we probably covered 95% of all use cases.

Stephan (51:22.692)
Interesting, right, because yeah, as you said, one of them relates to waking up the mobile phone when it needs to be woken up, and asynchronous payments is more like the generalized idea of having, let’s say, the LSPs help offline payments, or at least payments where the user is not online. So I guess they’re related and useful together. And so this would be really cool in a context where, you know, people have, sometimes they…

sort of reminisce back to the early days of Bitcoin when you just had this on-chain payment address and they say, oh wow, see, it’s just not as reliable as, you know, Lightning is not as reliable as just having back in the old days when you just did an on-chain payment to my address, here’s my address, you pay me whenever you want and I just pick it up whenever I want. But obviously the problem is that on-chain payments won’t scale to the world. Obviously Lightning is more scalable if not, you know, even if it doesn’t scale to 8 billion as in non-custodially. But the point here being…

this would enable people to come back to something like that old experience, but with a scalable approach. And so, yeah, so that’ll be really interesting to see.

Sev (52:25.638)
Exactly. As soon as we have properly decentralized lightning addresses, as soon as we have offline receiving, then you basically have the equivalent of a Bitcoin address. And then you have really good payment experience.

Stephan (52:44.996)
Yeah. I’m curious if you have any, if there’s something you want to get into or not, around Vault 12 as contrasted with Lightning Address as opposed to something like Slash Tags, which I know the Synonym team is pushing that idea more.

Sev (52:59.89)
Yes, so there’s a lot of things to unpack there. I’m not the biggest pro in slash tags. So if you want to get a deep dive there, then talk to John or one of our peer-to-peer engineers. Bold 12 is already very good to actually receive fonts anonymously. And then you have your static invoice. And you do a.

Stephan (53:12.248)
Yeah. Sure.

Sev (53:26.97)
onion routing to go back and forth and actually communicate, which is already pretty good. Lightning addresses at the moment, you need an HTTP server, which is probably hosted by somebody so it’s not so decentralized and under your control. It gets improved now with the newest proposal, which you might have read on the lightning mailing list.

They have a proposal up that you put these values on the DNS server, which is step forward. But in my head you can still improve this. But maybe let’s talk about this another time.

Stephan (54:08.604)
Right. Yeah. So let’s see what happens there. Um, and I think, yeah, there’s a range of these different competing approaches and people are just going to try different things out there. Uh, and you know, something will stick and, and it’s funny because sometimes the approach that’s not the most, you know, technically purest.

often can win out just because it’s like easy, you know, and so we’ll see. There’s competing standards, as we’ve seen even in the Bitcoin on chain world, things like BIP39 versus Electrumseed versus AEZ, the LND one, and other approaches and it’s all the Bitcoin core, key pool, all the approach. And it seemed like BIP39 just sort of won out at least in the hardware wallets world. And so maybe it’s going to be a similar thing. People will just sort of have these different approaches.

Sev (54:36.021)
Allen URL.

Stephan (55:01.628)
whichever one sort of plays out there. So I guess looking forward, what do you see as sort of the next kind of big things that’ll come in the sort of short to medium term? What do you looking at coming in Lightning?

Sev (55:19.266)
Yeah, Ball 12, obviously, when it’s actually coming at some point, but I’m optimistic it will hopefully come in the next 12 months especially, because LND is now, so not Lightning Labs, but an external project is doing LNDK, is now working on Ball 12, onion routing for LND. And…

So I’m relatively optimistic this will come and this will bring a big improvement to the network from a privacy point of view but also from a usability point of view. We will need as lightning developers we will need to scale our infrastructure to a bull market scale which will highly likely onboard us a lot of more users. So that’s a big development that

And the whole peer-to-peer space is very interesting. You can do a lot of things with peer-to-peer applications that traditionally in the last 10 years, you probably would have taken a blockchain for. And there is a lot of development going. It is not so easy to do. But I predict we will have.

and explosion of peer-to-peer applications potentially in the next two years, especially also coming from Synonym.

Stephan (56:52.244)
Great, and so this also aligns, I guess, similarly with like Keat and other applications using Keat-style infrastructure. And so for people who don’t know, Keat is also by the Bitfinex hole punch team. And the idea is it’s peer-to-peer and using this kind of similar to BitTorrent style approach, like a DHT sort of approach, but allowing people to do chat and other things.

it’ll be interesting to see. And as I understand, slash tags is sort of similar in some elements using like a DHT to help share the information around relating people’s identity and payments that they can self-host or self-use. Yeah.

Sev (57:38.534)
Hole Punch is our sister company, so we’ll use techniques from them. We will also innovate on some other things. And with Slash Tags, we wanna bring peer-to-peer, you own your own data technology to the user, to Bitcoin, to our lightning wallet, and really create your decentralized payment experience from scratch.

Stephan (58:03.236)
Right, and I guess just closing up, anything to update on Block Tank or what people can look forward to there with Block Tank, the LSP side?

Sev (58:12.974)
We are about, so right now our focus is on scaling, but there is also the LSP spec happening, which we’re gonna integrate into Bitkit. So in Bitkit you will have the LSP spec experience where you can choose your own LSP, and at some point even US users can use Bitkit. And a Blocktank site,

At some point we need to implement the LSP spec as well. And yeah, that is the, basically the roadmap like preparing for bull market, like fixing bugs everywhere, make everything way more smoother, way more better, and the LSP spec.

Stephan (58:48.153)
Right. That’s the main priority.

Stephan (59:00.04)
Great, okay, well, let’s finish up here. Where can people find you online and find your work?

Sev (59:05.49)
Yeah, sure. So you can always follow me on Twitter, Severin Alex B. I run ElanRouter on the side, which is a service, lightning service for routing node operators, which is elanrouter.app. Have a look at Synonym, synonym.to, which is the company I work for where we create Bitkit, also bitkit.to. And yeah, check out Bitkit, the lightning wallet.

And yeah.

Stephan (59:38.532)
Excellent. Well, thanks for joining me and chat soon. Bye.

Sev (59:40.91)
Thank you very much. Ciao, Stephan.