Future Visions of Lightning, Greenlight & Breez SDK

Hi, you're listening to Stephan Livera podcast, a show about Bitcoin and Austrian economics brought to you by Swan Bitcoin. Swan dot com makes it safe and easy to buy Bitcoin with recurring purchase plans or with smash buys. Swan dot com also offers free custody in your own legally owned trust account, but of course, not your keys, not your coins. Swan also offers free automated withdrawals to self custody, which I highly encourage listeners to take advantage of that and to withdraw coins to your own self custody. Of course, Swan Bitcoin has a range of educational resources that are available for people to learn, such as Inventing Bitcoin by Jan Pritzkow, which is available for free and it's a great resource to learn a little bit about the technicals of Bitcoin, but explained in a non-technical way. Swan Bitcoin makes it really easy for you to get started stacking Sats. Go to swan dot com to get started. Are you still using a plain old block explorer? Bitcoin has grown beyond a single layer, it's a fully fledged multi-layer ecosystem, and mempool dot space helps you explore and view that and visualize that with tools that allow you to see the mempool, the blockchain, and second layer networks like the Lightning Network. With mempool dot space, there's no need to trust a third party, it's free and open source software, you can host it yourself with full node distributions like Umbrel, Raspiblitz, and more. If you're with an enterprise, mempool dot space offers custom mem branding, increased APR limits, as well as increased access to the team for feature requests. Go and learn more at mempool dot space slash enterprise. For today's show, Christian Decker of Blockstream and Roy Scheinfeld of Breez rejoin me on the show to talk about what has improved about Lightning over time, as well as where they think things are going, and we talk about what they are building with Greenlight and Breez SDK. So for this episode, it is more into the technical details, but I think it is appropriate for developers and And builders who are interested in building on Lightning. So with that said, onto the show. Christian and Roy, welcome back to the show. Love what you guys are doing.

Hey Stefan, thanks for having us. Thank you Stefan.

Yeah, great. So we're gonna talk a little bit about, you know, the future vision of Lightning and as well as, you know, what you guys are working on with obviously Greenlight and Breez and Breez SDK. So yeah, I guess let's start with a little bit on, you know, what we think the future of Peer economy. So, what, what, give us some of your updated thoughts. Is that still, that's still your view, right?

yeah, nothing has changed much, much in the last couple of weeks. actually, I'm even more bullish than ever on, on Lightning coming back from Prague. I'm, I'm, I'm completely amazed to see the maturity of Lightning these days. I, I spent the week in Prague where I met you, Stephan, and everyone, kind of everyone, the, the thousands of people Lived on Lightning for a week. So if I compare Prague to previous conferences in, in Miami or even back in twenty nineteen when I first met Christian in Berlin, where nothing kind of worked. I, I was completely amazed to see the, the maturity of the technology, which also very much, aligned to what I'm thinking, our thinking at the moment, which is, Lightning has achieved a level of maturity in terms of technology, technology, and it is ready to be taken to the next level, and the next level in, in our mind is to start integrating, Lightning payments into more traditional mainstream use cases

Yeah, Christian, anything to add there?

No, I think, Roy pretty much captured it. it's, it's been a long way to get here, but, we definitely are, seeing more and more of the results of that long, long work. And I think, we are just about to start onboarding more of the less technical, users, and that's, and that's pretty exciting because now it's not, it's not the conviction of the Bitcoiners keeping this going, but actually the, the usage of, of Lightning by real mortal users. and that's, that's incredibly exciting. And as Roy mentioned, we finally have a, performance and, And a, success, profile that is appealing to end users as well, so that has also been a lot of work in the background, but we finally get to a point where it, it becomes usable and, we can see a lot of experimentation by different, different users for different use cases and, and different uses. So, it's an incredible exciting time.

So, I guess on that topic, what would you say has improved over the, you know, if we look back, like let's compare back to October 2019, the Conference in Berlin. What would you say are the big improvements that we've seen between then and now, June 2023? What would you say the biggest, you know, improvements have been in how we use Lightning?

I, I think there have been a lot of small changes over the time that, that are cumulative in nature and often not as visible to the end user as, as some of these huge features that, that we often talk about. but I, I think the, the ease of, of, running a, a lightning node have, have certainly, increased and the, performance of, of the nodes themselves as well, as in, time to success. Or time to finality for a payment and the rate of success for, for these payments, and that has been both a function of the technical development, but also of the evolution of the network itself. So it goes very much hand in hand both aspects of, of that.

Yeah. And right from your perspective, what would you say the big improvements have been?

It's just, it, it just works, right? That's what we all want to see. We want to go into the beer stand and, and pay for our beers in Lightning, and it works, and you don't need to Just take a few seconds for you to purchase the beer. so that use case of buying stuff works much more reli-reliably than it, used to be in the past. tons, tons of work in the background to get, where we are, but, it's not perfect yet. Like there's still a lot room for, for improvement. I always say that Lightning is a, is a liquidity network. So in terms of, liquidity, the amount of liquidity that we see in the network, they want in- Of investment that we see in the net-- in the, in the network is, is much higher than the past and more liquidity in the network, creates more reliable payments, more users are using the network, so we, we definitely come a long way, when it comes to robustness and maturity of the technology.

Yeah. And I guess one other area I'm curious to ask both of you guys is we saw this recent high fee period, in terms of on-chain fees. Right now some- So that was driven by the, you know, the inscriptors, the inscriptions, degenerates. But, you know, I think it's an interesting example of using Lightning, and I guess I'm curious to hear what you think in terms of how Lightning fared, how did the Lightning Network fare in this recent high fee period in your experience?

So I, I think it, it has been overall a positive experience for us, it's, it's been a bit of a forcing function and a trial of fire, trial by fire, for us, and we've definitely noticed some pieces of, of our model that, that broke and other parts that, that worked fine. and now it's, it's up to us to essentially take those learnings and, and apply them. one of them was, for example, that, core Lightning didn't have zero Anchors and now we have them, or soon we have them, as soon as the, pull request goes, through. And, techniques su- such as bring your own fee, have been, have been very successful during this, these high fee, moments, because we don't need to essentially guess what the fees might be in future, and that future might be such a, such a high fee environment. so I think that's the biggest impact that, that we've had. we've also seen a couple of reports where it wasn't clear, what the channel lifetime looks like. If the channel doesn't get confirmed or it doesn't get closed in a timely manner, the specification, for example, allows after two weeks to just forget a channel that is incoming, and, we've seen a number of users essentially wait forever on a non-confirming channel and then it confirmed, but the channel didn't activate because- Well, our counterparty had already forgotten about it, right? So it's both a protocol as well as a usability issue in this case, and we've collected all of this feedback and, will try to, to, to learn from these experiences as much as possible.

Yeah. Now, Roy, I know you recently wrote about the inscriptions as well, so do you wanna just give us some of your thoughts there in terms of inscriptions and the high fee environment and how Lightning is dealing with it?

Yeah, definitely. So, so I think, we all want to- To see a high fee environment. High fee environment, means, a more secured, network. we want to leave, constantly in a high fee blockchain env-environment in terms of, miners compensation, miners incentives, it's very important to, for them to ha- to, to make a lot of money from, on-chain transactions. So I think that's, a positive. I think, there are a couple of other good implications. one, it- Only demonstrate the need of Lightning. I, I think there's a kind of a misconception, I'll, I'll try to clarify. Lightning isn't, isn't a, a scaling solution for Bitcoin, meaning Bitcoin blockchain can't really scale. Lightning is an optimization of specific use cases that you, where you interact with the chain. I mean, if someone doesn't need, Bitcoin, Lightning, they, they don't need Lightning as well. Lightning isn't gonna solve, the, the on-chain, interactivity. Lightning's gonna optimize the on-chain interactivity. So one way to, to, to look at Lightning, you can think about a channel opening and a channel closing as a way to zip multiple, on-chain transaction into just two on-chain, on-chain transactions. So you open a channel, you make countless, of, of transactions, between opening the channel and closing the channel. But if you-- but if you hadn't had a, a lightning channel, you would have used on-chain transaction to do that instead. So in that way, I, I want people to perceive lightning not as a magic, magical solution of solving Bitcoin scalability issues, because there's no way of solving Bitcoin scalability issues because blockchains don't scale by definition. It's a way to optimize the usage of, on-chain by creating this, entity of a lightning channel. And in that regard, everyone that wanted to, to, to do on-chain transactions during this, high fee environment period now understand the need of Lightning. And we see that, all the time now that we get, we get, inquiries from, Bitcoin brokers, from Bitcoin exchanges, from hardware wallet, everyone now is rushing to, to implement Lightning because they understand they need to be there because fees Are gonna spike, and they need to be ready to have a lightning infrastructure in place. So that's a net positive in terms of lightning. I think there's another positive thing about the, all the ordinals, experiment, which is people understand, it's another use case for using Bitcoin as a medium of exchange, for using Bitcoin as money. these ordinal wizards are paying for Bitcoin storage in Bitcoin, and, and these bit-- and miners are earning Bitcoin Coins as a result of these wizards paying in Bitcoin and they are paying the miners paying their expenses in Bitcoin, so it's another use case of, of, of, another demonstration of, Bitcoin, being used as a real currency. I don't care really what they're paying for, they can pay for, whatever they want. I don't know if there's a real utility in inscriptions or not, like my, my personal, my personal- The thinking is that there's no, there's no real value in what they're doing, but I don't want to argue with the market. As long as they're paying with Bitcoin on, on these, JPEGs, I don't care.

