Christian Decker (Blockstream) and Roy Sheinfeld (Breez) rejoin me on the show to talk about: 

• What has improved about Lightning over time
• Lightning in a high fee environment
• What Greenlight is 
• What Breez SDK is
• Is anything changing on the existing Breez app?
• Core-lightning contrasted with other implementations
• Lightning protocol improvements

Links:

• Twitter: @Snyke
• Twitter: @therealkingonly
• Site: Your personal Core Lightning node,without the technical fuss.
• Site: Breez SDK

Sponsors:

• Swan Bitcoin
• CoinKite.com (code LIVERA)
• Lugano PlanB Forum
• Mempool.space

Stephan Livera links:

• Follow me on Twitter @stephanlivera
• Subscribe to the podcast
• Patreon @stephanlivera

Podcast Transcripts:

Stephan Livera 00:01:34  

Go and learn more at mempool.space/enterprise for today’s show, Christian Decker of BlockStream and Roy Scheinfeld of Breeze.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 green light and Breeze SDK. So for this episode. It is more into the technical details, but I think it is appropriate for developers 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? 

Christian Decker 00:02:08  

Hey, Stephan, thanks for having us. 

Roy Sheinfeld 00:02:10 

Thank you, Stephan. 

Stephan Livera 00:02:11  

So we’re going to 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 green light and breeze and Breeze SDK. So yeah, I guess let’s start with a little bit on, you know what we think the future of Lightning is gonna look like. I know Roy, you have written extensively about this, this idea of a peer-to-peer. Give us some of your updated thoughts.Is that still? That’s still your view, right? 

Roy Sheinfeld 00:02:36 

Yeah,, nothing has changed, but much in the last couple of weeks, actually. I’m even more foolish than ever on Lightning coming back from Prague. I’m completely amazed to see the maturity of Lightning these days. I spend the week in Prague with where I met you, Stefan and everyone. Kind of everyone. The thousands of people lived on Lightning for a week. So if I compare Prague to previous conferences in Miami or even back in 2019, when I first met Christian in Berlin, where nothing. work I was completely amazed to see 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 and it is ready to be taken. To the next level and the next level in our mind is to start integrating lacking payments into more traditional mainstream use cases. 

Stephan Livera 00:03:44 

Yeah, Christian, anything to add there? 

Christian Decker 00:03:46 

No, I think Roy pretty much captured it. 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 usage of Lightning by real mortal. Users, and that’s incredibly exciting. And as Roy mentioned, we finally have a performance 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 becomes usable. And we can see a lot of experimentation by different different users for different use cases and different uses. So it’s an incredibly exciting time. 

Stephan Livera 00:04:49  

So I guess on that topic, what would you say has improved? Move over the you know, if we look back like, let’s compare back to October 2019, the Lightning 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? 

 Christian Decker  00:05:08   

I think there have been a lot of small changes over the time that are cumulative in nature and often not as visible to the end user as some of these huge features that we often talk about, but I think the, the ease of running a Lightning node have certainly increased and the performance of the notes themselves as well as in time to success or time to finality for a payment and the rate of success. 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 both aspects of that. 

Stephan Livera 00:05:53  

And Roy, from your perspective, what would you say the big improvements have been? 

Roy Sheinfeld 00:05:56  

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

Stephan Livera 00:06:59 

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.These right now some of that was driven by the, you know, the in scriptors. The inscriptions are 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? 

Christian Decker 00:07:26  

So I think it has been overall a positive experience for us . It’s been a bit of a forcing function and the trial of fire trial by fire for us and we’ve definitely noticed some pieces of our model that broke and the other parts that worked. And now it’s up to us to essentially take those learnings and apply them. One of them was, for example, that core Lightning did not have zero HPLC anchors, and now we have them or soon we have them. As soon as the pull request goes through and techniques such as bring your own. The have been very successful during 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 high fee environment. And so I think that’s the biggest impact 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 that the channel didn’t activate because well our counter party 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 we’ll try to learn from these experiences as much as possible. 

Stephan Livera 00:09:13   

Now Roy I know you recently wrote about the inscriptions as well. So do you want to just give us some of your thoughts there in terms of inscriptions and the high fee? Environment and how Lightning is dealing with it. 

Roy Sheinfeld 00:09:23  

Yeah, definitely so I think we all want to see a higher environment, higher environment means more secured network. We want to live constantly in a high fee lock chain environment in terms of minors compensation, minors incentives, it’s very important. To for them to make a lot of money from on change transactions. So I think that’s a positive. I think there are couple of other good implications. One, it only demonstrate the need of Lightning. I think there’s a kind of a misconception. I’ll try to clarify Lightning. Isn’t 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 don’t need lighting as well. Lightning isn’t going to solve the on chain interactivity. Lightning gonna optimize the on- chain interactivity. So one way to  look at Lightning. You can think about channel opening and a channel closing as a way to zip multiple. Unchained transaction into just two on chain transactions. So you open the channel, you make countless of transactions between opening the channel and closing the channel. But if you but if you haven’t had a Lightning channel, you would have used Unchained transaction. To do that instead. So in that way 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 blockchain 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 do Unchained transactions during this high fee. Now understand the need of Lightning and we see that all the time now, like we get, we get inquiries from Bitcoin brokers from Bitcoin exchanges, from hardware wallet. Everyone now is rushing to implement lighting because they understand they need to be there because. These are gonna spike and they need to be ready to have a Lightning infrastructure. So that’s a net positive in terms of Lightning. 

 Roy Sheinfeld 00:12:04 

I think there’s another positive thing about 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 this bit and miners are earning bitcoins as a result of this, Wizards paying in Bitcoin and they’re paying the miners paying their expenses in Bitcoin. So it’s another use case of another demonstration of Bitcoin being used as a real. Currency, I don’t care really what their. Paying for they can pay for whatever they want. I don’t know if there’s a real utility in the inscription or not. Like my personal 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 these. The Jpegs I don’t care. 

