CD112: Lightning Node Security with Ken of the VLS Project (HSMs for Lightning)

Happy Bitcoin Wednesday, freaks. It's your host, Odell, here for another Citadel Dispatch, the interactive live show focused on actionable Bitcoin and Freedom Tech discussion.

I am honored here to be joined

by Ken, the cofounder of VLS Tech.

His project is focused on improving the security

of lightning nodes. We've talked about lightning nodes many times on this show.

We've talked about

key management risk. We've talked about how you would always prefer cold storage over hot

wallets,

when it comes to protecting your keys because you don't want them to connect to to the Internet. But at the same time, this show,

I run 5 lightning nodes, and I know a lot of the freaks run lightning nodes. We're all doing them on hot wallets. So today, we're talking about how we can improve the security

of our Lightning Nodes. How's it going, Ken? Welcome to the show. Great. Thank, thank you, Matt, for having me.

Looking forward to talking about how to make Lightning more secure.

So, I mean, where where should we get started here? What is,

I I guess an interesting part to get started here is is what is your background specifically?

So I'm an engineer.

In the earlier days, I was a performance engineer. So I worked with UNIX systems, threading,

parallel processing, stuff that run-in ran in server racks.

Almost never do UI. When I do UI, it looks really bad. So

so I try to work with people who have much better sense than I do in that.

In around around 2013, I got interested in Bitcoin and, decided to do a project

in order to,

learn things and meet people. And so I wrote a an Android wallet,

and I it succeeded in,

meeting people and learning a whole bunch of stuff.

I'm

no longer interested in doing a a wallet like that,

but it did get me very interested in Bitcoin custody. What was the name of that wallet? Do I know that wallet? It was wallet 32.

It had a Walrus as a logo. It's a long time ago. I dig the Walrus logo. That's a great logo.

And it was around for about a year, I think.

I think it was the first

HD, you know, bit 32,

Android wallet. And so I had used Electrum before that and thought, wow. This, this whole HD thing is really great. It's a really,

excellent way to back up a wallet because you only have to save the one seed,

and then you don't have to update that backup

as, as you add addresses and and use the wallet in daily use. And that was the case with,

wallets which came before that. The backups were frequently a weak point,

and that they weren't up to date. And they were also since you're touching them so often, they were less secure because you had to go, you know, get them and update them. Kids these days don't know how easy they have it.

They sure don't. I mean, literally, files with lists of addresses and keys in them sometimes. It was really awful.

Earlier, when you did your intro, you mentioned that you guys are running hot wallets, and, I was just gonna add that chime in with well, you have to because, the lightning

protocol requires that the keys be available,

in order to update the commitments even when money is not being sent.

So, for example, if the fee rate changes,

then the commitment will be updated in order to have a a fee rate which better, predicts

what it might need to be.

And so your

your node needs to sign that updated commitment. Right. To receive money, same thing. So you're gonna see a new commitment,

which has more money on your side of the channel, which is a good thing. But you have to assign it and say, yes. This I approve of this. This looks good.

And so for those reasons,

lightning nodes

cannot

be usefully cold. They really have to be hot wallets By design.

By design.

Another

related thing is when you're doing

a hot wallet for an exchange or a broker or any kind of large,

enterprise,

you would endeavor to keep most of the funds out of the hot wallet. You would only have in the hot wallet what you needed to do day to day stuff.

And frequently, you know, at the beginning of the week or the day, whatever your business is like, you would estimate how much funds you were gonna need and then, you know, put that amount in for the day or, you know, for the time period. Because if your hot wall is compromised, then you just lose 1% of funds or whatever.

Exactly. Always minimize.

It's just like the till in a bank. The tellers are gonna have small amounts of money. And if you need a really big withdrawal, you have to arrange for it ahead of time, and then they go get it from the safe or a different branch even.

So

the point is that the oh, I know where it was. In in the Lightning Network, you have to keep liquidity

available. Right. We really can't take it out of the node. You need to have a bunch of liquidity in the node,

and then that's what makes it useful to send money to other places and do routing and stuff like that. And both of these things lead up to sort of astounding amount of money at risk because it's hot,

to do a quick thing. Like, if you were a large retailer and you had a 1,000,000 channels and each of them had a $100 in it, That's a $100,000,000

in a Internet connected

interactive computer, and that's frightening. And, yes, specifically, to have outbound liquidity, to be able to send payments or route outbound, you need to

have equivalent amount of money locked up on the node.

Right.

And so Dev Randham,

my cofounder, and I,

I guess it was 3 years ago or so,

had previously been working on a a Bitcoin custody,

thing for enterprises and stuff, and we were looking for,

something more interesting to do. And

and this lightning thing looked like it was dangerous.

Right. Hashtag endless.

We we needed to, you know, we needed to,

raise the game, find some ways to make it safer.

One thing that's worth pointing out is people are comfortable with Bitcoin

wallets

because in many cases, they only have x pubs in them. In other words, to receive money, you don't have to have any funds hot.

You can receive directly into cold storage.

So the sensibility of people who were used to working with Bitcoin was that it was, you know, kind of this safe. And the problem was that lightning is a really different thing, and it's not that safe. It's much more dangerous.

And so we wanted to try to find ways to make it safer.

And so that's where VLS comes in.

Yeah. I mean, Ken, it's it's pretty crazy.

So, I mean, I got into Bitcoin around when you got into Bitcoin.

And it's just pretty crazy, like, the

for big corners that came in post lightning,

maybe, like,

I'm not gonna include, like, the first two years of lightning, but, like, they came in, like, 2020

or 2021.

A lot of them might have come in as lightning first, And and and for me, it was obviously the opposite. Lightning didn't didn't exist yet. And it's so interesting, you know, everything has trade offs. We talk about that a lot of times in the show.

But it's interesting how the trade offs specific for lightning

have kinda turned on its head

all of these,

axioms or,

you know, the the these these general best practices that we talk about. These ideas of of keeping your keys cold. Right? Like,

these ideas of

of

of not using custodial wallets. We see way way more users are using wallets on lightning because of the trade off balance that lightning presents and makes it difficult to use on mobile.

And it's just it's just a real it's to me, like, I've

I've personally come to appreciate

off,

on chain Bitcoin, regular Bitcoin transactions so much more because I've had to do so much

in in the lightning space. Just this idea that, like,

you can actually generate your keys cold and receive Bitcoin to

to an address without ever going online, without having to deal with liquidity that, like, self custody is incredibly easy on on something like mobile

where you don't need to have, you know, 247 interactivity and all this stuff. And Lightning just adds all these this complexity to it and what is the benefit that we get out of it. We get we get cheaper transactions.

We get, you know Faster.

Extremely fast settlement.

Basically, instant settlement.

Hopefully, is much better as well. Tangential privacy benefits, especially on the sending side. So ever since lightning began,

there's been 2 major promises that I've heard,

many times repeated,

