{ "episodeId": "SLP521", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "stephan_livera": { "name": "Stephan Livera", "role": "guest", "tag": "STEPHAN" } }, "segments": [ { "speaker": "stephan", "time": "00:08", "start": 8.47, "text": "Hi, you're listening to Stephan Livera podcast, a show about Bitcoin and Austrian economics brought to you by swan dot com. Today we're talking about supporting Bitcoin and Lightning Network using Greenlight with Christian Decker. So if you're interested in building out support to have Bitcoin and Lightning payments, this is a great episode for you. I'm speaking with Christian about the improvements in Lightning's experience. Over the years, as well as what it looks like to use Greenlight and what kind of features you can expect to see. Now, onto the show with Christian. Christian, welcome back to the show. Hey, it's Stefan. Thanks for having me back. So, lots of things going on, obviously we're gonna talk a lot about Lightning and Greenlight and all kinds of things. I wanted to start with, some of the recent developments in terms of what's happening with the Lightning Network. So, as I'm sure you probably saw, River, recently put out a Lightning report, and I think it helped dispel some popular narratives that are out there. I'm curious if you had any, firstly, if you saw it and if you had any reactions to that. Obviously, you're, you know, Level with Greenlight, so I'm sure, it must have been, good for you to see some of the statistics and, points made in that report." }, { "speaker": "stephan_livera", "time": "01:22", "start": 81.57, "text": "Oh yeah, it's, it's very much, encouraging, to be honest, to see how, how nicely the adoption is going on. we've also seen a couple of numbers being shared from Wallet of Satoshi, for example, and, despite these only being sort of select, very small points of vantage that, that, that sort What is going through them, they still have very, very impressive numbers, and, and if we were to look at the network as a whole, it would probably look, look even more impressive but, we, we built in privacy from the get-go, so that's sadly in some sense not possible. But, having, having these companies share their, their numbers is, is definitely awesome" }, { "speaker": "stephan", "time": "02:08", "start": 128.47, "text": "Gotcha. Yeah. And just so, just for context, what's going on here is Sam, Wouters from River, he actually went and asked some large Lightning ser- providers and Lightning companies, just asking them for their data, and some of them gave him that data, and he was then able to basically calculate or estimate, to be clear, these are estimates, how much Lightning usage there is, there is today. And so the, I think probably the most interesting number was the headline number of the lower bound, so the lower bound for the- The number of Lightning transactions per month recently is six point six million, and that's incredible when you think about it, right? Because for so long it's been, you know, a quote-unquote fud line, \"Oh, Bitcoin can only do seven transactions per second, \"and so on. \"And if you just kind of divide six point six million by, you know, the number of seconds in a month, it's-- I can't remember the exact number, but it's like two to three transactions per second are happening today on Lightning, and that's the lower bound. That's not even" }, { "speaker": "stephan_livera", "time": "03:07", "start": 187.35, "text": "Absolutely, yeah. And, and, these, despite being, being estimates, are, are very nice numbers that are very well researched and sort of always give you a range of, of lower and upper, limit and, and I really like the approach of, of, of communicating, the adoption this way. And yes, those are two to three million transactions that aren't, not being sent to the Bitcoin blockchain that we have on top of what you can actually- They do on the blockchain itself, so that's, that's a force multiplier for the Bitcoin ecosystem." }, { "speaker": "stephan", "time": "03:43", "start": 222.89, "text": "Yeah. And so there was also some internal statistics shared, things like payment reliability, and I'm curious if you have anything to share on that or any experience you have, you know, comparing Lightning today, October twenty twenty-three versus the early days of Lightning?" }, { "speaker": "stephan_livera", "time": "04:00", "start": 240.37, "text": "Yeah, so the, the payment performance very much depends on how well you are managing your node, of course. it, the, the uptime has an impact, the, the availability, your connection to the Bitcoin network, has an impact, and, while we're not yet at ninety-nine point nine nine nine percent success rate, that is definitely something that, that we are looking to, where we are cl- looking to To close the gap, by building, building more advanced payment systems, and liquidity management systems, and those include, the mincost flow that Renee, Renee proposed a couple of years ago and which is now implemented as an experimental plugin in core Lightning, with the liquidity adds, with the, with the LSPs, being, building a specification and all of these, complementary system that actually- They help us get the performance to where it should, should be. it's, it's also very nice to see those numbers creep up over time and, and, and getting better and better." }, { "speaker": "stephan", "time": "05:13", "start": 312.94, "text": "So on that, actually, just on the payment reliability question, do you have any, I guess, just from the people you're talking with and the work you're doing, do you-- would you have any thesis on what were the main reasons that payment reliability wasn't so great before? Is it mainly like nodes were going offline, or maybe it's like certain wallet types that people were using were just sort of not able to wake up on time to take the payment? Do you have any, you know, what would be sort of the main highlights there in terms of why payment reliabil-- reliability wasn't? At that rate in the early days, a-and has seems to have improved a lot now." }, { "speaker": "stephan_livera", "time": "05:48", "start": 347.8, "text": "There's probably a combination of factors that, that plays into this, direction. first and foremost, I would say that node operators have, have become more and more professional. the actual liquidity, being provided in the network has, has been better allocated. People are starting to learn, from experience what, what works and what doesn't. And it's this sort of collective learning that, that gets us, that gets us a better success probability, better pay performance, a better time to completion, even, right? We, have seen a drop in Tor-based nodes because Tor has a tendency of, of adding quite a bit of latency. Latency then again brings into, brings with it, the fact that if you- You end up using a channel that is very slow, you are actually cutting into your time budget and you may not be able to retry if, well, this, this payment attempt comes back after thirty seconds, you only have thirty seconds left, to complete the payment due to some timeouts on the recipient as well. And, and so it is, it is an improvement in the network, both in terms of liquidity, but also in terms of pure- More communication, primitives underneath it. And then of course, we have the improvements when it comes to, to providing liquidity on demand, such as LSPs. We do have quite a few LSPs nowadays that can actually open a channel on demand, when there's an incoming payment and the, and the capacity isn't sufficient. But also at the endpoints themselves, we are seeing more and more, improvements with the recipient providing ra- Out hints hinting at, hey, you might want to try this path because there is liquidity there, but also on the sender side, and particularly the sender side, where we are building better and better models about where is the liquidity in the network, what are our expectations, and how can we, can we make use of that to perform our payments. Gotcha. So" }, { "speaker": "stephan", "time": "08:05", "start": 485.09, "text": "it's not really one answer, it's, it's, it's, it's a combination of all these things. And, you know, I remember in earlier days, you might try to route a payment and it Would say, \"Oh, route not found,\" you know? And then, you know, it could be that, you know, because in the earlier days, you didn't-- we didn't even have MPP, so the payments couldn't even be split. So you needed that exact amount across every hop in the route, for that recipient to be able to take that money. And nowadays, you know, payments can be split, payments, you know, there's all these, all of these aspects have come to make it better. there's another interesting idea that, I think A lot of payments that wouldn't have been viable on chain, which is an interesting idea as well, right? Meaning, so just spelling that out for listeners, the on-chain payment fee, if you were to do that as an on-chain payment, it could have been five dollars, ten dollars, especially in the recent fee spike with the ordinal inscriptions stuff. And These people were still able to transact using Lightning, whether that's zapping on Nostra or it's podcasting value for value, or whether it's Geyser dot fund donations, or whether it's, you know, payments to and fro the Lightning supporting exchanges. I think that's another interesting area where Lightning is enabling more kinds of payments that weren't viable before. Do you have any comment on that?" }, { "speaker": "stephan_livera", "time": "09:22", "start": 562.05, "text": "Absolutely, and, and that was one of the goals, we had when we set out to build the Lightning Network, there was, there was the real time aspect that could open up new use cases that simply weren't feasible on, on chain. There was a scalability aspect where we could say, hey, all of a sudden we can do tiny payments, we can do machine-to-machine payments, we can do, signal payments, right? Where, where you-- the payment isn't the actual thing going- Going back and forth, but you're actually attaching a message, very similar to how many of the, of the early chat apps were working, was essentially to, to piggyback a message on top of a tiny, tiny payment of, maybe one Satoshi or one milli-Satoshi. And, these use cases were simply not possible back, back on chain, and, that is also an aspect that, that renders the, renders Lightning, an excellent complement to To the on-chain payments, because we-- they, they have different trade-offs and different use cases might need the, the one or the other depending on their own requirements And so it's less about on-chain and off-chain competing with each other, rather than, essentially Lightning bringing, bringing on board many, many new use cases that are interesting to, to different users and, the overall system becomes a, more welcoming and one more flexible system that, that people can build applications on top of" }, { "speaker": "stephan", "time": "10:57", "start": 657.16, "text": "Yeah, I think the key point you mentioned there is the instant payment aspect. I think, you know, people said a lot of things about Lightning, whether it's, you know, it's meant to be cheaper and faster and all this stuff, but I think really That is the ultimate thing, is the instant confirmation or not, not needing to wait for a confirmation. Whereas, you know, in years gone by, people would do things like, \"Oh, hey, here's my Bitcoin address, Christian, make a payment to me.\" And people would do this sort of awkward dance of one, you know, someone having to wait for, significant for, for enough confirmations, and it, it just kind of made it really awkward, and people could overpay or underpay the amount, whereas with Lightning, it's, you can have a set amount. If, if" }, { "speaker": "stephan", "time": "11:39", "start": 699.06, "text": "You don't, we don't get this kind of overpayment or underpayment factor, we're not waiting, so there's a lot of ex- experience points, that are improved in a lightning user experience, and in some cases, you might be willing to pay more for that because you want the instant confirmation. So that's also an interesting angle. so let's get into Greenlight. I know you guys are recently launching that out, and you've been going through a process so far with, let's say, earlier testing. So tell us a little bit Launch, and how things have gone there?" }, { "speaker": "stephan_livera", "time": "12:12", "start": 732.06, "text": "Yeah, so, we announced Greenlight a couple of, a couple of years ago. Back then, it was still very much in closed beta with a, a couple of handpicked, partners with whom to, to, develop, and, these early learnings helped us, a lot to, to refine, the APIs and the libraries we provide to, to talk to Lightning, to, to greenlight, and, and we now think it's, time for us to sort of open up this, to the general public by, by essentially saying, \"Hey, if you are a, somebody who wants to build on Lightning, or you want to run your own node for your own use case, then, You can essentially just, sign up on, at greenlight.blockstream.com, get a certificate. The certificate allows you to create up to one thousand nodes for free, and, then we, and then you can start hacking and developing your, your application on top of, of Greenlight without having to pay a sim, a single dime. the announcement we, a-and that is pretty much the announcement we did last week. and the important takeaway here is that we wanted to assure, prospective developers and, and users that they won't wake up to a surprise bill by essentially providing a very generous free tier and, assuring them that if, if they start building on top of Greenlight, that would, that would be something that, that lasts and that, remains a way available for them, for the foreseeable future. and, if people go beyond those one thousand free nodes, if you, for example, have a very ex- a successful wallet, or a very successful service, you might want to, reach out to us. We are, we are looking to learn about, about the usage patterns and we, and, what it would, what it would cost to, to operate such, such a system, and therefore we're We're very open to, to feedback when it comes to, to these, things, and, we'd, we'd be making, we'd, we'd be coming up with a custom pricing model for you, in a way that, that allows you to build out, your, your client without hitting, hitting limits, and for us to be able to, assure you that we, that we will provide the service, as it is, with the same performance and guarantees, as- As, as you have access, right now." }, { "speaker": "stephan", "time": "14:59", "start": 898.51, "text": "Got it. And so typically that's the free tier, what we're talking about there is the one thousand free nodes, that's the nodes operation, but that, that's distinct from the LSP, right? Like to get channels opened and things like that. Correct. That's another thing where either the, in this case, you know, Greenlight's customer is going to have to, you know, either provide their own LSP, be an LSP, or pay an LSP, or, you know, I guess you, are you To find an LSP to pair with Greenlight." }, { "speaker": "stephan_livera", "time": "15:29", "start": 928.79, "text": "So, w-we're not running an LSP ourselves, and that's for, for good reason, because many of the attack scenarios in the Lightning Network are only possible when, when you have essentially the node and the, and the counterparty on the other side of the channel collaborating. And so we definitely don't want to have both endpoints, under our control, just like we don't want to have custody of, of user funds, we don't want to, want to, have that risk essentially. and so what we, what we currently do is, we are building out the, the LSP specification for Core Lightning. and since Greenlight essentially runs just Core Lightning on, on our infrastructure, those features will be available eventually. But if you need, an LSP right now, the, the team over at Breeze is, is building out the Breeze SDK Which essentially wraps the, the Greenlight, client and, and integrates with their LSP, essentially, allowing you to, even without any channel, just create an invoice and the channel will be established on demand as soon as somebody tries to pay that invoice. there's a bit of magic going on there for payments for the LSP liquidity and stuff like that, but that's all taken care of by, by, Greenlight and the Breeze SDK. So, for end users, it becomes really easy to essentially just open the app, create an invoice, and it, and somebody paying in the background will just happen automatically." }, { "speaker": "stephan", "time": "17:10", "start": 1030.5, "text": "Got it. And so then the Greenlight customer in this case may be a person who's building a wallet or maybe a business who wants to be Lightning enabled. And so that-- these are, these would be some of the main uses here, right? Like, w- What, what, who are the main people who you're envisioning as your customer for Greenlight?" }, { "speaker": "stephan_livera", "time": "17:31", "start": 1051.03, "text": "Yeah, so the goal here essentially is to make it really, really easy for, for developers to integrate with Lightning. And I, I don't think I'm, smart enough or creative enough to come up with, with the coolest and best use cases. but I am here to provide you the ability to, to integrate with Lightning if you already have an idea. Yeah. And as such, I ob-uh, obviously will always, mention wallets and chat applications because those are the use cases that, that we've already seen. But, there is a multitude of, of systems that might, that, that might benefit from, from being, lightning con- connected. take, for example, Nostr Zaps, that- That is probably, more of a social media application, but it still benefits from, from the fact that, that you can just call, call an API on some server and be able to, to push over some sets to, to somebody that, that has has posted something that is interesting to you and that you would, that you would like to tip, and, essentially by making it easy to integrate with Lightning, we are also broadening the scope of who can build, build applications either on top of Lightning or integrating them with Lightning, and I think the future will, will give us quite a few interesting ones, to see." }, { "speaker": "stephan", "time": "19:05", "start": 1145.31, "text": "The lead sponsor of this show is Swon dot com. At Swon dot com or using the Swon Bitcoin app, you can conduct safe and easy Bitcoin buys using a recurring purchase plan or a smash buy. Swon also offers free automated withdrawals to self-custody. Now, if you are a high net worth investor and you're looking to buy a larger amount of Bitcoin and you want some more hands-on service, check out SwonPrivate dot com. This is a service where you will have a dedicated concierge, a person you can pick up the phone and call, you can get additional and extra guidance Guidance around things like Bitcoin investment, custody, accumulation strategy, support for retirement, trust, and corporate accounts, as well as receiving original Bitcoin and investment research. So if you wanna sign up and start stacking with Swan, go to swan dot com slash livera. And now back to the show. Yeah, interesting. And so, yeah, I think the obvious kind of, the one that probably sticks out to most people is just like if you're trying to make a Lightning wallet and you need, you know, you wanna make it self-custodial and you don't wanna run the actual node infrastructure for those users, then Greenlight is obviously a pretty obvious fit in that case, and then I guess you could sort of see it like, okay up to one thousand users, end users that is, would be free, and then above that, that's when you need to, I guess, you need to figure out a business model for that wallet so that, you know, I, I obviously you, you've gotta, everyone's gotta get paid somehow to make this work, and so I guess, yeah, it'll be interesting to see what kind of models come out there for monetization. Maybe in some cases it's, you know, it's more simple, maybe it's like a business just wants to onboard to Lightning, and maybe they have different stores, and each store has to have its own node, and that might be another example, where that store needs to, wants to, or wants to, let's say, have their own" }, { "speaker": "stephan", "time": "20:55", "start": 1255.15, "text": "but, but I guess I'm curious, what do you think? Do you think that would be a plausible setup, or do you think it might be, you know, maybe certain places would just sort of have one node that does all of their stores? I guess it's all, it's all open at this point, isn't it?" }, { "speaker": "stephan_livera", "time": "21:07", "start": 1266.62, "text": "Absolutely, it, it, it very much depends on, on what you would like and, and essentially the flexibility that we provide is, is both a, an advantage for the end user, as well as the developer itself, right? if you, if you go with one of the classical models where you essentially bundle the node with the application itself, you all of a sudden have a node per application, and that means that if you, if you want to try some new app, you, you, you just want to see, hey, this, this chat app works different or this Noster client looks, looks a bit better. with a bundled node, you would have to tear down, some, some other node in order to get the funds, move them over, recreate channels, and essentially now start ma-managing liquidity on yet another node. And the fact that with Greenlight you can actually share the node, among as many applications as you want, it makes it really easy for end users to essentially just test a new app out and they're For also for developers to get, to get testers, because it's less of a time and less of a money commitment now to actually try out a new application. and then there's the other dimension, right? We might have a single app that has many, many Bitcoin backends, for example, if you run a retail store that has many different locations, you might, you might want to give each of them, A, a separate node, and so each retail location manager would have their own nodes. And even then, there's the, there's the multi-client aspect where you could give, multiple people give, give them access to the same node, but with different access permissions, right? So the point of sale, for example, could, be allowed only to create invoices and, and check if an invoice was paid. And then there's the back office that, that can send and receive. And then you maybe have the accountant that has a read-only access, but that, that is actually assured that it is seeing every, every movement of funds. And so there again, we have this, we have the structure where multiple clients are actually talking to the same Lightning node, and then we can, you can decide if you want to have a Lightning node per store location or a Lightning node for the entirety of, of, of, Walmart or, Even go, go even more, granular and have different, different parts of the shop have their own, their own lightning node. So essentially the-- there is no limit to the flexibility of, of how you can set this up. we just provide a core lightning node instance running in the cloud and that is reachable from, from wherever you want. And, if you want to take that node and, we, and s- and something is preventing you from, from, implementing your perfect scenario, then, we give you the opportunity of, of exporting the node and running it on your own infrastructure where you can then fully customize the node however you want." }, { "speaker": "stephan", "time": "24:19", "start": 1459.17, "text": "Got it. Okay. And so, yeah, so the idea is to have self-custodial nodes to, you know, let developers build in a way that's more easy rather than try to, trying to have to do everything themselves. So I guess, In some ways, Greenlight has similarities or comp- i-is competing with other like Lightning providers in the industry as well. So people like, I'm thinking Voltage or perhaps Lightspark, kind of playing in a sort of similar space. Whereas, let's say somebody using like OpenNode or eBEx Mercado is different because that's more like a custodial provider of just like merchant services, whereas this is at a more, let's say, generalized level that you're helping run the node infrastructure for people. People, but in this case you're running the node, but not the LSP, so I guess that's one other kind of, distinction." }, { "speaker": "stephan_livera", "time": "25:08", "start": 1508.28, "text": "It's just, it's just a separation of concerns that we, that we, that we'd rather like and that we would like to, to maintain. It could be that, that we offer an LSP of last resort for For people where that, that don't have an LSP offering out there, but, it really is, the LSP of last resort, so to speak. I think the, the comparison with, with Voltage and Lightspark and OpenNode, are, are definitely valid. But there's, as, as, as always, there's a bit of a spectrum of, of, of custody, right? And, for, Lightspark and Voltage, the keys are still on, on the hosted infrastructure, whereas with us, we, we- Physically keep the, the device that is holding the keys is under, under the control of the user. And so I always say if, i-if any of, of the other offerings do get the non-custodial, flag, we will definitely get it because we, we essentially provide an even stronger, stronger system, where the operator can, can do even less. And if the operator can do less, an attacker can also do less." }, { "speaker": "stephan", "time": "26:26", "start": 1586.28, "text": "Yeah, interesting. Okay, and that's, that's a, that's a fair point, I, you know, hadn't, really thought that through as deeply as you had. and so with the, node spinning up and spinning down, as I understand, this is something you have built into the Greenlight system as well. So the idea is that the node can sort of spin up when it needs to and then come back down. Can you explain a little bit how that's working and how you make sure it, it is able to come up on time?" }, { "speaker": "stephan_livera", "time": "26:51", "start": 1611.2, "text": "Yeah. So, the core observation in, in, in all of, the system is that essentially the keys being at the user means that if the user isn't present, the node can't actually do much. And so we take that opportunity to essentially just shut the node down if, if it's not being used at the moment. And that, essentially just means that, a couple of minutes after you last interacted with a node, we will, we will take the node, shut it down gracefully, and release the resources for other users' nodes. and this, this gives us a, I would say two to three orders of magnitude more use out of the resources that we are committing to Greenlight, and that in turn then becomes, cost savings that we pass on to, to our end users. and, the way that, that we spin up on the other hand is, is, is much more interesting because, that is, that is very much the critical time, right? The user has just opened the app and wants to talk to, to their nodes. So, we need to ensure that, that in the least amount of time possible, the node is back fully functional, connected, has a full view of the network, and can pro- Form payments in case the user is scanning an invoice, when opening the app. And so what we do there is essentially, we have, assigned each node a unique, URL, essentially gl, node ID dot notes dot block, gl dot blockstream dot com. And whenever you try to contact that, that endpoint, which is specific to every single node, what we will We'll do is we will internally see an incoming request, we will check, hey, is that node running somewhere? If it's not running somewhere, is there a slot where we can essentially start that node up? We will start the node up and then connect, and forward the connection to the, the now running node. And so from an endpoint, end user point of view, it, it is absolutely seamless. You are connecting to your node. Sometimes it takes a quarter quarter of a second longer because we are actually spinning up the node, and sometimes it's immediate, but this slightly, delay is the only thing that, that you should notice. and by doing that, we assure, we ensure that the node is available whenever you have, the app open. And while testing with, with outside developers, we found that, this, this fact that, that the node is actually spinning down often gets Forgotten about, the developers integrating with Lightning often have the feeling that the node is actually running twenty-four seven despite it not being running twenty-four seven, simply because it is so easy to actually spin it up again." }, { "speaker": "stephan", "time": "30:03", "start": 1803.46, "text": "Yeah, and I presume, as you mentioned, each node has a unique ID. Is there some kind of a shared infrastructure? Like as an example, do the nodes share like gossip sync data? So as an example, Lightning nodes, they have a view of the network and they wanna know, okay, what are the other nodes out there and what's my view of the channels? And so in the Greenlight context, are the nodes sharing that view?" }, { "speaker": "stephan_livera", "time": "30:27", "start": 1827.42, "text": "pretty much, yeah. So there is quite a bit of shared infrastructure. For example, the databases are, are being shared, shared in part. We have watchtowers running that are also part of the shared infrastructure. We have a routing node with, a routing server which maintains a coherent view of the Lightning network and, then synchronizes that view down to the node in, when, when it starts up. And we have, a whole, what I like to call the circulatory system, in the form of, our Bitcoin, backend infrastructure where we, where we can distribute, Bitcoin information very quickly to all of the different parts of the system and of course also, inject new transactions into the Bitcoin network Work in a, in a very reliable and very, fast way. And since you, since you zoomed in onto the, onto the gossip, that is one of the most critical parts, during startup, because, an up-to-date view of, of the gossip is paramount for, for our chances of finding a successful payment. And, so it wouldn't be much use if a node was offline for a couple of hours, now it comes back, and now it still uses an old view of the network. And therefore, we, we went and, built this routing server that aggregates information, aggregates views from, from all the different, nodes running on a number of different networks, builds a cohesive view of, of the network, and then compresses it and streams it down to, to nodes When they start up. And so, in a matter of seconds after startup, the node actually has a very, very up to date view of the network, and that, that serves to maximize the chances of the payment being successful. and so yeah, that's, that's definitely one part that we have customized for, for Greenlight, that, in case you're off board is less useful for you, but we're considering to, to, to, open up access to the rapid gossip sync, implementation too, just because it turns out it's really useful." }, { "speaker": "stephan", "time": "32:51", "start": 1971.22, "text": "Yeah. And so as I understand, that might also be useful in a range of contexts, as you said, the payment reliability is also an important- Important point. But even things like knowing if your channel has been closed or knowing if, you know, having the most up-to-date state of what's happening even on the Bitcoin on-chain level, because you just, you just wanna make sure you're sort of, you're on stable ground here and you're not sort of operating on this old view, and I think- The other question, and maybe this is an important topic, I'm curious if you have any thoughts on this, is mobile nodes. Right now, in our recent episode, you know, you, myself, and with Roy from Breeze, We were talking about how, you know, mobile nodes and so on. I think it's like, let me put into an example. So as an example, I think with Breeze, at least as it is today, as an app, if you haven't used Breeze, the app, for a little while, then it will then, you-- and you open it, then it'll have to do that sync up process, because it is using like the Neutrino style filters and it has to sort of understand the latest state of the chain. I guess in the green You won't have to do that, and so it'll just sort of be like, you open it up and it'll already be synced up per se. So I, I guess that's gonna enable an easier mobile user ex-experience. So can you maybe compare for us the mobile nodes that try to do it all on the phone versus the mobile Greenlight experience? So that might be an interesting point of comparison." }, { "speaker": "stephan_livera", "time": "34:21", "start": 2061.1, "text": "Oh, very, very different, world views there, but, we'll, we'll see which one, ends up, winning in the end. so one of, one of the issues that, that, that we have with mobile nodes, as you correctly point out, is that, for example, they can't run in the background and therefore can't synchronize with the, with the, with the network. And if the node happened to be offline for a while, then, well, you're starting to lag more and more Time next time you wanna use it. With, Greenlight, on the other hand, we can actually start the node without the signer being present and, and that means that the node can process blocks and identify, changes in, incoming funds or outgoing transactions being confirmed or channel closing or channels being funded and, and the funding confirming and stuff like that. So having the The ability of, of starting the lightning node without the signer present means that we can ensure that your node is actually up, as, as up to date as possible. We allow for up to six blocks in, of lag, and then we end up essentially just starting your node quickly, synchronizing the blocks, and if nothing happens, we will, we will then, put it to sleep again for you to, to essentially wake up when, when you ne- when you need it next time, and most time you'll- You will have to wait, to synchronize those six blocks. Those six blocks are also being served out of, out of our, infrastructure we mentioned earlier, out of our shared infrastructure and will be, will be processed by, the node running on our infrastructure too. So there is very little, very little latency and we, we can process blocks, relatively quickly, so a couple of seconds and you will be up to date, no matter how long you kept, you kept your, your Your phone app closed. The other thing that, that mobile phones can't do and we can do because we have this very active monitoring system and, and we do, start your node from time to time, is actually reach out to the signer and say, \"Hey, there's something happening there, please come, come see and, and help us resolve the situation.\" So for example, if one of our channels closes on chain, we might- We might need to, we might need to react, based on that, and therefore summoning the signer, using a hypoc system that we are currently implementing but, will hopefully, be, allow us to summon a signer in case we need it, and, with the signer we can then process the, the event, have the, have the re- appropriate reactions if it, for example, is, is, If it's a cheat attempt, the watchtower will, will react, but also the node itself will essentially get a signal saying, \"Hey, your attention is required. Please, please help us resolve and get past this, this issue.\" And, this, for example, wouldn't be possible for a phone because the f- the, the bundled node with the phone, because the phone would have to wake up the node, at regular intervals and, and synchronize with the blockchain. To even identify that it is being needed, whereas we have the server side assistance where you can, where you can essentially track stuff on behalf of the user and wake it up, if, if there's something that, that needs attention. And then there's a whole lot of trade-offs we can, we can, we can probably spend an entire hour talking about trade-offs of, of mobile and, and, and bundled versus non-bundled, applications. Some of them we mentioned already, right? having the ability of having multiple clients attached to the same node, not having to share resources between those nodes, whether that's, your own time managing liquidity or whether that's actual funds being split up across a, a number of nodes. And let's not forget the recovery story, right? I'm, I'm a, a passionate sailor and I've had my fair share of boating accidents. And if your node is, is essentially running on the phone, well, that boating accident, losing your phone, might actually cost you quite a bit of money. Because the seed isn't sufficient to recover all of your funds, right? And so, with us, it essentially is just regaining access to your, to your node and v- having a signer be, be reestablished, and you can do both of these just starting from the seed that you used to register the node itself. And so the recovery and safety, story for, for a hosted solution is, is much, much different from, from a bundled node, for example." }, { "speaker": "stephan", "time": "39:29", "start": 2368.67, "text": "This show is brought to you by CoinKite dot com, the creators of my favorite Bitcoin hardware device, the Coldcard Mark IV, and this is an ultra-secure device that you can use to secure your coins with a range of features. And if you haven't been following, they've got a new firmware release five point two point zero with a range of new features. This is the first Bitcoin signing device to store- Multiple seeds, and you can switch between them effortlessly. This might be ideal for you if you're a custodian, maybe you're holding grandma's stash, if you are a developer, you're doing experiments, you need secure key handling. So for example, if you're doing TapSigner backups, there's all kinds of new features here. So with the Seed Vault, you have the new feature of pspTV2, you have the new lockdown seed feature. There's just so many features and ways that you can use the Coldcard to improve your security. So go to coinkite dot com and This show also brought to you by mempool dot space. This is the leading Bitcoin and blockchain visualizer in the ecosystem. Bitcoin is a multi-layer ecosystem, and you can use mempool dot space to see multiple aspects of this ecosystem, whether that is the mempool, the blockchain. You can search transactions, you can target the fee for your transactions, whether you are looking for a high priority or medium priority. You can search the Lightning Network and see different Lightning nodes out there, what kind of capacity they have. They even have a mining dashboard, and they are continually rolling out new features. So keep an eye out for the upcoming Mempool Accelerator over at mempool dot space. And now back to the show with Christian. Okay. Yeah, so I guess in that context, it might be like the user has to have, written down seed somewhere, but as you're saying The s- assistance of the server side infrastructure in this case with Greenlight sort of helps them recover without losing stuff basically." }, { "speaker": "stephan_livera", "time": "41:12", "start": 2471.93, "text": "Exactly. You don't, you don't even have to close any channels like you would for the emergency recovery, or, or have some, some real time backup being streamed somewhere. It's all being handled for you, while you stay on the hosted solution. And, the same is, is true for, for one- When you offboard into your own infrastructure, as long as it's your phone going overboard and not your entire Lightning infrastructure, which I think might be more difficult to throw an entire server overboard." }, { "speaker": "stephan", "time": "41:48", "start": 2507.61, "text": "Right. Yeah. That'd be a next level, boating accident. It's like, oh, I lost my Lightning node, at sea. Oh no. okay. and So I know Blockstream recently did a partnership or some kind of collaboration with VLS, Validating Lightning Signer, and I know that's, I think that's gonna be part of the Greenlight, solution. So can you just spell out a little bit about VLS there?" }, { "speaker": "stephan_livera", "time": "42:11", "start": 2531.15, "text": "Yeah, so, the Vilas project by, by Defrandem and Ken Cedric, I know you had Ken on, on recently on the podcast. they're, they're excellent, people to work with, and, we, we had a blast. The idea for, for the signer was essentially that we can't have a signer that, that blindly signs off on, on just anything we send it, right? Because then, having access to the node would be- sufficient to do whatever you want despite technically the keys being, in the hands of the users. And so we needed to, to ensure that, the signer is smart enough, to enforce, to enforce policies. and, the VLS team, we found out while doing our own research, was building exactly that and was already at, at a very advanced stage with their VLS, signer, based on LDK, but, implemented, very closely to Core Lightning And so it, it just happened that, that, that we found each other, they had, been inspired by Core Lightning's, HSM-D, module. To, to look into bu-uh, building a validating lightning signer, and we were looking for, for a signer that could, that could essentially perform these extra validations that we needed for, for the node operators or attackers to be sort of locked out of, of, managing the funds for users. And so what they have is they have re-implemented part of the Lightning logic, enough of the Lightning, protocol to verify that whatever, whatever is going on matches the expectations that, that the policy set forth. And these policies could, for example, be, hey, you're only allowed to, to spend ten dollars worth every, every day. you're never, we will never sign an old commitment transaction, which would- Would could be used to cheat, and that if we perform a payment based on an invoice, we s- we never exceed sort of the amount, and all of these ver- validations. On top of those, we then built, what we call the end-to-end verification, where we say, VLS is very good to, to verify policies that have, that it has con- been configured with. but what we want instead is, to have an additional layer that ensures that every single command that touches funds, was actually initiated by an end user. And so that's where, that's where, where we, where the end-to-end verification comes in. Each client essentially has an identity and is used to sign off on the user's intent," }, { "speaker": "stephan_livera", "time": "45:23", "start": 2723.18, "text": "Expressed as, as a command call, and this command is then sent to the node. The node computes the cha-state changes that are sort of needed to perform this command, and then the command, as well as any signature request that, that is needed for the signer to sign, is get-is getting passed down. So the signer has the entirety of the context, who initiated the command, what was the command, and then it verifies, hey Does this match the expectations that I have, and is this, is this user actually authorized to initiate this payment? And so by, by essentially closing that loop despite the node being in the middle, we can ensure that, that the signer has the context and can independently verify that whatever it is signing off on actually matches the user's intent. And so that is, that is the core contribution that we built on top of, Of VLS, but VLS was, was an excellent basis to, to get started from, and there, and we spent a lot of time actually brainstorming together about how we can, how we can perform, certain things. And one of the, one of the, things that, that we brought to the table there, for example, is the, validating signer, state server. so I mentioned before that you can have as many frontends as you want, but you can also have as many signers as you want. And the advantage of having multiple signers is that the node remains functional as long as one signer remains online. Now, signers aren't stateless, they have to remember, oh, I, I, I processed, ten satoshis worth of, of HTLCs and the invoice is asking for ten more, so I, I will, I will be allowed to essentially," }, { "speaker": "stephan_livera", "time": "47:25", "start": 2844.74, "text": "Sign off on ten additional satoshis. And so having many signers, we all of a sudden have a distributed system where they need to somehow communicate about the state that they, that they are collaboratively managing. And so with a validating signer state, server, we can push state from one signer to the next through the use of an external server and ensure that, that we always, as, as signers, we always agree what the current state is and what What we, what we should sign off on and what we shouldn't sign off on." }, { "speaker": "stephan", "time": "47:58", "start": 2877.88, "text": "Gotcha. Okay, yeah, interesting. So it helps you stay in sync then across different signing devices. and, one other question I think people might be wondering is, obviously Greenlight, you know, it's Blockstream, it's Core Lightning, so So presumably then Greenlight, you know, inherits all the features that Core Lightning is, you know, taking on. So as an example, Rusty's been a big proponent of Bolt twelve and, you know, splicing, liquidity adds, maybe even peer swap. Are these features things that people could come to expect in Greenlight?" }, { "speaker": "stephan_livera", "time": "48:30", "start": 2909.98, "text": "Absolutely. anything-- my goal is to, is to enable anything built on Core Lightning to also work on Greenlight and vice versa. so, we have essentially taking all the learnings that we, that we, that we learned from the rollout of, of the new, the new API, back to Core Lightning, and for us, Greenlight is very much also a, a project that helps us validate our- some of the design choices, that we, that we did in Core Lightning and, funnel back feedback from the operational side back into the open source project to make the, make the open source project better overall. And so it's, it's very much a two-way street between, between the two projects. And, indeed, we should, we should end up in a situation where, anything that, that was built for Core Lightning can also be, be run on Greenlight. there are still some, some open questions, for example, what do we do with plugins? plugins are very different in, in a hosted setup. for example, we need to ensure that plugins are actually safe to run, that they aren't, just some malicious payload, that somebody else put out there, and at the same time, we need to ensure that, that all of the functionality that a user might want to- is actually available as well. also running plugins alongside with, with a node is just one, option we, we have here. a plugin could, for example, all of a sudden be a web API that we call. And so We, we sort of reconnect the Lightning customization and Lightning extension, world with the, with the well-established world of, of web development and offerings, web services. So I can, for example, see that, somebody might want to use, use the plug-in API that we have in Core Lightning to build an accounting software that automatically gets told about, movements of funds and that, that can present you with a very nice, sort of view of what is happening with your node and Pull that back into your existing accounting infrastructure, for example." }, { "speaker": "stephan", "time": "50:59", "start": 3059.37, "text": "Yeah. Okay, gotcha. and so yeah, so as you mentioned the plugins, so maybe it comes to a point where there's certain plugins that you just say, okay, these aren't allowed because security reasons, et cetera, but all the other ones are allowed or whatever, as long as you've vetted them and they're fine to work, you know, technically. and then in terms of, I guess, technical features and things like that, like as an example, having Bolt 12 support," }, { "speaker": "stephan", "time": "51:24", "start": 3084.25, "text": "benefit do you see coming from that? Like, it means, as I'm understanding it, it means the developer user of Greenlight can build in the function where he, his users, his end users can have Bolt 12 and they can just have like a static QR code to say, \"Take donations,\" as an example, because Core Lightning has that feature." }, { "speaker": "stephan_livera", "time": "51:43", "start": 3103.47, "text": "Absolutely, yeah, and, and I think we already have a vast majority of, of the bolt twelve related, methods exposed on, on the, on the Greenlight API. So, they're, it's, it's available right now, is what I'm, what I'm, what I want to say. ultimately the expressiveness that, that you get for Greenlight should be at the same level as Core Lightning, and that translates into having the same exact- API methods available both on a local core Lightning as well as, as on Greenlight. And so building, building a version that is compatible with both, should be, should be absolutely a no-brainer after all, and, It should open up many, many interesting, use cases, like for example, we hope to eventually have, have access for browsers so that the browser itself can be an app talking directly with a Lightning node, and the, and, a very much browser first, experience should, should eventually be possible as well." }, { "speaker": "stephan", "time": "52:55", "start": 3174.95, "text": "Yeah. When it comes to developers using Greenlight and maybe, I guess, I'm thinking of like the parallel world maybe where they are using VMs and they need to kind of orchestrate or use lots of things at once or spin them down, up and down. What does that look like from the developer's perspective when they wanna use Greenlight and spin nodes up and down?" }, { "speaker": "stephan_livera", "time": "53:17", "start": 3197.16, "text": "So for developers, there's, there's very little to do. They, they can essentially always assume that, there is a node in the cloud. That node in the cloud is reachable, and it's not up to them to, to, to register that, that node even. It's actually the users themselves who are using the apps developed by developers are going and creating their, their nodes, in our cloud. And And, so essentially the only thing that differs from assuming you have a loa-a local core Lightning node is that you first have to call register on, on, on Greenlight. And once you have registered with, with Greenlight, and so that Greenlight knows that there is a node that should be spinning up, if a, if a, if a request comes in, once you've done that, you essentially just, take the li- Library and you tell it, hey, here is the private key, initialize the signer with it, and then it starts spinning up the entire rest. And from there, from there on, you essentially just say, hey, node, get info, node, pay this, node, create an invoice, and, and all of these very simple, RPC methods that, that we expose." }, { "speaker": "stephan", "time": "54:41", "start": 3281.47, "text": "Yeah, gotcha. one other question around offboarding. So is the idea then- So as you've mentioned, the idea with Greenlight is that these potentially end users could offboard that node to their own thing, like maybe they're running an Umbral or a Raspiblitz or something like that. Is that the idea that you could have, maybe there'll be like an app in these node in a box packages, and then you can sort of offboard it to your own thing? Is that the idea or what does it look like?" }, { "speaker": "stephan_livera", "time": "55:08", "start": 3307.98, "text": "Absolutely. So, what we run on our servers is, pretty much a stock core Lightning version, with some minor changes. And, so it is, it is relatively easy for us to take a snapshot of your database, take your node out of rotation so we don't start it anymore, encrypt the, encrypt this backup, and give you a link to that, to that backup. And so you have this bundle essentially Representing the state of your node, and then you can use a tool to decrypt it, and you can then take that, that backup And restore from it without, without incur, incurring any, any sort of prolonged downtime. And right now, it is, it is a bit of a manual process, right? You, you get, you get a URL and then you download it, and then you have to say, \"Please decrypt this for me,\" and, and then you have to set up a database and load it in there. But, I hope that, that eventually we will have, node in a box solution where you essentially just say, \"Hey, export my node, here's my seed, and everything else happens in the background.\" And, this is, this is very much possible, and we actually have a couple of users who've already done it. the advantages of, of doing so are, pretty clear, right? W- we don't charge for notes that, that aren't longer running on, on our infrastructure, and you aren't running your node anymore on a third party that, while untrusted, still has access to some of your- Data for debugging, for example. And so it is, it is very-- and, and we use this price and, and increase in security, an increase in, in privacy to essentially nudge people to actually- Once they, once they've seen what, what Lightning can do for them, learn, invest the time, and then once they have caught up with the status, with the state of the art of running Lightning, to actually take their node and offboard into their own infrastructure. That could be a pre-built light, Lightning node as a box, or it could be their own custom environment." }, { "speaker": "stephan", "time": "57:38", "start": 3457.68, "text": "Yeah. Okay, so, last question, just as we're looking out into the future with Lightning, what kind of features do you think are gonna really move the needle? Like, is it Bolt 12 or is it something else? Like, do you see what kind of things do you see that will really, you know, bring a lot more people to use Lightning?" }, { "speaker": "stephan_livera", "time": "57:56", "start": 3475.83, "text": "probably a combination of many, many different changes, but, let me just, let me just plug some of my favorite ones. so, one of, one of the most, interesting ones that, that I'd like to see that from a user experience point of view is, is the Absolute Number Plus Ultra is async payments. this, this, green light being essentially a system for end user nodes, that are fronted by an LSP are a perfect match for async payments, where, the LSPs of the sender and the LSP of the receiver essentially negotiate, hey, are you online? Can I, can I now forward this payment to you now that you are online? And, and essentially we defer until the recipient, we defer the payment Payment until the recipient is, is online, making, making it appear as if a payment went through while you were offline. And for us, that, for example, is, is a, is a huge win. we are looking into a lot of, smallish core Lightning changes. For example, like I mentioned before, the gossip sync is, is one of the things that is, that could be better. sadly, the gossip Store, for example, is specific to each node because there are private messages in there, and so we are trying to extract them into a separate store such that we can actually share the gossip among all of the nodes and then sort of Add the private gossip back on top. Bolt 12 is definitely something that, that I, that I'm very much looking forward to. It is, it allows us to without adding extra infrastructure like, like LNURL would, for example, allows us to negotiate payments going, going in either direction, have recurring payments, have payments denominated in different currencies. Which, again, from a user experience point of view, it's much easier for a common mortal to say, \"Hey, I'd like, I'd like ten, ten, US...\" dollars instead of, oh, let me quickly take out the calculator and enter all of the zeros that I have to add before I get to satoshis, and then probably have a zero too many or too little, and then you're a factor of ten off and so automating a lot of these conversions, for example, mentioned already recurring payments and, many of these, use cases that are pretty established in the LN URL space already, We bring, back to, back to common mortals that don't know how to run a, a web server, and don't want to trust, somebody else to do it on, on their behalf" }, { "speaker": "stephan", "time": "01:00:56", "start": 3656.76, "text": "Yeah, fascinating. And as you said, I think bringing back that early experience that a lot of people had from, let's say, earlier days of Bitcoin, where, you know, when people were making on-chain payments, they didn't have to think about, \"Oh, my Lightning node being online or the other guy being available at this time.\" They used to, you know, and some people have an attachment to that Level of user experience, which is fair enough for them really, because that's what they're used to. They would just put an address and take a payment to that whenever, and now with asynchronous payments, it can come back to that, like you could have that with Lightning without being custodial and make it feel the same way where you just kind of give someone that invoice, they just pay it, and without you knowing you've, you've kind of received this money offline, especially when it's combined with things like Vault 12, so I think that could be really cool to see, and yeah, it very much goes" }, { "speaker": "stephan_livera", "time": "01:01:45", "start": 3705.34, "text": "back to this, the, to this fire and forget, mentality that we had and still have for, for, for Bitcoin on chain and essentially every payment mechanism that we, that we had so far, right? The moment I press send, I, I stop thinking about the payment I just did, whereas in Lightning, it, it can take a bit of time for the payment to complete, especially if the counterparty is currently offline. And so sort of hiding- Hiding the actual action being taken under the covers is, is something that, that again abstracts away difficulties from the end user and makes it more approachable and, and should widen our user base, as a, as an end result." }, { "speaker": "stephan", "time": "01:02:29", "start": 3749.55, "text": "Yeah, that's a great point to finish on, I think, because, obviously a lot of the end users aren't really gonna think about this stuff, but obviously listeners of this podcast are sort of more developers, builders, advocates, educators, and those people Might be interested to know these things, because that helps them out there when they're building things, doing things, teaching people about Bitcoin and Lightning and so on. so we'll finish up there. Christian, we'll put all the links in the show notes and, thank you for joining me again." }, { "speaker": "stephan_livera", "time": "01:02:54", "start": 3774.43, "text": "Hey, thank you so much for having me, it was a blast." }, { "speaker": "stephan", "time": "01:02:58", "start": 3778.37, "text": "Show notes are available over at stephanlivera dot com slash five two one. Thanks for listening, and I'll see you in the Citadel." } ] }