Stephan Livera 00:13:08  

And I think you make a fair point as well what you were saying around optimizing and 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. 

Christian Decker 00:13:22 

So coming back to the compression comment that I just made, I think it’s very important to notice that 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 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 to interact with the chain, which allows us to determine, to pick what, fees we might want, right. Except in a unilateral close, you can essentially choose when to open and when to close a channel, and you will essentially. Use the fees at those points in time. And that allows us to spread the load of the chain interactions over the entire time space and essentially smooth out these fee changes over time. But besides these, these scalability and fee. We also have the opportunity of bringing truly novel use cases 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 10 minutes and 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, on chain payments you will leave a permanent trace of every single interaction with off chain you have. It’s different. I’m not saying it’s better or worse. 

Christian Decker 00:15:09  

I’m saying it’s different. Because now you’re telling in real time other people that you are performing a payment, but that payment that is only shared with the nodes that are interacting with you and on the other side that information is not stored in eternity on a blockchain. For example, so these are different facets of what Lightning brings to the table and scalability is one of Them and I totally agree. It’s not a silver bullet, but it can easily allow us to grow by two to 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. 

Stephan Livera 00:16:06 

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 enlightening. So then if you can earn enlightening and then spend 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. 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, right, because we may already, there may already be, 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. These, but no, they were kept off chain because all this podcast value for value. Or nostril zapping or bit refill 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. 

Roy Sheinfeld 00:17:24  

I don’t think that the 21 that says apps would have gone to the chain. So I think there are two use cases. Done that our transaction that 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 lighting only use cases real time payments, use cases around the value for value around the podcasting, the apps, etc. I don’t think people are aware of the number of transactions that are executed in Lightning. I think were at the range of 10s of millions of transactions per month in Lightning right now significant amount of this volume would have gone to the chain if it was. Wouldn’t if lighting wouldn’t exist for sure. Another technical example for of what Kristen said about like choosing where when to hit the chain is our usage or not just our usage, but they use. Of 0 confirmation channels with the zero confirmation channel, an end user doesn’t really choose when the Open transaction is the open Channel transaction is being executed, chain. It’s the LSP that chooses when the transaction is confirmed and the SP can. Can use can bump, can bump the fee whenever they want to get the channel confirm sooner. So another way to mitigate a high fee environment, by the way, a high fee environment is not really the issue, it’s the volatility of the fees that are an issue for another fee, it’s not really like if the if the if the environment is is consistently high then it requires 1 If the fees are spiking. All the time and. It’s a very volatile environment. You need that’s more challenging for, yeah. 

Stephan Livera 00:19:22  

It’s more tricky. Yeah, to deal with, yeah. So, look, let’s talk a little bit about what you guys are building.I know, Christian, you’re obviously very involved with green light, 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 green light? How’s it going to work? 

Christian Decker 00:19:48 

So we noticed that a certain point in time that the way that we were onboarding users into Bitcoin and Lightning and specifically. Was essentially pretty much broken because we as a Community have a tendency of airing 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 a manual. Read that and then there is a second manual which is the Lightning. Manual and then there is the safety for Lightning manual and only once you’ve read all of these, you may touch your first Bitcoin and the and the user might get halfway through the first manual. And then give up because for them learning Bitcoin and Lightning has been only work for now. So I think we need to invert 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 how to what, what the technology behind it is, and how to safely manage their own infrastructure. And So what we what we were wondering is, hey, there is, 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? 

Christian Decker  00:21:19  

How do you secure your Unchained footprint with the watchtower? How do you ensure that your node is online? And so on and so forth, all of the. These more operational aspects that can be quite overwhelming for new users. So what we thought is how can we take on some of that responsibility on our side without ever touching the users phones, right? We wanted to have. A system that can compete with custodial solutions when it comes to ease of use, but we don’t want it to be custodial. Right. And so the idea came up that well, one part is the note. 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. Well, we essentially split up the node we said OK, here, here we have 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. An App Store. And then there is the more complex operational aspects of actually running setting up in node and running that node and making sure that we never do anything dangerous with it, because remember, even doing backups for Lightning nodes is dangerous. And green light is essentially the end of that thought process where we say, OK, we, we take care of the database, we take care of the Watchtower, we take care of the node. Would 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 can steer your node and as a signer, and this essentially means that we never touch the funds, but we can perform the operation. 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 a more information to educate them 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 have the experience and have the knowledge to do so safely. 

Stephan Livera 00:24:00  

OK. So just summarizing a little bit then. So green light 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, OK, 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 key is still live in the client device, whether that’s you know on their phone like Breeze or something like this. But BlockStream and green light 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. The game or some app or something like this, is that broadly the. 

Christian Decker 00:24:47  

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

Stephan Livera 00:25:20  

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 Breeze, you’ve got this, you know, the Breeze Wallet, which is great and now you’ve got Breeze SDK. So can you first? Yeah, just explain a little bit about that and I guess explain to the users who might be curious. Well, hang on, what’s happening to the?Is that going away? Or is that, you know staying? 

Roy Sheinfeld 00:25:43  