is is some way to secure the hot wallets, you know, some kind of additional signing mechanism to secure the hot wallets.

And,

this idea very easy,

sovereign

as sovereign as possible mobile lightning usage. So, obviously, we're gonna table that second one.

But the first one, how do you guys how are you guys thinking about

solving this this hot wallet risk issue?

So so, actually, what you always wanna do in a security situation is use the simplest, cheapest, easiest

technique, which gets you the security you need. And you only raise the you know, go to a a more expensive or more difficult technique

when it's required, when the simple thing just won't work anymore.

So in the case of Lightning, all we're doing is

using another tried and true technique, which has been used for, you know, forever

in other businesses. So when they did have to have signing that was happening, you know,

and it was hot, then folks used HSMDs.

Right. Oops.

Make sure I'm still am I can you still hear me? Yes. Sure. HSMDs.

Okay.

So we're we're modeled on an HSMD.

So HSM is a hardware security model.

Takes the keys out of the

entity that needs the signatures and puts them in a safer computing environment

and then,

protects them

with all sorts of additional,

things. So you What does d stand for an agent? Surface by making it a that's independent computer, and then you make it a much tougher,

computer to break into. It might run a different operating system. It's gonna have much less

operating system interface, and it's not connecting to, hopefully, any other computers.

I mean, we can think of VLS is doing. It's basically

an HSMD

or hardware signer, if you wanna think of it that way,

for a lightning node. What is the deal? You mentioned mobile, and actually, VLS may have an impact on mobile as well,

because what we're doing

is distilling the custody aspect of the Lightning Wallet to the smallest amount of code. And, ideally, in the future, we'd love to run that in the trust zones in phones.

And so DLS may be a candidate at the low end as well because you can that in that way, you can protect your keys, on a phone or other similar

small,

device.

Can you hear me, Ken?

Uh-oh.

I think so. I think I lost my

headphones there. Can you still hear me? I can still hear you, but I don't think you could hear me.

Give give me give me one second. Let me see if I can

He secured himself out of his headphones.

Yeah. I guess he heard that part.

We're hanging in there with you.

Okay. Then I held him back on once. He was disconnected for 10 minutes while I just talked to the audience.

No. I I can hear you fine,

as long as we're not getting feedback through the microphone.

Yeah. I don't hear an echo.

So then let's just Very good.

So what is what is d stand for an h or HSMD?

Damon?

Damon. Yeah. So

when Corelightning was setting up their architecture,

I don't know if you know Core Core Lightning well, but it's based on having multiple teams that all intercommunicate,

and that gives them them some security benefits. Because if you, for example,

take over a channel d, which is talking to a channel partner, that doesn't give you access to the, the state of the signer. That's in a different one. That's the HSM d. So it's hardware security module daemon.

Now Corelightning

names it that, but it's not really an HSM. It's sort of a HSM goes here kind of identification.

It's as per as Rusty puts it. And so we're actually trying to make that true. So the basic idea behind VLS when used with core lightning

is you remove the HSMD and you replace it with a proxy.

And the proxy

just

handles all the exact same commands as the HSMD would, but it sends them through a

secured connection

to a signer, which is

hopefully located somewhere else. You don't want it in the same, computing environment.

You can use different kinds of communication. So a very secure way to do it is via a serial line to that signer, which is then otherwise not on the network.

And that becomes really hard then for the attacker to get onto the signer because it you know, serial line has much less attack surface.

Got it.

So, I mean, if I was in in simple terms,

like, big picture on on how you visualize this,

I'm running my lightning node in some some

server farm somewhere,

and then I have a hardware signer somewhere else, and they're connected to each other. And the hardware signer is always interactive because it needs to constantly sign updates and whatnot.

Now

use

on your website, you talk about a blind signer versus a validating signer.

Presumably, a blind signer just signs everything that they're given.

And then Right.

Your your concept is a validating signer, so the validating signer is

is actually

checking what it's signing, and I guess is listening to some kind of preset rules that the user is setting, like, sign anything that falls under this?

Well,

so there's a bunch of different let's see.

First of all, blind signing is incredibly dangerous because if a node gives you, for example, a closing transaction,

and let's just for, purposes of discussion say that a channel was 50.50 balance, so you're entitled to half the money in the channel. But if it gives a blind signer a closing transaction where all the money goes to the other guy,

then they've just stolen all that money. It doesn't really solve that. Sign that transaction, you're giving away all that money.

So a validating signer would know that that wasn't the case and would,

decline to sign that. It would refuse to sign that.

The

policies that it's enforcing

are designed so that even if the node is is completely compromised so our security

model or assumption is that the node has been completely taken over,

by a bad guy and is now, you know, doing everything it can to steal the money, and we are going to prevent that. We will not allow you to lose any significant funds,

because we're able to

see the state and make sure that we don't sign things which lose money. Does that mean that the small well, go ahead. Does that mean that the signer is essentially running it's a full lightning node on the signer side too? Because they need to understand what the state is and what's going on. It's far from a full node. So the node has just tons of stuff which do not relate to custody. So you have routing, you have gossip, channel announcements.

We can go on and on all these different things, which don't really affect whether or not you lose money. But the signer is doing it, does have a complete set of,

signer states. So for example, it knows the commitment transaction for each side.

In some cases, it has to know 2 about the remote one. So when you send a new one to the your counterparty,

you know the new one that you've sent, and you have the also the old one that,

the the last one you heard from him

about. So it could be either one of those.

And then when he, revokes his old one, then you're back to just the new one.

Anyway, we have a complete set of states, so we can

enforce that you don't lose any money.

Got it. But it

right. And it needs to be it needs to have some kind of view into the into the network and what's what's going on with the node, I guess. Well, it turns out that

the signing messages themselves

give you almost all the information.

So

Gotcha. When a channel is opened, they're gonna ask you to sign the commitment and the funding transaction, and those define what the channel setup looks like. And,

for example, we can look at that and go, okay,

it's transferring 10,000,000 satoshis from the on chain wallet, and it's going into a channel that has 10,000,000

satoshis value

to this side.

And so that's cool because that means you're not losing any money. We can get that back.

And so that's, for example, how we would look at an opening transaction

to make sure a funding transaction to make sure that it was okay to sign that.

Similarly, with a closing transaction,

we're

we know the balance, what it was, and when it's time to close, we wanna see that the closing transaction delivers your fair share to you.

Right.

Another thing to add is

a node would have an allow list. So it's a list of addresses which are safe. A good example would be your cold wallet for your layer layer 1, your Bitcoin,

addresses

should be, you should have an XPUB there, which so you can always transfer money out of your node into your Bitcoin cold wallet

without having to do any additional stuff. It will just, you know, allow you to do that because it knows that those addresses

are yours, and and you're not losing money when you send it to them. Another example is

if you're a large operation and run multiple nodes and have connections between the nodes,

you can put the other nodes in

a given nodes allow list. And so it knows that it's okay to do, for example, a key send from one node to another, doesn't require additional