Gotcha. Yeah. And I think you make a fair point as well what you were saying around optimizing rather than seeing Lightning as like a silver bullet, and I think maybe that's a line of criticism that, let's say, probably all of us have received over the time. Sorry, go on, Christian.

Yeah, so, coming back to the, to the compression comment that, that I just made, I think it's, it's, it's very important to notice that, that by, by using an off-chain protocol, we are using a force multiplier. we are making better use of our on-chain capacity. but scalability is just one aspect of, of what Lightning and off-chain protocols in general bring to Bitcoin itself, right? All of a sudden, we can actually pick a time when we want- want to interact with the, with the chain, which allows us to determine, to pick what, what fees we, we might want, right? Except in a, in a unilateral close, you can essentially choose when to open and when to close a channel, and you'll, essentially use the fees at those, points in time, and that allows us to spread the load of, of the chain interactions over, over the, the entire time space and, essentially smooth out So these, these, fee changes over, over time. But besides these, these, scalability and fee, opportunities, we also have the opportunity of bringing truly novel use cases to the, to the Bitcoin space, such as real time payments, right? Before Lightning, we couldn't do real time payments. because, well, you'd have to wait ten minutes in expectation and if the fees are high, even longer. And on the other side, they bring a new privacy trade-off to the table, whereas in, in, in on-chain payments, you leave a permanent trace of every single interaction. With off-chain, you have, it's, it's different. I'm not saying it's better or worse, I'm, I'm saying it's different, because now you're telling in real time other people that you are performing a payment. Payment, but that payment, that is only shared with the p- the, the notes that are, interacting with you, and on the other side, that information isn't stored in eternity, on, on a blockchain, for example. So these are different facets of what, what Lightning, brings to the table, and scalability is one of them. And I totally agree, it's not a silver bullet, but it w- it can easily allow us to grow by two, two- Three orders of magnitude over what raw Bitcoin might be, and beyond that it gets interesting for researchers like me again, to find sort of the next step to unlock, And, we've seen quite a few of these developments lately, and yeah, I think we'll talk about some of them later on as well.

Yeah, of course. And I think it's fair to say that, Lightning, as you, as you said, it allows us to choose the time that we go to chain, except for the unilateral close. So for example, when the fees are low, I can open my channels to you guys, and then we can do all these Lightning transactions. And of course, it sort of makes more sense for people who can ideally earn in And over Lightning, you can sort of stay off chain longer and it makes more sense. And so I think maybe that's also part of why it makes more sense. It makes sense that we will see more spending on Lightning once more people are earning on Lightning, I think. And so maybe we still haven't really built that flywheel out yet, and maybe it will, maybe it's coming, but that's kind of fundamentally one of the things that we're going to see. And I think the other point that's really interesting is that Lightning may have already taken a lot of load off the chain per se, You know, hundreds of thousands of transactions that would have otherwise hit the chain, that would have otherwise gone into a block, that would have otherwise caused higher fees, but no, they were kept off chain because all this podcast value for value or nostra zapping or bitrefill, lightning or other lightning uses have not gone to chain. So in that sense, it's already helped at least a little bit, and potentially in the future, maybe it'll be even more.

Yeah, I, I don't think that the twenty-one, satz zaps would have gone to the- The chain, so I think there are two use cases. One that are, are transactions that, i-if not for Lightning, they would have gone and been executed in the chain, and there are use cases that are kind of new use cases that are Lightning-only use cases, real-time payments use cases, around the value for value, around, podcasting, zaps, etcetera. Definitely, I, I don't think people are aware of the number of transactions that are executed in, in Lightning. I think We're at a range of tens of millions of transactions per month, in Lightning, right now. A significant amount of this volume would have gone to the chain, if it was-- wouldn't, if Lightning wouldn't exist, for sure. Another, another technical example for, for what, Kristen said about like choosing where, w-when to hit the chain is the, is our usage or, not just our usage, but the, the, the usage of zero confirmation Channels, with a zero confirmation channel, an end user doesn't really choose, when the, the open transaction is, is the open channel transaction is being executed in the chain, it's the LSP that chooses, when, when the, when the transaction is confirmed, the LSP can, can, use, can, can, can bump, can bump the fee whenever they want to get the, the, the channel confirmed sooner. So another way to mitigate, a high- Fee, environment. By the way, a high fee environment isn't really the issue, it's the volatility of the fees that are an issue for, for an LSD. It's not really like if the, if the, if the environment is, is consistently high, then, it requires one mitigation strategy. If the fees are spiking all the time and it's a very volatile environment, you need-- That's more challenging, more

tricky, yeah, to deal with for,

for an LSD. Yeah.

Yeah. Okay, great. So look, let's talk a little bit about what What you guys are building. I know Christian, you're obviously very involved with Greenlight, which is, a new service coming out from Blockstream, and I know we spoke about that even, I think, last time you were on the show, but obviously, I'm sure there's been a lot of development going on in the background since then. So, do you want to just give us an overview, what is Greenlight, how's it going to work?

Oh, absolutely. So we noticed at a certain, certain point in time that the, that the way that we Was essentially pretty much broken, because we as a community have a tendency of, erring on the, safety side, which is definitely the way to go, but that can be off-putting to many, many users, which are being told, "Hey, here's, here's a manual, read that," and then there's a second manual, which is the Lightning manual, and then there's the safety for Lightning manual, and only once you've read all of these may, you may touch your first Bitcoin. And, The, and the user might get halfway through the first, first manual and then give up because they, for, for them, learning Bitcoin and Lightning has been only work for now. So I think we need to, we need to invert that, that setup and, sort of show them first what Lightning can do and only then force them to learn or encourage them to learn about, about how to, What, what the technology behind it is and how to safely manage, manage their own infrastructure. And so what we, what we were wondering is, hey, there's, there's a lot of details to be, to take care of when running a Lightning node. how do you secure your database? How do you secure your keys? How do you secure your unchained footprint with a watchtower? how do you ensure that your node is online and so on and so forth? All of Of these more operational aspects that, that can be quite overwhelming for, for new users. So what we thought is, how can we take on some of that responsibility, on, on our side without ever touching the user's funds, right? we wanted to have a system that can compete with com- custodial solutions when it comes to ease of use, but we don't want it to be custodial, right? And so the idea came, came up that, well, one part is the node, the Lightning node itself, and it doesn't have to be the same, sort of domain of control as the keys or, whoever is controlling the node So what we did is, we essentially split up the node. We, we said, okay, here, here we have, on, on the one side, we have clients and a signer that is self-contained and that can be run by the user as easy as installing an app from, from an app store. And then there is the more complex, operational aspects of actually running, setting up a node and running that node and making sure that, that we never do anything dangerous with it. because remember, even doing backups for Lightning nodes is dangerous. so, what, and, and Greenlight is essentially the, the end of that thought process where we say, okay, we, we take care of the database, we take care of the watchtower, we take care of, of the node, and, we give you as the app developer or the end user, we give you a library that essentially acts as a client so that you- You can steer your node and as a signer, and, this essentially means that we never touch the funds, but we can perform the opera- the infrastructure management that is off-putting to many users. And so once they had a good experience with using Lightning, now is the time we can expose them to, to more information, to educate them about, about how to run a Lightning node, and ultimately our goal is to offboard them into their own infrastructure, because now they are fully self-sovereign Bitcoin users that, that have the experience and have the knowledge to do so safely.

Gotcha. Yeah. Okay, so just summarizing a little bit A little bit then. So Greenlight is essentially like Blockstream is running a cloud node for that user or the developer, let's say. This really, maybe this is more relevant for the developers because they may be using this. And the idea is that you're running the cloud node infrastructure that's giving them the data about, okay, where, where's the block, what's the state of the blockchain, what's the watchtower, if you're getting cheated, and various other things, but the keys still live in the client device, whether that's, you know, on their phone app like

Greenlight is running the infrastructure for, the developers who are in turn, you know, helping their users get onboarded to Lightning very quickly, whether that's as part of a game or some app or something like this. Is that broadly the- Exactly. Yeah.