So if I look like Breeze is five years old now, and if there’s something I’ve learned in the past five years, is that the users don’t care? Let’s be honest. Like we live in an echo chamber. We care, we care about our kids, we care about our sovereignty. We care about our freedoms. But the majority of users simply. They don’t care, but what they do care is about the utility of Bitcoin and what we’ve proven in the past in our journey, 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 merchants to accept payments. Without the need of a bank account, with we proved that using our podcast player where users were able to stream sets to podcaster like yourself without using like only peer-to-peer, no intermediaries, no any third parties in the middle taking their cut. So 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 number of transactions in the throughput in the number of users. So naturally our next step in our revolution. Was to provide the infrastructure that we’ve built in order to provide the non custodial Lightning as a service to provide it to other. Offers and other companies to integrate Lightning payments into their own stack into their own solution. When we understood that that’s what where we want to focus on, we chose green light as the platform to implement our SDK. Because of the problems that we’ve ourselves experienced in running a fully featured node on the mobile device, we’ll, I’ll, touch, I’ll touch, I’ll talk about it in a. 2nd but also there’s a hidden kind of benefit to using a platform like green light where you can have multiple apps running against the same node. Essentially, it means that you can reuse your liking balance from multiple apps, and if Reese is creating an SDK. Very natural that all the apps that are using the SDK will be. Able to interact with the same user balance. 

Roy Sheinfeld 00:28:14 

Kind of 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, suck your news, and you need to top up fountain and you need to top up trees and phoenix and like and. You need to use. Different balances, you know, to interact with different services. We wanted to solve that also as part of our SDK. And having a hybrid approach for running Lightning nodes where you have the node in the cloud and the keys are on the users device helps with providing this user. Experience so I didn’t answer your question. To answer your question, the current bridge app which is LND based isn’t going away. We’re not gonna deprecate it. We are maintaining it. 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 current bridge app, but we will have a separate wallet which is green. Based we it’s already kind of ready for data. We’re there are few issues with green light that are waiting for us to kind of publicly announce the green light the better. But we will have a separate app that provides the same user, the same breed, user experience sequence again. And we’re not 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 green light and the rest of our stack from other applications as well. 

Stephan Livera 00:30:15  

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. And will be the end user, let’s say right your customer is sort of the developer or the entrepreneur who’s 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 want to, you know, use green light or breeze and then provide that service for their end customer end user? 

Roy Sheinfeld 00:31:04  

So the braces decay aims to be a very simple drop in solution for all your lighting needs. Needs as a Christian mentioned, blocks to build green lighting or kind of to simplify the end user node part of using. Happening, but it’s just one piece. Of the puzzle there are. Other there is more infrastructure to put in place. There are other pieces that you need to take in mind to take into consideration where you’re when. If you want to provide a fully featured lighting solution, an end user node powered by green light is 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 and users to the lighting network exactly like an ISP connects users to the Internet. From a technical standpoint, opening channels. Or two end users, two end users nodes. So you need an LSP as part of your solution and the bruises decay encapsulates not only our LSD service, but it encapsulates an open LSD model where we allow developers either to use our LSP services or other LSD services we’re promoting. Standards with companies like CE. Rules and synonym. It also includes on chain interoperability, meaning the ability to send and receive funds to an Unchained address and and swapping them to off chain balances. So either sending funds to an on chain address. And having these funds in your lighting 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. Provide and another service that we provide. We are partnering with third party Fiat on ramps off ramps. You know kind of to bridge that gap from the Fiat economy. So if you’re a developer, again, developer, Social Network developer, Wallet developer, a Fintech developer, recruiter, 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. Payment 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. 

Stephan Livera 00:33:37  

Let’s see, yeah. So I guess I could summarize it then like it’s, you know, the 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 want to run it yourself, that’s where maybe this is useful for you, right? 

Roy Sheinfeld 00:33:57  

I think it’s useful for you, even if you’re a hardcore .I think it’s very useful for even if you’re a Hardcore likening Bitcoin developers. Because the pre 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. 

Stephan Livera 00:34:31  

So it might be like an example. Maybe an analogy might be you’re 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? 

Roy Sheinfeld 00:34:40 

Or your own LSD, or a different swap service, or a different Fiat on ramp, or different not green light. They want to host green light themselves, or they want to use voltage instead. You can do all this, mix this mix and matches in the context of the Breeze SDK. 

Stephan Livera 00:34:54  

Yeah. Christian gone. Yeah, so. 

Christian Decker 00:34:56  

The it coming back to the point that it might be interesting even for hardcore Bitcoin developers. You have to keep in mind that if you build on Breeze SDK and transitively on green light you have, you are actually building a non custodial 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 you can run the node in a non custodial manner. Because if you don’t have that infrastructure, all of a sudden you’re the custodian for all of your app users, which might be OK if you’re the only user, but I would guess that most app devs do not feel comfortable holding their users keys as are we so what you get out-of-the-box is essentially just when stripping away the additional services that that Breeze SDK provides green light underneath is essentially a Lightning node as a service. So what you get is an API. That you can program again. And you don’t have custody of the funds of your apps users. The users are have custody of the funds because that’s the only place where the keys are stored. So you’re not entering that liability and we have a number of additional features that make it. Much nicer for app developers to build on green light. One of them, for example, is that we have a mechanism for transparently offboarding. So while you might program your application against green light, a user might later decide, hey, I want more power over the node. I want to have more control or I’m curious. I want to see how this works under the hood, so they might off board, but now all of the applications that you’ve. 

Christian Decker 00:37:02  

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 in our infrastructure, a competitor, or at home at the user itself, right? So there are many, many of these. Nice usability features for app developers to make use of. Hiding complexity and abstracting away from different issues that people might encounter 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.. 

Roy Sheinfeld 00:37:55  

I just want to mention one thing about the non custodial aspect of this solution. It’s not about ideology here. 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 is no longer a thing. 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 the latest developments. In the regulation in the States and in the EU, also from a user experience standpoint, 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 brokers and. Because 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 a like a hardcore Bitcoiner thing to be done. I think there’s a very concrete trend that we see that people are. Looking actively for non custodial solutions in order to mitigate their regulatory landscape. 

Stephan Livera 00:39:28  

So in other words, it’s like there’s a business case to be non custodial as opposed to just like the ideology of being decentralized, let’s say. 

Christian Decker 00:39:36  

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

Stephan Livera 00:40:45  