approval or processing because it knows that that money is still in your,

your custody. It it it's still beneficial to you.

Got it. That makes sense to me.

Because that's the the the core the core of the problem is

is is, at least in terms of fund loss,

I guess,

there's there's 2 main there's 2 main vulnerabilities and

I don't know if that's the right way to phrase it. In terms of fund loss, if you're a lightning node operator, there's 2 things that a malicious actor can do. They can do a malicious closed channel state where they're lying about what the balances are on the close, or they can just withdraw money from your node. They can just literally just press send on chain transaction. Right? And this is designed to protect against both those situations.

Sure. There's also you could make payments. So simply a bad guy, if you didn't have any on chain payment, like an on chain withdrawal or whatever. Oh, on chain. Oh,

no. Like, it's all in lightning. Just say, kisend, 10,000,000 satoshis over there. Right. Right. Right. That money's gone.

And so and a blind signer would sign it because they don't know not to.

Interesting.

So

I would say it's really sort of 2 things. 1 is you want it to keep the keys remote because if the bad guy has the keys, obviously,

they can sort of run them up and do whatever they want. Right. But then, the next thing you quickly realize is simply moving the keys remote is not nearly enough because there's too many ways to attack. We just outlined 2 or 3, the closed,

sending money or withdrawing money. But I think if you think it through, there there's really quite a few,

different ways to lose money. And that's and then there's griefing. So bad guy can do things where the money gets held up or is burnt to fees. We wanna make sure that,

the amount of money going to fees is appropriate.

Fees are a hard thing, actually, because you you're gonna see a little slippage due to fees in normal operating,

and we have to allow that. In fact, we really can't interfere with that because if the if the fee market is high, your transactions need to go through, and so they need to have high fees in order for you to defend against,

breach transactions and other things. There's, you know, parts of the lightning protocol that require timely

resolution.

So fees

are,

an area that we're constantly focusing

on and working on. I think in the future,

we're hoping to see a

useful

fee oracle infrastructure

developed, not just for us, but for everybody. Everybody needs it. So what you need is a way to ask a bunch of trusted computers,

please attest to what you think a reasonable fee is to get something, you know, closed in 24 hours or, you know, whatever you pick. And those would be signed messages, and you would be able to say, okay.

3 out of the 5 have said it's this. So I think that this is a reasonable fee number, and then you could

veto a transaction that spent 10 times that in fees, for example, because that doesn't just doesn't look reasonable.

Right.

The the key thing is actually to

to distill exactly what you need to do custody and no more. So

Yeah. So smallest amount of state and ethnicity. I like that.

And then that

not only makes things more secure, but it does also offers other opportunities

to establish custody in places where you can't run a full node. So a very common idea

a very good idea is to run most of the node in the cloud,

and then just have the end user have the smallest amount, have a signer, a VLS signer, so that they control

custody of the funds, but the actual operational

stuff is all all done in the cloud.

And so, Blockstream's green light is doing exactly that,

and they've they're using BLS as the signer inside green light.

So that That makes sense to me. We've covered that

to a degree, at least on the service level, like, also Breeze SDK,

this idea that, like, the keys

are on the phone. Right? And but the the node is in the cloud.

So you you but

that comes with the negative that,

I mean, first of all, you're there's not gonna be a routing node in that situation.

And then second of all, there's needs to be some level of interactivity. Right? Like, to receive, you need to actually be online, and your your phone needs to sign things. Right?

I think you actually could be a routing node.

Let me outline an a new thing that we're working on right now. So this is not in VLS just yet, but we're hoping it will be in the next release, which will be in a couple months.

I'm calling it tag team signing.

So what you have is 2 different signers, but they have the same keys in it. They control the same custody, the same,

lightning wallet, if you wanna think of it that way.

But one of them

is on 247

and only receives. So its policies are set to, I only receive money, I don't send money. But routing would be okay. You might you could have that one do routing, for example.

And then

a separate signer, and maybe that one's on your phone,

but it doesn't need to be on all the time. It's really not on all the time. But when you wanna make a payment or do something exceptional,

like make a payment, you would turn on your phone and that signer would tag the other one and say, hey. Let me do this. Let me do it for a bit. First, I'll come up

to bring my state up to sync, sync up my state,

and then I'm gonna make a payment or 2,

and then I'm gonna tag you again and we'll transfer control back to the other signer to do receive and route only.

And that that has a very appealing features

for

folks who

mostly receive and occasionally send, and it also has nice features for,

robustness.

Because

if you lose one of those signers, you've still got the keys in the other or if the, you know, the signer's destroyed or something like that. So it seems for multiple reasons to be a a really

great way to go.

But then you're expecting the user to be running VLS somewhere 247?

So Stackwork, another partner that we're working with,

Sphinx is another name for the same guy. No. No. Sphinx is,

like, he's got Paul's got 2 projects, Sphinx and Stackwork. Yeah. So we're working with them, and they're putting VLS on a very small hardware device at at ESP 32.

I I

don't quote me on this, but it might be like $10.

So it's a little bit on a 10. Yeah. Fairly inexpensive.

And the the vision there is that you would plug it into a wall socket in your house. It would connect to Wi Fi and then connect up to the cloud

where the node is actually operating and do the signing that we're talking about. So that would be the receive

only signer. It would just it's not, like, a full lightning node, the hardware can be much cheaper, the bandwidth is less, everything, yada yada yada.

Exactly.

And, also, it's in your yeah. It's in your possession, and you're not doing all the other operational stuff.

So the the nodes in those cases are being professionally administered. So people are keeping track of the resource usage and how much, you know, bandwidth it needs, and let me get a better connection for it.

It may even be the case that the node

operators are arranging for liquidity, if you wanna think about it, because

it is

possible for those things to be justified to the signer that they are not losing you money.

You know, use really this is complicated, but, for example, suppose I want to loop in or loop out. I'll just do a loop out.

One of the ways you do that is by putting a transaction on the chain, which can only be redeemed when you know the preimage.

And then so then when you send the money to the to the,

do the the lightning transfer, that's the other part of that loop,

you get the preimage which allows you to then claim the the UTXO

on chain. And that can be you can just show that transaction to VLS, and VLS

could see that you can't lose money because it knows that you're protected by that preimage.

That feature is not in place yet, but that is planned.

So that's an example how

certain balancing and routing operations can be done in a

trustless way. I I don't like the word trustless. You you you don't You don't trust anybody.

Yeah.

Trustless doesn't exist. It's trust minimized.

Right.

But in a trust minimized way. So you do it in a safe way where the hard work can say, yeah. No. This is okay.

So is that how you expect most people to use VLS?

They'll be running,

like, a cheap hardware device at home and plug it in, connect it to the router, or

or is it I know your website breaks it into

enterprise and I the app side is, like,

I it's not as interesting to me, like, the

breeze green light. Like, I think it's massive for for consumer adoption