And, and the big advantage for app developers is that they don't have to be Lightning, experts, right? Because if you, if you were to bundle a Lightning node with your application, all of a sudden you'd, you'd have to know how to drive the- That, how to automate that, how to secure that, and, and with, with Greenlight, all of this essentially boils down to calling an API and having a small piece of software running inside of, of your app, that doesn't need active management.

I see. And so, I guess, Roy, let's talk to you a little bit and hear a little bit from you. Obviously, you're working, you're leading the team at Breez, you've got this, you know, the Breez wallet, which is great, and, DK, so can you first, yeah, just explain a little bit about that, and I guess explain for the users who might be curious, well, hang on, what's happening to the existing Breez? Is that going away or is that, you know, staying?

Yeah, sure. So if I learned, like, Breez is five years old now, and if there's something I've learned in the past, five years is that, users don't care. let's be honest, like, we live in an echo chamber, we're Bitcoiners, we

Majority of users simply don't care, but what they do care is about the utility of, of Bitcoin and, what we've proven, in the past, in, in our journey in the, in the Bitcoin sphere is that we can provide utility to end users. And we've done that through our, point of sale, interface where we allow merchant to accept payments without the need of a, of a bank account. We've, pro- we, we proved that using our po-podcast player where users were able to stream green sets to podcaster like yourself without, using like only peer-to-peer, no intermediaries, no any, any third parties in the middle taking their cut. so I, I strongly believe peer-to-peer, economy has a lot of value. every time we've added such an interface to the bridge application, we saw a spike in the, in the number of transactions, in the throughput, in the number of users. so naturally, our next step in, in our evolution was to provide the infrastructure that, that we've built in order to provide the non-custodial lightning as a service to provide it to other developers and other companies. Companies to integrate lightning payments into their own, into their own, solution. when, when we understood that that's what, where we want to focus, we, we chose Greenlight as the platform to, to, to implement our, SDK, because the, the, the, the problems that we've ourselves experienced in running a fully featured node on the mobile device, I'll, I'll, I'll touch I'll touch, I'll, I'll talk about it in a second. but also there's a hidden kind of benefit to using a platform like Greenlight, where you can have multiple apps running against the same node. Essentially, it means that you can re-use your lightning balance, from multiple apps. And if Breez is creating an SDK, it's very natural that all the apps that are using the SDK will be able to interact with the same with the same user balance, kind of mimicking, mimicking the same user experience that we have with, in the fiat economy, in the fiat world, where you just put your credit card in your Uber, in your Netflix, in your Spotify, and all these applications are interacting with the same balance. You don't have a separate bank account for Spotify, you don't have a separate bank account for Uber, and the scattered user experience that we, see now in Lightning, where you have to top up Safarnews and you need to top up Fountain And you need to, to top up, Breeze and, and Phoenix, and like-- and you need to use, different balances in order to interact with different services. We wanted to solve that, also as part of our SDK, and, and having a hybrid approach, for, for running Lightning nodes where you have the node in the cloud and the keys are on the user's device helps with, with, providing this, user experience. so I didn't answer your question. To answer your The current Breez app, which is LND based, isn't going away. We're not gonna deprecate it, we, we are maintaining it, we, we, we will keep developing it. this is kind of our sandbox of understanding the market needs. maybe we'll experiment with the Taproot assets, maybe we'll experiment with other stuff in the, in the, in the, in the, in the current Breez app, but we will have a separate wallet which is Greenlight based we, it's already kind of ready for, beta, where, where, where there are a few issues, with Greenlight that are waiting for us to kind of publicly announce, the, the Greenlight, beta, but we will have a separate app that, provides the same user, the same Breeze user experience against, against, against Greenlight, and we will have, and we already have examples in the field right now, in the market right now that are using the Breeze, SDK to interact with Greenlight And the rest of our stack from other applications as well.

Gotcha. Yeah. So essentially Breeze as it is will continue the app, but there's also a new Breeze SDK which is helping developers. And so really this conversation is useful for listeners who are developers or builders and entrepreneurs themselves looking to provide some kind of lightning service. So while we're there, let's talk a little bit about what it might look like for your customers then, because your customer may not be the end user, let's say, right? Your customer Where sort of the developer or the entrepreneur is building something that he wants to provide for his end user, and that could be, whether it's like a gaming app or a, some other app, could you just walk through what that might look like for them when they wanna, you know, use Greenlight or Breez and then provide that service for their end customer, end user?

yes, definitely. So the Breez is the key aims to be a very simple drop-in solution for all your Lightning needs. Needs. as a- As, Kristen mentioned, they, Brockstein built Greenlight in order kind of to simplify the end user node part of using Lightning, but it's just one piece of the puzzle. There are other, there, there, there is more infrastructure to put in place. There are other pieces that you need to take in my-- to take into consideration when you're, when, if you want to provide a fully featured Lightning solution. An end user node, powered by Greenlight is, is one, one piece of the puzzle. Another piece of the puzzle is using an LSP. You need a liquidity provider in order to simplify an LSP. Just to recap, is the entity that magically connects end users to the Lightning Network exactly like an ISP connects users to the internet. from a technical standpoint, opening channels for, two end users, two end users nodes, so you need an LSP as part of your solution and, and the Breez SDK encapsulates not only our LSP service, but it encapsulates Let an open LSP model where we allow developers either to use our LSP services or other, LSP services. We're promoting an LSP standard with companies like C equals and, and Synonym. it also, includes, on-chain interoperability, meaning the ability to send and receive funds to an on-chain address and, and, and, and swapping them to off-chain, balances. So either sending funds to an on- On-chain address and, and, and having these funds in your lightning channels or sending funds to an on-chain address, through your, via your lightning balance, this is also a very key service that the SDK provides. And another service that we provide, we are partnering with third-party fiat, on-ramps/off-ramps in order kind of to bridge that gap from the fiat, economy. so if you're a developer, a game developer, social network developer, a wallet developer For a fintech developer or a crypto developer, and you want to integrate Lightning payments into your own, into your own solution, what we offer is a very simple API to send payment, send payment, receive payment, and, and, and you don't need to think about the underlying infrastructure and how everything works behind the scenes. It's really, really a breakthrough in the way that, we interact with Lightning.

I see. Yeah. So I guess I could summarize it then like it's, you know, the most, most- Hardcore Lightning developer people might want to do their own stuff and roll their own, but really if you're one layer out or two layers out and you-- maybe you are a developer, but you're not like a hardcore Bitcoin Lightning guy, or even if you are, but you just don't wanna run it yourself, that's where maybe this is useful for you, right?

I think it's useful for you even if you're a hardcore-- I think it's very useful even if you're a hardcore Lightning Bitcoin developers because The PRESTO SDK is essentially open source code, a glue code that connects all the pieces of the puzzle. And if you want to rip and replace, the pieces and kind of take control of one of the pieces or even contribute to this glue code, you can. It's just an open source code that kind of connects all the pieces of the puzzle to a very streamlined API. So I think if you're a Bitcoin hardcore developer, you'll find a lot of value in this interface. So it might be

like an example, maybe an analogy might be you're a A wallet developer who wants to use an existing library instead of writing your own. I guess maybe that's like a good analogy here, right? Yeah.

Or you're, or an LSP, or a different swap service, or a different fiat on-ramp, or a different, not Greenlight, they want to host Greenlight themselves, or they want to use Voltage instead. You can do all this mix This mix and matches in the, in the context of the Breeze SDK.

Yeah. Christian, go on.

Yeah. So the, it, coming back to the point that, that it might be interesting even for hardcore Bitcoin developers, you have to ke- keep in mind that, if, if you build on Breeze SDK and transitively on, on Greenlight, you ha- you are actually building a non-custodial s-s-system yourself, right? If you are a Lightning expert And you want to build a Lightning app, you'd still have to somehow make sure that, that you can run the node in a non-custodial, manner, because, if, if you don't have that infrastructure, all of a sudden you're the custodian for all of your app users, which might be okay if you're the only user, but, I would guess that ma- that most app devs, don't feel co-uh, comfortable holding their users' keys, as, as are we, so So what, what you get out of the box is essentially just, if, when, when stripping away the additional services that, that Breez SDK provides, green, green light underneath is, is essentially a lightning node as a service. so what, what you get is, an API, where, that you can program against. You don't have custody of the funds of your app's users. the users are, have custody of, of the funds. Because that's the only place where the keys are stored, so you're not entering that liability, and we h-uh, we have a number of additional features that make it, make it much nicer for app developers to build on Greenlight. one of them, for example, is that we have a mechanism for transparently offboarding users. So while you might program your application against, against Greenlight, a user might later decide, "Hey, I, I want more power over the node, I want to have more control," or, "I'm curious, I, I want to see how this, this works under the hood." So they might offboard, but now all of the applications that you've essentially, paired with that node would have to be reconfigured to point to the new node, right? you'd have to open a firewall port And so on and so forth. And we, came up with a system where, essentially every node become, has a static address that can be contacted independently of whether it's running on our infrastructure, a competitor, or at home at the user itself, right? So there, there are many, many of these, nice, usability features for app developers to make use of, hiding, complexity and abstracting away from, from different, issues that people might encounter. Counter, and allowing app developers to concentrate on their core idea instead of having to also start building infrastructure and start learning about lightning and so on and so forth.

