{ "episodeId": "SLP502", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "validating_lightning_signer": { "name": "Validating Lightning Signer", "role": "guest", "tag": "VALIDATING" } }, "segments": [ { "speaker": "stephan", "time": "00:08", "start": 8.41, "text": "Hi and welcome to Stephan Livera podcast, a show about Bitcoin and Austrian economics brought to you by Swann dot com. Today we're speaking about validating lightning signer with Ken Sedgwick, one of the co-founders of the project, and this is basically about this idea of making lightning more secure. So this project is trying, you can think of it kind of like a- A hardware wallet or a secure element for Lightning, where people use hardware devices and secure elements to secure their cold storage coins. In this case, validating lightning signer is a project that's helping or aiming to help improve Lightning security. So for example, you might have policy rules on your lightning node that restrict how much Bitcoin can flow out of it, and by having some of these rules segregated, it's, it's separation of concerns. So that's what we talk about in this episode, and I hope that is interesting for you in terms of learning about the future of Lightning. If you're bullish on Bitcoin and you think it's the future of money, well, we need ways to make Lightning secure. Now, before we begin, a message from the show sponsors. If you're a technical listener or you're looking to learn to build with Bitcoin, or maybe you're looking for a job in Bitcoin development, check out Base fifty-eight. This is a Bitcoin protocol school by Lisa Nugget, and so this is a great way to get guidance in your Bitcoin developer education. Base fifty-eight has Classes and materials ranging from beginner developers all the way up to expert level classes. There are online classes as well as in-person intensive classes where you can learn in a guided pathway from Bitcoin and Lightning experts. So for example, the upcoming Taproot intensive in-person class is coming up, and it will cover using Taproot, Tapscript, Schnorr, Frost, and MuSig 2. This in-person class is coming just prior to TapConF in Atlanta from the fourth to the sixth of September, and this class is on again in Austin. Austin, Texas, the thirteenth to the fifteenth of November. So if you're interested to learn, to brush up your skills, or you wanna learn about Bitcoin development, go to base fifty eight dot info. Now, when it comes to securing your coins, you need to think about Bitcoin hardware, and CoinKite dot com make the best Bitcoin security hardware. You can get the Cold Card, which is a phenomenal device. It's ultra secure, it has all kinds of features that you can use to secure your coins and get them off the exchange or get them out of custodians. With the In an airgapped way, and, and importantly, you can spin up the new device, i.e. initialize it and get that twelve or twenty-four words without even phoning home. It's not calling back to the manufacturer. You can literally plug that cold card into the wall socket and power it that way and write down your twelve or twenty-four words and have your pre and post pin as well as the anti-fishing code words. So the cold card is a fantastic device and you can use it in different configurations, whether that's single signature or With a passphrase or using it as part of a multi-signature device or setup rather. Now go to coinkite dot com and you can get your cold cards over there with a discount using code livera. Ken, welcome to the show." }, { "speaker": "validating_lightning_signer", "time": "03:12", "start": 192.26, "text": "Thanks," }, { "speaker": "stephan", "time": "03:13", "start": 192.78, "text": "it's" }, { "speaker": "validating_lightning_signer", "time": "03:13", "start": 193.04, "text": "good to be here." }, { "speaker": "stephan", "time": "03:14", "start": 194.02, "text": "So I understand you're working on validating Lightning signer, and I, I think this is an interesting project for Lightning, and, really interested to get into this. But first, let's hear a little bit about you. Who are you, and what are you-- what's your role in all of this?" }, { "speaker": "validating_lightning_signer", "time": "03:28", "start": 208.47, "text": "So I'm, I'm a software engineer. I was a consultant for many, many years. I did a lot of time working on threading and, parallel processing and, throughput and stuff Exciting, but this is even more exciting. So yeah, how I got here was I got into Bitcoin in 2013, it suddenly struck me like, \"Wait, what is this? And, can it be real?\" And then it began to occur to me that it must be kinda real because there's a lot of money at stake and no one's stealing it, so the, the security is at least as good enough to, to, to protect this much money. and then that amount grew rapidly. But it, it was, it was Of, of, of concept for me that I got in, involved and then I, I decided, okay, I wanna do something and, and my goal was to, meet people and learn things. And so I wrote a wallet in twenty thirteen for Android. as I was playing around, I really fell in love with Electrum, the, the Python classic, yeah. And I said, you know, we really need an Electrum for, for Android. Now there was one, you could run the Electrum in some strange mode, but really didn't work A native Android app, and so I, I went off to, to, to build that and, and let's see, so the first thing that happened was I met Dev Random, because he was working on the, on the, Bitcoin J project, which was the Java library that we were using to build such things, and I was having, you know, usual questions and issues that you have when you don't know what's going on, and he was very helpful, and then at the end of a message, he noted that, hey, you know, we met up. I did build a wallet, although over time I decided not to support it for very long. I really didn't want to be the wallet to conquer the world. What I wanted to do was learn stuff and meet people. we then went on and did many other projects. so we did some colored coin stuff in twenty fifteen. We, did a custody company in, twenty seventeen. I hope I'm getting the dates right. and then around, twenty nineteen We started really looking at, at Lightning and saying, \"Hey, you know, we're good at custody for Bitcoin, but this Lightning stuff is really much, much more challenging, and it has a-- some really hard problems in it, and, we think we have the skills to maybe, you know, give the world a leg up on that to try to make it so that, people can make much more secure implementations.\"" }, { "speaker": "stephan", "time": "06:04", "start": 363.68, "text": "Fantastic. And so then, I guess, that's where this idea of VLS validating Lightning signer came up. And so what, what's your role? In this." }, { "speaker": "validating_lightning_signer", "time": "06:12", "start": 372.2, "text": "Well, I'm, I guess I'm a co-founder. but well, Devereux is really the, the crypto guy, and I'm more of the, you know, make it all work, kind of get it all together, kind of completion guy. so we have complementary styles, we're not the same at all, we're different, but that, you know, together I think we get a better thing. So, we both review each other's code, so all of us, you know, we know all of the code that's going in, Security, we're both very conservative security wise. We would much rather see the company fail to deliver a product than to deliver one which loses anyone any money, for example. So it, it's important to, to be rock solid at what we say we do and be conservative about how we think about that. so since we're together on that and on the same page, it allows us to make, good progress on, on most things." }, { "speaker": "stephan", "time": "07:04", "start": 423.98, "text": "I see. And so is VLS actually a company or is it a project or is it both? It's both." }, { "speaker": "validating_lightning_signer", "time": "07:10", "start": 430.0, "text": "It's an open source project Project. So, there really is no significant corporate thing going on, there is a entity which is a, sorry, right, nonprofit, which is to su-support people doing work on it, but there's no effort to make any money, and nobody's getting rich doing this. We're, you know, we're, we're getting by, but it's not, this, this is a labor of love." }, { "speaker": "stephan", "time": "07:33", "start": 452.69, "text": "Okay, understood. And let's, I mean, so let's explain a little bit about, why VLS was created, Lightning, obviously there's an online requirement, and generally for listeners who are newer, the idea with Lightning is, let's say you and I have a Lightning channel together, when we do channel state updates, when I'm, you know, sending a transaction to you or when I'm routing a transaction through, we need to sign new transactions, and which that also implies that the private keys are online. So I guess that's maybe that's the key insight of trying to take those keys and keep them offline, right? So do you want to just explain a little bit about- You know, the, the idea of VLS." }, { "speaker": "validating_lightning_signer", "time": "08:13", "start": 493.48, "text": "Well, you hit the nail on the head. I think the important thing, though, that from where we were coming from is, since we'd worked in Bitcoin custody for a number of years and even did a, a real for-profit company there, the real trick there is to keep everything cold. I mean, really cold. So air-gapped, not connected at all. And so if you're an exchange, a very common number is ninety-five to ninety-eight percent of their funds are just very cold, and that's unquestionably secure and it I mean, as a, as a, as a software engineer or as, you can look through it and go, \"Oh, yes, let's see, that, the stuff's really air-gapped,\" and the number of people who knew-- you need to make sure that no one has sole access to anything and yada, yada, yada. but, but that's a fairly well-understood science and it's really pretty straightforward to do, and a lot of companies are doing an okay job of it. Lightning is a completely different animal because it's just not possible. So if you" }, { "speaker": "validating_lightning_signer", "time": "09:11", "start": 551.1, "text": "And you have a million channels, and, an average channel might have a hundred dollars in it. Suddenly, you have a hundred million dollars online. And as you alluded, in Lightning, the, the funds need to be online, and they need to be-- the protocol requires that you deliver signatures in a timely fashion, sort of all the time. Why is that the case? So even if you're not doing transactions, the fee market changes, and so you sometimes have to rewrite the commitments because you have to rec- recognize different, requirements. Especially fees lately. So it isn't feasible to keep the funds cold. So you take a step back and you say, \"Okay, so what do you do in a security situation when you have to keep funds hot?\" the answer is that you try to make sure that the keys are very, very carefully isolated. So you wanna put them in as secure an execution environment as possible. You wanna have as little code there as possible. You wanna have as few connections to that machine as possible. And I can go, you know, on and on, but we're reducing attack surface, and, you know, the, it's pretty straightforward. The less gaps there are, the smaller the space is, the easier it is to, to prove that there's nothing that can get in. now the ide-- now the idea, Lightning nodes have to be very, very prolific. They're gossiping, they're routing, they're doing all these things which involve talking to many, many nodes, and so the Lightning node itself is a, is an unfortunate container for that activity because it's, it's got- You know, hundreds or thousands of connections, and it's, you know, constantly going, you know, sending messages and doing things and so on and so forth. It has a lot of code in it, and we're doing a lot of aggressive coding lately, the routing people are, there's, you know, pickard payments, there's all kinds of features happening, and so, you know, unfortunately, any bug in any of that could result in a case where a lightning node could have, an exploit, and then suddenly you've got a big problem. So our vision is to extract the keys, the stuff you need to do the signing, out of the node, and put them in something that's more secure, and then connect it in sort of the, I wanna say the smallest possible way, the thinnest, you know, pipe you can imagine, and, and get the job done that way. we'll talk a little bit, I, I imagine, about the various scaling options here. So it's a little hard to just describe it as one thing because you might use VLS in a, a consumer dev-- device which is connected, you know, one particular way, using, you know, home Wi-Fi or something, and you also might have a, enterprise setup where you have an HSM which is connected through a very special kind of network connection, and there are many, many options in there. We're trying to be general and so we can do all Those things." }, { "speaker": "stephan", "time": "12:00", "start": 720.38, "text": "Yeah. Okay. And so I guess I'm thinking, just as you're explaining this to me now, I'm thinking of a couple parallels. I think of in the early days of Bitcoin, a lot of people were downloading the software and they were both a node and a miner. And then only later it sort of became clear that, wait, hold on, hold on, you can be just a node who isn't a miner. And it's a similar kind of idea to that, and also another related idea, and this is, back to on-chain security, if we think about hardware wallets or hardware signing devices, secure elements are kind of like another way of segregating and having operations done inside the secure element and then passing out the information back out of the secure element. So in a similar way, VLS is quasi, it's a bit imprecise, but it's kind of like a secure element for your lightning node." }, { "speaker": "validating_lightning_signer", "time": "12:45", "start": 765.31, "text": "Yeah, no, that's a, actually a very good model. Yeah, that's a very Analogy, because, the simplest way to describe it, if you only have, you know, ten words or something, is we're a hardware wallet for-- or we're, we're the software in your hardware wallet for lightning nodes. Now, even with a hardware wallet for Bitcoin, for layer one stuff, you would still keep it cold, you wouldn't keep it connected to the computer all the time. Yeah. So you can see how it's even harder to do, but still, that's actually not a terrible analogy at all, and in fact, it might look exactly like that Model would be you're running a node and you have a serial cable, a, you know, a USB cable with a serial connection to a small device which is doing, the lightne- the VLS software. and that's much more, more secure because to attack VLS through the serial cable is much harder. So-" }, { "speaker": "stephan", "time": "13:36", "start": 816.0, "text": "I see, yeah. So then what are the challenges of building VLS? As I understand, is you are, in some sense, building the lightning state machine into VLS, and it's sort of like duplicating across the node, let's say the- The online connected node and then the VLS, which is basically the challenge then could be that you have to make sure everything is perfectly aligned, because if it falls out of sync, then that could be-- there could be problems there, right? Sure." }, { "speaker": "validating_lightning_signer", "time": "14:02", "start": 841.84, "text": "No, so you're-- That's absolutely correct with respect to some stuff. And then we don't have-- For example, we don't have to know anything about gossip, we don't have to know anything about routing, we don't have to know anything about path finding. Okay, so what, what do we have to be exactly in sync on? When, you know, what does it mean to-- for a commitment to, if your last commitment was this one and your-- the proposed one is this one, is this a reasonable step to" }, { "speaker": "stephan", "time": "14:27", "start": 867.37, "text": "take? Gotcha. And just to explain for the listeners, then, there's the-- with Lightning, there's the concept of when we set up the channel, it's a funding transaction, and then when we close the channel, it's a commitment transaction, as you're saying. So that's why we have to know what the commitments are, and the general operation is that we're passing back and forth these pre" }, { "speaker": "validating_lightning_signer", "time": "14:49", "start": 889.13, "text": "And so yes, we absolutely have to get the state machine precisely right, but the good news is the commitment state transitions are very well documented and fair-- and very well understood, because all of the lightning nodes need to interoperate with each other already in the same manner. So we are piggybacking in, in some sense, we're riding on the shoulder of a node which has to do all these things exactly right already, but we're looking at that and saying, \"Yes, yes, that's correct, that's correct, that's correct.\" What we're doing though is bringing in an additional set On it. so, the concept I introduce here is that our security model is that your lightning node has been taken over and now it's evil, and so we're gonna protect your funds even if your node isn't even working for you anymore. And there's, you know, dozens or hundreds of ways in the lightning protocol for the node to, to cheat you and send, send the funds to the wrong place. And so what we're busy doing is making sure that as commitment states Are being modified as they're changing, that your beneficial value, the amount of money which is coming to you, at the end of the day when this, when this channel is finally resolved, is consistent with your policies. Basically, you're not losing money. Now, there are, are obviously cases where you have this little bit of slippage, like fees are gonna slip a little bit, and we're gonna velocity limit them and so on, so forth." }, { "speaker": "stephan", "time": "16:14", "start": 974.12, "text": "Yeah. Okay. Yeah, no, that's right. And so let's talk a little bit about that because it's like, I That idea, it's, it reminds me of, a similar concept in hardware, hardware wallets, right? The idea is even if my, let's say I'm using Specter or Sparrow or something online, and somehow that device gets corrupted, when it sends the transaction to my cold card, I'm looking, okay, what is the address and what's the amount I'm sending to, and I'm verifying on here. So it's a similar idea that you're building in a, let's say adversarial sense of even if my lightning node got compromised, I'm trying to not lose funds How do we achieve this? There's certain policy rules that you've built in, so maybe now's a good time if you could explain a little bit about how those rules are done, in VLS?" }, { "speaker": "validating_lightning_signer", "time": "17:00", "start": 1020.44, "text": "So we have a document, which enumerates them all and lists all of the specifics involved with them. I think I should probably give some examples though, which are easy to digest, and then, you know, people who are really interested can-- we can go in and discuss, you know, specific ones. but a very good one is the closing transaction. This is a mutual closing. So we've just-- we've had a channel, and now it's time to close it. It's all friendly. We're gonna both do the same. And so you propose a mutual close transaction to I sign it. Now, if my node has been compromised, a very simple thing for the bad guy to do is to propose a closing transaction which sends the money to, not to me, so, you know, to a, to an address I don't control. And so the VLS is, is, is aware of that. So what it has is it has an allow list. So that's a list of all of the allowable addresses where you can unquestionably send money. So you would put your, your layer one cold storage in there for sure, so you can always send money from your node. To your cold storage. If you have other, team nodes, so like if your company operates five nodes, you may have the other nodes listed in there so you can move money between the nodes, without worrying. you can use xPubs to, to do that so that it's, it's efficient. You can set it up and don't have to be editing it all the time. Anyway, when the close transaction comes in, we know what your, your expected balance was previously, and we look at what we, we think you're getting out of this closing transaction, and You've set, you have a tolerance, then we say, we won't sign that because that's not good for you, it doesn't deliver beneficial value to you. So that's an example of a policy that a closing transaction must deliver your value to you. It's very simple." }, { "speaker": "stephan", "time": "18:44", "start": 1124.39, "text": "Right, mine is like, say, a small percent for fees, something like that." }, { "speaker": "validating_lightning_signer", "time": "18:48", "start": 1127.87, "text": "Fees are always a challenge, and, and things are actually, things are getting better with fees by jumps and starts. So, just to divert for a second, with the advent of zero, zero Anchors, we, we're getting to the point now where we don't have to build in a fee with a lot of guesswork about what the fees are gonna be next week or next month, so instead we can just say, \"Oh, we don't put the fee in here and later you'll bind it.\" another thing which the, the world badly needs is a fee oracle. It needs a way for, as a user to get a reasonable fee estimate from a trusted source. s- So VLS doesn't actually provide that, but it would definitely use that. So right now, what we have is some basic heuristics that, you know, don't do more than X percent or this total amount. yeah, I forgot where--" }, { "speaker": "stephan", "time": "19:38", "start": 1178.13, "text": "Could that be provided by something like mempool.space or something like that?" }, { "speaker": "validating_lightning_signer", "time": "19:42", "start": 1181.75, "text": "Sure. so there's some discussion that needs to go on there, and we already have actually some things that we already do, are using oracles for other reasons, but the oracles that we're gonna-- that we'll probably talk about, They don't, they're not judgmental. The problem with fees is it requires, some prediction math. You have to, like, Bitcoin Core does a reasonable job of estimating fees, and most of the nodes, that I work with use those fee estimates and then go up, but they have-- There's a timing tolerance in there. If you need something right away, then you're willing to pay a much higher fee, and sometimes in Lightning there are deadlines to, to sweep certain things, especially with respect to justice transactions. So the- Handling of fees there gets really sticky because if, if we don't sign something because the fee isn't high enough, but there's a deadline involved, that's actually really bad. We, we need to allow you to be aggressive with fees when you need to be. So" }, { "speaker": "stephan", "time": "20:40", "start": 1240.35, "text": "it could be like a false positive if you-- Yeah. It could be actually in a scenario where you need to spend a lot of fee because, let's say, the other channel partner is trying to cheat you or maybe they're, they've restored from a wrong backup and now you need to put in your transaction to take what's rightfully that's where the difficulty can come in. That's," }, { "speaker": "validating_lightning_signer", "time": "20:59", "start": 1258.68, "text": "that's exactly it. And the, the case is if it's a, it's a severe attack, if it's a really bad attack, they've, they've held you up in a bunch of ways, right? They've, thrown some banana peels in front of you so that, so you had one week to resolve this, but now you're down to just two days because of, of things, ways they've managed to mess you up. And so now you need, your fee needs to escalate" }, { "speaker": "validating_lightning_signer", "time": "21:27", "start": 1286.78, "text": "The-- what, what I'm trying to get at is, this all sounds painful, but really it's much, much better than the alternative where you just trust the node and, and the closing transaction sends all your money somewhere else. That's, that's very bad." }, { "speaker": "stephan", "time": "21:40", "start": 1300.08, "text": "Right, that's the nightmare situation. And so VLS, as you've mentioned, because we've got this lightning layer, right? The peer-to-peer lightning layer, and then there's also on-chain. So is VLS looking at both components here? Yes," }, { "speaker": "validating_lightning_signer", "time": "21:51", "start": 1311.27, "text": "yeah. I mean, it, it, it signs for both, so absolutely, right? We sign, when a channel is created, there's a, a, an on-chain transaction which creates the funding transaction. Sometimes those are batched, so VLS is involved in looking at that and saying, okay, so we Getting three channels out of it, and our portion of these three channels is, you know, this much, and, and based on that, we can say, yes, you have appropriate beneficial value, and therefore, we can allow that to happen. So it doesn't require explicit approval to open a channel because we can tell that you're entitled, you haven't lost any money, the money's in the channel, and you, you should be able to get it back. if you just go do a payment to someone, so just, from the, from a V-L-VLS will ask the user, so, hopefully on a trusted display, this depends how it's, it's built, but VLS just like a hardware wallet will say, \"Do you wanna pay this invoice?\" And it'll list the invoice details, and you can say accept or decline. and if you decline, then VLS will not allow that payment, and if you say accept, then it will let it go through." }, { "speaker": "stephan", "time": "23:03", "start": 1383.42, "text": "Great. And so the-- I mean, we're talking about all this stuff, but the overarching end goal is that Lightning nodes can Run more securely, which in turn helps more people run larger lightning nodes or just be more comfortable running a lightning node altogether. So for example, you know, there are big lightning nodes out there today like Bitfinex and Bitrefill and River and Async, and some of these lightning nodes, they literally have hundreds of Bitcoin, hundreds of bitcoins on them, and so they need something." }, { "speaker": "validating_lightning_signer", "time": "23:31", "start": 1411.47, "text": "They have to if they're going to participate, if they're gonna provide that liquidity or absorb that liquidity. So, you know, you certainly would minimize how much is held The node, but, but with Lightning you don't have the option of having nothing." }, { "speaker": "stephan", "time": "23:46", "start": 1425.54, "text": "Yeah, great. And so I guess, yeah, just explaining some of the policy rules. So I guess there are different-- Thinking about the ways that, let's say, a malicious person might be coming at you to try to, you know, attack you or steal your funds, in one way they might try to route payments out to themselves, or another way might be to try and, let's say, close the channel and take the f-- like send the funds on On-chain to themselves, right, to the, to the hacker or attacker. So in some of these contexts, VLS can help you, right, or can stop that. That's the idea." }, { "speaker": "validating_lightning_signer", "time": "24:18", "start": 1458.31, "text": "Yes. Yeah. I, I think actually we're-- it, it's fairly complete. I, we don't think there are like any good ways. The, the ones were the, the smaller ones that we're tapping down now and trying to close are mostly griefing attacks where someone can burn more of your stuff into for fees. now that doesn't give them any money though, they have to" }, { "speaker": "validating_lightning_signer", "time": "24:39", "start": 1479.44, "text": "In some cases, so we feel that those attacks are gonna be less aggressive, less common, and less fruitful for the attackers, and we see lots and lots of reasons why that gets better as we have, anchors are gonna make a huge difference right off the bat, because they allow you to do fee determination at the time instead of like guessing ahead of time, which is terrible. another one is L2, you know, someday when we can do L2, all of that will get much, much better, but that, that's, you know. Far on the horizon. So." }, { "speaker": "stephan", "time": "25:12", "start": 1511.58, "text": "Yeah. Okay, so I guess, I guess that's the question I, I wanted to ask. Are there any-- What scenarios does VLS not cover?" }, { "speaker": "validating_lightning_signer", "time": "25:21", "start": 1521.4, "text": "well, VLS requires that the operator be honest, right? I mean, you have to-- So one thing we say about VLS is that it separates concerns, and this is something we actually like. if you're doing VLS the right way, then your ops guys can be maintaining the nodes and can just go to town and do all-- They can open channels, close channels, they can do all that kind of stuff, but the finance department can be controlling the wallet and saying, \"You know, these are my rules, this is, you know, my allowances, these are my velocity limits,\"" }, { "speaker": "validating_lightning_signer", "time": "25:53", "start": 1552.64, "text": "The, exceptions have to be made by them, so they have to check, yes, if there's an exception or if they wanna bend the rule or if they wanna open the, velocity limit up for a week because there's something going on. You know, there's lots of legitimate reasons to do those things, but the finance department can cover that instead of the ops department. And so I think that, that's a very nice thing, but you still have to trust the people to, in doing that, right? Yeah. Right. another one is the, Then the temptation is to build an API to do the approvals and all that sort of stuff, and there have been some famous hacks where those APIs themselves have been hacked. So it's tempting to build an API which then needs to be protected with another whole system, which is just as complicated. So that part we, we don't actually really solve. You, you have to approve correctly and disapprove correctly, and we can make it so, but, and I think that's a huge advantage. Gotcha. Yeah, but it's still not a- Yeah, yeah, it's not a non-problem. It's not" }, { "speaker": "stephan", "time": "26:58", "start": 1617.78, "text": "a civil bullet, right? Yeah. But as an example, it means you have to make sure your whitelists are set up correctly, because obviously if the hacker can get his address added to the whitelist, you're in trouble now." }, { "speaker": "validating_lightning_signer", "time": "27:08", "start": 1627.67, "text": "Game over. You know, game over. Yeah. I mean, you'll just be able to send the money to the hack-hacker. the hacker will be, well, that assumes a hack, but a very simple hack nowadays" }, { "speaker": "validating_lightning_signer", "time": "27:23", "start": 1642.74, "text": "Millions of reasons, everything is done with RPC access on all the implementations, and it's probably a really good security model to assume that an attack is gonna get access to that somehow, and then there's a huge amount of damage they can do, through the, you know, they can send money on chain, they can send money off chain. In fact, the off-chain ones are the, the worst, right? Because they go immediately and they're, effectively it's cloaked immediately, so it goes out through the lightning network and you have no idea where it went." }, { "speaker": "stephan", "time": "27:51", "start": 1670.94, "text": "Back to the show in a moment. The lead sponsor of this show is Swann dot com and Swann is organizing Pacific Bitcoin Festival. So last year there was Pacific Bitcoin Conference in LA and this time it's coming again in October 5th and 6th. So make sure you check out the times in your diary, book the flights and hotels. This is going to be an amazing experience and just recently announced is Vijay Bohra as a speaker. So Vijay is a legendary, author in the space, an economist. And he also has a lot of interesting things to say around the technicals of Bitcoin also. Alongside him will be other speakers such as Max Kaiser and Stacey Herbert, Preston Pish, Greg Foss, Alex Gladstein, Corey Klipstein, Lynn Alden, Jimmy Song, and so many more. So get your tickets at PacificBitcoin dot com, use code Livera for a discount there, and think about bringing some family and friends along. This is going to be an amazing experience, and I'm looking forward to seeing you there in LA October 5th and 6th over at PacificBitcoin Mempool dot space. This is where I go to target my on-chain fee before I send on-chain transactions. You can see at a glance the ecosystem, you can see the multiple layers of the Bitcoin ecosystem, whether that's the mempool, the blockchain, the second layer network like Lightning Network as an example. You can see a mining information tab, you can see mempool blocks, and you can scroll those blocks, which is really cool. You can even search particular transactions or you can search an address and then see and visualize the information Nation, all there. And keep an eye out for an upcoming feature, it's called the Mempool Accelerator. So this integration is coming soon, so keep an eye out for that over at mempool dot space. And now back to the show. Yeah, gotcha. And I can imagine where-- so this might be in context where somebody is trying to connect their Lightning node to an application. So as an example, Alby, like a web extension to do Lightning payments, and, I guess people might be, relying on some of the security elements inside the node. As an example with LND, they have, macaroon-like so you can have like read-only or invoicing capabilities. And I think on the core lightning side, I think it's called runes, but similar sort of idea that you can give permissions for certain things. So I guess VLS is more like it's independent of all that and it might be like another layer of defense, right? So maybe the user will assign a read-only macaroon or a read-only permission in some way, but somehow if that were to fail, could VLS catch that?" }, { "speaker": "validating_lightning_signer", "time": "30:20", "start": 1819.61, "text": "Yes, that's exactly the idea. so macroins and runes are great, but they are enforced by the node. So i-in the simple model where the node has been hacked, then they're being enforced by the bad guy. So, Now there are some, it is tempting to have some other thing, it's not e- exactly a rune or a macaroon, that you could send a VLS, which, so it's a signed thing which says, I have given, I, I wanna add this to the allow list. There, there you go. That's an, an easy to understand example. I wanna add this address to the allow list. Now that's very handy and that's a great admin function and it's convenient and it would make a lot of, operate, user flows go really well Do this, now do this, and then it all happens. But we'd be worried about the security of that, of course, because that's an attack point. The allowlist is a very, very clear, obvious one. It's, you know, if, if they can add their own address, then it's game over." }, { "speaker": "stephan", "time": "31:16", "start": 1876.43, "text": "Then it's game over. Okay. And so when it comes to the different implementations, which implementations does VLS support?" }, { "speaker": "validating_lightning_signer", "time": "31:25", "start": 1884.62, "text": "so today we're, highly integrated with Core Lightning. So, the Core Lightning, that is delivered by them can work with VLS. we have an integration repo where we actually, you can type make at the top and it builds both systems and runs all the integration tests and so on and so forth. That, that we use that for testing and for demonstration. So, so that's Core Lightning. LDK, we're, highly integrated in that we use LDK code. So our, our models What the interfaces look like and the APIs look like, internally are LDK defined generally wherever possible, and s- and sometimes we get to influence those. and so that means if you're building an LDK node, now it really depends on which-- LDK doesn't mean like one particular node, it could be, you know, it's how you built the node with LDK, but it should be relatively straightforward to use, VLS with LDK. We have a sample, node That we wrote so that we could run it and prove that it worked, which does that. So it's called LN-Rod, Lightning Rod, which I guess may have been used by other people as well. Anyway, it's up on our repository and it should be current and work. Yeah. So," }, { "speaker": "stephan", "time": "32:38", "start": 1957.53, "text": "okay. And so is the plan then to have other implementations supported over time, like, I don't know, Async or, LND and things like this?" }, { "speaker": "validating_lightning_signer", "time": "32:46", "start": 1965.97, "text": "We want, we want it to work with everybody. so really, if possible, we'd love to" }, { "speaker": "validating_lightning_signer", "time": "32:54", "start": 1974.16, "text": "Implementations, but there, it seems like there really needs to be a, a very open implementation that everybody can look at and look at the rules and that we can discuss them and add rules and, you know, remove them and debate and so on and so forth. And, we'd love to get all of the nodes capable of doing it. in terms of LND, there's a project called, LND Signer, which is done by N Y Dig. I don't, actually, I don't know if they're Nidig or" }, { "speaker": "stephan", "time": "33:21", "start": 2001.02, "text": "whatever. I think" }, { "speaker": "validating_lightning_signer", "time": "33:24", "start": 2004.16, "text": "Project called, LND Signer, and we're in touch with them, and they are working towards a proxy so that they can, connect to LND and, connect it up to a, a VLS remote signer. In fact, in CLN, we exactly use a proxy, so we replace a CLN component, the HSM-D demon, with a remote HSM-D, which just looks the same to CLN, but instead proxies all the, the, requests to us And then we sign them and, and send it back." }, { "speaker": "stephan", "time": "33:57", "start": 2036.6, "text": "Gotcha. Okay. Yeah. And as I understand, there may be commercial reasons where some of these companies want to support you, as I-- Correct me if I'm wrong, I think Blockstream did something recently, maybe they sponsored you or they did some kind of partnership with you?" }, { "speaker": "validating_lightning_signer", "time": "34:08", "start": 2047.99, "text": "Both. so we, we are sponsored by Blockstream, and, but we're integrated in Greenlight, so Greenlight needs a signer in its, in its flow di-- in its diagram, there's a spot for a, a" }, { "speaker": "validating_lightning_signer", "time": "34:24", "start": 2064.18, "text": "They used their own native signer, initially, I believe, but pretty quickly switched to VLS because we were completely compatible with that signer due to the other way we were working, which was the replacing the HSM-D. So yes, we're currently the signer in Greenlight, and, and working with them on that." }, { "speaker": "stephan", "time": "34:42", "start": 2081.93, "text": "Gotcha. And that also makes a lot of sense for their context, which is the idea is in that context, Blockstream is going to run the node, and then the user might have his keys on his phone, as an example, and so that's where V Come in, because that might be what's operating on the phone." }, { "speaker": "validating_lightning_signer", "time": "34:57", "start": 2096.74, "text": "Yeah, that, that's an important concept, for VLS in general, though, is what we're trying to do. If you look, if you really step back and abstract it, we're trying to distill custody and nothing else. So we're, we, we don't want any routing, we don't want any other efficiency, no other features, just custody. So what does it take to say I control the funds and I control all of the funds and I give all the options to the person who's This software. So like if they decide that the service has become evil, that they have options, they can, you know, connect it to something else and get their funds. If the minimal custody is also very important for resources, because a lot of these cases, you wanna put it in an embedded device or, you know, you wanna run it in a web browser or there are many, many different cases, and so being as small as possible is really a good thing, a beautiful thing, because, you can make it cheap. Yeah. Stackwork and Sphinx, they're the related dev teams, are building something using ESP32s right now. I think it's about a ten dollar part. and the, the vision there is that you can plug this VLS signer on a chip into the wall and it connects to your Wi-Fi and it signs using, a cloud-based node, but it allows you to receive money day and night. So if you're a, streamer who's getting some funds from folks for, or delivering some, Service in some other way, people can pay you all the time because you have the funds are supported by that little device, and that gives you custody, and they don't have to trust, Stackwork or anyone else." }, { "speaker": "stephan", "time": "36:35", "start": 2195.06, "text": "it's an interesting idea. Okay. And so then, in a way, like you're saying, it's hardware agnostic, right? Because VLS is the software, and people could be running it at different, all kinds of different levels. So like you said, from, down from that ESP thirty-two device to a mobile phone, all the way up to the" }, { "speaker": "stephan", "time": "36:53", "start": 2213.38, "text": "All of these things can run VLS, that's the idea. That's" }, { "speaker": "validating_lightning_signer", "time": "36:56", "start": 2215.78, "text": "the idea. We're, we're writing it in Rust because Rust seems to be minimal, it seems to have less system dependencies than other things. So if you're writing something in, you know, C or Python or, or what have you, you tend to, to need more in terms of library support than Rust. Rust is more self-contained that way. Rust is very good for embedding. I, I personally have been using, doing stuff with the, STM32, this guy, We, we run on this and we can connect it up to a core Lightning node and run a node. I've got a node running at home doing that, and it's a, it's a lovely environment. I've done embedded work in the past and, you know, it's, it can get weird, Rust on embedded environments is really pretty great. Now, HSMs are another interesting case, but we're gonna-- it's gonna take us a while to get there because, those generally require the right word, partners who can wield-- you have to get companies to allow-- their non-disclosure agreements and all sorts of problems, and it requires funding and, you know, yada yada. I think the best thing you can have is a really concise library implementation for the core signer, which, you know, which is what we have, and then you can say, \"Look, we can put that on that HSM.\" But, you know, somebody with political clout needs to solve some of these other problems. we definitely can run on a, a protected Unix server today. So a very, very good option for a lot of people right now is probably to have a rack in a secured location where you're running VLS, and you connect that rack to your nodes, which are running in a somewhat less secure situation. Those might be in a more general-- they could be in the cloud, for example, whereas your rack might be in your physical custody. there are many examples and there isn't a one size fits all here, but, running it, on a general Unix server is very straightforward. We do that all the time now." }, { "speaker": "stephan", "time": "38:52", "start": 2332.05, "text": "I see, yeah. And I mean, it makes a lot of sense. I know there are some large Lightning nodes that are in the cloud, and so this would make a lot of sense for them to run VLS in their own home or in their own office somewhere as a way of protecting themselves or even" }, { "speaker": "validating_lightning_signer", "time": "39:05", "start": 2344.6, "text": "in a different cloud. So a very, very good model is to say, \"My nodes Yada, yada, yada. And then over here is VLS, and it's running in a different setup, and it's much more restricted. Now the hacker has a problem, right? Because, you know, attacking the node isn't good enough. He can, he can shut it down effectively, right? If you can, if you can just maliciously attack the node well enough, you can basically shut it down. But to get the money, he has to attack the VLS one, which is a much, much smaller footprint and different than the node itself. So it, he doesn the RPC gateway, it doesn't have all those things." }, { "speaker": "stephan", "time": "39:46", "start": 2385.98, "text": "Gotcha. Yeah. And I mean, this is all important because if we want, if we, you know, like, presumably we all believe Bitcoin is someday going to be the money of the world, and we want everyone to use it, we, we want people to be able to securely spend it and using Lightning, of course, because then you get the instant settlement and cheaper fees depending on, you know, the fee rates at the times, and yeah, just a lot of functionality. So, it's project, if Lightning is gonna continue professionalizing and maturing, now one other area, the website mentions, as in your website mentions, multi-signature Lightning. So could you just elaborate a little bit on what would that be? What would that look like? It's" }, { "speaker": "validating_lightning_signer", "time": "40:28", "start": 2427.89, "text": "very exciting. I mean, multi-signature, imagine the same setup we just talked about, except instead of a single signer, now we've got, say, five signers, and we need three or four of them to be, you know, operating And honest. So the bad guy has to take over, you know, n of them in order to-- it's the standard multisig thing. it is feasible, we believe, to build it so that none of the signers has all the information they need to, steal any money. So you simply compromising a signer now isn't good enough. You have to compromise, you know, n of them. It depends how you build it, but three out of five is, is a, or four, four of-- those are our typical, things that People talk about. Yeah. Now that would allow you to do very, you know, you could be very confident there because those signers could be running in very different places on different hardware, and so that would make it very secure. Another thing, that's cool about that at the low end, so that was an enterprise story, but a, but a, a user, a, a low end user story is that you have your phone and you have the wallet at home and you have something in a safe deposit box which you can plug in if you have to. and maybe there's an online partner who you trust to do certain things, to, like much like GreenWallet did in the old days. And so you can use that sort of setup, which is very heterogeneous. There, you're, you're not just get, you know, three out of five, you, you can't get them enough. Instead, it's, no, I have different motivations for these. this one's always with me, but it's intermittent. That one's always available to give a signature, but maybe it doesn't automatically sign those kinds of things, so those heterogeneous setups can lead to a lot of really cool things for users as well." }, { "speaker": "stephan", "time": "42:17", "start": 2537.32, "text": "I see. And so, yeah, there's a lot of possibility there. And so in terms of the protocols required for that, the website as well, you mentioned, that requires or relies on the maturity of key protocols, namely Taproot, Music 2, and Frost. Yes. And so, do you wanna just elaborate a little bit on, on what the, what the relation is there for those?" }, { "speaker": "validating_lightning_signer", "time": "42:37", "start": 2557.12, "text": "Sure. And this is where, I mean, de verdim's gonna be a little stronger but I, I, so Taproot is working and it's great, and, the music part is all very good, but then we get to, there's several hard parts. So the, contested, sorry. If you have to do a revocation, for example, I'll give you an example of something that's hard. Today, there's a scheme for how to store the revocation keys so that you don't use a lot of memory to do it. So when the, when your channel partner is re-revealing key secrets to you, You can-- there's an a, a, a trick to storing them so it doesn't use unbounded storage. Otherwise, every single commitment you'd have to store a big secret, and then you would run out of, you know, memory before long. The problem is those algorithms don't, break up the same way, for multi-party, computation, as the signing algorithm. The signing algorithm itself isn't the problem. It's how do we do, revocation secrets and so on. Now there are, discussions about that, the VLS team has a, matrix group called L2 Multisig, and we have, people from many different, let me see how many people are in here. There are thirty-four people in here from all different companies, and so everybody's discussing it, batting ideas around, and so on and so forth. T-there's an idea right now which I think is going to, maybe gonna work, it was discussed today in the Lightning, developers protocol group, that we could just use ten- Copies of the same trick we do now, and then each of those signers would have some set of those, and then you would XOR them together in a clever way to get, you know, simply XOR them together to get the actual revocation secret. So that would cover, groups up to four out of five, for example. So you could do four out of five that way, and it, it's not terribly-- it's not as bad as it sounds. Remember, the revocation stuff is only ha-- only comes into play when there's a justice trade. There's a justice thing going on, so it's okay if it, it, it's a little bit unwieldy, otherwise. Yeah." }, { "speaker": "stephan", "time": "44:48", "start": 2688.23, "text": "one other question, so if we're talking about multi-signature or multi-party, are there concerns around latency here? So if, you know, let's say every time light-- Lightning nodes are routing payments, especially for routing nodes, not as much for the end consumer node, but the routing node, he has to take in, you know, and forward payments, forward HTLCs, et cetera, and I presume at every moment That if he's running a Lightning node with VLS, he's got to also now connect, talk to the other VLS and to the, you know, to the multiple ones before being able to sign that channel state update." }, { "speaker": "validating_lightning_signer", "time": "45:20", "start": 2720.09, "text": "There's a minimal number of round trips and everybody's working to reduce it to, to take a step forward in those, in those state machines. But the cool part is, let's see, two things. One is at the consumer level, it doesn't matter a lot. So, I mean, if you're going to do a payment or something like that and you have a One second instead of half a second or a quarter of a second isn't terribly important. Not a big" }, { "speaker": "stephan", "time": "45:45", "start": 2744.83, "text": "deal, yeah." }, { "speaker": "validating_lightning_signer", "time": "45:46", "start": 2745.73, "text": "Now for the, for the large retailers or the very large routing nodes who have hundreds or thousands of channels, it's a really big deal. But here's the cool part, we're working really hard inside VLS to make sure that the channel state is separate, i-it's, isolated, so those could be proceeding in parallel is the idea. So there, there are obviously join points for routing, we have to make sure that the incoming, is Guaranteed before we send the outgoing, but that's only linking two things, like a different payment can be getting routed some other way in parallel, and that should be okay. So we're working hard to keep the channel state separate so that we can get the throughput that we need, even though we're doing that kind of, those, those extra rounds. I guess," }, { "speaker": "stephan", "time": "46:32", "start": 2791.8, "text": "yeah. So I guess the short answer is parallel, parallelization is," }, { "speaker": "validating_lightning_signer", "time": "46:36", "start": 2795.96, "text": "parallelization." }, { "speaker": "stephan", "time": "46:37", "start": 2797.16, "text": "Yeah. Okay. I" }, { "speaker": "validating_lightning_signer", "time": "46:38", "start": 2797.98, "text": "mean, really, when it comes down to it, if you're Trying to protect a hundred million dollars or even a billion dollars, then the fact that you have to have some, throw some significant hardware at it and some very fast links isn't actually the problem. The problem is that a bad- That would be" }, { "speaker": "stephan", "time": "46:55", "start": 2814.87, "text": "considered table stakes, yeah." }, { "speaker": "validating_lightning_signer", "time": "46:56", "start": 2816.45, "text": "Yeah, the, the problem is a bad guy could get in there. I mean, you know, or a dishonest employee, the, the usual thing. That having to protect each one of those things individually is really harsh, but having to say that, no, the bad guy has to take over two of 'em or three. Three of them, is a good deal, and so you would absolutely be okay with, you know, stepping up and making it go faster. Getting the software architected so it can do that is the key," }, { "speaker": "stephan", "time": "47:23", "start": 2842.95, "text": "that's what we- Gotcha. That would be the hard part, is making sure the software can deal with it, and then you've got to find the hardware and the internet connectivity to, you know, and the hardware that can deal with it. Okay. Yeah, I think that's a fair, fair answer. and when it comes to, relationship with There's independent things that both help increase the secu- or improve the security and maybe in the future watchtowers will be more prominent or there'll be more people using them and poten- maybe that would be in an L2 or let's say a sim- L-LN symmetry world where we have VLS working and watchtowers, maybe they'd, they'd be both operating to increase the security for the users." }, { "speaker": "validating_lightning_signer", "time": "48:03", "start": 2882.88, "text": "Right. A, a, and VLS does have a, a-- there is a watchtower, angle there, which is if you're using a watchtower, VLS probably needs to know that the wa-- needs a, a signed attestation from the watchtower that it has what it needs in order to take the next step, if-- And so that's another case where we have to be involved in that, in that protocol. I think what I've been hearing, and I don't claim to understand it, is that the Taproot stuff is gonna help watchtowers a bunch. I think there's some simplification that happens in the Taproot, right, once we move to Taproot channels. Yeah, I think the Watchtower stuff gets much better somehow, although I don't, not really clear on, on why yet. Yeah. but hope that-- We still need to know that your Taproots, that, sorry, that your Watchtower is up to speed before we go on, because it's, you gotta check your parachute before you jump out the door. Right. Yeah. Of" }, { "speaker": "stephan", "time": "48:54", "start": 2933.78, "text": "course. Yeah, okay. and so let's talk a little bit The LN symmetry, right? If we get that, that would make a lot of things simpler for lightning developers, both at the protocol level and the software level. And I guess are there other protocol upgrades or improvements over time, and basically you will have to just update VLS to be in line with that, right? If there's, I don't know, I don't know if Bolt twelve or route-- blinded routing or some other thing that comes, means you've got to now update VLS." }, { "speaker": "validating_lightning_signer", "time": "49:27", "start": 2967.04, "text": "Yeah. So Bolt twelve, we've already done a bunch of work. Bolt twelve is actually multi Bolt twelve invoice needs to be approved just like a bolt eleven invoice. The, now the bolt twelve invoice went through more round trips and protocol to get there, but it's the same thing. At the signer level, is it okay to spend a hundred bucks here? And you gotta say yes. there's additional things though higher up in bolt twelve which are interesting though. Like, for example, if you're watching a movie, you might wanna say, \"I am, would a, approve paying up to ten dollars over forty-eight hours to this, this node?\" and so that's an example of a bolt twelve recurring payment which bolt eleven has, you know, no idea of, and the signer would be a good place to make that allowance. And so it's going to-- we don't currently have, but want to support, higher level bolt twelve concepts so that we can, a user can approve a higher level payment. it, it won't do for the user to have to approve every nickel that you're paying Netflix to watch movies. Of" }, { "speaker": "stephan", "time": "50:32", "start": 3031.54, "text": "course, yeah. And I can, I can imagine, you know, you might have like payments where it's like ten dollars every month or maybe it's ten dollars a day, but then that can also be restricted by the flow or velocity requirement where maybe you have a global rule of no more than fifty dollars a day or whatever." }, { "speaker": "validating_lightning_signer", "time": "50:47", "start": 3047.01, "text": "You've exactly got it. It gets, it gets tricky and it's infinitely customizable. So I, I'm not worried there. I think we can build sensible things for different use cases so that, you know, home users can easily set up payments for movies And other things like that, or can set up monthly payments, because that, that's gonna be a lot of their payment stuff, and they may wanna give allowance. I mean, there's just-- Well, anyway, I don't wanna, Other, other features which are coming up and in the sort of on the near side, splicing is, now h-- you know, getting, well, it's being released in Core Lightning, today. I think the, Core Lightning is in release candidate two of twenty-three point zero eight, and so they will be releasing zero eight soon, and that will have experimental s-splicing support. so, so VLS will have to do some work to make, To make that work. But again, slicing is really sort of the same idea, which is when you're slicing out, we wanna make sure that the-- if it's your money that's getting spliced out, in other words, if the money is coming out of your side of the channel, then, we wanna make sure it's going to an address that's in your allow list or in your wallet. If it's coming out of the other guy's side of the channel, then you don't care where it goes," }, { "speaker": "stephan", "time": "52:04", "start": 3124.45, "text": "it's-- that's up to him. Gotcha. Yeah, I mean, it may-- it's interesting to see. So I guess it's just like this project sort of has to ke-keep in line with everything else that's happening in Lightning because it's, it's the same thing, you're replicating the Lightning state machine." }, { "speaker": "validating_lightning_signer", "time": "52:17", "start": 3137.12, "text": "Well, not everything, or at least" }, { "speaker": "stephan", "time": "52:18", "start": 3137.84, "text": "part of it. Yeah, yeah, just the custody part, right?" }, { "speaker": "validating_lightning_signer", "time": "52:20", "start": 3140.42, "text": "Picard payments, which are also coming out in Core Lightning, this week, we don't have much to do with. I mean, we have to approve the payment, but" }, { "speaker": "validating_lightning_signer", "time": "52:36", "start": 3155.95, "text": "For how that works, and it's exciting, but VLS doesn't have to change at all for that. So, so yes, though, we do need to keep up to date with how the commitments are, the valid state transitions for the commitments, and make sure we understand what all, what they all mean, you know? PTLCs is another one, right? so that will, yeah, all of those things." }, { "speaker": "stephan", "time": "52:57", "start": 3176.88, "text": "Yeah, fantastic. Okay, so, if anyone's listening now and they wanna get involved or support you guys, what, what are you looking for in terms of, you know, users or help?" }, { "speaker": "validating_lightning_signer", "time": "53:08", "start": 3187.81, "text": "Well, all kinds of things. So if you're a developer, then we'd love to have you come check out our, list of issues and see if there's any that you, you could work on. So we're, we're open to accepting, merge requests. We're on GitLab, so it's merge requests instead of pull requests, same thing. W-we also need people with all sorts of other skills, though. so recently the team added, Jack Rinaldi, who maybe you t-talked, talked to, who's doing Connected to places that need us, but there's a lot of communication that has to happen in describing what does it mean and how is this good and what will it do for you and what do you have to do for it. and so getting people involved who understand those parts is, also important because we, we engage at a lot of different levels of a lot of different business models. They're not, it's not a one size fits all at all. So we need folks who, understand those sorts of business relationships. we need partners. So if people want- want to make a killer Lightning thing and it needs, it can use VLS, please come talk to us because, you know, we're-- everybody's actually, it's not just VLS, Lightning is looking for the killer app. And so when that killer app happens, we would like to make sure that VLS can offer security to that killer app. Let me give you an example. L four O two is one that I'm excited about. I hope I have the right name, but it's the ability for publishers to receive, payments at fairly low friction You know, you can just put a little proxy in front of your, current server, not change anything else, and now suddenly you have a lightning wallet filling up with Bitcoin. That's fabulous. It'd be great though if it had VLS so that you're So that your Bitcoin wasn't stolen, that would be a bad, you know, experience. So w-we're, if you're working on something like that, you know, come talk to us, 'cause maybe, maybe there's an API that we need to add or something we need to be aware of which can help you." }, { "speaker": "stephan", "time": "55:06", "start": 3306.17, "text": "Fantastic. Well, yeah, it sounds like a great project to me. Hopefully, I, I've got a lot of developer and technical listeners and hopefully, some of them are interested to come and, get involved in some way. Yeah." }, { "speaker": "validating_lightning_signer", "time": "55:22", "start": 3321.9, "text": "The simplest thing is vls dot tech, so v l s dot t e c h, is a website which has, you know, basic information, but has pointers to everything else. We are on GitLab, if you prefer to go there, but the link to GitLab is, is on vls dot tech. We have a bunch of Matrix groups, is what, we're currently, currently using. I'm a little channel fatigue nowadays with all the different ways to send messages. if you'd like to just come in and ask questions, that's a great, you know And type in your question, we'll be glad to answer it. And then we do the normal-- Oh, yeah, that's great. Normal number of conferences and things like that. So if you, if you see us at one of the conferences, we're friendly, come talk to us. We wanna, we wanna work with you. Great." }, { "speaker": "stephan", "time": "56:05", "start": 3364.92, "text": "Well, that sounds, that's great. And yes, I'll put all the links in the show notes. And Ken, thank you for joining me today. It's been a, it's been a great chat, and I hope to speak again" }, { "speaker": "validating_lightning_signer", "time": "56:12", "start": 3372.42, "text": "soon." }, { "speaker": "stephan", "time": "56:15", "start": 3374.8, "text": "If you're enjoying the show, please do press like and share it around so that other people can see it also, and get the show notes at stephanelivera dot com slash five zero two. Thanks, and I'll see you in the citadels." } ] }