that we can have, you know, semi sovereign,

trust minimized

lightning wallets.

But that makes sense to me just because it's it's it's

it's a professional operation. It's not hobbyist node operators or independent sovereign node operators.

You know, Blockstream can figure out a system for it. Breeze can figure out a system for it. They use the phone to hold the keys. Like, it'll be really polished. The UX will be really nice.

But in terms of, like, VLS

for an independent node operator,

is that how you view it happening? Like, them operate you know, they're running some kind of hardware at home and, that's running 247, and then maybe their their nodes have voltage or something running on AWS? Or Yeah. So, you know, we also run on this device. This is an STM 32.

This is just a demonstration,

of the technology,

but and then it uses a serial USB cable to connect to your node. So even if you're co locating the signer on you know, sitting on top of the node, the advantages you get are that, a network attack cannot

easily get into the signer at all, so you're probably safe from a whole lot of different attacks,

which would affect a home node operator.

One thing to say here was that we started off with the enterprise

use case in mind. That was the original vision that got VLS fired up because we said, wow. You know, if we're gonna if Lightning is successful, these nodes will exist. They're clearly gonna be a target. There's a financial,

incentive to get this right and to make it safe. And so this should be an area that will get,

you know, attention and funding and and what it needs. We discovered the low end stuff, like the,

Greenlight and,

the STM 32 stuff sorry, the ESP 32 stuff that Stackwork is doing,

sort of it came out of the blue. Like, oh, wow. At the low end, it makes sense too because we are reducing the amount of state as much as possible, and that has a lot of beneficial effects,

for low end hardware and things like that. And then there's middle stuff. So if you are a

small retailer,

so maybe you're a coffee shop Right. And you'd like to have a lightning node running,

you could secure that by using

one or more of these things that we're talking about. So, for example, you might use the receive only,

trick in the coffee shop because mostly you're receiving all day long. And then at the end of the day, the the owner might be moving some money out of the the lightning wallet.

So

and, unfortunately, I I don't have enough vision to know which of those things is actually

gonna take off. We're

carefully working to make sure

we're not

constraining it arbitrarily. In other words, we we really wanna be able to support all of those things.

There's some pretty different tuning involved.

So a few months ago, we tuned for small memories,

low resource,

signers. So that meant going through and making sure we're using as little heap as possible, for example,

during signing operations. And there was quite a bit of work done there to reduce our our heap memory footprint

and the amount of memory that it takes us to process,

given requests.

Then for enterprises, we need to work on throughput. So,

enterprises can afford a lot more expensive hardware, but they're gonna wanna do 1,000, you know, per per minute

of whatever, routing or,

receiving payments or sending payments. And so we need to make sure that

we have exploited all of the available parallelism,

for example. We wanna make sure that 2 different channels on the same node can be, you know, doing stuff,

concurrently,

because

all of the policies and stuff we're talking about mostly can be enforced enforced at the channel level.

Routing is an exception. Routing, you have to know that this channel is

gonna

have a surplus of, you know, a 1000000 Satoshis, and this other channel is gonna have a deficit of just less than that. So you get a fee. And the VLS will see that and go, okay. That's okay.

I mean, I guess the way I I I mean, VLS

is a company built on top of an open source project.

It's actually just an open source project. There is no There is no company. No company to speak of. There is a nonprofit that we use to, you know,

to fund our develop to, you know, to pay the developers.

But there isn't any equity. There's no,

attempt to Oh, shit. Pull the intellectual property.

There's you know, it's really we're an open source project that are we're trying to get this so it's usable.

And then I think there will be follow on companies that

use it to make something. So we're gonna take VLS, put it in a hardware device,

and make a So you have no intent of monetizing this?

Not directly. We we

intend to make VLS successful,

as an open source project.

I have respect.

Well, I mean, in the future, we may monetize other things, but I don't think you can

make a project like this work if it is being proprietary

or controlled in any way, if you think about it. No. I mean, I agree. I I Nobody's gonna put up with that. They they need to know that they control

the ability

to do it in the future themselves if, you know, if that's what it is. It needs it needs to be a you you can't have a project like this that requires permission. But I guess if if it if I was gonna run a monetized business off of this, I would have the open source project,

you know, independent node operators who run on ESP 30 twos. They could build it themselves. They could do whatever they want. And then I there's probably a pretty lucrative enterprise business there. I mean, like, you know, how much Bitcoin does River have on their notes? How much Bitcoin does Binance have on their notes? Kraken have on their nodes? Like, there's there's an enterprise model there that is,

you know, maybe a a mix of support and

and actual hardware. Yeah. Like, actually provide them hardware.

There's something there in that regard, and you could keep the actual project open source. Anyone could build it, yadayadayada.

In the future, it may be that people want certain features to be accelerated, you know, sooner than they would normally be available on the road map. And so it's possible if they're I think that would be grant I'm not an expert at that kind of stuff. We we're really not in this to try to get rich at all. We're trying to make it happen.

And then I think there's a lot of exciting things that happen

after

it is

it's working and it's, you know, demonstrated and it has the support it needs.

Really, we wanna run with all of the different nodes, so we'd like it to become a standard. We'd like to work to standardize the protocol,

so that all of the different nodes in the world can use it.

It would also be great if there were even competitive projects, come to think of it. I mean,

maybe there you can tune it differently or just have a different viewpoint on something that's worthwhile. So that would be cool too.

I love it. Yep. Have you guys applied to OpenSats yet?

We we have. Yes.

Okay.

Actually, I think I need that already.

It's a dumb question. But that's why OpenSats exist. But I I mean, so where's my, like,

so I I love, like, I love FreedomTech. Like, I think I think,

free and open source software is hope. Like, I think that's how we solve a lot of the broken incentives we have in the world.

So I completely support that.

But, like, my dream projects

or or the or

is is it like, there's something there's something to be said about an open source project that's completely false,

that can find some kind of sustainable way of monetizing.

And, like, my dream situation

for OpenSats is we fund these projects,

and and we just give them the breathing room in the beginning. Like, we give them enough breathing room where they can get to a point where they can actually

have some kind of revenue stream or something without compromising the false ideals.

And then we can

divert our funding to a new project. And then all of a sudden, we start scaling like that where these projects, we're just giving them training wheels in the beginning just so they can get off the ground, and then they

can, you

know, be sustainable without grants in the future. Like, that is the to me, that's the the big unlock. That that's where you start to have, like, really exponential returns in terms of freedom.

Right. And

from from my perspective,

open source is critical. It's absolutely necessary,

but decentralization,

which, you know, Bitcoin's all about, is really the thing that makes this

makes me happy.

I love the idea of a technology

which gives empowers people. So in in the case of all of this, it's about making payments,

without having to have the permission

or regulation or lots of other negative aspects of, you know, banking.

I I shouldn't have to worry about a bank creating

extra accounts that I don't need or monetizing me with fees and charges or figuring out what order to,