And so when it comes to being an LSP Lightning service. I guess users today are used to an example like it exists in Breeze today. You can receive funds and it will create what’s called an on the fly channel. So is there a similar concept here in green light and Breeze SDK? 

Roy Sheinfeld 00:41:01  

It’s the exact same concept. Instead of running the user node on the mobile device like in the existing bridge app, the node runs on the green light environment. The LSP intercept the HDLC open, opens the channel on the flight to the green light node, the green light node asks the end user on the mobile device. Sign the Channel, Open transaction and all the cycle is completed. 

Stephan Livera 00:41:27 

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. So how do we deal with that? 

Christian Decker 00:41:42  

So we essentially have three different levels 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 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 the payment comes. Also, if I want to send my friend a quick payment to show him how easy it is to 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 signer present. This is sort of an opportunistic way of looking at it, right? We have the app open, so why not use it? 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 long as a single one. As present, we can sign off on changes, so that is sort of the multi headed HYDRA model of thinking about. 

Christian Decker 00:43:15  

This and we have we are experimenting with setups where we have a standalone signer running at home, essentially acting for you and your family and it is on line 24/7 and you can essentially just restart the node and the signer. Attaches to it and we’re fully operational. Again, and then the third iteration is what we have on the road map is essentially being able to reach out to app developers and say, hey, there is a need for a signer. Do you know any way you could contact your app users for that note and kick started? And that can be a mobile notification or that can be some container spinning up somewhere depending on the complexity of your setup. But in this case, we essentially defer to the app developers who know the best how to reach out to their own application, and I’ll let Roy talk about how reliable notifications are probably. 

Roy Sheinfeld 00:44:29 

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 queuing it. It’s still in testing, but that there’s no problem in Android. The problem is only with iOS gives you as always. This gives you 30 seconds of signing transaction or CPU time and we find it very reliable right now with green light. So in our exit. The Breeze app we weren’t really able to implement a notification as a mechanism to implement the offline receive it because we used an LND node and the start up time of the LND node combined with network reliability was. Very challenging when it came to kind of fulfilling the iOS CPU requirements, but in green light where you decouple the node operator. From the signing part itself, we find that there are 30 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 Lightning, so I think. We need to be. And self-sufficient enlightening. That’s why we’re trying to promote a protocol that we call asynchronous payment that includes several bolts in order to implement asynchronous payments in the protocol level. It requires support 11. It requires trampoline payments and it’s. Wires only on messages and it requires another specification of being able to hold the payment and then release it afterwards. But the I think there is a consensus at least out of from 4 implementation for from four major implementation 3 implementations are actively working on the. These specifications, so I’m very hopeful we’ll see the ability to implement asynchronous payments in the lighting protocol itself 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 year, so hopefully early 24, we’ll see. We’ll see the at least the first implementation of asynchronous payments in the Lightning Protocol. 

Stephan Livera 00:46:54  

Back to the show in a moment. Have you thought about securing your Bitcoin keys with hardware that you control? Coinkite.com makes some of my favorite hardware in the Bitcoin space. They most notably make the cold card Mark 4, 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 entirely. And you can use the cold card easily with wallet software such as Sparrow Wallet, Spectre desktop, Electrum or nunchuck, and you can use it as part of multiple configurations. Whether that is in single signature or multi signature. So go to coin card dot. Com and use. Code Livera for a discount on your code. But 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 100 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 Zarbo, Adam Back, Paulo Arduino, Prince Philip. Document Zuko Mike Peterson from Bitcoin Beach and so many more. It’s happening October 20th and 21st. There’ll be a mainstage as well as a secondary Lightning and peer-to-peer stage along 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 Plan B dot Lugano dot Ch for the Plan B forum on October 20th and 21st, and now back to the. 

Stephan Livera 00:48:38 

And I think I recall. Boy, 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 Matt Corello 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 somebody kicks off this payment and then the LSP 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? 

Roy Sheinfeld 00:49:14 

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

Stephan Livera 00:49:40  

Across the network, yeah. 

Roy Sheinfeld 00:49:43  

So 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 and LSP is always online serve. You can use the power of the payer LSD and the pay LSP to coordinate the payment and notify each other when the pay or the payer are online and liquidity isn’t locked in the pay LSP or in the middle of the chain it’s being locked on the first hop. 

Stephan Livera 00:50:17  

At the LSP level, yeah. 

Roy Sheinfeld 00:50:18 

At the fair LSP level? 

Stephan Livera 00:50:21  

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’d I just got a new payment like he doesn’t really have to think too hard about going online offline. None of that. Right. It’s all dealt with by the developers. It’s all kind of in the background, developers and entrepreneurs and LSP’s really are handling that problem. So the user doesn’t have to think about it, right? That’s kind of the. The end user message, right? 

Roy Sheinfeld 00:50:45  

That’s kind of our goal in, in, in the previous or experience like either users don’t need to think about anything or developers don’t need to think about anything that’s. Of our goal, yeah. 

Stephan Livera 00:50:55 

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 I’m understanding the end user in this case, he is not a routing node, he is an end user who just either receives payments or makes payments. He’s not trying to be a routing node. Who is like routing payments back and forth, right? 

Roy Sheinfeld 00:51:14  

Let’s translate it to a technical lingo. There’s a private channel between the LSB to the end user, meaning this channel doesn’t participate in the routing payments, and person can talk about the magic of green light. Because green light is magical. In a sense that way that it operates and optimizes resources, cloud resources. 

Christian Decker 00:51:39  