I just want to, mention one thing about the non-custodial aspect of this solution, it's not about, ideology here. Well, maybe it is about ideology, but what we see with the conversation that we have with customers, in the market today, non-custodial- In the past few months, i-is no longer a, a thing, a, a, a, a, a, it's very relevant in the current regulatory climate. There's a lot of pressure on financial institutions not to hold users' keys, because of, because of the latest developments in the, in the regulation in the states and in, the EU. also from a user experience standpoint, we see, we see the implications of creating custodial solutions. So we see arbitrary jurisdictions are being excluded from, custodial solutions. We see a lot of friction when it comes to KYC and AML requirements, unlike the past Where we didn't really have these discussions with exchanges and, and brokers and, and, and, and, and fintech, solutions, I see a trend in the past couple of months where these institutions, these vendors come to us and ask For a non-custodial solution. So it's no longer an, a, a like a, a hardcore Bitcoiner thing to be non-custodial. I think there's a, a very concrete trend that we see that people are looking actively for non-custodial solutions in order to mitigate that. So in other words, like there's a business

case to be non-custodial as opposed to just like the ideology of being decentralized, let's say. Definitely. I,

I mean, holding customer funds is a risk, right? and, and making- Making a non-custodial system is, is simply the idea that you can't lose funds that you didn't have, right? So, by, by going for a non-custodial solution, you are a-- actually indemnifying your business from being a piggy bank that attackers might want to attack. And we are, we are very careful that even, that even we as operators from, for, for the Greenlight service, we can't do anything with the funds, right? Because The signer will independently verify any, any operation and, and will verify that, yes, this is actually, this was triggered by a user action and the, and the end, the state change that we're signing off on actually, matches the user's intent. And since that is a closed system, the node is pretty much just the connectivity and coordination pa- piece, whereas the client, the, the front end and The signer are essentially making all of the decisions here.

Yeah. And so when it comes to being an LSP, Lightning Service Provider, I guess users today are used to, as an example, like it exists in Breeze today, you can, you can receive funds and it will create what's called an on-the-fly channel. So is there a similar concept here in Greenlight and Breeze SDK?

It's the exact same concept, the, instead of running the user node on the mobile device like in the existing Breeze app, the node runs on the Greenlight environment. The LSP Let's say we intercept the HTLC, open, open the channel on the fly to the greenlight node. The greenlight node asks the, the end user on the mobile device to sign the channel open transaction, and all the cycle is completed.

Gotcha. And so I'm also, that's probably the other question as well, because if, you know, if private keys live on the phone, how do you deal with waking up the phone or making sure the phone is online and available in order to, you know, as we know in lightning, you need to be able to sign a channel state update How do we, how do we deal with that?

So, we, we essentially have three different, different levels of, of how we approach this, right? the first level, which is what we're currently using, today, is essentially that we assume the wallet is open. That is obviously the simplest, simplest mechanism, and it usually matches wh-uh, whenever we have either peer-to-peer interactions or we have, or we have in-person interactions where I go to a bar And I pay my beer, I have my app open to pay the invoice, right? And then I just keep it open or running in the background for that minute until, until the payment completes. also if I want to send my friend, a quick, quick payment to show him how easy it is, it works, then of course he will, he and I will have the app open. and the same goes for a point of sale, the point of sale will likely have the app open, and so there will be a Now this is sort of an opportunistic way of, of looking at it, right? We have the app open, so why not use it signer? the second iteration, which we also have right now already, is that as Roy mentioned before, we can attach as many clients as we want to a single node, and the same is true for multiple signers. So we can have any number of signers attached to a single node, and as, and as long as a single one is present, we can sign off on changes. so that is- that is sort of the multi-headed hydra model of, of thinking about this. And, we have, we are experimenting with, s-uh, setups where we have a standalone signer running at home essentially, acting for you and your family, and, it, it, it is online twenty-four seven, and you can essentially just, we start the node and the signer attaches to it and, and we're fully operational again. And then the third iteration Vision is what, what we have on the roadmap is essentially being able to reach out to app developers and say, "Hey, there is, there is a need for a signer. do you know any way you could contact your, your app users for that node and, and kickstart it?" And that can be, that can be a mobile notification or that can be some container spinning up somewhere depending on the complexity of your, of your setup, But in this case, we essentially defer to the app developers who know the best how to reach out to their, their own application. And, I'll let, I'll let, Roy s- talk about how reliable notifications are probably

yeah, so we've actually implemented the, mobile notifications as a mechanism to sign off on, receiving a transaction. It's not in production yet, we're still QAing it, it's still in testing, but, that-- there's no problem in Android, the problem is only with iOS. iOS gives you, i-- as always, iOS gives you thirty seconds of, signing, transaction or CPU time, and we find it very reliable right now with Greenlight. So in, in our existing Breez app, we weren't really able to implement, notification as a mechanism to implement, offline receive because we used an LND node and the startup time of the LND node, combined with, network reliability, was a very challenging when it came to kind of, fulfilling the iOS CPU requirements, but in Greenlight, where you- Decouple the node operation from the signing part itself, we find that our, our thirty seconds of CPU time to be very reliable, and we're gonna ship it, soon. I don't like the fact that it's an out-of-bound, solution for, asynchronous payment or offline, payments in, in Lightning. So I think we need to be, self-sufficient in Lightning. That's why we're trying to promote a protocol that we call Asynchronous Payment that includes several- Bolts, in order to, to implement asset forness pa-payments in the protocol level, it requires bolt eleven, it requires trampoline payments, and it requires, onion messages, and it requires another specification of being able to hold the payment and then, release it afterward. But the, I, I think there's a, a consensus at least, out of, from, for implementation, for, from four major implementation, three implementations are actively working on the, these specifications. So I'm very hopeful we'll see the ability to, implement asset in-finance payments in the Lightning Protocol itself, and, and we won't have to wait a few years, for it to happen. I think it will be matured, towards the end of the, the year. So hopefully early '24 we'll see, we'll see the, at least the first implementation of asset in-finance payments in the Lightning Protocol.

Back to the show in a moment. Have you thought about securing your Bitcoin keys with hardware that you control? CoinKite dot com makes some of my favorite hardware in the Bitcoin space. They most notably make the Coldcard Mark IV, which is the latest edition. It has two secure elements, it has NFC support, it's a really reliable performer. You can set up this device without phoning home, and it's really easy to generate your keys and use all kinds of advanced features such as dice rolls to add entropy, or you can use dice rolls to bring your own entropy and Entirely, and you can use the coldcard easily with wallet software such as Sparrow Wallet, Specter Desktop, Electrum, or Nunchuk, and you can use it as part of multiple configurations, whether that is in single signature or multi-signature. So go to CoinKite dot com and use code Livera for a discount on your coldcard. For those of you not familiar with Plan B Lugano, Lugano is the city in Switzerland, and they are really driving forward Bitcoin adoption. They have over a hundred places in town that you can spend satoshis, they are doing Bitcoin education, and they're hosting a forum. This forum will host awesome speakers like Nick Szabo, Adam Back, Paolo Arduino, Prince Philip, Jocko Muzo, Mike Peterson from Bitcoin Beach, and so many more. It's happening October 20th and 21st. There'll be a main stage, as well as a secondary Lightning and peer As long with master classes where Bitcoin, Bitcoiners can learn skills relating to self custody, multisig, setting up your node, and more. And as I mentioned, it's real in the sense that there are hundreds of places around town that you can really pay with Lightning, cafes, restaurants, bars, clothes stores, McDonald's, barber shops, hairdressers, watch stores, and more. So go book your tickets over at planb.lu.gano.ch for the Plan B Forum on October 20th and 21st. And now back to the show. Gotcha. Yeah, and I think I recall, Roy, I think we briefly spoke about that last time you were on the show, and I believe I also spoke a little bit about it with Macarallo last, recently with him also, where I think he has been, you know, talking about this idea for a while, and I know the LDK guys are also keen on this idea of asynchronous payments. So I guess sort of very high level, maybe I'm oversimplifying, but as I understand it, the idea is the LSP is helping the end user that, let's say Might hold it until they're ready to sort of, until that user comes back online and he's ready to now accept the payment. Is that roughly how it works? Exactly.

Yes. roughly, yes. the problem with, you can implement, asynchronous payments very naively in Lightning right now using hold invoice, you can hold the payment until the pay-- the, the payer is back, online and then hold the payment again until the payee is back, online. The problem is when you hold a payment when you- Hold an HGLC in a channel, you lock, you lock the liquidity