cash my checks in order to maximize their, you know, fee penalties. All these evil things they do.

So so this is an opportunity to empower people to transfer money,

you know, plainly and simply by themselves. So it

it reduces the evil in the world that way because

you can always be out com outcompeted by someone who's just more honest,

and that's a really good thing.

Ken, I mean, I love it. I think,

first of all, thank you. I mean, we it's it's sorely needed. I always joke around with the freaks that I you know, I've been using lightning now. I've been running lightning nodes for almost 4 years now. I don't really know how much

stats I've lost.

It it's kind of just

I I know I haven't lost the majority of it because it would be obvious,

but sometimes I just wonder if

I'm just getting fucked on things that I just, you know, it just gets lost in the mess.

So anything to improve security of light. And, also, at the I wake up every morning with the assumption that, like, maybe my lightning nuts are trained.

And, like, that's just how you have to operate. But at the same time, like, this show is I don't know if you see the Noster comments in the center.

Like, this show is is almost purely supported on donations via lightning just because it can handle smaller donation amounts.

We get some on chain donations, but it's mostly lightning. And if I have liquidity issues, if I have nodes down, what what not, like, I we just don't receive donations.

So lightning is something that we rely on heavily here at dispatch, and I rely on heavily in my daily life.

And and the security has just lagged behind, and it's been kind of fine because

I just don't really think we've been in an adverse environment yet.

But that could happen at any point, and we need to be prepared for it ahead of time. So, I mean, thank you for that, and thank you for really caring about

about open source and the principles that stand behind it, also, that, you know, for something like this, it needs to be open source.

Yeah. Absolutely. But, like, where do we where do we sit in the timeline here? Like, is this

like, I don't I hate when people, like, hype up things that

this is not an accusation. I just hate when, like, people are like, oh, like, we don't have to worry about that because Ken's working on it, and it's gonna be great. It's gonna be fabulous. Like, you're gonna you're gonna love it. And we just, like then we just dismiss it, and we're like, okay. Like, Ken's working on it. And it just 2 years down the line, 3 years down the line, I don't have anything to show for it. Like, where do we stand on this timeline?

Well, so Greenlight is moving into,

actually, I wanna be very careful

about

status updates like that that are not on my project. But, you know, they're getting very close to to production,

with, you know, various,

sub customers, if you wanna call it that way. And so that forces us to be ready. The it's a forcing function. We have to be there. We have to be working. We have to have a minimum set of features. You know, we're not we're always adding more

stuff, and, there's

advanced policies. So, for example, some of the I some of the blue sky I I I had there about

balancing nodes with loop in loops in and loops out

and, does not exist yet. We're gonna work on that. Mostly, we need a customer who needs it if if you're following me. We don't really wanna build a feature that isn't gonna be used immediately.

We really want the feedback of you know, actually, we wanna ask you upfront, like, what do you how does

this need to work exactly?

And then when we know there's a trade off, we wanna come in and say, you know, do you want a or b, or how do you want that mixed?

Then we wanna deliver something, and we want you to come back and say it worked great or it didn't work at all or,

great except, you know, x, y, and z, and we work on those.

So we've been lucky to have partners,

over the past,

year. So Stackworks, their team, we work with them,

daily.

We have a week, you know, weekly meetings with them. We're always

asking them questions and they're telling us, you know, which parts are the remaining obstacles to to them going live. Same thing with Greenlight. And so that's the secret to all of this. It's for us to find partners who have a need,

and then we're going to we look at it as we're exploiting them

to to do the market research we need and get the feedback we need. It's you know, we can't do it without that stuff, or we can't do it well without that stuff.

So,

yeah, I mean, we're we're trying to, move along

as fast as we

another big thing is features.

So the lightning world

is very,

is is active in turn,

in terms of adding features. So a good example is splicing. So splicing is being rolled out in core lightning right now. I think,

async already has it. They're gonna work on interoperability,

and we're hustling to make sure that we can,

sign for splicing, you know, enforce all the same policies

around the splice the splices.

But splicing is complicated, so it's, you know, it's gonna

we have to keep our heads down and and work hard to get that to to happen. Do you have a good relationship with the async team?

Sure. I mean, we're friendly with them. We get advice from them.

They have

built their own solution. They run the I believe they run the largest lightning node on the network. Yeah. That was my next question. Like, what's cool about the and what's cool about lightning is that we have multiple implementations, multiple multiple teams working on it. But what's really cool about async

is, like, they've always just it's just been, like, this vertical stack. And, like, everything's open source, like, other people can build on it. But at the end of the day, it's like they're trying to run Phoenix Wallet, and they're trying to do it the best way possible. And they have this massive node that they run that runs a sync,

or that runs a clear

And, async's the company, and then it it powers Phoenix, and they were really quick to get splicing. And my next question for you was, I wouldn't be surprised if async has their own solution where they're, like, essentially doing VLS

with their node.

They,

they released a white paper in

June,

recent,

where they describe how they secure

that big node. Yeah. And it's fairly complicated, and I don't wanna do it from memory, but it involves c node. Like, it's fucking huge.

Yeah. It's giant. And there's,

a

some

rarefied,

cloud services that they're using.

What?

Yeah. I'm I'm not gonna get the name off the top of my head, but but look for that paper and that describes everything.

And

that's great. That you know, if you have the resources to do that and the,

the developers

and that it takes to understand that and work on it and tune it,

that will be a good solution

for that kind of node. We're trying to make it so that we have a general purpose tool, which can be used for many more nodes than just that one.

And and TBAS has said in public that when VLS is ready, they'll, you know, consider using it Awesome. Which is all we ask, you know.

And then he

we're constantly in discussion with them over whatever,

protocol things are happening. So splicing is very much,

in the fray right now, and, you know, just yesterday, we were chatting back and forth trying to refine and understand

the finer points of, you know, what what this means, what that means, what do you do when you see this.

So it's a very cooperative

yet still competitive environment,

and we're hopeful that out of that, we will get you know, the the right things will happen.

If a team is, you know, doing particular excellence in a particular area, we'd like to, you know, see that rewarded, and then we obviously wanna combine

all the best

parts. Long term, hopefully, we'll evolve towards nodes which are, you know, stronger, have more features, and,

and are more secure.

So So, I mean, Ken, just completely selfishly,

first of all, you keep mentioning core lightning, Breeze, and

Breeze SDK and Greenlight are both core lightning based is my understanding.

Is this core lightning specific? Like, what's my

Ken, what I'm trying to get out of you is, like, just humble lightning node operator running LND.

Like, what is my like, when am I going to and is feel free to just be, like, fuck you, Matt. Like, you can run it today, and you're just not doing it. It. We'd love to know how you can use it. We were closest to LND when we started. Our first initial work was on LND directly and not the others.

LND's

signing abstraction

is a little challenging, so it requires some adaptation.

Let me call it upstream in LND to to do this.