So one of the optimizations that we have for example is that we there is no point in keeping a node running if we don’t have a signer present, right? We can’t, we have no way of signing off on you. And So what we can do is essentially we can preempt nodes that are passive because they 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 a lot has a large. Impact on what costs we have to sort of share with our users and thus we get a system 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 node is being requested. And then scheduling it on demand on one of the slots in our infrastructure and startup usually takes a sub half second and usually by 1.5 seconds you will have a fully functional node with the gossip synced and everything because one of the biggest issues that we have. 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 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 able to receive requests. So from the point of view of the user. 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 a number of techniques that we use to ensure this fast start up time. But from a developer point of view, these notes are always running and we simply handle all of the life cycle in the background for them. 

Stephan Livera 00:54:05  

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 want to set up your own Lightning. It’s, you know, not you’re not going to 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 green light 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 user and you have like basically bad inbound channels or not enough channels, not enough connectivity, your payment experience might not be great if you don’t have a good reliable LSP, yeah. 

Christian Decker 00:54:53  

Exactly. LSP part is. 

Roy Sheinfeld 00:54:53 

So one of the facts. One of the functions of an LSP is to provide liquidity. To open channels to end users. But the LSP needs to be very well connected into 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. 

Stephan Livera 00:55:28 

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 green light gonna kind of let you pick different? Like, how does that work? 

Roy Sheinfeld 00:55:38  

So the breezes decay the way we’ve implemented in the breezes decay. Green light is the end user node. Breeze is the default LSP, but we’re using an open protocol to allow you to use other LSP, so you don’t really have to use the bridge LSP. We hope that we’ll provide the competitive, reliable service that user. To use, developers will choose to use the VSP, but you can pick and choose a different LSP. And even in the bruise LSP we already offer you several options for other LSPS, but the LSP entity is separated for green light. Green light in this topology is represents the end. User node which is connected with a private channel to the LSP, and the LSP provides both liquidity to the annual user node, but also connectivity to the external lighting network, if that makes. 

Christian Decker 00:56:34  

On the green light side, we are pretty much provider agnostic, though I personally have a preference for libraries LSP, given its longevity and the operational experience that the breeze has collected over the years, that’s definitely it. It was really fortunate that we could collaborate with. Please, but from our point of view, what you as a developer or end user get is a stock core Lightning note and everything that you could do with a core Lightning node you can do with a green light. Note 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. 

Stephan Livera 00:57:24  

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 talking. As an example, LDK with a rapid node rapid graph sync, I think it’s called and you know L&D. Obviously Roy or you’ve already got L&D in the current breeze. So how does core Lightning compare with some of the other implementations? 

Roy Sheinfeld 00:57:47 

Before question answer this question, I want to kind of to demystify the term node. If that’s OK we need to talk about liking nodes in general in our comments to have an intelligent discussion about the different trade-offs, there’s always trade-offs. No matter what solution you choose. And just to give a mental model for a developer, for the listeners to understand the trade off, 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 trade off in terms of. I don’t know. Just minimize or privacy or other replications. So I would breakdown like I. think we’re going also from a vision standpoint, I think the term node we’re gonna be used less and less in the context of. Of Lightning, I think we’re not. We’re already see a world that node doesn’t. Node doesn’t provide all the function. It’s not a monolithic environment where all your Lightning needs are being serviced in this entity that is called the node So what is a likely node? Let’s break it down to into four parts. I would say signing is part currently. People think about signing. Transactions as part of the functions of the locking node channel state management is the second part 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 Lightning network notifications that that’s the 4th kind of part of Lightning node function. Did I miss anything? 

Christian Decker 00:59:37 

No, I think that’s Everything. 

Roy Sheinfeld 00:59:40  

OK. So so just to put that in the context of real life, not in the context of CLN, but in the context of real light green light is magical in the sense that they took the Unchained sink and the graph sink, which is very challenging to run end user node on mobile devices. If you constantly need to query the chain. Where you constantly need. To get updated from the Lightning network gossip, they offloaded it to a separate operation. Then each user node managed its own channel state in the cloud, so that the channel management is being handled in the cloud and the signing. Is in the user device, so from the four parts of for the 4th from the four functions of a Lightning node, we are left with 1, so it’s a philosophical question whether green light is even like node in that sense, so you see. Where I’m going. I think like there’s no real concept of a node anymore with this hybrid approaches. I can speak of LDK in that regard, but I’ll chime in. 

 Christian Decker 01:00:57  

So first of all, I I think that all of the implementations have a reason to exist and they will have their own applications at which they excel. And the various trade-offs that we are about to discuss are trade-offs on the front end, right in the back end where we always aim to be compatible and to have to share as many features as possible. And so we have collaboration on the back end and competition. On the front end and most of the differences we have between the different implementations. Are purely colored by our prior experience, and so and so depending on where you come from, you might prefer one option over the other, so let’s take a look at how core Lightning compares, for example to LND we. Very early on when we decided that we wanted to have a modular system where you could swap out individuals. Parts and following the Unix philosophy, we wanted every single part to do one thing and one thing only and do it well. And that’s exactly where sort of the hierarchy of different pieces that interact with each other and complexly, 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 process and through the use of this modular structure, we could actually take the stock core Lightning, the open source project. And by just tweaking the command line arguments, we could swap out individual parts. For example, the signer is now simply receiving requests from the main process and shipping it over to the users device where it is then verified and injected into the signer. And then we do the same route back again. So this kind 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 OK 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. 

Christian Decker 01:03:34  

Here are all the tools. But it’s less complete feeling out. Of the box. NDK on the other hand went a step further and started with. With mostly library, so they now have implementations of where they put all of the pieces together, but they went on the extreme end of the modularity where you can essentially pick and choose every single detail. And whereas core Lightning requires some knowledge. To wire up the pieces correctly, you definitely have to be a developer to wire up the LDK pieces correctly, and many of those choices that we made in core Lightning As for defaults and behavior, and so. On you can and have to customize an LDK. That being said, LDK, if you have the knowledge is an excellent, excellent environment to build Lightning nodes or components for a Lightning node. I should probably mention that we have been collaborating with the validating Lightning signer. Team to build the signer that we are using ourselves in green light. And the validating Lightning signer is for example one such project built on LDK, so it being 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 4th implementation clear which is even more out-of-the-box depending on which deployment you want to use. Eclair and Phoenix are about the easiest, easiest  Android wallets that I’ve seen so far, and their LSP is also one of one of the oldest ones and so they are very good 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 note and you will see a lot of a lot of the same terms when it comes to where does the signer sit and how does it, how does it work. So 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. 