across the net, across the network, yeah.

Exactly. So the, the kind of the secret sauce in the asynchronous payment mechanism is to hold the payment on the payer LSP side. If the payment is being held on the payer LSP side, and we know an LSP is always online service, you can use the power of the payer LSP and the pay LSP to coordinate, the payment and notify each other when the Payee or the payer are, on, online, and liquidity isn't locked, in the, in the payee LSP or in the middle of the, of the chain, it's being locked on the first hop, yeah, at the, at the payer LSP level. Yes. Yeah. So I

guess that's kind of a lot of technical stuff, but at the end of the day, the user can see, the end user gets a nice experience where he sees, "Oh, I, I just got a new payment," like he doesn't really have to think too hard Around developers and entrepreneurs and LSPs really are handling that problem so the user doesn't have to think about it, right? That's kind of the, the end, end user message, right?

That's kind of our goal in, in, in, in the bridge user experience, like, either users don't need to think about anything or developers don't need to think about anything. That's kind of our goal.

Gotcha, yeah. And I guess one other area I'm curious to talk about, as I'm understanding, you guys tell me if I'm getting it wrong, but

as

Either receives payments or makes payments, he's not trying to be a routing node who is like routing payments back and forth, right?

Let, let's translate it to a technical lingo. there's a private channel between the LSP to the end user, meaning this channel doesn't participate in, in, routing, payments. And Christian can talk about like, the, the magic of Greenlight, because Greenlight is magical in a sense that the, the way that it operates, and optimizes, risk Resources, cloud resources.

Yeah. So, one of the, one of the optimizations that we have, for example, is that, we-- there is no point in, in keeping a node running if we don't have a signer present, right? We can't-- we have no way of, of signing off on new states. And so what we can do is essentially we can preempt nodes that, that are passive because they ca-- because they're currently don't have a signer attached to it and, by doing that, we can massively increase the scalability of the system, which then, has, has a lot, has a large impact on what costs we have to sort of, share with, with our users and, thus, thus we get a system that, that can scale up and down much, much more easily. To do that, we also need to ensure that these nodes are there when the user needs them, right? And, we do that by essentially having A system that detects when a, when a node is, is being requested and then scheduling it on demand on one of the slots in our infrastructure. And startup usually takes, sub half second and, usually by one point five seconds, you will have a fully functional node with the gossip, synced and everything. Because one of the bigger, biggest issues that we have when, when spinning up a node on demand is that, well they would then open connections and start synchronizing gossip, which would trickle in, and then maybe half an hour later you would have a complete view of the network and now you can do payments. on the other hand, we have optimized everything in, in such a way that, you can essentially open the app on your phone, and by the time the splash screen has disappeared, your node will already be running in the background and be, be able to receive, requests. So from the point of view of the user, it, it essentially is an always-on node, but behind the scenes, we are, turning them off and on depending on what is needed. And there are- Are a number of techniques that we use to, to ensure this, fast startup time. but from a developer, point of view, these nodes are always running and, we, we, we simply handle all of the lifecycle in the, in the background.

Gotcha. So there's a bit of secret sauce there. and so when it comes to the LSP, I guess the other aspect is as a user, if you want, like, let's say today in the Lightning Network, if you wanna set up your own not, you're not gonna be the most connected node when you're just getting started out, right? So there's kind of an aspect there where if you want to be able to reliably make or take payments, you need to be a well-connected user, ideally. so how is that working in a Greenlight and a Breeze SDK context, because the user is already sort of piggybacking off an already well-connected LSP? Is that, is that the idea? Because otherwise, you know, you could be a user who gets a-- It's like if you set up as a Channels not enough connectivity, your payment experience might not be great if you don't have a good, reliable LSP.

Yes, yes, exactly. The LSP part is paramount. The,

the one, one of the, of the functions of an LSP is to provide liquidity to, to open channels to end users, but the LSP needs to be very well connected into, to the network, to the external lighting network in order to facilitate, reliable payments. so if an LSP isn't reliably connected to other nodes, other public nodes In the network, then it's a bad LSP, and you need to choose a different LSP, for your payments to, to, to be processed, successfully.

I see. And so just to be clear, then the LSP in this case, are we talking about Breeze is acting as the LSP in this case, or is Greenlight gonna kind of let you pick different LSPs? Like how does that work?

So the Breezes the key, the, the way we've implemented in the Breezes the key, Greenlight is the end user

Using an open protocol to allow you to use other LSPs, so you don't really have to use the Breeze LSP. We hope that we'll provide a competitive, reliable service that user will choose, to use, developers will choose to use the Breeze LSP, but you can pick and choose a different LSP. And even in the Breeze LSP, we already offer you several options for other, LSPs. But the LSP entity is separated for Greenlight. Greenlight in this topology Technology is the represents the end user node which is connected with a private channel to the LSP, and the LSP provides both liquidity to the end user node, but also connectivity to the external Lightning network, if that makes sense.

Exactly. Yeah. On, on the Greenlight side, we are pretty much provider agnostic, though I personally have a preference for the Breeze LSP, given its longevity and the operational experience that Breeze has collected over the years, that's definitely Really, it, it was, it was really fortunate, that, that we, that we could collaborate with Breez, but from, from our point of view, what you as, developer or end user get is a stock core Lightning node. And all everything that you could do with a core Lightning node, you can do with, with, with a Greenlight node. With, I think, two small exceptions, we don't yet have a clear plan on how to integrate plugins, as in user provided plugins, and that's the only limitation, but we're working on that too.

Yeah. And, I guess while we're here, it might be interesting just to hear some discussion about core Lightning implementation as compared to others out there, because I know people- We're talking about, as an example, LDK with a rapid node, rapid graph sync, I think it's called, and, you know, LND, obviously, Roy, or you've already got LND in the current breeze. So how does Core Lightning compare with some of the other implementations?

B- Before Christian answers this question, I want kind of to demystify the, the term node, if that's okay. We, we need to talk about lightning nodes in general in order to have a, an intelligent discussion about the different, trade-offs. There's always trade Matter, what solution, you choose. And just to give a mental model for a developer for sub-- for the listeners to understand the trade-offs, I, I think we need to kind of decompose the term node into multiple parts, and we can talk about, each part separately, like what is the, the trade-off, in terms of, I don't know, trust minimize or privacy or other, other implications. So I would break down, like, I, I, I think we're Going also from a vision standpoint, I think, the, the term node, we're gonna be used less and less in the context of, of Lightning. I think we're not, we're, we already see a world that node does, a node doesn't provide all the function, it's, it's not a monolithic, environment where all your Lightning needs are being serviced in this entity that is called a node. So what is a Lightning node? Let's, let's break it down to, into four parts, I would say. I would say, signing Is part currently people think about, signing transactions as part of the functions of, of a lightning node. Channel state management is the second part of, of, a second function of a lightning node. on-chain, interactions, being able to track, on-chain changes is the third, part of a lightning node, and the gossip, or, or lightning network, notifications, that, that's the fourth kind of Part of a lightning node function. Tristan, did I miss anything? No, I think that's

everything.

Okay. So, so just to put that in the context of Greenlight, not in the context of CLN, but in the context of Greenlight, Greenlight is magical in a sense that they took the on-chain sync and the graph sync, which is very challenging to, to run end-user nodes on, on mobile devices if you constantly need to query the chain or you're constantly need to, get updated From, from, from the Lightning Network gossip, they offloaded it to a separate operation. Then each user node managed it, the, its own, channel state in the cloud, so the, the channel management is, is being handled, in the cloud, and the signing is in the user device. So from, from the four parts of, of, for the fourth, from the four functions of a, a Lightning node, we are left with one. So, It, it's a philosophical question whether Greenlight is even a, a lightning node in that sense. So, you, you see w-where I'm going with it. I think like there's no real, concept of a node, anymore with these hybrid, approaches. I can speak of LDK in that regard, but, I'll, I'll let Christian, chime in.