And so when we saw that Corelightning had an HSMD

already identified,

that was just begging for us to come and drop a proxy in there, and so that's how we got there.

The LND effort right now,

there's a project from NYDIG

called

LND Server. Apologies if I get it wrong. And it's,

Alex

Axelrod,

hope I'm getting the name right,

is working on that.

And he is working towards a proxy,

so that will run-in

or with LND

and connect to to VLS.

So there is an effort underway to connect LND to VLS.

And we're Awesome. We would love it, and we're, you know, happy to support it in any way we can.

Doing the node integration requires quite a bit of work actually on both sides. So one thing we're doing is we have to submit,

a pull request upstream with

the nodes in order to

get additional information, like,

what's a good example?

Sometimes when you mention an an address that's in in the wallet,

it it's helpful if you tell us the index, the wallet index Right. Of that address because then we can immediately verify it. Otherwise, we'd have to go do some painful search

to to see if it was there. And all the addresses, basically. Yeah. Which we're not gonna do. So we needed to go in and add a a hint, if you will,

on wallet addresses to make sure that we we that they were telling us the index.

So that's just a

another one is

there are some messages that are not exactly signatures, but they're critical for the

VLS to see. What's an example?

When you do a

when channel peers revoke their commitments, they're revealing a secret, which which makes it possible for the other side to apply a justice transaction

if they breach in the future. That's a mouthful. But but, anyway, so there's a a a a revealing of a secret.

VLS needs the

the local node to show us the revocation

so that we can guarantee

that it's actually correct.

Because if a if a bad peer

sent

an incorrect,

revocation, but we just believed it to be okay, later, we we discover that we couldn't do a justice transaction

because we actually had what we needed.

The same thing is true with the commitment that the remote peer sends to us. So

the remote peer sends you a commitment and then you save it, and then later if you need to go on chain, you're gonna use it. But VLS needs to see that commitment to make sure that it's well formed and isn't stealing money from you.

So those are cases where we're not actually,

delivering a signature. We're not signing anything, but we need to see those things in order to know that it's safe to advance the state. So those have to be added to you the the original signing infrastructure in each of these nodes doesn't usually

have a call out to send those to the, you know, to the remote signer. So you need some buy in from the maintainers of the implementations?

We absolutely do. And we're we're really, blessed with Alex who's

from NYDIG because he used to work with the,

Lightning Labs guys, I think, maybe 5 years ago if I'm don't quote me on that. But he's, you know, he's known to them, and he's,

knows that

code base inside out. And so he he's the ideal person

to figure out

how to,

make such a proxy.

We we had, you know, not as much exposure to Lightning Labs, and so it was going to be a painful uphill battle for us to figure out how to do that proxy. I mean, meanwhile, it's, like, 80% of of nonprofessional

notes are L and D or something like that.

Yeah. It

we wanna cover them all.

I I kind of view it as the progression here is we're gonna go along adding features and doing things until suddenly

some killer app is going to emerge. And I, you know, I I have some guesses of what what it might be, but I'm probably wrong.

But when it happens, everyone will get it. It'll be like CryptoKitties for Ethereum back in was that 2018,

2017?

It'll be like,

NFTs,

you know, couple years ago on, you know, or it'll be like ordinals and inscriptions.

Now whether whether or not you like those things, they definitely stimulate interest and activity.

The killer app the killer app is gonna be people are gonna lose a shit ton of money on lightning,

and we're gonna scramble to harden all the systems. And the unfortunate reality is, like, you wish the support happened before that happens, but it just I don't think it happens until people start losing money. Like, it's been like I said, it's been 4 years of

of of, like, real lightning usage

since, like, January ish 2019. Like, that was when the lightning torch was going on. Like, very few wallets supported yet, so I'm just gonna I'll just give it 4 years. It's been 4 years.

And we just really haven't seen many attacks. Like, people are not using it in a very secure way, and, like, as long as or, like, think about if you go back

you go back a decade

to on chain Bitcoin usage. Like, this basic idea

that you only keep 1% in your hot wallet,

99%

in your cold wallet, and you practice,

you know, key security in that regard and and fund segregation.

Like, the reason that became general best practice in the industry was because exchanges lost a shit ton of money. Like, that is why it happened. They learned by touching the stove.

And I there's it's gonna be the same thing with node operators.

They're still learning. I mean, the the prime trust fiasco where they lost

6 keys. I mean, 6 multiple

No. That was for I think that was fraud, but, I mean I

I always suspect in anyway, I better not.

Yeah, Ken. This is you know, I don't know how many podcasts you do, but you keep saying don't quote me on that. That's literally what people are gonna do. We're just gonna quote you on you're being quoted. I know. I know. Yeah. Ken says that

that they're crooks.

No, no, no. I totally agree. So my progression is killer app, then we'll see a large

the amount of commerce going on and lightning will explode. It'll go Oh, right. Killer lightning app. Right. And then then what'll happen is these nodes aren't prepared for a 100 x scaling. Like, suddenly instead of $1,000

on the node, you're gonna have a $100,000, and suddenly it becomes worth some,

hacker's time to try to figure out if you can take your note down.

Another angle on that is we're adding features really

fast to all these different nodes. So the amount of code development going on in all the different teams, I I won't you know, it isn't just one of them, it's all of them, is really, really rapid and aggressive.

And, unfortunately, that comes at some

concern,

comes with some concern about security because you you things become secure after you've studied them for a while and after people have had a chance to look at them and attack them. And so if you're, you know, bolting things onto a car

as fast as you can, it's a the safety might you know, some there might be some interaction between things that you didn't expect.

And and specifically for something like a

a dedicated signer. Right? Like, you want

at least some level of loss notification. Like, it'd be ideal, like, if you're not updating the signer over and over again. You know? Right now, I always joke around. Another another,

common best practice in Bitcoin is not to update so quickly because updates can be an attack vector, and lightning flipped that on its head. It's like, oh, immediately update. Like, you'll lose all your money unless you update right away. And just like everyone goes and clicks a big blue update button.

Well, earlier when you mentioned

you weren't sure if you were losing money with your nodes,

probably let's assume that there's no,

nobody stealing from you.

Probably the biggest

fund loss in recent history is,

undesirable,

channel force closes. Closes. Force closes happens out of the fee market. The fees go up. Moves, and then people get loads get confused, and nobody's being dishonest.

But based on that, we close the channel,

which is the conservative thing to do. But often, you're doing that in a, you know, crazy fee market, and sometimes you're gonna lose more money than you like.

So those are cases where adding you know, working on that, getting anchors in place for it. So anchors are gonna be a huge benefit there because you will not have to,

preload the commitment transaction with a huge fee in case the fee market is high next week. You can have,

in fact, very little fee, and you just bump it as necessary next week if you need to do it.

And not having to negotiate that fee means there won't be so many forced closes that you don't want. So maybe channels will only get closed,

when you want to close them.

Splicing helps some of that. Forced closes.