Stephan Livera 01:06:14  

Gotcha. Yeah. No, 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 why 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 breeze as it is today? The LD LND, let’s say version 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? Or do you see that there’s still going to be a future for, let’s say, mobile Lightning node wallet or applications? 

Roy Sheinfeld 01:06:48  

Again, I think it’s all gonna be like kind of implement implementation detail on where do you run, which part do you run. Where I think kind of where LD KL just an example and another shout out to LDK, excellent projects. We actually used some of the libraries that. Kristen mentioned in. Our SDK amazing Project LDK, for example, is a more kind of has a mobile first approach, not the cloud first approach like a green light 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 do you need to? You need to offload. The on-chain sink. And the gossips in two 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 VSS, which will be their component of cloud synchronization. So the channel state itself is going to be synchronized to the cloud. So I think the lines of where each component is running. We are already blurry. And it’s going to be even. It’s going to get even more blurry in the future. There’s one thing I want to mention, one advantage that LDK has now and breathe, running and LED node in the mobile has now is the fact from a privacy standpoint. Loads have better privacy because no entity is aware of the destination of your payment. There is a feature in green light Christian can expand called oblivious send that aims to mitigate this privacy. This privacy implication. But currently running using a mobile node is better from a privacy standpoint because no one is aware of the destination of your payments. 

Christian Decker 01:08:53 

So just jumping, jumping right to the privacy point it is. It is true that green light nodes, while we do not have access to the funds, we do have access to the logs and that is definitely a concern. And we want to minimize that as much as possible. As Roy mentioned, we are looking into a number of techniques to minimize the information that is even shared with the Lightning, with the node running on our infrastructure and oblivious send is one of these mechanisms, trampoline. So essentially what we try to do in oblivious send is instead of sending the invoice to the server and the server then computing routes, then using those routes to build onions and then sending those onions forward. We instead synchronize. The gossip over to the Lightning, to the user wallet running on their phone. The phone itself is then computing the routes and create. Using 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 what is going on. So that is essentially taking the payment process. Composed of a number of HTLC’s and moving it over to the client side, and that’s possible because the pay the pay command in core Lightning itself is doing the exact same but as a plug in for example. So we already have the capability. Of computing all of these pieces and injecting the onion 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 want to tell. Breeze instead of us that. Who? The destination? Tell us to forward a single large HTLC to breathe containing the invoice and then and then your online note 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 increasing the privacy that that we can offer on, on, on green light. 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 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 have a closed feedback loop that allows us to optimize how we send payments, how we manage our gossip and so on and so forth, essentially getting a wider view. 

Christian Decker 01:12:07 

A wider sample of what is happening and whether our changes have the intended effect when once we deploy them so. It’s a bit of a. Made of, 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 the other side being having a node on green light. But with green light, you once you’re off board, you have complete control of your information as well. So the way I see it is that new users temporarily share some more information with us until they off board 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 note on a phone or having a note on some server, these are more or less philosophical questions, right? You will pick the deployment that suits you best and. You can probably imagine that since we are going with the server assisted thing, whether that’s green light or a self hosted node at home, that you remote into, which by the way, is my preferred absolute preferred setup. We think that having the remoting into somewhere. Option 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 can have multiple front ends, so like Roy said, if I just want to test out this podcasting 2.0 app, I don’t have to close some other app, drain the funds from it, feed the funds into the  podcasting 2.0. App create channels finish all that set up and then find out that this is an ugly app I wanted. I preferred the other one. Right. We have a better recovery story because your phone, the entire state for your phone is essentially surmised in your private seed. And so as long as you have. Your 24 words. You can just. You can lose your phone on a sailing accident. Accident and you can then take another phone, enter your 24 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 a sailor myself, I quite like the comfort of having the ability of throwing my phone overboard and just recovering somewhere else. 

Stephan Livera 01:15:16 

And so then I guess green light is also dealing with backups for. The user, right? Yeah. 

Christian Decker 01:15:21 

So we are actually creating backups. that we then give to the users in the case of if they want. To off board. 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 backup and they pick up exactly where they left off essentially 

Roy Sheinfeld 01:15:45  

I think the fact that you’ll see is. Similar hybrid approach server assistant software coming from LDK as well. Backups ability to have like a multi device environment, ability to have multi app environment. Require your server software, so I think that again everything is going to be very blurry on what is it. The one take away from this post that the there’s no more nodes, there’s just different services that are composed differently on different devices. 

Stephan Livera 01:16:15  

Yeah, gotcha. Yeah. 

Christian Decker 01:16:16 

And  there is a lot of interaction between us, like Roy mentioned before the LDK guys are building a system called V. Access to synchronized state across multiple instances of their software and 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 are not stateless. And so we needed a signer state synchronization protocol where we could say OK here is my current state and every signer would get a copy of that state along with the request. Tests verify against that state and then feed that state back so that is something that we knew we had to build and talking to the LDK guys we found out that oh 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. 

Stephan Livera 01:17:26  

Yeah, I guess one other interesting implication here is it hopefully. And we were talking about this earlier custodialism versus non custodial ISM 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. 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 stacked dot news and have a little custodial balance there. You might have found an app with a custodial balance there. 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? 

Roy Sheinfeld 01:18:17 