Yeah, so, first of all, I, I think that, that all of the implementations have a reason, to exist and they will have their own applications at which they excel and, and the various, trade-offs that, that, that we are about to discuss are trade-offs on the front end, right? In the back end, where we, we always aim to be compatible and to have, to, to share as many features as possible. And so we have collaboration on the backend and competition on the front end. And most, most of the differences we, we have between the, the different implementations, are, Purely colored by our prior experience, and so, and so depending on, on where you come from, you might prefer one option over the other. so let's, let's take, let's take a look at how Core Lightning, compares, for example, to LND. We very early on went down, decided that we wanted to have a modular system where you could swap out individual parts, and following the Unix philosophy, we wanted every single part to do one thing. One thing and one thing only, and do it well. And, that's exactly where sort of the hierarchy of, of, different pieces, that interact with each other and complexively make up the node, that Roy was talking about comes from, right? so very early on, we already had the signer split out into its own, its own process, and through the use of, of this modular structure, we, could actually take The stock core Lightning, the open source project, and by just tweaking the, tweaking the command line arguments, we could swap out individual parts. For example, the signer is, is now simply receiving requests from the, from the main process and shipping it over to the user's device where it is then, verified and injected into the signer, and then we do the same, route back again. so this kind of- Of modularity is something that we experimented very early on and we are very happy with, today. whereas LND had, has a bit of a different approach where they say, okay, we, we want to have a, system that is, that, that you can essentially unpack and everything is there, right? Whereas Core Lightning goes more into the direction of, oh, you might want to customize a bit more, here are all the tools, but it's less- Complete feeling out of the box. LDK on the other hand went, went a step further and started with, with mostly library, so, they now have, have implementations of, where they put all of the pieces together, but they went on the extreme end of the modularity where you can, you can essentially pick and choose every single detail and Whereas Core Lightning requires some knowledge, to, to wire up the pieces correctly, you definitely have to be a developer to wire up the LDK pieces to, correctly, and many of those choices that we made in, in, in Core Lightning as for defaults and the behavior and so on, you can and have to customize in LDK. that being said, LDK, if you have the knowledge, is an excellent, excellent environment to build build, to build lightning nodes or components for a lightning node. I should probably mention that, we have been collaborating with a validating lightning signer team, to build the li- the, the signer that we, we are, are using ourselves in Greenlight. And the validating lightning signer is, for example, one such project built on, on LDK. so, it being very, very granular can also be a huge advantage When it comes to, oh, I have an idea of what I want to build and I have the skills to put things together. and then we have, we have the fourth implementation, Eclair, which is, which is even more, out of the box, depending on which deployment you wanna use. Eclair and Phoenix are about the easiest, easiest, Android wallets that, that I've seen so far, and their LSP is also one of, one of the oldest. So they are very good at, at, running, running their wallets and their LSP, and if, I don't know if you've seen it, but they recently just published an excellent blog post on how they secure their node, and, you will see a lot of, a lot of the same terms, when it comes to where does the signer sit and, and how does it, how does it work. so we, we've had a bit of a, convergent evolution there. Where, starting from two different, starting points, we ended up with very similar designs there. So yeah, that's pretty much the, ecosystem here.

Gotcha. Yeah, no, that's, that's a great overview. Curious as well, do you guys have any thoughts on the future of, well, mobile nodes, let's say, even though I know Roy, you were saying kind of the term node is, let's say, it's getting a bit blended, but do you guys have any thoughts on the future of mobile nodes like as Breez You know, where do you see the future of that? Do you see that diminishing over time and it's going to be more like this kind of server supported approach, or do you see that there's still going to be a future for, let's say, mobile lightning node wallet or applications?

Yeah, again, I, I think it's all gonna be like kind of implement-implementation detail on where do you run, w-which part do you run where? I, I think kind of, where LDK, just as an example, a- and another shout out to LDK, The project, we actually use some of the libraries that Christian mentioned in our, SDK, amazing, amazing, project. LDK, for example, is a mo- kind of has a mobile-first approach, not a cloud-first approach like, Greenlight, but a mobile-first approach. But behind the scenes, if you take, if you want to run an LDK node right now on a mobile device, what you need to, you need to offload the, on-chain sync and the gossip sync to external Third party services, so you're left with the signer and the channel state. And even when it comes to the channel state, they are planning to add a VSS, which will be their component of cloud synchronization. So the channel state itself is gonna be synchronized to the cloud. So I think the, the, the, the lines of, where each component is, is running are, are already blurry, and it's gonna be even, it's gonna get even, more blurry In the, in the future. There's one thing, I want to, to, to mention one advantage that LDK has now and, and, and Breez, running an LDK node in a mobile has now is the fact from a privacy standpoint, the mobile nodes have better privac-privacy because no entity is aware of the destination of your payment. There is a feature in Greenlight that Kristen can, can, can expand, called Oblivious Send that aims To mitigate this, privacy, this privacy, implication, but currently, running using a, a mobile node is better, is better from a privacy standpoint because no one is, is, is aware of the desti-the destination of your payments.

Yeah. Christian?

Yes. So, Just jumping, jumping right to the privacy, point, it is, it is true that, that greenlight nodes, while we don't have access to, to the funds, we do have access to the logs, and, that is definitely, a concern for us And, we, we want to minimize that as much as possible. As Roy mentioned, we are looking into a, a number of techniques to minimize the information that is even shared with the, with the lightning, with the node running on, on our infrastructure. And Oblivious Send is one of these, mechanisms. Trampoline is another one. So essentially what we try to do in Oblivious Send is instead of sending the invoice to the server and the server server than, than computing routes, com- than using those routes to build onions and then sending those onions forwards. We instead synchronize the gossip over to the lightning, to the user wallet, running on their, on their phone. The phone itself is then, computing the routes and creating the onions and then injecting those onions into the node running on their server. So all we see is essentially an encrypted blob of information. We don't know who the destination is, we don't know the exact amount being transferred, we don't know the description of, of what is, what is going on. So that is essentially taking the payment process, composed of a number of HTLCs and moving it over to the client, client side. And that's possible because, the pay, the pay command in Core Lightning itself is doing the exact same, but as a plugin, for example. So we already have the capability Of, computing all of these pieces and injecting the onion into, into the node and hiding that information from the node itself. On the other hand, trampoline is another mechanism that we could use where we tell the node, hey, look, there, you, you wanna tell Breeze instead of us that, that, who the destination is? Fine, tell us to forward a single large HTLC to Breeze containing the invoice and then, and then your on- Online node or your LSP can take care of actually routing the payment to the destination. So these are various, constructions where we can hide information from us, and we are looking into, into increasing the, privacy that, that we can offer on, on, on Greenlight. On the flip side, though, having access to the logs can help us as core Lightning developers to inform our decisions, and that is definitely one, one of our goals as well to take some of the operational experiences we make, and check if our assumptions we made while programming core Lightning were correct. So we can now, we now have a closed feedback loop that allows us to optimize how we send payments, how we, how we manage our gossip and so on and so forth, essentially getting a wider view, a wider sample of what is, happening and whether our changes have the intended effect when, once we deploy them. So it's, it's a bit of a trade-off. But ultimately, we don't want that information, and that's also why we hope that as many users as possible will eventually off-board, because let's not, let's not conflate having a node on a mobile phone with having a node on, at, and the other side being, having a node on Greenlight. But with Greenlight, you, once you off-board, you have complete control of your in- Information as well. So the way I see it is that, new users temporarily share some more information with us until they offboard, and we make sure that this information can be used to optimize the open source project, which then is an advantage to everybody. And now coming back to your, to your question about having a node on, on a phone or having a, node on, on some server, these are, more or less philosophical questions, right? you will, you will pick the deployment that, that suits you best, and you can probably imagine that since we are going with the server assisted, thing, whether that's Greenlight or a self-hosted node at home that you remote into, which by the way is my prefer- Our absolute preferred, setup. we think that, that having the remoting into somewhere, option is, is superior, but that's an, that's an opinion. Can give a couple of examples why we think it's superior, and, that boils down to essentially we, we can have multiple frontends. so like Roy said, if I just want to, test out this podcasting two point o app, I don't have to, close Some other app, drain the funds from it, feed the funds into the, the, the podcasting two point o app, create channels, finish all, all that setup, and then find out, oh, that, that, this is an ugly app, I wanted, I preferred that, the, the other one, right? we have a better, recovery story, because your phone, the entire state for your phone is essentially, is essentially, surmised in your, in your, private seed and so as long as you have your twenty-four words, you can just re- you can lose your phone on, on a sailing accident, boating accident, and you can then take another phone, enter your twenty-four words, and just with that recover access to the node that is running somewhere else. so all of the sudden, you can, you, you, you are safe against boating accidents. I'll let everybody decide whether that's net positive or net- Negative, but being, being a sailor myself, I quite like the comfort of having the ability of throwing my phone overboard and just, recovering, somewhere else.

Yeah. And so then, I guess Greenlight is also dealing with backups for the user, right?

Yeah, exactly. So, we, we are actually creating backups that we, that we then give to the users in the case of, if they want to offboard, in an encrypted form, and just using their seed phrase, they can decrypt this whole- Package and start a new core lightning, node against that, that backup, and they, they pick up exactly where they left off essentially.

I think Stefan, that you'll see similar hybrid approach, server assistance software coming from LDK as well, big, big backups, ability to have like a multi-device environment, ability to have multi-app environment require server, C/C++ software. So I think that again, everything is gonna be Very blurry on what is it. I maybe one takeaway from this post is that there's no more nodes. They're just different services that are composed differently on different devices.

Yeah, gotcha. And

there,