That's great. Splicing helps because you can

top off a channel or take out of a channel without having to remove the channel, which is

expensive from a routing perspective. So when you take down a channel and make a new one in its place,

it takes a while for the rest of the network

to trust that channel. So it might take weeks before that channel is as effective as the old one was.

So being able to splice money in or out will allow you to keep the channel's identity, keep it running all the time, and that's gonna be a huge benefit.

So a lot of these features right now are gonna make it work better, and I'm very hopeful that a year from now,

the friction, if you will, in the lightning

world will be radically less.

But the security issues will still be there. And that's why we're trying to be ready. We're we're just trying to make sure that we have VLS well positioned and in the right, you know, direction and with all the right

connections and stuff so that as the problem becomes recognized and you turn up

the the intensity on needing to solve that, that we're ready for that. Like, you know, there's there's something to use and it has working examples

and people who know about it, and that that'll make that happen.

Awesome.

Ken, this has been fantastic. I'm,

I'm grateful for the work you and your team are doing. Like, it's it's it's sorely needed. I think,

I think it's important for people to realize that, you know, lightning is still a work in progress, but we're making great progress.

I I sometimes I disparage only say it's been 4 years, but also it's crazy how much progress we made in 4 years. Yeah.

So it's it's, it's important to keep ourselves grounded in reality.

I would say to you, first of all, you have me on signal now, so consider me a resource,

if I can help you navigate the space.

I do have

just a lot of friends in Bitcoin,

and, I hope Open Sats will will

will help you guys out on the on the money side.

Yeah. I mean, before we wrap up, do you have any final thoughts for the freaks before we close?

I I'd, you know, like to call out and, thank all the different teams and groups that we work with for,

being as positive as they are. The LDK team is very near and dear to us. We use the LDK library, so our code is styled on their thing and uses their interfaces.

Square was an initial supporter,

the earliest supporter, so they've been supporting us the whole way through.

The Blockstream team and the Core Lightning team are really enjoyable to work with. They're really professional.

Everybody's,

you know, almost

perfectly aligned.

There's a lot of common ground and people know that, you know, we're all trying to get to the same place.

It's true of all the different teams, and so we're we're definitely not here alone. In fact, VLS is of no use at all by itself. You have to combine it with a node

and a and a and a vibrant ecosystem in order for it to make sense. So

it I'm really appreciative of everybody else being there and having,

being so much fun to work with. It's just the simple thing to say. So Cheers to that.

I mean, to be clear, just to put this out into the

mindshare,

like, what I would just fucking love to see, like, my dream like, if I could wake up tomorrow morning, like, the dream would be,

like, a nice little piece of hardware

that I can plug in at home that, like, connects to Wi Fi or Ethernet,

and then it just is instantly compatible with something like voltage where just it's just very easy to run my own node in the cloud, and it just connects back to my little VLS signer.

And, like, I would pay

I I would love

I think at the bare minimum, you should be able to build it yourself.

But I think there should also be, like, a nice little polished

piece of hardware that I can, you know,

give 90% margins to to some enterprising businessman to to to make me, like, this little nice device that I could tell people, plug this in, go to voltage, press the big start node button,

you know, follow this pairing setup,

and it just fucking handles it for you.

That would be my ideal situation from a independent node runner.

So that is a shared vision. We that's completely

on our road map. We wanna see exactly that and other related things, but but that one's a very important one because,

I think

the early adopters in the world

are gonna want that one.

The other ones like the enterprises

or the mass market green light stuff are gonna have more inertia and, you know, take longer to get all spun up. But the early

adopters

are the the we can get feedback from them immediately. And so the thing you just described is absolutely

in reach.

You you could actually make that now. Yes. It goes like, fuck you, Matt. Like, you can just do that now. Yeah. I know.

Well, you you would have to add the networking part around the signer. So we have the signer part part for you. Right. You need you need a a signer controller, if you wanna think of it that way. That's exactly what Stackwork is working on. And, actually, you're maybe you're almost a 100% aligned with what they're building. So, you know, you should talk to them and see what they're gonna I'm visiting Paul in 2 weeks. I'll just

I'll harass him. It's not obvious to me where there's any difference in there. They are talking about a small device for home, connect to something in the cloud.

Yeah. Let's let's make that a reality. I like that. And, you know, Ken, like, I don't know how you feel about, like, the lightning network to me. Like,

to me, I think of lightning as 2 different,

there's almost 2 different lightning networks. It's like this corporate regulated lightning network that has these massive routing nodes, and then there's, like, this sovereign freedom

lightning network. And, obviously, because it's lightning, everything's interoperable.

But, like, I think there's product market fit on the regulatory the regulated side, like, just an interoperable protocol between custodians. Like, it's very obvious, works really well. You wanna send between River and Kraken and all this shit. Like, it works fantastically well. I still think the jury's out on the freedom side.

And so to me, it's it's incredibly important that we provide as many tools as possible to the independent node runners because they're the frontline of that situation. Right? They're the they're the ones that provide the hop between you and River, so you don't have to KYC or get your channel whitelisted or whatever to do that. And almost everything in lightning development,

I'm not I'm not gonna be that dismissive. That's fucked up. I'm I'm very grateful for open source developers, but there's been there's there's a

there's a weird disadvantage that has happened,

where it's it's it's you're just you automatically start off from the back foot if you're an independent node operator versus

a corporate node operator that's running on clear net that's, you know, doing all these different things. So those kind of things that level the playing field that make some

random person

in Singapore or something who's willing to put 10 Bitcoin on a node because they're able to secure it, like, that could be the difference between,

you know, where Sovereign Lightning is in 5 years or Freedom Orient Lightning, where is it in 5 years versus it takes 10 years or 15 years or something like that?

I'm hoping the l four zero two stuff explodes

any day now. That do you know what I'm talking about? The,

like, the Wall Street Journal and the other publications that require a $20 a month subscription that they're leaving money on the table because I wanna, you know, spend a quarter or whatever the the market whatever the price is to to read a given article, but I'm not gonna get a $20 subscription.

Lightning Labs has proposed something called l402.

402 is the status code for Pay not required.

Yeah.

Which never was used, but Lightning could actually be the right thing for that because you could have a

small,

wallet in your browser, and then when you go to the Wall Street Journal, it says, do you wanna pay a nickel for this or a quarter or whatever it is? And you just say yes, and now you read the article. It's anonymous.

They don't have to have an account.

There's the amount of

the advantages seem obvious to me because in this day day and age where everyone's stealing all the account information Right. That's the biggest liability. So instead if I just have, like, a little bucket and it filled up with Bitcoin every day, that'd be wonderful.

And so,

I mean, I've got their Netflix account information.

Ken, how familiar are you with Noster?

A little bit. I've been following it. I'm not running a Noster,

relay yet, although I'm certain The cool part is you don't have to, but you're able to if you want to.

Yeah.

Yep. Right. I probably would just to check it out.