All that you’re doing. Christian with the Green Network and asset breeze with the Breeze SDK work is there’s no such thing as a custom. The Lightning is Bitcoin. Bitcoin is non custodial, they’re like. And any. Other terminology, I think it’s just smoke, smoke and mirrors. Everything is like if you want to use Bitcoin as a medium of exchange, we need Lightning. The way to do Lightning is only. 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 a non castle 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 green light 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 Twitter land it is complete FAD there is. There’s a lot of non custodial usage of Lightning by end users and I think R SDK and the work that we like is doing the work LDK are doing will take Lightning to the next level and you can already see example of that with the. Fitting in well it. I don’t think we’re far from a future where all the services will use better, non custodial infrastructure and non custodial Lightning will be like the first default solution in implementing end user products. I think we’re very close to that feat. 

Stephan Livera 01:20:13  

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 fee to get into the next block in Fiat terms was well, I think it was like 500 Seats per the buyer or around. $50.00 Do you think 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 you know to? 

Roy Sheinfeld 01:20:48 

There’s always a price that makes sense. That’s what if you have conjunction in the mempool, and if there’s a lot of demand for on change transaction, it only infers more demand for Lightning. So it’s better to open the channel no matter what. Like let’s say it’s a. That’s why I said before. The challenge is a volatile field environment, not a higher environment, because in a consistent type environment it always makes sense to open a Lightning. Channel if you’re making multiple Bitcoin transaction, 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 Bitcoin. If you’re not interested in Bitcoin, no, it doesn’t make sense. Go and find another solution like USD or another token to do your transaction. If you want to do Bitcoin the way to optimize your spending on fees is only by Lightning. 

Stephan Livera 01:21:52 

Christian, anything to. 

Christian Decker 01:21:54 

So I just want. To go back to the custodial versus non custodial thing and add maybe 1 facet namely that we as a Bitcoin community have a tendency of blaming or shaming the user. Choosing A custodial solution over a. Non custodial solution. But we also have to. You 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 green light, one of the goals was essentially to see how far can we push the non custodial. Sure, because I want to have a a system that is as easy as it can be, but not easier. And being a bitcoiner I definitely do not feel comfortable holding on to user funds. So having a custodial option is something that I would never be. Possible with, but I have to be fine with users potentially choosing a custodial options that might. Be easier to use I should take that nod as a negative for the users. But I should take that as my lack of usability that 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 sort of providers of a service is 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 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 custodians and not shout at the users that didn’t know better. 

Stephan Livera 01:24:05  

And I think 1 interesting area that people will 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 and maybe Bolt 12 is perhaps part of the. Cancer that the non custodial? 

Roy Sheinfeld 01:24:19  

That’s part of asynchronous payment that will allow us to support lacking 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 Bree is, for example, the Breeze app currently doesn’t support lighting addresses. Addresses is because we don’t have a reliable way to send users funds when they’re off. Line and that is the primary use case of a Lightning address. Once we’ll have a good infrastructure in place, whether it’s through mobile notification in the green light environment or via the protocol changes that are expected and implementing the asynchronous payment, we will implement Lighting addresses in the non custodial fashion. 

Stephan Livera 01:25:13  

And so just turning to Lightning protocol staff 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? 

Christian Decker 01:25:24  

All of the above. 

Roy Sheinfeld 01:25:27 

Well, yeah, we. We mentioned asking for payments. I think there’s an area of the exploration and research and discussion that is going on right now around stackless payments or channel jamming that I think is very important for Lightning. So I would say stackless payments is important asynchronous payments for me. It’s a top priority and I think improving payment reliability is something that is constantly being researched and being improved shut out to L&D on the work that they’re doing on routing algorithms. I think there’s more room for improvements. On the reliability of routing. 

Christian Decker 01:26:14  

I definitely do have to agree on reliability and it is worth mentioning Rene Picard, it’s min cost flow solutions and overpay solutions, so. Those are all ongoing experiments and we hope to support those efforts by building out the infrastructure to test them out in the wild and provide sort of the verification metrics to see if A or B works better besides those of course. I do have my oldies splicing and L2 or L and symmetry as it’s now called and both of these are progressing nice. And so hopefully, hopefully we will have them soon making it, making it easier to manage your channel funds with splicing, potentially 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 land symmetry being a different proposal. For how to build Lightning channels, but beyond that, 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. states being rather hard to track in the current protocol that’s being simplified a lot by L and symmetry. But yeah, it’s been the same couple of items on my wish list for a while now and some of them are definitely coming through so. I’m definitely looking forward to that and of course async payments is a huge step forward because that is the solution we need to enable offline payments and once and for all. 

Stephan Livera 01:28:22  

And it’s interesting, you guys both mentioned the splicing as well. I know Dusty Demon has been working on that has been he’s doing some talks on that. I saw him speak on that at B C++ and also at Bitcoin 2023 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 to like constantly set up new channels right I guess that’s one of the main benefits. 

Roy Sheinfeld 01:29:00  

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 we have in order to optimize liquidity is very important for running a successful. And the speed business, so the more tools that we have in our tool set, the more we can optimise liquidity and efficiently allocate liquidity to where it actually needed SO11 complete. Case let’s say adversity is opening a channel with an end user node. The user is making a few payments and now there’s a lot of and then 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. You know, 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 means that there are UX implications to the end users to deal with the closed channel, the. That 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 to allows you kind of to reallocate the and the unused liquidity. The liquidity that is not on the end user end but is on the. SPN and to reallocate that to a different channel to a different user that hopefully will be more active than the user that isn’t really being active on Lightning because Lightning by the end of the day the the inherent business model in Lightning is to reuse the. Channel as much of as possible in order to gain the Lightning fee. 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, but it’s not really trivial that users will want to splice in order to pay an on chain address. 

Roy Sheinfeld 01:31:15  

