How can lightning users secure themselves even further? Just like how hardware wallets and secure elements can help secure your cold storage coins, Validating Lightning Signer (VLS) is a project aiming to help improve the way lightning security works. In this conversation with project co-founder Ken Sedgwick, we chat:
- Why VLS is needed
- How VLS works
- Implementing part of the lightning state machine
- What rules are covered?
- What lightning implementations are supported?
- The impact of lightning protocol changes
- Interactions with watchtowers?
- How you can get involved
Links:
- Twitter: @VLSProject
- Site: Validating Lightning Signer
Sponsors:
- Pacific Bitcoin Festival (code LIVERA)
- CoinKite.com (code LIVERA)
- Mempool.space
- Base58
Stephan Livera links:
- Follow me on Twitter @stephanlivera
- Subscribe to the podcast
Podcast Transcripts:
Stephan Livera 00:03:11
Ken, welcome to the show.
Ken Sedgwick 00:03:12
Thanks, It’s good to be here.
Stephan Livera 00:03:13
So, I understand you’re working on validating Lightning Signer, and 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’s your role in all of this?
Ken Sedgwick 00:03:28
So, 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. Like that, all very 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, it occurred to me that it must be kind of 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 protect this much money, and then that amount grew rapidly, but it was enough of a proof of concept for me that I got involved. And then I decided, Okay, I want to do something, and my goal was to meet people and learn things. And so, I wrote a wallet in 2013 for Android. As I was playing around, I really fell in love with Electrum. The Python yeah.
Stephan Livera 00:04:30
Classic, yeah.
Ken Sedgwick 00:04:31
And I said, you know, we really need an Electron for Android. Now there was one you could run the electron in some strange mode, but it really didn’t work very well. It needed to be a native Android app and so I went off too. To build that 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 live kind of close together. Let’s have you know tea sometime. So, we met up. I did build a wallet, although over time I decided not to support it for very long. 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 2015 we did a custody company in 2017, I hope I’m getting the dates right and then around 2019 we started really looking 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 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, trying to make it so that people can make much more secure implementations.
Stephan Livera 00:06:04
And so, then I guess that’s where this idea of VLS validating Lightning sign. It came up. And So, what? Your role in this.
Ken Sedgwick 00:06:12
Well, I guess I’m a cofounder, but different. That’s really 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 and we both have very, very similar 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 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 most things.
Stephan Livera 00:07:03
I see. And so, is VLS actually a company or is it a project? Or is it both? Is it both?
Ken Sedgwick 00:07:09
It’s an open-source project, so there really is no significant corporate thing going on. There is an entity, which is a sorry right nonprofit, which is to 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 getting by, but it’s not. This is a labor love.
Stephan Livera 00:07:32
Okay, understood. And let’s, I mean, so let’s explain a little bit about why VLS was created, I guess Presumably because of 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 idea of VLS?
Ken Sedgwick 00:08:13
Well, you hit the nail on the head. I think the important thing though that from where we were coming from is since we’ve worked in Bitcoin custody for a number of years, and even did a real for-profit company there, the real trick there is to keep everything cold. I mean, really cold. So, air gaps not connected at all. And so, if you’re an exchange, a very common number is 95. And 98% of their funds are just very. Old and that’s unquestionably secure, and it’s easy to audit. I mean, as a software engineer. Or you can look through it and go, yes, let’s see, 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 yadda. 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’re a let’s, if you’re a large retailer, say a Walmart. You have a million channels and an average channel might have $100 in it. Suddenly you have $100 million online. And as you alluded in lightening 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 recognize different requirements, especially fees lately. So, it is not 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 want to put them in as secure and execution. Possible you want to have as little code there as possible. You want to 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 the you know the it’s pretty straightforward. The less gaps there are, the smaller the space is, the easier it is to prove that there’s nothing that can get in.
Stephan Livera 00:10:24
I see.
Ken Sedgwick 00:10:28
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 note itself is a unfortunate container for that activity because 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 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, pick card 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. So, our vision is to track 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 get the job done. That way. We’ll talk a little bit, 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 consumer device which is connected, you know one particular way using 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 options in there. We’re trying to be general and so we can do all of those things.
Stephan Livera 00:12:00
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 minor, and then only later it sorts of became clear that, wait, hold on, hold on. You can be just a node who is not a minor 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
Ken Sedgwick 00:12:45
No, that’s actually a very good model. Yeah, that’s a very, very good analogy because the simplest way to describe it, if you only have, you know, 10 words or something is we’re a hardware wallet for or we’re the software in your hardware wallet for Lightning notes. 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. So, you can see how it’s. Even harder to. To do, but still, that’s actually not a terrible analogy at all, and in fact it might look exactly like that. A very, very good model would be you’re running a node and you have a serial cable, a USB cable with a serial connection to a small device which is doing the VLS software, and that’s much more secure because to attack. VLS through the serial cable is much harder so.
Stephan Livera 00:13:35
I see. So then one of 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 duplicate. Thing across the node. Let’s say the online connected node and then the VLS which is you know that but 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.
Ken Sedgwick 00:14:02
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 do we have to be exactly In Sync on? We have to be exactly In Sync about commitments. We have to know when. What does it mean for a commitment to? If your last commitment was this one, and you’re the proposed one, is this one, is this a reasonable step to take?
Stephan Livera 00:14:28
And just to explain for listeners then there’s the with Lightning that 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 where we have to know what the commitments are and the general operation is that we’re passing back and forth these pre signed commitment transactions and that’s what you’re getting at with this commitment. Idea, right?
Ken Sedgwick 00:14:47
Yeah, that’s exactly right. 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. Good, 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. We’re doing those, bringing in additional set of checks. On it. So, the concept that you 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 going to protect your funds even if your node is not even working for you. Many more, and there’s, you know, dozens or hundreds of ways in the Lightning protocol for the node to cheat you and 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 final. Resolved is consistent with your policies. Basically, you’re not losing money now, there are obviously cases where you have this little bit of slippage like fees are going to slip a little bit and we’re going to velocity limit them And so on and so forth.
Stephan Livera 00:16:14
Yeah, Okay, You know that’s right. And so let’s talk a little bit about that because it’s like I like that idea. It’s it reminds me of a similar concept in hardware wallets, right? The idea is even if my let’s say I’m using Spectre 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 here and so I’m trying to validate with and. So how do we achieve this? There’s certain policy rules that you’ve built in, so maybe it now’s a good time. If you could explain a little bit about how those rules are done in VLS.
Ken Sedgwick 00:17:00
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 in. 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 going to both do the same. And so, you propose a mutual closed transaction to me and if I agree with it, I sign it. Now if my note 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, you know, to A to an address I don’t control. And so, the VLS 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 layer one cold storage in there for sure, so you can always send money from your node to your cold. If you have other team nodes. So, like if your company operates 5 nodes, you may have the other nodes listed in there so you can move money between the nodes without worrying. You can use X pubs to do that so that it’s efficient. You can set it up and don’t have to be editing it all the time anyway. When the closed transaction comes in, we know what your expected. Balance was previously and we look at what we think you’re getting out of this closing transaction and if it doesn’t, if it falls outside a threshold which 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. So that’s an example of a policy that a closing transaction must deliver your value to you. It’s very simple.
Stephan Livera 00:18:44
Right minus like, say, a small percent for fees, something like that.
Ken Sedgwick 00:18:47
Fees are always a challenge 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 0 fee anchors we getting to the point now where we don’t have to Filled in a fee with a lot of guesswork, but what the fees are gonna be next week or next month. So instead we can just say, well, we don’t put the fee in here and later you’ll bind it. Another thing which 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. 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. I forgot where.
Stephan Livera 00:19:38
Could that be provided by something like mempool.space or something like?
Ken Sedgwick 00:19:41
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 going to that we’ll probably talk about are very clinical. They don’t. They’re not judgmental. The problem with fees is it requires some prediction math that 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. 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 sweep certain things, especially with respect to justice transactions. So, the handling of fees there it gets really sticky, because 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 need to allow you to be aggressive with fees when you need to be.
Stephan Livera 00:20:37
I see, yeah. It could be like a false positive if you yeah, it might 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 back up and now you need to put in your transaction to take what’s rightfully yours That’s where the difficulty can cause.
Ken Sedgwick 00:20:58
That’s exactly it. And the case is, if it’s a, it’s a severe attack. If it’s a really bad attack, they’ve held. You up in a bunch of ways, right? I’m throwing 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 things of ways they’ve managed to mess you up. And so now you need your fee needs to escalate pretty aggressively to make sure that you get it cleared in time. Now hopefully these are going to be what I’m trying to get at is this. Well, sounds painful, but really it’s much, much better than the alternative where you just trust the node and the closing transaction sends all your money somewhere else, that’s very bad.
Stephan Livera 00:21:40
Right, that’s the nightmare situation. And so VLS as you mentioned, because we’ve got this Lightning layer, right, the peer-to-peer Lightning layer. And then there’s also on change. So is VLS looking at both components here?
Ken Sedgwick 00:21:51
Yeah, I mean it. It signs for both So absolutely right. We sign when a channel is created, there’s an on chain transaction which creates the funding transactions. Sometimes those are batched, so VLS is involved in looking at that and saying Okay, so we’re putting this much money from our wallet into this thing, but we’re getting three channels. Out of it and our portion of these three channels is you know this. Much and based on that, we can say, Oh 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 command line prompt, say pay this invoice. VLS will ask the user, so hopefully on a trusted display, this depends how it’s built, but VLS, just like a hardware wallet will say, do you wanna pay this invoice and it will list the invoice details and you can say accept or decline and if you decline then Phyllis will not allow that. Payment and if you say accept then it. Will let it go through.
Stephan Livera 00:23:03
Right. And so, the, I mean, we’re talking about all this stuff, but the overarching end goal is that Lightning nodes can be run more securely, which in turn helps more people run larger Lightning nodes or just be more comfortable running a Lightning node all together. 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 are hundreds of Bitcoin hundreds of bitcoins on them, and so they need something.
Ken Sedgwick 00:23:31
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 in the node, but with Lightning you don’t have the option of having nothing so yeah
Stephan Livera 00:23:46
And so, I guess Yeah, just explaining some of the policy rule. 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 themself or another way might be to try and let’s say close the channel and take the file like send the funds 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.
Ken Sedgwick 00:24:18
Yeah, I think actually we’re it, it’s fairly complete. I we don’t think there are like any. Good ways. The ones where the smaller ones that were tapping down 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 or they have to work with a minor to and have to be very lucky in some cases. So, we feel that those attacks are. Going to 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 feed 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 better. But that’s, you know, far on the horizon, so.
Stephan Livera 00:25:11
Yeah. Okay so, I guess that’s the question I wanted to ask. Are there any what scenarios does VLS not cover?
Ken Sedgwick 00:25:22
Well, VLS requires that the operator be honest, right? I mean, you have to. So, one thing that we say about the 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, closed 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 and they can observe and they exceptions have to be made by them, so they have to check, yes. If there’s an exception, or if they want to bend a rule, or if they wanna open the velocity limit up for a week because there’s something going on, 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 doing right, so.
Stephan Livera 00:26:15
Yeah, right.
Ken Sedgwick 00:26:18
Another one is the if we talked about a very large system, then the temptation is to build an API to do the approvals and all that sort of stuff And there been some famous hacks where those API’s themselves have been hacked, so it’s tempting to build an API which is then needs to be protected with another old. System which is just this conflict. So that part we don’t actually really solve, you have to approve correctly and disapprove correctly and we can make it so. But and I think that’s a huge advantage, but it’s still not a yeah, it’s not a non-problem.
Stephan Livera 00:26:53
Gotcha, Yeah, because in this analogy. Yeah, it wouldn’t be 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 because you know, yeah.
Ken Sedgwick 00:27:07
Game over. I mean, you’ll just be able to send. The money to the hacker the hacker will be like, well, that assumes a hack, but a very simple hack nowadays would be that you somehow got RPC access to the lighting node. So Lightning nodes have RPC access for millions of reasons. Everything is done with RPC access on all the. Foundations 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 worst right because they go immediately and they’re effectively it’s cloaked immediately, so it goes out. The Lightning network and you have no idea. Here it is.
Stephan Livera 00:27:50
Yeah, gotcha. And I can imagine where so this might be in context where somebody is trying to connect to 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. So as an example with L&D they have macaroons. Like so you can have like read only or invoicing capabilities. And I think on the core lighting side, I think it’s called Runes, but. 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?
Ken Sedgwick 00:30:21
Yes, that’s exactly the idea so, macaroons and runes are great, but they are enforced by the nodes so it in the simple model where the node has been hack then they’re being enforced by the bad guys. So now there are some. It is tempting to have some other thing. It’s not exactly a runes or a macaroon that you could send to VLS, which so it’s a signed thing which says I have given I wanna add this to the allow list. There you go. That’s an easy to understand example. I want to add this Address to the all list. Now that’s. Very handy and that’s a great admin function and it’s convenient and it would make a lot of user flows go really well. If you know, then 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 allow list is a very, very clear obvious. Yeah, if they can add their own address, then it’s game over.
Stephan Livera 00:31:16
And then it’s game over. Okay and so when it comes to the different implementations, which implementations does VLS support?
Ken Sedgwick 00:31:24
So, today we’re highly integrated with core lighting. 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 it the top and it builds both systems and runs all the integration tests and so and so far that that we use that for testing and for demonstration so, so that’s core lighting LDK. We’re highly integrated in that we use LDK code, so our models for what the interfaces look like and the APIs look like. Internally, our LDK defined generally whenever possible 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. 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.
Stephan Livera 00:32:37
Yeah, Okay. and so, is the plan then to have other implementations supported over time like, I don’t know Asycn or L&D and things like this.
Ken Sedgwick 00:32:45
We want it to work with everybody, so really if possible, we’d love to make it. Actually the protocol of standard and even support, you know, competing implementations. But there it seems like there really needs to be 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 L&D, there’s a project called L&D Signer which is done by NYDig. I don’t actually I don’t know if they’re NYDig or whatever.
Stephan Livera 00:33:21
I think I think they say NYDig anyway. Go on. Yeah, but night.
Ken Sedgwick 00:33:23
NYDig has a project called LED Signer and we’re in touch with them and they. They’re working towards a proxy so that they can connect to L&D and connect it up to a VLS remote signer In fact, in CLM we exactly use a proxy. So, we replace a CLN component the HSMC D Demon with a remote HSMV which is. Looks the same to CLN but instead proxies all the requests to us. And then we sign them and send it back.
Stephan Livera 00:33:57
Gotcha Okay, 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
Ken Sedgwick 00:34:08
Both, and so, we are sponsored by Blockstream and but we’re integrated in green light. So green light needs a signer and it’s in its flow in its diagram, there’s a spot for a remote signer that’s part of its vision.
Stephan Livera 00:34:16
That’s right, yeah.
Ken Sedgwick 00:34:21
And early on, they decided, you know, they used their own native signer initially I believe, but pretty quickly switched to the VLS because we were completely compatible with that signer to due to the other way we were working, which was the replacing the HSMC. So yes, we’re currently the signer in green light and working with them on that.
Stephan Livera 00:34:42
Gotcha, and that also makes a lot of sense for their context, which is the idea. Is in that context block stream 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 VLS can come in, because that might be what’s operating on the phone.
Ken Sedgwick 00:34:56
Yeah, 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 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 running 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 want to put it in an embedded device or in and you want to run it in a web browser or there are 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, got you. Stack work and sphinx. They’re the related dev teams are building something using ESP 30 twos. Right now I think it’s about a $10. Part and 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 stack work or anyone else.
Stephan Livera 00:36:34
Ah, 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 it from down from that ESP 32 device to a mobile phone all the way up to the enterprise grade HSM hardened server. All of these things can run VLS. That’s the idea.
Ken Sedgwick 00:36:55
That’s the idea. 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, see your Python or what have you, you tend to need more in terms of library support than rust, rust is more self-contained that way rust is very good for embedding. I personally have been using. Doing stuff with the STM 32 this guy here. So, 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 can get. Weird rust on embedded environments is really pretty good. Now HSM’s are another interesting case, but we’re gonna it’s gonna take us a while to get there, because those generally require. Let’s sorry, we’re. 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 I think the best thing you can have is a really. Precise 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 the HSM, but you know somebody with political clout needs to solve some. Of these other problems. We definitely can run on a protected Unix server today, so a very, very good option for a lot of people right now. It’s probably to have a rack in a secured location where you’re running VLS This 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 in many examples and there is no one-size-fits-all here but running it on a general Unix server is. Very straightforward. We do that all the time now.
Stephan Livera 00:38:51
I see. And I mean, it makes a lot of sense I know there are some large lighting 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.
Ken Sedgwick 00:39:04
Or even in a different cloud. So, a very, very good model is to say my nodes are over here. In this cloud, they’re running on this. Operating system 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 attacking the node isn’t good enough. He can shut it down effectively, right 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. He doesn’t have those attack entry points. He doesn’t have gossip, he doesn’t have the RPC gateway, he doesn’t have all those things.
Stephan Livera 00:39:46
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 want people to be able to securely. Spend it, and using Lightning of course, because you get the instant settlement and cheaper fees depending on the you know, the fee rates at the times. And yeah, there’s a lot of functionality, so it’s actually strikes me as quite an important project. If Lightning is going to 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? Would that look like?
Ken Sedgwick 00:40:27
It’s very exciting I mean the multi signal, imagine the same setup we just talked about, except instead of a single signer, now we’ve got say 5 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, any of them in order. It’s the standard multi sync. 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 any of them? It depends how you build it, but three out. Of five or is a four. Those are our typical things that people talk about 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. But a user, a low-end user story is that you have your phone and you have the Wall wart 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 Green Wallet. In the old days, and so you can. Use that sort of set up, which is very heterogeneous. There you’re not just get, you know, three out of five. 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 if you know what I mean. Those heterogeneous setups can lead to a lot of really cool. Things for users as well.
Stephan Livera 00:42:17
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 to and frost. And so, do you want to just elaborate a little bit on what the, what the relation is there for this?
Ken Sedgwick 00:42:37
Sure. And this is where I mean, dev random’s gonna be a little stronger here than me, but I so taproot is working and it’s great. And the music part is all very good. But then we get to there. Several hard parts, so the contested 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 revealing key secrets to you. There’s an a trick to storing them so it doesn’t use unbounded storage. Otherwise every single commitment you would 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 is not 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 see how many people are in here? there are 34 people in here from all different company. And so, everybody’s discussing it, batting ideas around and so on and so forth that there’s an idea right now, which I think is going to maybe going to work. It was discussed today in the Lightning Developers Protocol group that we could just use 10 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 simply export 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 to five that way and it it’s not terribly, it’s not as bad as it sounds. Remember, the revocation stuff is only comes into play. When there’s a justice, you know when there’s a justice thing going on, so it’s Okay if it’s a little bit unwieldy otherwise
Stephan Livera 00:44:48
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 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, HCS, etc. And I presume at every moment he’s running a Lightning node with VLS, He’s got to also now kind of talk to other VLS into you know the multiple ones before being able to sign that channel state update
Ken Sedgwick 00:45:20
There’s a minimal number of round trips and everybody’s working to reduce it 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 very small loan, it doesn’t have much traffic, then the fact that it took one second. Instead of half a second or 1/4 of a second isn’t terribly important.
Stephan Livera 00:45:44
Right, Not a big deal, yeah.
Ken Sedgwick 00:45:45
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. It’s isolated, so those could be proceeding in parallel as 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 yeah, linking 2 things like a different payment can be getting rather 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. Need, even though we’re doing that kind of those extra round trips.
Stephan Livera 00:46:31
I guess yeah. So, I guess the short answer is parallelization is.
Ken Sedgwick 00:46:35
Parallelization.
Stephan Livera 00:46:37
Yeah, Okay.
Ken Sedgwick 00:46:38
Yeah, really, when it comes down to it, if you’re trying to protect $100 million 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 is not actually the problem.
Stephan Livera 00:46:53
Right, that would be considered table stakes. Yeah, yeah.
Ken Sedgwick 00:46:56
Yeah, the problem was a bad guy could get in there. I mean, you know, or a dishonest employee. The usual thing that having to protect each one of those things individually is really harsh. But having to say that now that guy has to take over two of them or three of them is a good deal. And so, you would absolutely be Okay with, you know, stepping up and making it. Faster getting the software architected so it can do that is the key, and that’s what we’re.
Stephan Livera 00:47:23
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, I think that’s a fair answer. And when it comes to relationship with watchtowers, right, so maybe we can think of these as independent things that both help increase. Or improve the security and maybe in the future watchtowers will be more prominent or there’ll be more people using them and maybe that would be in an L2 or let’s say a 6L N symmetry world. Where we have VLS working and watchtowers, maybe that they’d be both operating to increase the security for the users.
Ken Sedgwick 00:48:02
Right and VLS does have a, there is a watchtower angle there, which is if you’re using a Watchtower, VLS probably needs to know that the needs a signed attestation from the Watchtower that it has what it needs in order to take the next step 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.
Stephan Livera 00:48:35
Right. Once we move the taproot channels, that is.
Ken Sedgwick 00:48:37
Yeah, I think the watchtower stuff gets much better somehow. And although I don’t not really clear on why. Yeah, but hope that we still need to know that you’re tap roots that. Sorry that your watchtower is up to speed before we go on. Because it’s, you have to check your parachute before you.
Stephan Livera 00:48:52
Right. Yeah, of course. Okay and so, let’s talk a little bit about then protocol upgrade. So, we’ve touched on some of these, right obviously the biggest. The biggest one? Would probably be Ellen 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 Vault12 or route blinded routing or some other thing that comes means you’ve got to now update VLS.
Ken Sedgwick 00:49:27
So Vault12, we’ve already done a bunch of work, Vault12 is actually multi layered. So, at the very base level, Vault12 invoice needs to be approved just like a Vault11 invoice the Now the Vault12 invoice went through more round trip. And protocol to get there, but it’s the same thing at the signer level. Is it Okay to spend 100 bucks here? And you gotta say yes, there is additional things though. Higher up in Vault12, which are interesting though, like, for example, if you’re watching a movie, you might wanna say I would approve paying up to $10 / 48 hours to this. This node and so that’s an example of a Vault12 recurring payment which Vault11 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 Vault12 Concepts so that we can a user can approve a higher-level payment. It won’t do for the user to have to approve every nickel as you’re paying Netflix to. Watch a movie so.
Stephan Livera 00:50:29
Of course. Of course. Yeah. And I can. I can imagine. You know, you might have, like, payments where it’s like $10 every month or maybe $10 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 $50 a day or whatever.
Ken Sedgwick 00:50:46
You exactly got it. It gets. It gets tricky and it’s infinitely customizable, so I’m not worried there. I think we can build sensible things for different use cases so that home users can easily set up payments for movies and other things like that or can set up monthly payments because that’s gonna be a lot of their payment stuff and they may wanna give allowance. I mean, there’s just. Anyway, I don’t want other features which are coming up and in the sort of on the near side. Splicing is now, you know, getting well, it’s being released in core Lightning today. I think the core Lightning is in release candidate 2 of 23.08 and so they will be releasing 08 soon and that will have experimental splicing support. So VLS will have to do some work to make that work, but again, Splicing is really sort of the same Idea, which is when you’re splicing out, we want to 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 want to 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, it’s. That’s up to him.
Stephan Livera 00:52:07
Gotcah I mean, it’s interesting to see. So I guess it’s just like this project sort of has to keep in line with everything else that’s happening in Lightning because it’s the same thing. You’re replicating the Lightning state machine.
Ken Sedgwick 00:52:17
Well, not everything.
Stephan Livera 00:52:17
Or at least parts of it. Right. Yeah, just the custody part.
Ken Sedgwick 00:52:20
Pick card payments, which are also coming out in core light this week. We don’t have much to do with I mean we. Have to approve the payment, but that approval is exactly the same as any other payment. So, there’s a lot of technology and math involved in the model for how that works and it’s exciting. But VLS doesn’t have to change at all for that. 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. PTLC’s is another one, so that will the all of those things.
Stephan Livera 00:52:56
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?
Ken Sedgwick 00:53:07
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 could work on. So, we’re, we’re open to accepting merge requests, we’re on GitLab, so it’s merge request and set up pull request. Same thing. We also need people with all sorts of other skills, though, so recently the team added Jack Rinaldi, who maybe you talk to who’s doing product management stuff for us and it’s fantastic because he’s able to get us connected to places that need us. But there’s a lot of communication that has to happen and describing what does it mean. 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 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 to. Make a killer Lightning thing and it needs it. It can use VLS. Please come talk to us because you know we. Everybody’s actually, it’s not just the 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. We give you an example. L402 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 to be less so that your so that your Bitcoin wasn’t stolen. That would be a bad, you know, experience. So, we’re if you’re working on something like that, you know, come talk to us, because maybe there’s an API that we need to add or something we need to be aware of which can help you.
Stephan Livera 00:55:05
Well, yeah, it sounds like a great project to me Hopefully I’ve got a lot of developers and technical listeners and hopefully some of them are interested to come and get involved in some way, yeah. So, let’s finish up here. So, Ken, where can people find you and find the project online?
Ken Sedgwick 00:55:21
So, the simplest thing is vls.tech, so vls.tech 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 on vls.tech. We have a bunch of matrix groups. Is what we’re 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. Please come in and just type in your question and we’ll be glad to answer it. And then we do the 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. Want to we want to work with you, Okay?
Stephan Livera 00:56:04
Great, 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 soon.
Ken Sedgwick 00:56:12
Thank you, Stephan. There’s been a lot of fun.
Stephan Livera 00:56:14
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 stephanlivera.com/502 Thanks and I’ll see you. In the Citadels.