And you seem like you type who just ape in and just immediately run over I Ran my own news servers back in the day. You know? Nast

Nastar rep is actually

echoing back to UDP

for me. I don't know if that

it was,

unregulated.

You could create it if if you had support from other people and other people would peer it, if you know what I mean, then those,

news groups would happen.

And there were

different things for different folks, like there were some really

scary stuff that you could go look at if you wanted to, and then there were really safe you know, there was, you know, alt. Pets with, you know, with, you know, lots of pictures of cats. So,

but, anyway

No, sir. It's getting back to that, and, it would be nifty to be able to,

layer some,

payment in there so that you could So there we've already done that.

That has been done.

Like, we we there's l n URL support, essentially. So there's you can attach to your

attach to your nostril pub key. You can attach,

your ln URL or your lightning address, if you want human readable.

And so, like, right now, like, this live chat that we have in the front of the screen

is through something called zap.stream.

The audience can get there through my redirects to dispatch.com/stream.

But I didn't have to do anything additional to set this up. Right? It was it's just my noster pub key, which is attached to my l n URL.

And then as a result, they're able to support the show live in line with the comments. As you can see, like, if someone

puts a comment and they they have a big zap, pseudo carlos zap 2.1 k sats. It highlights it and does all this stuff. And why do I get to that? I because

early on to me,

obviously, I'm never fucked I'm not gonna pay $20 a month for New York Times to read a single article. Like, obviously, like, there's something there in terms of small paywalls,

But I think the future is actually

something that we call value for value,

which is information

wants to be free.

So as a result, you provide that information out, and Nostra has this novel way of basically,

you control your own social network graph

even if you're not running your own relay. So if one relay decides to censor you, your social graph still continues as long as other people are connected to the other relays, and you can always run your own relay. So it has this this this situation that it it works really well for this value for value concept. And

and and the difference with value for value

versus a paywall concept is this idea is that you put the information out there, because information wants to be free regardless, and it's gonna be free regardless. It doesn't matter how much DRM you put on it. People are gonna take a screenshot and share it on TikTok and Twitter and everything.

You put the information out there, and if people wanna give you value, they can send you Bitcoin.

And if you reduce that friction to the point where it's convenient for them to do it, doesn't cost them that much to do it, people will actually go and do it. So I think

I think the low hanging fruit, the first step is micro paywalls, and we're gonna see that first because New York Times or whatnot are not gonna switch to a value for value model. And then, ultimately, what we will see is we will see

content creators

if that's at the end of the day, New York Times wants to call themselves a paper record. They're just a glorified content creator.

Content creators that are doing value for value will get more more Bitcoin for it than than if you do paywalls.

And that's kinda how I view the whole thing unfolding. I I totally agree that that it's exciting to me because it means that we're gonna see a lot more diversity in content

because,

you know, some random person who has a random niche today

may not fit into, you know, Twitter or any of the other social networks in terms of acceptability and monetization, and they're at someone else's whim, and now they can get monetized. And if they do a quality job, people will

reward them, and then you'll see more of that. And so that will reverberate, and we're gonna see all kinds of really cool interesting stuff.

And they can easily be rugged. And and and also why I bring it up, by the way, is with Nasr, we have a similar issue. Like, if I post or like something or, you know, repost something, like, my keys have to be hot for that.

And, so there's different projects. I saw Pablo in the comments. He has something called NSEC bunker, but there's different projects that are basically designed to make it so we're not pacing our private keys and to punch different wallets. And there's a lot of similarity there, but in in this regard, at least money is not on the line. It's

it's more reputation or speech or social graph or I don't know. I like

some in some ways that might be more important. I don't I don't haven't really circled that square yet, but what's cool about Nostra is it's simple. And so we don't have to solve all the problems, and there's this nice viral open source community that's building it out. It's really cool. So I implore you to check it out. That's my Nostr shell of the episode.

It is another, another Nostr thing is I see people using it whenever you need to do a pubsub

broadcast effectively. So, like, CoinJoin via Noster Yeah. Is the thing apparently.

Yeah. But there are many other examples of that where you wanna advertise a service or even,

you wanna,

what's that word? Solicit bids for something,

you put it out in Nostra and say, you know, I'm over here. If you want this, come get it.

And that's cool.

Well, anyway, Ken, check out

Will do.

Okay. So, I mean, this conversation been

fantastic.

As always, freaks,

CIL dispatch is supported,

by viewers like you. What is this? PBS?

We do not have ads or sponsors. We rely on your Bitcoin donations. Value for value, we just talked about it. You can support the show via podcasting 2 point o. You can support the show via our Nostril livestream. You can support the show via our dedicated donation page, all powered by Bitcoin.

All the links are at siladispatch.com.

I'm gonna read the top four messages

from last week's episode. We have ride or die freak, Eric 99 with 400,000

sets saying stay humble, Stack Sats. We have Mary Oscar with a 100,001

sat saying, okay. Here we go. Fingers crossed. We have 8

with a 100,000 sat saying, having the local Bitcoin community support local merchants in adoption

seems like the best approach. And then we have rider die freak at Cum Rocket with 69,420

sets. Great conversation. Worth every set, especially the successful ones. Here in peace, gee. I wanna say huge shout out to the entire dispatch audience. I appreciate you all. It's always a pleasure when I get to meet you guys in person. Thank you for joining for the live chat to all of you who have done that. You guys make the show unique.

Yeah. And just a huge shout out to Ken. Thanks thanks, Ken, for joining us. Well, thanks to the audience and all the other folks who are being supportive. It's really great. Thank you. And one last thing. I'm gonna give you the floor one more time. You're an open source project. Are you seeking contributors? You want you need you need help over there?

We're trying to grow, but we need to grow slow carefully because it is a security project. So, you know, security code needs to be carefully reviewed, and we need to, you know, on and on and on. There are other aspects of VLS though,

which are don't involve security directly. So we we need people to document, we need folks to think about how to integrate it with other things. I think that's probably the biggest

draw, which is if you see a way to use VLS in an interesting way, please contact us, because we'd love to talk more about it and learn about it and,

and, you know, help out if we can.

Those are the things that'll keep us going. You have the website vls.tech.

What's the best way for people to contact you?

So if you go to vls.tech, down on the bottom, there are a bunch of links on how to contact us. So Twitter works.

We're a matrix kind of place, so if you're good with matrix, that's absolutely the best way. We have a matrix, I think it's called a group, but it's a set of

associated channels, you know, VLS general, VLS

dev, and, yeah, on and on and on. Please, you know, join those and and ask us questions or, you know,

offer criticism, whatever. We we'd really love to hear about it.

Yeah. Love it. By the way, Ken,

our live chat before was Noster, was a matrix live chat, and Noster replaced it. Oh, cool.

Okay. Huge shout out to Ken. Thank you, Freaks.

I'll see you guys next time. Stay on the stack sets. Cheers. Bye bye.