I think swap makes sense if users want to keep the channel open and they need an inbound liquidity. So it’s not that trivial, but definitely the ability to, for example, open a channel directly without the swap to splice in a channel from your own chain balance. That’s definitely another tool that we need in our. Tool set right here to improve. Move the user experience. Right. 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 the without their reverse submarine swap is another tool, so spicing super important by the way, just maybe we haven’t mentioned it Liquidity management is still ongoing topics we there are suggestion of doing negative fees there are suggesting and doing of adding inbound fees on top of outbound fee outgoing fees. So I think we’ll see more movements on liquidity allocations in general. 

Stephan Livera 01:32:15  

So I guess bottom line. And 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 tool set 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 L. Fees and maybe that can bring the fees down a little bit on the margin, let’s say it’s not going to be you know totally but on the margin. 

Roy Sheinfeld 01:32:48  

And it’s not about covering the cost. LSD is gonna be a very lucrative business. It’s about making money. It’s about generating revenue. The revenue is being generated by augmenting the traffic in the Latin network like this, this defensive behavior we have in lighting like to save cost. You don’t need to be defensive about the 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 to augment the lacking traffic in order to make more money, and in this in return I’m a I’m a I’m a I’m a believer in a free market. This will in return will lower the cost for end users because we’ll have a competitive environment where different MSDS are competing for. 

Christian Decker 01:33:37  

Yeah, very much an alignment of incentives here, yeah. 

Stephan Livera 01:33:40  

And so I guess, Christian, from your perspective, you mentioned a little bit about Ellen Symmetry, 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 proof out or perhaps check template verify or something like that? And I guess to give the benefits that could come with having? L2 or L6? Because then you know, we could have benefits in terms of backups and potentially in the future this multi party channel idea. 

Christian Decker 01:34:08  

Yeah. So I think the our last discussion about L2 is pretty much still up to date. We need something like a PO or check template verify plus check 6 from stack to have the. Have the pieces to build out this, this, this. Mechanism sadly check template verify alone does not suffice, which is something that many got wrong initially and me too by the way. So sadly we need checks it from STACK if we get the check template verify. But both of these proposals are very much. Blind and both of these not only enable L2, but also as far as I’m being told, ARC by Barack, so or an improved version of our. 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 working on a proof of concept built on top of liquid elements and liquid of course. And it is looking. Quite nicely and all of the details that he uncovered and all of the sort of small hurdles that we didn’t see during the design of L2 from my 10,000. Feed Birds Eye view of the problem. Those are definitely huge wins that we can reuse once we get a PO or CTV. So I’m optimistic that we’ll get them and we’ll have the knowledge on how to build this stack out. At the time we get them. They’ve been skewing in the background, which I think 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. Longer we let it Stew the better. We have an idea of what alternatives are there. How could we improve each individual of a proposal and which of these proposals do maximize the usability and minimize the risk that we introduce into Bitcoin? And by going down that road, and so I’m quite happy with the state it is in right now, there has been a lot of experimentation and it’s looking quite good. Nevertheless, we still don’t have a PO and CTV, but we’ll get it. 

Stephan Livera 01:36:57  

Yeah, let’s hope so. So 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 elements of liquid. And that will sort of prove it out for people that, OK, there’s commercial demand for it, it’s safe, etcetera. There’s, you know, and there’ll be more work there. Well, so I guess let’s wrap it up there. So yeah, so I guess we spoke about a lot of stuff, but I guess if I had to summarize some of the key ideas, essentially, you know Lightning helps us optimize our use of the chain. Green light is essentially a service from BlockStream, where they can help you run a node for you. Although the node the term node is getting a bit confusing nowadays as you mention. And so the idea is green light helps the builders out there, developers, entrepreneurs. If you want to build a Lightning service, you can use green light as your cloud node. But the user still holds his own keys on his phone or elsewhere, and then Breeze SDK is kind of like a packaged green light 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. 

Roy Sheinfeld 01:38:11 

Just to reiterate on the fact that I think it’s time to build on Bitcoin and I’m still in kind of Jones, Barry the terminology here. Let’s start and build on Bitcoin. I think the tools that are provided right now with the green light. Winter decay and with the breezes decay are very make it very easy for non for non Lightning expert to integrate Lightning payments into their own stock. I’m very bullish about the Lightning. I see the maturity in the ecosystem. I see the traction that we get in the leads that we get from audience that just getting exposed to Bitcoin and Lightning and 1:00 and they want to integrate lighting payments into their own solutions. Now is the time. There’s no need to wait. So go and experiment. You can reach out to me in any medium to kind of get you going with the stock, but like now is the time. 

Christian Decker 01:39:20  

Yeah, couldn’t have said. It better we all Bob build on. So, if you want to give a green light a spin or the breeze SDK a spin, just reach out to any to either of us and we’ll give you a quick tour or the access you need and any assistance 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 Rusty Russell always says we are the engineers building something in our small cubicle. But the people actually doing the innovation actually building the interesting user visible things are. Are the ones that are inventing the, the, these new? And so we are always surprised when something new and innovative comes our way. So keep the surprises coming. 

Roy Sheinfeld 01:40:25  

And we haven’t seen yet nothing yet, meaning currently the way that the way that the ecosystem is is the state of the ecosystem is that the existing solution is in Lightning kind of trying to mimic the existing Fiat solutions. I think the innovation of the power of the innovation. The programmable permission. This accessible money we haven’t really seen the user experience and the transformation it can have in the way that humans interact with the value in general. So I think there’s a lot that we can do and that in the future is like I’m. I’m excited to see what comes next. 

Stephan Livera 01:41:09  

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 hope they’re ready to get out there and build something or. Help promote 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. 

Roy Sheinfeld 01:41:28  

Thank you, Stefan. 

Christian Decker 01:41:28  

Thank you so much for having us. 

Stephan Livera 01:41:30  

I hope you found that informative and educational. Get the show notes to stephanLivera.com/488 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.