there is a lot of, of, interaction between us. Like Roy mentioned before, the LDK, guys are building a system called VSS, to synchronize state across, across, multiple, multiple instances of their software and, That is, that is in response to a need that we ourselves had, because I mentioned before that you can attach as many signers to a single node as you want, but signers aren't stateless, and so we needed a st- a signer state synchronization protocol where we could say, okay, here is, here is my current state, and every signer would get a copy of that state along with requests, verify against that state, and then feed that, state back. So that is, that is something that, that, that we knew we had to build and, talking to the LDK guys, we, we found out that, oh, they, they want to get one step further and actually synchronize the entire node, whereas we just synchronize, the signer state, which I think is probably easier, but we'll see how that turns out.

Yeah. I guess one other interesting implication here is it hopefully, and we were talking about this earlier, custodialism versus non-custodialism. And perhaps the business case and perhaps lower or lesser legal regulatory risk associated. So I guess there's a lot of people talking about custodial adoption and non-custodial adoption, and I, I suppose you could say this kind of software and this kind of build out is going to help more people be non-custodial because today they might have various services that they are a custodial user of. So you might have, I mean, just even in the Bitcoin world, you might have Stacker dot News and have a little custodial balance there. You might have a Fountain app with a custodial balance there, and you might have this other app with a small custodial balance in there. How do you see that potentially changing? Do you see possibilities there that it could become more non-custodial?

all that we're doing, both Christian with the, the Greenlight work and, us at Breez, with the Breez SDK work is, there's no such thing as a custodial lightning. lightning is Bitcoin, Bitcoin is non-custodial. Like, an-an-any Technology, I think it's just, just a smoke, a smoke and mirrors. everything is, like if you want to, use Bitcoin as a medium of exchange, we need Lightning, Lightning. The way to do Lightning is only non-custodial Lightning, and all the work that we're doing is to promote the usage of Lightning, in the world. If you're not using Lightning in, non-custodial fashion, it means that you're using, Not even using Bitcoin, in a sense. so definitely the user experience that we can provide with the Breeze SDK through the Greenlight infrastructure is superior to the user experience that we're providing right now with the Breeze, wallet, which is great, and what Phoenix are doing, is great, and I think people will be surprised of the amount of transactions and the throughput that we both these wallets are processing, and all the stats and all the fact that it exists right, right now In the, in Twitterland is, is complete fad. there's, there's a lot of non-custodial usage, of, of Lightning by end users. And, and I think, I think our SDK and the work that Greenlight is doing, the work LDK, are doing will take Lightning, to the next, level and, and you, you can already see example of that with the Mutiny wallet. I don't think we're far from a future where all the services will use Better non-custodial infrastructure, and, and non-custodial Lightning will be like the first default solution, in implementing end-user products. I think we're very close, to that future. Yeah.

So I'm curious, just on that then, do you think there are thresholds above which you need to be for it to make sense for you to be self-custodial? Because let's say we move into a higher fee environment, you know, in this recent spike we saw at one point, you know, the, the fee to get into the next block in fiat terms Well, I think it was like five hundred satz per v byte or around fifty dollars. Do you think that there's certain thresholds that, you know, let's say there's another bull run, let's say the price goes up and the, you know, the block space market gets more congested, do you think there are certain thresholds above which it's difficult to be self-custodial or to, to, to, you know?

There's always a price that makes sense. That's what, w- if you have congestion in the mempool and if there's a lot of demand for First, more demand for Lightning. So it's better to open a channel, no matter what, like, let's say it's, that's why I said before, like it's, it's, the, the challenge is a volatile fee environment, not a high fee environment, because in a consistent high fee environment, it always makes sense to open a Lightning channel if you're making multiple Bitcoin transactions. You're better off doing that in Lightning than doing that in on-chain because you will save money doing that. Off-chain then on-chain. So it always makes sense if you're interested in, in Bitcoin. If you're not interested in Bitcoin, no, it doesn't make sense. Go and find, another solution like USDT or another token, to, to, to do your transaction. If you want to do Bitcoin, the way to optimize your spending on fees is only by Lightning.

Christian,

anything to add?

So, I, I just wanted to go back to, to the, to the custodial versus non-custodial thing and, and add- Maybe one facet, namely that, we as a Bitcoin community have a tendency of, of blaming or shaming the user choosing a custodial solution over a non-custodial solution. But we also have to, have to see that, custodial options, often are easier to use because, well, they don't have all of that, complexity behind it. And with Greenlight, one of the goals was essentially to see how far can we push The non-custodial nature, because I want to have a, a system that is as easy as it, as it can be, but not easier. And being a Bitcoiner, I definitely don't feel comfortable holding on to user funds, so having a custodial option is, is something that I would never be, never be comfortable with. But I have to be fine with, with users potentially choosing a custodial option that might be easier to use. I should take that not as, as, as a, as a negative for the users, but, but I should take that as, as my, my lack of usability that, that, that we have to improve. And so hopefully we can get closer and compete with custodial solutions, for their users, such that the "oh, it was just easier to use" isn't a valid, excuse anymore, because the only thing we can do as, As, sort of, providers of a services to make sure that these users are aware of the trade-offs that they are, taking. And if a user prefers to work on their day job and, and, pick a custodial solution with whom they might have a contractual obligation, that should be fine. But we always, I wanted to make a system that is non-custodial, and, it is up to us to compete with, custodial- Audience and not shout at the users that didn't know better.

I see, yeah. And I think one interesting area that people talk about is things like Lightning address, right? Which I'm sure you guys are both familiar with, and we, even we earlier we were talking about asynchronous payment. So I guess that's part of the answer, maybe Vault 12 is perhaps part of the answer that, the non-custodial- That's part of

asynchronous payment that will allow us to support Lightning addresses as well. Yeah. The main challenge in supporting Lightning addresses in a non-custodial environment Is the ability to receive offline. there are other dependencies on running an HTTP server that can be mitigated or externalized better, conveying the trade-offs to end users. Let's put it aside. The reason that Breez, for example, the Breez app currently doesn't support Lightning addresses, addresses, is because we don't have a reliable way to send users, funds when they're offline, and that is the primary use case of a Lightning address. once we'll have a good infrastructure in place, whether Through mobile notification in the Greenlight environment or via the protocol changes that are expected in implementing the asynchronous payments, we will implement lightning addresses in a non-custodial fashion

Yeah, got it. And so, just turning to Lightning protocol stuff more generally and more broadly, curious to hear what you guys are most excited about, what things you most would like to see come to the protocol.

All of the above.

Well, yeah, we, we mentioned the asynchronous, payments. I, I think there's, an area of the exploration and research and discussion that is, going on right now around stackless payments or, or channel jamming that I think is, very important for, for Lightning. so I would say stackless payments is, is, is important. Asynchronous payments for me, it's a top priority, and I think improving payment reliability Is something that is constantly being, being researched and, and, and being improved. A, a shout out to L and D on the work that we-- they, they, they're doing on, on routing algorithms. I think there's more room for improvements on, on the reliability of routing.

Absolutely, yeah. I, I, I definitely do have to agree on, on reliability and, it is worth mentioning, Renee Picard's, min-cost flow, solution And overpay solutions. So, those, those are all ongoing experiments and, and we, we hope to, to support those efforts, by, by building out the infrastructure to test them out in the wild and provide, provide sort of the, verification metrics to, to see if A or B works better. besides those, of course, I do have my oldies, splicing and, and, L2 or LN symmetry as it's now called and, both of these are, are progressing nicely, and so hopefully, hopefully we will have them soon, making it, making it easier to manage your channel funds with splicing, potentially making, making things like, swapping off-chain to on-chain a thing of the past, because you can just pay out of a channel, and, L2 of course, being a, LN symmetry being a Different, different proposal, for how to, how to build lightning channels, but, beyond that, how, how to build, multi-party channels, and eliminate some of the downsides that the current update mechanism has, like we mentioned before, the issues with backups being dangerous and, and, states being rather hard to track in, in the current protocol, that's being simplified Quite a lot by, by, Alan Szymczyk. but yeah, it's, it's been the same couple of, of, items on my wishlist for, for a while now, and some of them are definitely coming true. So, I'm, I'm definitely looking forward to that. And of course, async payments is a huge step forward, because that is the s- the solution we need to enable offline payments and, once and for all.

Yeah. And it's interesting, you guys both mentioned, I know, Dusty Demon has been working on that and has been, he's doing some talks on that. I saw him speak on that at BTC++, and, also at Bitcoin twenty twenty-three in Miami. that's interesting because, as I understand from an LSP perspective, it makes it easier for you to, let's say, manage the capital, for that user, and it makes it easier for the user to be natively Lightning rather than sort of having to, I guess, maybe it makes it a little bit easier instead of like swapping in and out or having Like constantly set up new channels, right? I guess that's one of the main benefits, with splicing.

I'll, I'll try to simplify it to concrete use cases. So in term, liquidity management is always a challenge for a routing node and for an LSP, improving on, liquidity management, the tools that, that we have in order to optimize, liquidity is very important for running a successful, an LSP business. so the more tools that we have in the, in our- toolset, the, the more, we can optimize liquidity and efficiently allocate liquidity, to where it's actually needed. So one, The one concrete use case, let's, let's say an LSP is opening a channel with an end user node, the, the user is making a few payments, and now there's a lot of liqu- and, and the user kind of stopped using, lightning, using, their channels. Now you have liquidity, that is not being capitalized on the LSP end of the channel. splicing can be a way to reallocate, this liquidity to Other channels without closing. So right now, in order to do that, we need to close the user channel, and that, that means there are UX implications to the end users to deal with the closed channel. The cha-the funds are going back, on-chain, and the user needs kind of to decide what to do with the on-chain funds. Instead, having a splice out, tool allows you kind of to reallocate the un-used liquidity, the liquidity that isn't on the end user End, but is on the LSP end, and to reallocate that to, to, to a different, channel to a different user that hopefully will be more active than the user, that isn't really being active on, on Lightning, because Lightning, by the end of the day, the bi-the inherent business model in Lightning is to reuse the channel as much of, of, as possible in order to gain Lightning fees. another concrete, example is like what Christian mentioned, I think- By the way, I think that swaps will always be part of the end user toolbox. Like, it's not really trivial that users will want to, splice in order to pay an on-chain address. I think swap makes sense if users want to keep the channel open and they need an inbound liquidity afterward. So it's not that trivial. But- But definitely the ability to, for example, open a channel directly without a swap, to splice in a channel from your on-chain, balance, that's definitely another, another, tool that we need in our tool set in order to improve, the, the user experience, then you don't need to kind of submarine swap, to a channel, and even offering a tool, to drain, to drain all the funds from existing channels or to send, to send, without a reverse submarine swap is another Or another tool. Gotcha. So splicing, yeah. Super important. By the way, just maybe we haven't mentioned it, liquidity management is still ongoing topic. So we, there are suggestions of doing negative fees, there are suggesting in doing, of adding inbound fees on top of outbound fee, outgoing fees. So I think we'll see more improvements on, on liquidity allocations in general.

Yeah. So I guess bottom line, having more tools in the toolbox for the LSP and for the wallet providers as well, it might help them lower their own costs of- Being an LSP, which in turn maybe some of that can be passed on to savings for the end user, because maybe today he's paying a certain fee rate because the LSP doesn't have the right toolset that they need. So you could sort of argue longer term, right? Maybe not straight away, but longer term you're gonna see a competitive dynamic between the LSPs, and maybe that can bring the fees down a little bit on the margin, let's say. It's not gonna be, you know, totally, but on the margin.

Definitely. And it's not about covering the cost But making money, it's about, generating revenue, the, the revenue is being generated by augmenting the, the traffic in the Lightning Network, I like the, this, this defensive behavior we have in Lightning, like to save costs, we don't need to be defensive about, it's not about saving, it's about earning. We need the right incentives to be in place. Everyone needs to make money. We want, we want to augment the Lightning traffic in order to make more money, and, and this, in return, I'm a, I Free market, this will, in return, will lower the cost for end users because we'll have a competitive environment where, different LSPs are competing for end users. Yes.

Yeah. Gotcha. Yeah, very

much an alignment of incentives here, yeah.

Yeah. And so, I guess, Christian, from your perspective, you mentioned a little bit about LN symmetry and some of the benefits there, and so I guess, do you have any, I guess, updated thoughts or is it, you know, more of the same that basically you'd like to see something like any prevail Or perhaps Check Template Verify or something like that, and I guess to give the benefits that could come with having L2 or LN symmetry, because then, you know, we could have, the benefits in terms of backups and potentially in the future, this multi-party channel idea.

Yeah, so I think the our last discussion about, about L2 is, is pretty much still up to date. we, we need something like APO or, Check Template Verify plus Check Sigmastack. to, to have the, have the pieces to build out this, this, this mechanism. sadly, check template verify alone doesn't suffice, which is something that, that many got wrong initially, and me too, by the way. so sadly, we need checks if from stack if we get, check template verify. But, both of these proposals are, are very much aligned and, and And both of these not only, enable L2, but also, as far as I'm being told, ARC, by Barak, so, or an improved version of ARC. and so I think that sooner or later we, we will get them. In the meantime, Greg, which, with whom you've spoken recently, I think, is, is working on a proof concept built on top of, of Liquid, Elements and Liquid, of course. And, and it is looking quite, quite nicely. and all of the, all of the details that he uncovered and all of the sort of small hurdles that, that we didn't see during the design of, of L2 from my ten thousand feet bird's eye view of, of the problem, those are definitely huge wins that, that we can reuse once we get, APO or CTV. So I'm, I'm optimistic that, that we'll get them and we'll have the, the knowledge on how to build this, this stack out at the time we get them. They've been stewing in the background, which I think is, is the way to go with Bitcoin. It might not be the quickest, quickest way to get new features, but it is the safest way. so the, the longer we let it stew, the, the better we have an idea of what alternatives are there how could we improve each individual of, proposal and which of these proposals do, maximize the u-uh, usability and minimize the risk that, that we, introduce into Bitcoin, by going down that road? And so I'm quite happy with, with the state it is in right now. There's been a lot of experimentation and, it's, it's looking quite good. nevertheless, we still don't have APO and

Yeah, yeah, let's hope so. so I, I think it's also interesting, well, it'll be, you know, there'll be time for people to, let's say, prove it out, like Greg is trying to do with Element and Liquid, and that will sort of prove it out for people that, okay, there's commercial demand for it, it's safe, et cetera. There's, you know, and there'll be, more work there, I'm sure. So, I guess let's, let's wrap it up there.

You know, Lightning helps us optimize our use of the chain. Greenlight is essentially a service from Blockstream where they can help you run a node for you, although the no-- the term node is getting a bit confusing nowadays, as you mentioned, Roy. and so the idea is Greenlight helps the builders out there, developers, entrepreneurs, if you wanna build a Lightning service, you can use Greenlight as your cloud node, but the user still holds his own keys on his phone or elsewhere. And then Breez SDK is kind of like a- A packaged greenlight that makes it easy for people who want to just kind of not think so much about the lightning stuff and just focus on their competence and what they're building. So I guess that's kind of my very high-level understanding. Any other things you want to mention as we finish up?

Just to reiterate on, on the fact that I think it's time to build on Bitcoin. And I'm still in kind of the John Spahr, terminology here. Let's, start and build on Bitcoin. I think Okay, the tools that are provided right now with, with, Greenlight, with LDK and with the Breezest DK, are very, are very make, make, makes it very easy for non- for non-lightning expert to integrate lightning payments into their own, stack. I'm very bullish about, lightning. I see the maturity in the ecosystem, I, I, I see the traction that we get and the leads that we get from, from- audience that, just getting exposed, to Bitcoin and Lightning and want, and they want to integrate Lightning payments into their own solutions. now is the time, there's no need, to wait. so go and, experiment, or you can reach out to me in any medium to, to, to kind of get you going with the stack, but like now is the time.

Christian? Yeah. Couldn't, couldn't have said it better, we all Bob, built on Bitcoin. so, if, if, if you want to, if you want to give, Greenlight a spin or the Breez SDK a spin, just reach out to any, to either of us and, and we'll give you a quick tour or the access you need and any assistance you might, you might want to. It's been incredibly exciting, as Roy says, we've seen a lot of different use cases. Suddenly pop up, that we weren't aware of, as, as Rusty Russell always says, we, we are the engineers building something in, in our small cubicle, but, the people actually doing the innovation, actually building the interesting user visible things, are the ones that, that are inventing the, the, the, these, these new experiences. And so we are always surprised when, when something new and- Innovative, comes, comes our way, so, keep the surprises coming.

And, and we haven't seen yet, nothing yet, meaning, currently, the, the way that, the, the way that the ecosystem is, is, is, the state of the ecosystem is that, the, the existing solutions in Lightning kind of trying to mimic the existing fiat solutions. I think the innovation of, the power of the innovation of a programmable, permissionless, accessible money, we haven't- Really seeing, the, the user experience and the transformation it can have in the way that humans interact with, value in general. so I think there's a lot, that we can do a-and the, in the future is, I'm, I'm excited to see what comes next.

Excellent. Well, yeah, look, I think we've, spoken about a lot of stuff in depth and, hopefully, listeners are, have taken some value out of that and they're hope they're ready to get out there and build Bitcoin and Lightning out there. All the links will be in the show notes, so I'll put the links there. And, yeah, Christian and Roy, thank you for joining me today. Thank you, thank you so

much for having us.

I hope you found that informative and educational. Get the show notes at stephanlivera dot com slash four eight eight and make sure to share this show with any people who are interested to build on Lightning. Thanks for listening, and I'll see you in the citadels.