CD88: Lightning Dev Kit with Jeff and Val

Happy Bitcoin Wednesday, freaks. It's your boy Odell here for another SIL dispatch,

the show that's focused on actionable Bitcoin and Freedom Tech discussion. I know you freaks just heard me yesterday with the wonderful BDK team,

but now I am back to talk about LDK.

Before we get started,

as you guys know, dispatch

is a 100% audience funded.

Could not do it without you guys. We have no ads, no sponsors,

purely funded by Bitcoin donations.

The easiest way to support the show is podcasting 2 point o apps, like Fountain Podcasts,

Breezewallet,

Echo ln,

and others.

You simply download the app, search for Siddle Dispatch,

press that subscribe button,

load it up with sats, choose how many sats you think the show is worth, and then as you listen, those sats get streamed directly to my node,

in real time. It's extremely fucking cool to see those sats and empowering to see those sats come into my node day in, day out. I really do appreciate all the support.

You can also support the show, through

geyser.fund.

That's connected to my own node. That's just regular Bitcoin and Lightning payments. I have a pay NIM.

It's Odell, very easy to remember. That's a BIP 47 reusable payment code that you can use with Sparrow Wallet or Samari Wallet.

All these methods allow you to support the show easily with Bitcoin, and all relevant links are at siladispatch.com.

Also, I know it's a bear market. I know it's a recession.

If you can't spare any sats, the easiest way to support the show

is to share with friends and family, subscribe on your favorite platform. It's available on Twitch, YouTube, Rumble, Bitcoin TV,

Twitter, every podcast app.

Subscribing,

reviews, sharing it really do help.

And then last but not least, this is an interactive live show.

We do it a little bit differently on dispatch.

You all are partially the host of the show,

and you are part of the conversation. So you can join that conversation either in our 247

matrix chat

or via Twitch or YouTube. And, once again, all the links are at sill dispatch.com.

Before we get started,

I like to read the top 4 Boostograms from the last episode, which is pretty impressive because that was yesterday.

Boostagram is a way to attach a message

to a set amount of stats, and you send it through a podcasting 2.0 app. You can think of it like a global commenting system

with

monetary you know, money attached to it. So we have rider die freak

Eric 99

with 21,000

sats

saying thanks for the content. Thank you, Eric.

We have at blogging bitcoin with another 21,000 sats saying,

the padawan wallet is awesome,

anyone wants some test net sats, Padawan Wallet is awesome.

We have at piccolo junior with 18,081

sats

saying, paladin drone boost, BDK crew are fire,

and their tools, elephant and padawan, are lit. And then we have

8 Mythrandor

with 7,777

sat saying,

very interesting. Would be cool to get Lloyd and Evan on for a follow-up

since it sounds like they are doing the cool new stuff in BDK. I agree. We'll make it happen.

So with all that said, let's get started here. We have a very busy week at Bitcoin Park. After this, we have,

our monthly open house meetup, which is gonna be focused on open source, which I'm very excited about.

So here today, we we're talking lightning dev kit,

and we have Val and Jeff. What is up, Val?

Hey, Matt. Thank you so much for having me on. Yeah. As you said, I'm with the LDK team, so excited to be on here. It's a pleasure to have you. Thanks for coming to Nashville. Welcome to Bitcoin Park.

Sweet. And we have Jeff. What's up, Jeff? Hey, man. How's it going? I'm also on, spiral working on LDK with Val. Happy to be here. This is a great spot.

So, Jeff,

what is lightning dev kit? I told him you to take this one. Yeah. Yeah. No. The hardest question, like, what do you work on? Okay. So,

you know, you could think of in software development, you have SDKs, these software development kits, which are used to sort of interact with different

you know, you might have, like, some libraries that you use. You want to, you know, have some networkings. You know?

For instance, some SDK there.

LDK is a lightning development kit. So,

I guess the question first is, like, what is Lightning? So Lightning is a protocol for

that scales Bitcoin payments, makes them, you know, fast instance,

you know,

for

there's a people to use Lightning and Bitcoin.

And

LDK is a way to

allow developers to integrate Lightning into their Bitcoin wallets,

and it's very customizable.

You could,

you know, really tweak it in different ways or you could use sort of, like, different,

I guess, utilities that we built into LDK, kinda layer up on top of each other

to to let us handle that for you.

It's really customizable. So I don't know if there's anything Bea wants to add on that.

Yeah. I think that's a really good summary. And, I'd say it's also because it's in Rust, it's, like, very performant and lightweight.

So it can be very suitable for, mobile noncustodial

wallets in particular.

Yeah. That's a special use case. So we definitely have some unique challenges in terms of balancing, like, mobile users who just want a lightning wallet and people who want to customize the absolute crap out of it. So that's a constant, balancing act for us. Yeah. And I think, like,

when you think of, like, the Lightning ecosystem

more broadly,

there are other implementations of Lightning Network Protocol, and

we all sort of participate participate together in oh, yeah. MBK looking through the window at us.

Oh, man. You know, so we have these, you know I guess, primarily, it's 4 implementations, but there's probably some smaller ones out there.

You know, the primary ones being,

l and d,

core lightning,

eclair,

and LTK.

And

those are sort of implementations of the specification. So we collaborate on on now what is Lightning, and,

through some back and forth and some,

I guess, just, you know, implementations,

we we we come up with with ways to, you know, I guess,

define Lightning for and each of those implementations sometimes have their strengths and weaknesses. So,

you know, some people might say that,

l and d is more for, like, servers and routing, and so that might be more of their specialty where whereas, like, I guess, maybe Aclara is more, like, mobile and and

but they have, like, trade offs too.

So right.

Yeah. I'd say that's accurate. Yeah. I mean, I I definitely don't feel like we're really trying to compete. I'd say we're trying to fill in things that aren't being filled in,

particularly noncustodial mobile and also just kind of the sheer flexibility allows for certain privacy use cases, advantages

in some cases, but kind of above all, I guess, experimentation

and just,

letting people's imaginations

run wild with what you can do with Lightning. So

I mean, it's the the comparisons happen a lot, like LDK versus LND or LDK versus core lightning.

But it's a little bit different what you're trying to build. Right? It's not Yeah. I mean, you think of it as, like,

you know, at the core,

we have

this part called Rust Lightning. So so LDK is based on the programming language called Rust. It's pretty secure,

safe to use, coming up pretty it's becoming pretty popular these days.

And from that, we sort of layer more up and up on top of it. And so someone who's, like, really into the nuts and bolts of Lightning, they could just take the core that we have, customize in different ways. They could add their own, like, networking stack to it, use their own data storage.

They could choose to, you know, I guess you know, for lighting, you'll need transaction and chain data be fed into it, and they could choose how they do that. They could use a Bitcoin full mode. They might have, like, an Electrum instance some running somewhere they wanna communicate with. So we provide, like, all those different mechanisms to do it. And

from that, we you know, from this core, we we've built up different abstractions that allow for things to be done a little more easier if if you're really not into fine tuning as such.

Yeah. Absolutely. It's it's been kind of a a journey for us kind of learning what people want to customize

versus the things that they want us to fill in for them.

Like, we were always

or for a long time, we've been built to be able to use Electrum, but a lot of people don't or, explore a kind of, stuff that's not just a full node or,

neutrino. But, yeah, just kind of learning that people would rather we build modules for them so they can just use it out of the box versus

some people want to customize certain things. So that's been kind of our journey as a project. Yeah. And I feel also like when you build something that,

where the developer is the user of the product, you don't really know what they want until they start using it. Right? Like, LND, like, the end users is me just downloading and running LND. Mhmm. Like Where where LDK is more, like, software developers trying to And LDK,

I mean, I don't wanna say never never say never or whatever. Right? But LDK's goal is not to be that. Right? Like Yeah. Exactly. Not gonna be a moment where I'm just downloading LDK and running it.

Too many of these layers built up, but we're, like, leveraging some of the utilities. So I don't know if I could go into some of that.

Oh, yeah. Mode. Yeah. The sample. Yeah. That was, definitely a really important step as a project just, in terms of learning

what utilities we needed to build to, make the developer experience

bearable,

basically.

But, yeah. That's, that's been around for a few years. And,

for a long time, that was the way that we pointed people to running LDK was by, running our sample node. And, now that's definitely evolving quite a bit. We have this new LDK node project that's,

Elias on our team is in charge of it. And, that was basically, I think, started in response to a lot of mobile devs. They wanna run LDK, but they just want an out of the box lightning node. They don't care about the customization. You know? They just care about their performance and the way that it accommodates

the very constrained mobile environment, basically.

So that was kind of the, the motivation behind,

LDK node. We think that's that's gonna be really awesome and just provide that out of the box experience that people want. But the nice thing about it is that it also kind of makes it easier to spin off a more of a server version of LDK as well. So while you're right that, yeah, we're definitely not trying to, like, compete with, in the routing node front per se, it's still like some people are interested. Like, it would be awesome if it could exist. And

in an ideal world, we would have example

LDK nodes of all these different things just for, you know, the flexibility of it and just You're kinda hoping someone else builds that. Right? Yeah. It's like I I would download

a, you know,

a a something that was built with LDK at its core, but it's a consumer

Yeah. For instance, like, sensei was, like, like, a stab at that. You know, it was it was But now he's with you guys. Right? That that's what I hear. Is it public yet? I was wondering. Yeah.

Oh, I'm not sure. I think you you Well that would spiral itself. Congrats. Well, it's live. So Yeah.

Hope so.

I think it might have been already. Okay. Well, who knows? Well, now it is. Yeah. Well, don't share, freaks. I know. It's official, at least.

But, anyway, Sensei is fucking awesome.

So, like, that was kind of that idea. Right? Yeah. Yeah. So that was one of the

but to, like, Bill's point about, like, you know, we we have these developers that come in. We have our Discord. We used to be on the Slack. Now it's currently Discord gets GitHub we use for communication.

And so we he we see all you know, we hear all these use cases that people wanted to use LDK for,

and we learn a lot from that. Like, we we wanna grow this developer community such that, you know, we're actually servicing them in some manner.

That is, you know, beneficial for the broader Bitcoin community.

So having that, you know, that access to us, I think has been very important for, like, the growth of the product of the of LDK,

and,

it's definitely shaped, like, what we're what where our road map's been.

Yeah. Definitely. I feel like we're constantly kind of being pulled in different directions by different projects. Like, we have the most

edge KC projects that wanna just run a 1,000 nodes on one little SGX box Right. Be constantly shutting them down, spinning them back up. So we're kind of, like, hearing their complaints in our ear and then simultaneously, like, other end of the spectrum,

like Cash App running these huge routing nodes. They wanna be able to load balance between them or not routing nodes, but, you know, receiving a ton of payments and Super high volume nodes. Yeah. Yeah. So to some degree, it's a good balancing act. Like, you know,

do we go so far down one one way that, you know, it detrimentally affects, you know, the other side of the spectrum of what these use cases are? So we kinda have to be very mindful of that and try and be in the middle of Yeah. Yeah. And just be careful, like, what what do we want this to you know, who who are we supporting

and, like,

define some of the limits, I guess. And,

we also have some constraints. So for instance, you know, while we are written in Rust, we have support for other programming languages.

So, like, in mobile, you're not typically gonna use Rust. You'll have, like, Kotlin, Java for

Android systems, and,

I guess, it would be Swift for for iOS.

So we have this, like, essentially, layer called, like, language bindings, which is a way to go from Rust to a different language that you're more comfortable with.

So defining those language bindings has been quite a chore. I mean, if Matt comes on at some point, that's pretty good chat about those. MacKorala?

Yeah. Yeah. MacKorala. Our language bindings are literally it's like we have Rust, LDK,

then we generate another layer of Rust on top, and then we generate c bindings that can interact with the new Rust layer. And then we have, like, Swift and Java that, like, talks of the c bindings.

And, yeah. And the c bindings are not meant to be consumed by c programmers, if that makes sense. They're just for the bindings. So Yeah. So you have these c bindings. You're producing, say, you know, Java sort of API

for

for LDK.

And, ideally, it's it's,

you know, very, I guess, idiomatic in

in people or for parameters in Java. They they use all the constructs that they would use when programming in Java. Maybe I'm not sure if we're quite there for that, but that's like the end goal. Like, it it should feel like you're programming in Java if you're using Java bindings. It should feel like you're programming in in Swift or if you're using Swift bindings. So the core is is Rust line. Yeah. Underneath the hood, it's all Rust. So

Yeah. That's definitely the goal.

But, yeah, it's it's tough. I mean, like, yeah, we have this this certain Rust client, and we can't always do things in idiomatic Rust, for example. Okay. Because we need to accommodate for these language bindings and for

all these weird,

like, WASM environment,

mobile environment.

Oh, no. I was saying it flashes. The block clock flashes, so it's super distracting. I was telling MBK about that earlier. I need to turn off the flash in the studio. MBK is in the studio, by the way, to the listeners.

We need to climb the fence to get in. Couldn't tell. Did he actually climb it? We gave you a key card, didn't we? Myself. It's weird. I don't have another mic. Otherwise, I would have you join us. So, I mean, you mentioned Corallo. Me and Corallo go way back, from New York Bitcoiners.

It was that was one of the reasons why bit devs last night was so great, because I just

I just remember being a young bit corner, and it was just, you know, Jay of New York BitDevs and Corolla going back and forth about things I had no idea what they were talking about. Yeah. I I was at one of the bittdevs in New York after I first got Harrowds heard it spiral, and

I was just amazed at the I think they called it, like, creme de la creme. It was special. At that time, it was, like, peak too. Mhmm. It's still very good, but, you know, he had to be there at the time. It was amazing.

But when I talked to Matt,

what we talk about a lot is this idea that is very focused on mobile developers. And, I mean, we talked about this yesterday with the BDK team.

When I look at, you know, the next

yeah. It's very memore. The next 1,000,000,000 Bitcoiners. Right?

The overwhelming majority of them are gonna come in mobile. They probably will never interact with Bitcoin on their computer.

They might not buy a hardware wallet from MBK.

Like, they will just use a mobile phone,

and that will be how they interact with this global financial network. But Lightning Wallets,

despite all the hype on Twitter and whatnot,

lightning wallets on mobile is still a very

Unsolved problem. Yeah. It it's unsolved. It's

it's it's a pretty unsolved problem. Like, while the satoshi is very, you know, was one of the most commonly used ones, it's completely custodial. Yeah.

A lot of the other ones take different trade offs. You know, they're not fully custodial, but you're trusting the LSP. You're making all these trust

assumptions and whatnot.

So one of the main focuses with LDK, I guess, is to try and at least mitigate some of these problems and and make it easier for developers to build good, you know, self custody, sovereign

Lightning wallets, right, that are easy to use? Yeah. Yeah. So I I think Val's gonna speak at this because,

you know, lighting on mobile doesn't have quite, like, the Venmo like experience. And, like, that's some of the, like, the more recent sort of spec haggling's about. And, like, Ace Hernandez payments, for instance, Vail has been working on. She could give a little more information on that. Yeah. Definitely. There's, I mean, there's, like, a ton of challenges with mobile. Just like go through them. Yeah. Just like backing up. Just, I mean, for example, there's no such thing as having a safe shutdown

with your node,

because, like, Apple can just kill the process anytime even if it just goes into the background.

Obviously, it's very memory constrained, very,

resource constrained and all that. And, you also wanna be able to write everything to disk safely, and you need, like, the cloud backup in case people will close their phones or delete the app.

So can you think of any others before we get into async panel?

As far as just, like Mobile challenges. Challenges.

There's a lot.

They're offline a lot. Right? Yeah. Offline like like like this, the whole Venmo experiences like you just want to pay your friend and receiving inbound liquidity is a major liquidity.

UX. Well Right. Friction.

Yeah. I think LSPs are kind of coming up to address that. But, yeah, something I've been working on recently is acing payments because, to Adele's point, a huge problem is that if you're on a mobile noncustodial lightning wallet, you're gonna be offline all the time. Like, you close your phone, you're offline all of a sudden. Right. You can't receive.

Even if your phone's online, the wallet's offline. Exactly. Like, even if just if the app isn't in the foreground, you're probably not gonna receive it. And, there's a lot of kind of

halfway solutions out there that in some cases can work amazingly well, such as, like, sending a notification to the receiver. And in some cases, that will get you a little crumb of CPU time that's enough or something. But it's all a bit like I don't wanna say half baked, but, like, if your phone is dead or in airplane mode, you're not receiving that payment. Right?

So async payments kind of async payments to the rescue on that one, I guess. And,

that started, I think, December 2021.

Matt sent out Blue Matt sent out an email on the mailing list,

about this scheme that was based on onion messages. And, the basic idea

is that the, sender's LSP will hold on to an HTLC

until it gets an onion message from the receiver saying, hey. The receiver's online now.

You can let the HTLC fly.

Does that make sense? Kind of at a super high level. I think so. Yeah. Yeah. Yeah. But, like, that's kind of an improvement on Basically, your phone is connected to this LSP's node. Right? And the node's, like, kind of holding on to it for you. Exactly. So this is assuming the sender has an LSP and the receiver has an LSP. But, obviously, if the sender is always online, it also works. They can be their own LSP. Or they can send it at that moment. Mhmm. Yeah. And for people who are who are not familiar,

onion messages is a way to

send a message to another peer on the network, not necessarily your media peer, but some other,

node on the network,

using basically the onion routing protocol you that you would normally use for a payment.

The difference, of course, is you you don't need to actually send any, funds. So, you know, finding a route is a little bit easier. You don't have to look for liquidity,

and there's no problems, you know, like, splitting. You like, if for multipath or multipart payments, you're not trying to find multiple routes to your your, tenant recipient. So you could send essentially a a network message through the this,

through through, like, the the lightning network itself.

So you're in this case, I guess, it would be the LSPs are essentially communicating. Right? When it knows anything you go into the, like, the sender's LSP, right, will will basically hold the the onion

and then send a message through onion messages to the recipients. Is that correct?

Yeah. Saying there's an HTLC available to claim when you're when the recipient comes back online.

And then, yeah, when the recipient comes back online, they'll send an onion message to the sender's LSP

saying or to the sender, I believe, saying, you can let the HTLC fly now,

because I'm online.

So yeah. So everything happens native in Lightning, so you don't have to have Yeah. Yeah. A separate message. You don't have to directly connect to any of,

peers.

There's this concept that they all worked on too is, find the paths, which you could essentially take,

a portion of the path. Typically, I I believe it's always probably the end of the path,

and have a few nodes that are are, you know, through this, you know, metric encryption,

sort of blinded away from, anywhere everyone else on the route such

that

you don't need to well, I guess that's kinda how onions work, but in general, but,

you're the recipient the intended recipient of the payments or the message

for, for instance,

would have,

supplied essentially a a portion of the route, the blinded portion,

and you could form a,

path from yourself to that introductory point of the blinded route,

the blinded path, I should say.

And,

like, you don't have to essentially docks the recipient or Right. Like, right now, if you make a lightning payment,

Yeah. Right. Yeah. Yeah. It's rough.

Which makes it extremely difficult to use Lightning privately on the receive side.

Exactly. So Exactly. Async payments,

you know, kinda help with this because it I guess they would be using would they be using blinded paths at all in that or not? I mean, they would be using them for any and all onion messages that are being sent in theory. So, yeah, you would you would get privacy there.

Yeah. No. Blended blended paths are cool. It's like you basically, like, select the popular node in the graph that's a few hops away from you and then create encrypted payloads for each hop until you, And then you reveal that to whoever the sender is. All they see is the internode's pub key who has a 1,000,000 connections and channels anyway, and you could be any hop within 4 or Right. 4 hops of that popular node.

So, And because they're known pub keys, you just encrypt it with their pub keys. Right? Like, the routing node's pub keys? Yeah. You just yeah. Well, the intro node, is like, the recipient or the sender can see that because Right. Yeah. They need a way to they need to know where they're sending. Right? Mhmm. Exactly. But every other pub key is obfuscated,

so it's totally, private in that sense.

But, yeah, I guess getting back to the async payments. So Matt sent out that scheme on the mailing list, like, December 2021.

And, so, yeah, that's been kind of a big priority for me, recently. And,

an interesting part about it is that we're gonna be basing it on trampoline, and so that's kind of a prerequisite for it.

And, the reason for that I guess, for context, trampoline

is a way where a sender who's who doesn't have a lot of, like, it could be a mobile non custodial sender who doesn't have a ton of payment data, doesn't really know what the best routes are, maybe doesn't even have enough bandwidth to sync the full Gossip Graph. They can give their payment to a trampoline node, and the trampoline node will

find a route for them on their behalf because they know all the good routes because they routed a ton of payments and have the full,

graph. This is what Phoenix is using. Right? Async is does it async use trampoline? Yeah. TBAS was the one who proposed it, and they are a trampoline node. But, yeah. Don't Or maybe they don't they don't have it enabled yet. Right? But that's the plan or something? I think they have, like, some proprietary one that maybe not proprietary necessarily, but, like, based on, like, a initial draft, and they just reviews that. But I I don't know all the details. That'd be They do have an initial version of, a kind of async payments like thing, but I think they definitely run a trampoline node straight up as well. And, they've been pushing for adoption of that. It's just that, I guess, like, people haven't really had time or listened until now, if that makes sense. Well, async is interesting. Right? Because, like, the most

like, they have an implementation, but, really, it's

used on Phoenix, which is one of the best mobile wallets. But it's like, I think Phoenix is the only thing that uses them really. Right? Like, a consumer wallet wise.

Yeah. It's interesting. They tend to, they just have, like, a vertical stack there. Right? Yep. Yeah. Yeah. They I feel like they don't really, push it that much. And, like, purely mobile focus too. Mhmm. Mhmm.

So I wanna go back. We talked about onion messages. Right? So one of the hot button issues is bolt 12. Mhmm.

And bolt 12 is this idea that we could have a

a privacy preserving reusable

invoice.

Yep.

Rather than generating a new Bolt 11 invoice every single time Mhmm. That also has our pub key in it. There's a bunch of different benefits with gold 12. But one of the key things that relies on is onion messages. Yep. And the common refrain of it is onion messages

can they're potentially a spam vector. They're a denial of service vector. You can just if there's no payment attached to it, I can just send a ton through your node or whatnot. That was the narrative. Yeah. Yeah. So yeah. One way to mitigate that is Counter that. Is

well, I I think the one that we've been thinking about is is just send, or just allow any messages from peers that have channels with you. So you already have a channel with them. You already gossiped them and let them know that. Down there,

so you know this this counterparty.

If they spam you, you could

well, I mean, there there's ways you could have, like I guess it's

called, I'm blanking out the term now. It's it's sort of like a pushback mechanism. You're saying, okay. You're you're sending too much. Back pressure. Yeah. Back pressure. There you go. And, I don't know if, Vail, if you're in discussion with some of the people in Oakland when we met about that. Yeah. No. TBEST has a really good solution for that, in my opinion, where, basically, if you're getting too much onion message spam,

you basically just, send a message to,

the last person that sent you an onion message, who's likely to be the spammer, right, just by, like, probability saying, hey. Like, please shut up. Because you don't really know if it's them. It could just be going through them. Right? Yeah. Exactly. Yeah. So you send your next PR message like, hey. Please shut up and forward this to whoever sent this to you, and it just goes all the way back to the original spammer. So you gave them a telephone. That's what I'm saying. Yeah. Yeah. You, like, telephone it back until they are forced. But does it also have, like, a oh, you're just sending back spam towards them. Is that what it is kinda? Or are you actually blocking the messages from coming? It's I think both. Yeah. So I don't know the exact proposal, honestly.

Because it's kinda funny if you just spam them back. No. I figured yeah. It's like a Mexican standoff dude here.

No. I I don't know all the details of that, so I would be, like, just surmising at this point. Because, personally, like, my simple monkey brain, like, I really want poll 12. Like, I'm

Yeah. I've been I've been implementing it, and Dale's been doing a lot of the early prep, like, prerequisites

to that with, like we said, onion messages,

line of paths.

Offers are really cool. I'd like to see it.

Right now, we have,

async and core lightning are doing some interoperability testing already.

We came in a little bit later and had quite a bit of feedback for the spec, so it's it's sort of evolved and morphed a bit, over the last number of months.

But at this point, we are hoping,

I guess,

not this coming release, which should be out in a couple weeks, but the release after will have,

full support for offers. So that'd be you, and Core Lightning already supports it. Right?

Yeah. They I mean, they've had to change their implementation since we've given feedback, but, yeah, they're they're, you know, they Rusty was, Russell was the one that proposed it. So,

that's been implemented since So it'd be cross compatible when Yeah. We will we will do interoperability testing with them before we we make it public. And async doesn't have it yet. Right? They are currently doing interoperability testing with correlating. They basically have it. They're almost ready to. So it'll just be l and d that doesn't have it. And Yeah. After the 3 of us. So l and d Like Electrum's Python implementation. Yeah. Yeah. There there's a few, like, esoteric implementations out there that probably won't happen.

LND

has a phased approach of doing,

bolt 12.

I I mean, there's, like, 5 phases from what I saw, so I I couldn't rattle them off right now.

But they will eventually have it one way or another, it sounds like. It's just a matter of priority for them, I believe. So you think L and D will implement?

They they have people already contributing

to the implementation. It's just gonna be a more slower approach to get there. So I think it will be there. Just a little Bullish. Yeah.

So, I mean, just to go back, when we're talking async payments and onion messages, it's actually way cleaner than that. Right? Because it's it's literally just your channel partners that you need to

send the onion message from. It's it's more like you would probably prioritize messages from channel partners and then only forward onion messages from randos

if you had time or maybe not at all. That's also totally fine. It'll probably be some kind of config option. Yeah. It's like a policy sort of change for your.

2 bolt 12? Yeah. 2 Yep.

Well, MBK is making it 2 weeks, but the account will have that done. The

public

data structures for bolt 12 in the next release.

The the following release so that'll be 114. The the then in 115,

the hope is that we'll have actual,

bind it path payments and forwarding and all that jazz. That's exciting. So yeah.

Yeah. We're really excited about it.

Long time coming.

Yeah. I mean, maybe not. I I think it's funny. Like, we,

especially if you're just if you live in this space, you think everything moves really slowly. But then if you just, like, think back, like, a year ago or 2 years ago Mhmm.

You know, I was just,

I was 4 years ago, I was doing work with I I I do a lot of work with activists through HRF. Yeah. And I just recently did some work with them, and I was thinking back to the first workshop we did, which was 4 years ago. Mhmm. And we were using green wallet with the activists because

Lightning didn't exist yet. It didn't exist in practice yet. Blue Wallet didn't exist yet. Moon Wallet didn't exist. Sparrow Wallet didn't exist. Spectre Wallet didn't exist. Strike didn't exist as a company.

Right? I think Cash App maybe it was at it was at Cash App headquarters. I think maybe they had just added Bitcoin support.

Like, when you start to actually okay. Let's think back, like, 2 years or whatever. Like, things are moving very fast,

and it's easy to get discouraged. And I get discouraged a lot, so I think it's important to remind everybody that,

there's a lot of progress being made. It's really hard to keep track of it. Yeah. Yeah. There was a time where

people lightning doesn't work. You know, my people are always failing. I go through phases. I'm I'm, like, either, like, super bullish on lightning, or then I get, like become, like, an on chain maximalist again, and then I, like, get bullish on my name. Yeah. It It ebbs and flows for me. Yeah. I I think too You'd be going on chain maximalist periodically? Yes.

Interesting.

What are the privacy? Well, like, I have, like, Tony I have, like, Tony on. You know, we, like, spend, like, 2 and a half hours talking about lightning privacy nuances or whatever. Oh, yeah. If you if you listen to Macarello's talk at TapCon for about all of the big things they have broken. Yeah. Where everything's But we can fix it is the Yeah. Yeah. Is the second part.

Yeah.

I think we're pretty excited about all the

the upcoming,

I guess, improvements to lightning, especially around privacy and,

reliability, especially facing payments.

So,

you know, Lightning

works, but now it's gonna hopefully you know, it'll take some time, but it'll it'll be,

much more improved.

Yeah. I mean, there's definitely, like, certain,

like, really not techie friends where I would genuinely hesitate to recommend Lightning to them until we had, like, the async payments nature. You know? Because I don't wanna I don't wanna be their tech support. Like, I want it to just work for them. It's, like, selfish almost. Yeah. If you ever, like, pay yourself on the same phone with Lightning, you're you're like, wait. What had happened? Like, oh, I have to switch the app back. First, it actually worked. But, yeah, async payments. I

like that.

No. Yeah. I feel that. And you see it a lot. I mean, a lot of my focus is on, like, the education space, so you see the pain points just all over the place.

But it's definitely way easier than it's ever been,

even, you know, 6 months ago or 8 months ago or something like that. Oh, yeah. Totally. And, I I think, like, on the the spiral side of things,

I guess it's maybe not entirely lighting related, but we have, we've funded the, you know, know, people in the Bitcoin design community. Right. And just seeing, like, improvement in UX,

like Steven's here this week, and and he was one of our grantees. Steven's awesome. Yeah. DeLoren. DeLoren. Yeah.

Yeah. And so, like, I remember when they had the Bitcoin design guide first come out. It was, like, their v one of it. They're like, hey. Now we're doing lightning.

And it's like, the questions are okay. Like, you know, what there's these, I guess, huge questions around UX and Lightning and what does that mean? Like, should Lightning eventually just become

some,

I guess, technology that no one really cares about that it's using Bitcoin? They just know it's Bitcoin. It's not lightning. Anything special about it, just how Bitcoin works. It's fast. It's instant. It scales.

So that's the the hope. Right? Yeah. Definitely. Like, ideally, people won't even know they're using Lightning. Right? It'll just be a seamless instant payment. So Right. That's right. They're just sending money. Exactly. Yeah. And the unified QR on the Bitcoin design side, the unified QR code is just kind of another step in that direction. Yeah. Is that bolt 21? I forgot which I think bit 1. Yeah. Bit bit 21 rather.

Yeah. I think, like,

Block took that on for Cash App. They announced that at the Miami conference last year, I think. Where And then Miles Souter wouldn't shut up about it. Yeah. At the time I talked to him. We really like to get that QR code down size down a bit. It was a giant QR code they they showed on screen.

So

Bolt 12 will help a bit with that. It has native support. Right? Yeah. Yeah. It is fallback to us as well, but I think

I guess the the issue would be, like, if you have a wallet that doesn't support Lightning. The whole point of BIIB 21 was that it was backwards compatible because

it's natively an on chain address. Right? Exactly. Like, the memo field has the Lightning address in it. Yeah. Yeah. So simple way to look at it. Whereas, like, once once everyone's has bolt 12 support,

you know, of course, it's, like, time for walls to adopt that,

You would be able to have an offer code,

that had fallback addresses, for instance. Actually, it's technically the invoice, which is communicated

through,

onion messages, so you don't have to worry about the the size of the of that.

So we could go on more into the QR codes and offers and if you want, I'm not sure if I can pull It is nice that it will talk about this is the QR side. The audience is very the the my audience is very technical, and also they're happy to just not understand 50% of it. They try and take it in by osmosis. Yeah. Yeah. I at least have this, like, more present in mind because I've been working on it. So,

you know, offers, like, you you I think you mentioned earlier, it's, like, a way to have, like, a static QR code for multiple invoices, essentially. And it's really nice for I mean, we're streaming video right now. I could just put a QR code there. I could post it in, like, my banner on Twitter,

Like, in the Global South, people, like, print out lnurls.

Yeah. Right?

No. We were getting pressure from Cash App for that feature because sellers wanna be able to print out a QR code. And just, like, put it on the Exactly. I mean, you I remember back in the day, like, 2013 and stuff for the Bitcoin adoption, like, that's what they did. They just took a fixed address,

put the QR code on, like, a little piece of paper, maybe laminate it or something. It was, like, oh, you wanna pay me Bitcoin? Send to this thing. Yeah. So, like, the predecessor to offers is bolt 11 invoices. Right. And so we we kinda talked a little bit about that.

Bolt 12 offers, you could think of, an offer as a a precursor to an invoice.

So you you know, they could still be represented just like a a Bolt 11 invoice as a, you know, a a Beck 32 encoded string,

but and also represented as a QR code.

The difference though is

you aren't

given essentially a I guess it would be in the invoice. There's, like, a a payment hash. Right? Typically?

There's no payment hash in an offer because you're you're basically requesting an invoice.

So the offer may be you know, I may have a description. I'm getting, like, a cup of coffee.

It might have some information about, like, how many cups of coffee you could purchase.

It'll have an amount that

that that coffee is in, I guess, MSATS or could actually be in a fiat currency. Currently, we're not supporting

or I guess

creating offers of via denominations, but we could pay them since those are eventually translated to MSATS.

So, essentially, once you scan this offer, you'd say, okay. I wanna request an invoice for this item.

And through onion messages,

you can

request an invoice using an invoice request.

The offer may have blinded paths in it. I think we're actually we're enforcing that. Right? Is that Yeah. It went back and forth, but it is required at the moment. So blinded paths will be required. So the offer itself will have, blinded paths. There there's some, like, technical challenges around that that I think we'll have to be careful about.

Basically,

making sure you have liquidity

to the node, on those blinded paths.

But once you request an invoice,

the person who

published that offer

would, get that request through an onion message. They would, you know, check it out and send you back an invoice

of a particular payment hash,

and the amount that you requested, making sure if there's any currency conversions that it's accounted for. Yeah. So that was a kind of a good improvement because people were having a hard time encoding an invoice in a QR code that was scanable, if that makes sense. Yeah. So I've seen especially, I mean, once again, Global South,

shitty old Android phones. Right?

Yes? M b k's question? Audience.

I find that, like, a lot of devs sort of, like, forget that you don't need so much error correction on those QR codes. M b k's saying that Yeah. Devs often forget you don't need so much error correction on QR codes. Mhmm.

Good point.

But that's the thing. Right? Like, the QR codes, like, you don't want them to be too dense. They're hard to bulk skin. You can have

Yeah. So LDK, like, we we don't take how many dependencies as as Val knows very well.

Made our own HTTP server. That's all I need to say. Yeah. So we don't have a a QR code dependency, but, you know, we do produce the the string, the the Beck 32 encoded string,

of an offer.

There's also different other probably, I don't need to get into these, but there's, like, a refunding mechanism in offers. So nice little feature there. Very cool. And then,

something we're calling, I guess, it would be not necessarily spontaneous invoices, but, unsolicited

invoices,

which is, I guess, more handy for, like, donations, I would say. You don't have all that back and forth with invoice requests, that way.

Wait. Hit me on that last part, the donations part. Yeah. So,

this is,

I think, it's in the spec. We haven't implemented on our side yet, but,

there are there's you could have, like, a invoice without

a invoice request that it originated from. So you'd have a QR code for an invoice. Right. And I haven't gotten into many of the details of this, but, essentially, I think it's helpful for for donations. Right, Belle?

I thought, Or am I thinking of of the I'm not sure. Okay. Yeah. We'll have to get back to you on. I thought that you would want to specify the amount in your invoice request

unless, I guess, the unsolicited invoice has an optional amount. Oh, yeah. That's right. I'm not sure about that. I'd have to look at the spectrum. I'd have to look too. I kind of thought that some people just

wanted unsolicited

invoices, so maybe they could skip

to that part of Bold 12 and then later add onion messages or something like that. Yeah. But, anyway

But in general, Bold 12 to to me,

the

the main the main use case of of these reusable offers, right,

that you could just, like, print out or post or something was donations. Like, that was, like, the pain point. The pain point was Yeah. I'm confused about the unsolicited. And you let you see it all the time. Like, you know, people wanna raise money. Right? And so, like, what are they stuck with? They're stuck with, like, running a full BTC pay server

Mhmm.

Or using a reusable Bitcoin you know, reuse a Bitcoin address, which is horrible for privacy.

Yeah. And You have to pay on chain fees and whatnot. Yeah. Or you can just tweet out a

QR code or a text string Yeah. And offer QR code. Then you're good. Yeah. And we get a tattoo. Yeah.

We we actually designed the,

the implementation of our offers. I think a lot of the other implementations are doing this too, such that it's sort of, like, stateless where you

if you produce an offer

and then you produce a invoice from that offer when they're requested,

we don't actually hold on any extra data. Like, there's no problem with,

like, a ton of donations coming in. They're not gonna, like, swap your server and and have, like or your data storage rather and have to take or, like, keep track of all these, like, payment hashes and preimages to to release

because we sort of derive that from some of the information that we have in the offer. So it's pretty cool. That's awesome.

Yeah. It's cool. And I've I'm excited for, in the original spec for offers was subscriptions as well. Right. That got taken out just because, you know, for simplicity, but I'm excited for when that gets added back in. I mean, the original spec had a lot of things. Yeah.

Yeah. And then for subscriptions,

that's when least, currently, that's when having,

Fiat denominations makes a little more sense because, you know, this fluctuation in the price of Bitcoin, like, if you're But then it requires some kind of oracle or Yeah. Yeah. That's that's one of the reasons know what the price of Bitcoin is. Right? Exactly. Exactly. So if you wanna do it. But I'm sending you $5 a month. I don't know how many sats that is. Yeah. So you if you wanna do it in, like, a trustless manner,

you would have to have some sort of, like, you know, oracle or money oracles to kinda come together on that price and be able to

you know, when you request the invoice, put that amount in, essentially.

We have innocuous

Finch in the comments asking

what wallets are available right now that use LDK?

Let's see. We have

Cash App is using a bit of it's not self custody, so there's that one. Were you guys involved in the Cash App situation at all? Or In what situation? I'm using Adding LDK? So we were Intimately. Assaulted

at them. We didn't actually implement it for them. Yeah. So how did the can you talk about how that happened, or you're not allowed to talk about that? Or It was probably well, I'll get some details. I think,

Ryan Loomba shared quite a bit at because that was a quite big undertaking. Right? Pardon? There's quite a big undertaking at the time. Yeah. Yeah. I mean, it started, let's see,

would have been

a year from this past November, I think, around that time frame, and it only took a few months frame. Well, first, they only added sends, and it took a while for them to implement receives. That is true. They they did that. Mhmm.

They work on Slack. You know, we we don't have much of a Slack presence, but we're, like, kinda lurking on their channels. They'll they'll ping us if they come into problems. Yeah. We had a channel that was, just The combined channel? Yeah. Yeah. So we were would kind of have

a bunch of notifications turned on for that and just try to get back to them as quickly as possible.

They definitely had some unique

feature requests such as the, Phantom node feature that we ended up adding. What's that? It basically allows you to run several lightning nodes and load balance payments between them such that any of the nodes can receive the payment.

So that was really important to them just because

for obvious reasons, basically, in case nodes go down

or need to be restarted.

But, yeah, it was it was definitely interesting because we were thinking a lot about mobile, but then our biggest customer was extremely enterprise. Right. We were coming out with these enterprise features. So, yeah, it was definitely but it was it was great working with them. I think it I was we were all happy with the way it turned out. Yeah. Yeah. Then, we mentioned earlier, but Sensei Right. Was on there. Blue Vault has an implementation. It's kinda hidden behind a feature. It was in the Puppet Jack video.

Oh, is it? Yeah. Yeah. Yeah. That's right. He he was using it. I forgot. But it's not in the main release?

It is in a release, I believe. It's like developer option. Yeah. You have to basically tap developer a bunch of times. Yeah. You you have access to it.

I think their largest,

the issue why they haven't gone forward with that is because of LSPs is my understanding. Yeah. They're waiting on an LSP to be available because,

Over Torment basically doesn't want to be an LSP or Fair enough. That he wants to,

use someone else's service. And he just wants to make a wallet. Yeah. And this kinda goes back to, like, the the mobile case of, like, you know, mobile's hard. We don't quite we're not quite there for Right. I mean, you look at the big ones. It's like Breeze, they're their own LSP. Phoenix is their own LSP. You're kind of forced to do it. Yeah.

Something like Zeus is, like,

they don't have an LSP, but they're required to use your own node and connect back home. Yeah.

So,

mutiny also uses LDK. We were just talking about those Yeah. I mean, we we're meeting up That's a cool project. Today and just, like, kinda going over all people or at least experiment And then exploit uses,

you know, Tony's project. Yep. Yep. On exploit. Like, he attacked my node with it. There there's He did. Probably. I'm like his test case. Oh, that's right. I don't remember that. Attacks my notes.

But there there's probably, like, I would say,

a couple to a few dozens of people, projects, etcetera,

experimenting with LDK based on the the spreadsheet that serve Steve has been coming up with. Yeah. Definitely, we're considering it on the road map. Yeah. So it's various degrees.

I would say,

you know, we're pretty happy with with where it's

going, but we, of course, like to have, you know, this be one of the more premier ones for mobile, and this is gonna take time for

that. That makes sense to me.

It's actually weird because sometimes,

on our Discord, someone will come out of the woodwork and they have built, like, this full LDK app and we had never heard from them. That's the cool part about open source. Right? Yeah. It's awesome. There's, what, Valera Labs? Is that Yeah. Valera Labs is one example. This neural developer from

country, but not child prodigy has been building this, like, multi LDK node Yeah. Privacy thing.

Is for you. Is that really is that I think he's trying to hire people right now. I don't think they've like, they definitely done quite a bit of work on it. That's my impression too. That's awesome. Yeah.

Cool.

I mean, where do you guys wanna go with this next?

I know I'm the host.

It's a good question. I don't know.

What are,

well, can we can we just pull back for a second?

How long have you both been at Spiral?

So same time we got hired. Right? It was a little over 3 years ago? Yeah. Like, October ish 2019 Mhmm. September.

And then

that's a while. Yeah. Yeah. So we joined we were serving the inaugural class, with Eric and oh, Matt got hired earlier,

and Steve was And that was, like it was, like, Steve and then Matt. Right? Yeah. Steve then Matt.

We are we're all interviewed by them.

We went through the regular block interview process

and came together end of September, early October. And,

yeah, we've grown since. So we we have 3

well, before, there are 3 new engineers. We we got,

Connor Okus, who

is a kind of PM on our projects Right. On our team rather.

Haley Burke,

who's also in sort of the PM program manager sort of role.

And then I'm not sure if I could say the I can't say the other one person's name, but I don't think so. The person Don't do it, Jeff. Our account. Who runs our Twitter account. Mhmm. We nameless. He's I just got along on our website at all. I just got to meet that person. It was great.

But, yeah, then we we hired 3 new engineers recently,

with with Elias,

Wilmer, and Gershaun. And that person writes those projects. Awesome blog posts. A good idea. Val, I don't know if you wanna point anyone that either of us could go into them. I'm sure. Yeah. Definitely. I feel like we could just, like, switch off. I mean, one of the new hires I mean, they joined last May, so they're not really new anymore. But, Gersharon from our team is working on the, VSS project, and, I thought that was cool because

it's a versioned storage service. And, it comes from the fact that one of the unique things that LDK can provide is switching between devices. So you can run your your lightning wall on multiple devices instead of just 1, kind of like,

you know, how you can use WhatsApp on your phone or your computer type of thing.

So yeah. And to do that, the

powerhouse behind is gonna be this storage service where you take a lot I mean, Jeff can talk more to it because he's been re actually reviewing the code. I've been reviewing a bit. So I I guess the problem that we're trying to solve is, like, you know, like, they also have the multi device.

And one issue you'll have with flighting is if you have a device out of sync and it's using old channel data, like You lose your money. Yeah. You lose your money. Lose your money. Very,

inclined to error. That's how I lost all my Bitcoin. I had to start fresh. To Tony.

Balance split.

So version storage service is a a way to sort of,

you know, you have this this service for storing your channel data,

and,

it versions in such a manner that

if you have another like, multiple devices trying to to sort of, make updates to it, it knows if it's sort of out of sync and it you know, you should sort of refresh the data and go from there. So it's it's very useful for lightning.

But Does it require is it a cloud storage? Or So the the storage itself right now, it's a a Postgres,

database. It's gonna be used SQL.

You could run it wherever you want, though. Like, you so if you wanna do It could be locally on both devices, or does it no. It can't? Well, no. It'd have to be it would have to be somewhere

It's either your server or someone else's server. Right? I mean, I suppose you could have it on You could have it on, like, an Umbrel or something, maybe. Yeah. Yeah. Like that.

So that that kind of helps solve that case. It's still pretty early on, like, where we have the develop underway,

but the initial version will be, like, working with just one sort of

one client essentially to the service. So,

there's never really a problem with with things being overwritten. But then when you get the multi device server approach, then get into the more tricky parts of

implementation.

So, that's pretty cool projects.

And that's, like, a that's a basic concept that people expect. Right? Just like I'm running it on my iPhone, and I wanna use my iPad, and I want it to be the same wallet. I don't wanna run 2 different wallets. Exactly. Yeah.

Yeah. That's what people have come to expect. I feel like it's a reasonable expectation. So

That makes sense to me. Anything else cool that Yeah. So that's that's excited about in support?

Project. We have a couple other things. Well, one thing, I guess, we didn't touch on, which we probably should, Let's do it. Arik

wrote something called rapid gossip sync, and

it's essentially a way

to,

it's good for mobile devices. If you have

a sort of like a semi trusted,

setup or maybe you have an LSP that you you kinda trust and Right. You want to,

route payments privately,

and there's there's basically you know, the the

way you would do that typically is you download the whole gossip graph from the network

and you verify that the channels are actually there, which would require a full mode,

And you're able to sort of,

you know, through that long process of dialing that data, you know, from the the p two p network,

you could eventually come up with a path to your tenant recipients and make a payment.

That kinda sucks for mobile. Like, if you're offline think so much. Getting yeah. Go ahead, Allison. Okay. So I mean, people see it. Right? Like, when you, like some of these lightning wallet apps, like, you open it, and you're just sitting there, sinking. Yeah. You're sinking. A lot of spinning bars showing spinner and just going around. Infuriating. Yeah. So it's not actually, like, block data coming in necessarily. It's it's more of, like, getting the the PDP gossip,

so you know what the channel graph looks like.

So rapid gossip sync is a a basically

a way to deliver that gossip data in a more compact format,

from, like I said, like a sort of, like, a semi trusted individual, like a like LSP.

And

from, I think, the size of the data, I've seen I mean, you could do, like, incremental updates as well, but it's, like, the order of, like,

a megabyte or less sometimes. So I think the full graph might be a little more, away. I looked it up in preparation. So, normally, if you're syncing gossip, I think it was either 53 or 83 megabytes, and then you get it down to, like, 2 megabytes

using rapid gossip sync. And it goes from, like Wow. A few minutes to 0.4 seconds. Yeah. So, like, all the signature data data gains. Yeah. Yeah. All the signature data is stripped, is my understanding. Mhmm. There's some I guess, the encoding format makes it easy for, like,

like, if you have short channel IDs, it it doesn't have to have the full, whatever, 60 or 8 bytes for each one of them. It could, you

know, have an offset from the previous one, for instance.

So it's very compact format.

Then when when you have that data on your phone, you can, you know, you could do your own path finding, and thus, you're not sort of telling your LSP, you know, everything about who you're paying,

or even relying on I guess, there there are some, I guess, drawbacks, like, you're relying on them to deliver that data to you, and

that it's, you know, actually accurate. They're not hiding anything from you.

But, you know, you might be that might be a fair trade off.

Yeah. I mean, they can't, like, steal your funds or anything. Right. Originally, actually, that was a privacy downside. This is kind of a tangent. Let's do it. Originally, that was kind of a privacy downside of trampoline was that you would be revealing who the recipient was to whoever the trampoline node was. Right. But the cool part about blinded paths now is when you put those two concepts together, you're no longer revealing the recipient, but you still get all the benefits of using trampoline,

if that makes sense. And there's multiple hops after the trampoline node. Right?

Yeah. So if you, like, if you give the trampoline node, say, I wanna send a 100 stats to Matt's blinded path, he doesn't know that it's to Matt. He just knows that it's to someone within 4 hops of this Or you have some plausible deniability at least. Yeah. Exactly. So and it's funny because, like, t best, kind of came up with both of these concepts, but he didn't even plan for them to, like, go together, but they just ended up going together. That is pretty cool. Yeah. Yeah. I thought that was really cool. So They compound on top of each other. Mhmm. Mhmm. Exactly.

Yeah. So that's right, Epic Rapagossip Sync.

We have a a new project as well called LDK Node, which we

earlier, we're talking about, like, level layers of abstraction we're kinda building up in this this LDK,

you know, development kit that we have here.

And LDK node,

we're focusing that on focusing that on mobile usage right now,

and it's,

you know, some some developers who want to add Lightning to their mobile app are sometimes a little overwhelmed by, like,

the way,

the way they could customize LDK, and they just want it to, like, you know, pick something off the shelf and have it tied to their,

a very

narrow API. It's, like, I think, like, 6 or 8 different function calls.

Whereas if you look at some of the other lighting implementations

with their RPC calls, there's, like, a 100 or something like that. And and, like,

maybe that's great for the power user, but for for some mobile clients that just wanna integrate lighting,

you know, that's maybe a little not necessary.

So LDK node is is more opinionated, I would say. Mhmm. And there's some of the choices I don't know if you wanna go through, like, with,

you know, where the block day is coming. Oh, this is what came up last night. Right? I think I'm not gonna say who said it, but Oh,

because this Chatham House rules, I think. Yeah. Yeah. Yeah. I think we we're talking about it a bit, but,

I could go into more detail. But but the

so for instance, like, on a node,

you might have you know, we we did I guess, we

decided for this particular configuration

of LDK nodes more geared towards mobile.

And,

the

I guess, one of the mechanisms for retrieving data, from the chain, the blockchain,

is Electrum or Explora.

And it's

a little different interface

for LDK versus, like, a full node and

probably a little difficult more difficult to,

work with compared to that. You're not just saying this block was connected, this block was, disconnected, and there's reorg. You're not just, like, feeding blocks in 1 by 1. You're monitoring,

you know, transactions

of interest essentially based on, you know, your your activity with your channel openings and, you know, whatnot.

And from that you only feed in data to

LDK that is actually necessary for your own channel. So mobile users can have 1 or 2 channels maybe, they're not gonna have a lot, and so it's

it's a good approach there where you're you have a a smaller amount of data going into it, for instance. So that's, like, one of the sort of

the, you know, choices that was made for for LDK Node for for its mobile set setup, I guess.

Yeah. Pretty much. I think, one of the last steps we're figuring out is, or Elias is figuring out really is persistence. But,

yeah, I think he's, hoping to get it, ready in March. And then, ideally, it would integrate with VSS to just, the storage service to just make this seamless, multidevice,

Lightning experience. So yeah.

And then from there, developers can then build

nice consumer wallets, mobile wallets. Binding scores on top of that for for Oh, that's the other nice thing about, LDK. Note is that because there's so few, function calls, there's a lot more flexibility with what kind of bindings we support. Mhmm. Because, like, for the whole LDK API, we are not gonna manually

write that. There's just too many things.

But for, LDK node, it's it's more stripped down so far. So we think that should be an advantage.

Yeah. Yeah. I mean, Bitcoin has talked a lot about, like, high time preference versus low time preference. Like, LDK is, like, the ultimate low time preference kind of like the project. Right?

So it's, like, slow and steady building blocks. Yeah. And then

Yeah. So then we'll few years, we'll look back, and it'll just be this nice

nice piece of foundation. Right? Yeah. And we we were like you know, we we have the sibling project, which you you know, you spoke to that BDK. BDK. And They're named fantastically, by the way. Yeah. It does all Steve.

Yeah. We have, you know, eventually, it just be Bitcoin development kit. Right? Like, Lightning should just be transparent. So at some point,

you know, I'm not sure how many years in the future it would be, but but we'll have this one development kit that anyone could use. Right. It'll be kinda combined. Yeah. Because you need the on chain components too. Exactly.

So that's the hope. I mean, there's a lot of cool also cool stuff going on right now, like, with Taproot,

Yeah. Anchor Outputs. A good one. So so Wilmer and and Arc have been working on those projects. It seems a lot of people are regretting Taproot right now. You wanna do,

why we should be happy we have Taproot?

I don't know if I could go into detail on that one. You know, let's talk about it. Well, just keys. No. Because the ordinals and description Oh, the ordinals. That's right. That's right. That's right. Yeah.

I mean, Tab Root's another, like, low time preference building block. Yeah. So how far ordinals has come. It's pretty impress I think I'm gonna have Casey on controversially. I'm gonna have Casey on this weekend. So

Yeah. I mean, Taproot, it it's gonna be

slowly rolled on to Lightning is my understanding.

Like, initially,

initial work, I think, is is involving, like, the the funding outputs and commitment transaction items. And it it's gonna be, like, phased approach very deliberately. And and Lao Lou from Lightning Labs was was 1, and Eugene, I believe as well, wrote the proposal for Taproot,

published it just last, I wanna say, June, end of May to June, somewhere around Oakland when we were there.

And it's got a lot of good feedback, and and I think it's gone through some iterations and come Yeah. Our team has been working, with Lalo on that. So they've been kind of, like, going back and forth on the spec and, yeah, making Taproot a thing. I think it's, it's getting pretty close, it seems. So, yeah, that's been really awesome.

Yeah. We're super happy with that progress, I think. Mhmm. I mean, there's some really crazy things you can do with Taproot combined lightning. Right? Like, it just gets really interesting. Yeah. More than I could probably describe right now. Yeah. Same. Definitely some some, like, crazy multisig,

yeah, multisig stuff. Yeah. So, like, the first phase is using And to be clear to the freaks that maybe are completely confused, lightning at this core is 2 of 2 multisigs for every channel.

Look, Rod brought a MBK mic, so you can stop heckling us from the couch.

Okay. Continue.

Musing.

Yeah. The

music too is, I think, the mechanism for doing the multi signature,

for Taproot on lightning.

And so

with that,

I I guess

the initial phase, like I mentioned, is funding output and commitment transactions.

So

that's gonna take some time, but that's that's the first phase of it, and there'll be many more to come, I'm sure. Yeah. What I'm most excited about for Taproot is that after we have Taproot, then we can get PTLCs.

And,

yeah, just going back to the async payments thing,

with, HTLCs

with async payments, you lose the proof of payment property.

But, with PTLCs, there's been some recent work, and we get the proof of payment property back, if that makes sense.

So, yeah, that's been

something that we've been talking about recently. But yeah.

Which yeah. Go on. Oh, so I say that just trying to wrap up a few things that I could recall that we have left,

dual funding. So we have a a outside of of Spiral contributor who's been pretty active on on LDK, Duncan,

working on dual funding and then

splicing is something that we're looking forward to as well. So Yeah. That's on you, Jeff. Yeah. It's my next project, Bill. I'll have some help, as well. I think Wilmer is interested, and, one guy, Jervis, who was Do you wanna give us the splicing shill?

Why should people care?

I don't know if I can get a shill yet. I I I really I'm I'm behind on splicing right now. We'll see. Oh, you're good.

So, I mean, I guess the idea is you You're, like, way you're, like, 99%

ahead of everybody else. You want to increase the the size of your channel, essentially.

Yeah. Because some, Right. I already have my channel, and the only way to make it bigger is to close my channel and open a new channel. And You open a second channel of the same And if inscriptions are making the fees really high, then I have to pay a fee on both sides of that. Right? Yeah.

So splicing lets me do it with just one fee instead of 2 fees. Exactly. Right? One on chain fee. Efficiency thing, I guess. Like You can also mix

You can also do coin mixing with

the with the splices too. Yeah. It's kinda cool. There's a lot of cool applications. I I think there was

there's a swapping potentium

part that was on the mailing list recently,

by Z Man and,

Jesse Posner, I believe. Mhmm.

I have the name right? Jesse Posner? Yep. Maybe Posner, but yeah. Posner one of the not sure the pronunciation, but they they, that involves splicing as well, I believe. And so it's pretty cool,

way to

have sort of a lot of your on chain funds kinda go right into a lighting channel. Yeah. Really cool. And, it's interesting because,

originally, we were resistant to splicing. And the reason

is having 2 channels is basically like having 1 channel, like, with the same peer. I mean Right. Like, you can just MPP over it, and it's you can treat it as if you have 1 channel. Yeah. So we were like, oh, let's not bother with this because you can get, like, equivalent behavior

in a way that's already supported. Open a new channel. Yeah. Exactly. And it's as if you But aren't there routing inefficiencies to have 2 channels? Like, I so, like, the way I learn is I just kinda, like, Leroy Jenkins into things. Mhmm. So when, like, lightning first came out, I was like, well, let me see if, like, I'm gonna get rug pulled if this thing works or it does not work or whatever. So I just created this node, and I said to all the freaks, I said,

if you open one to me, I'll open one to you. Right? Like, send me one bitcoin. I'll send you 2 bitcoin back. No. You open a channel to me. I'll open 1 to you. That's crazy. So I ended up having

I ended up having,

like, a 100, you know,

a 100 channel partners, but 200 channels. Right? Just a lot of lot of channels. And my understanding at that point was that was highly inefficient. That really

not only did I I I mean, you should have as few channels as possible, but also

that for each partner, you should only have one channel. Is that a thing, or is that a So, I mean, at one point, I think I probably should have implementation, but, like, only supported one channel for c yeah. Yeah. So that was a reason, but now they do support multiple Oh, no. But that was fine. I just couldn't open like, if someone the few people that were using CLN at the time or at that Yeah. Time it was c lightning I mean I just couldn't open a channel back to them. That was just didn't exist. Gotcha. But then with l and d users, which was the majority, I would open one back,

and it I thought it was something with path finding or something like that. It, like, confused the nodes. Or I'm not sure. It it really depends on the implementation of the path finding algorithm. So there's multipart payment or sometimes you're multipath, whichever which is actually correct.

But the idea is you split up no payments across, multiple HTLCs.

And, yeah, MPP is usually the how it's referred to as. And

with that, you know, if there's more than 1 HTLC involved,

while each one will have a smaller amount and they are more likely to

make it to the final destination,

there's just more opportunities for failure as well. So

that That's just with MPP. Yeah. Right?

I don't even think MPP existed yet at that point.

There is various incarnations of it, I think, going through time, but, yeah, I I'm not sure. Where are you going with that, Val? You say you said, why don't we just open another channel? Like, why do we even need splicing? What was what was the answer? Oh, yeah. I mean, not not a major point, but, basically,

people just ended up wanting it because they were just, really set on their architecture being

one channel per node. Is that something? Cleaner mentally. Right? I think so. And I think it made their code base cleaner or something like that even though we were just kind of like, well, doesn't make a huge difference. But, yeah. Sure. It's it just seemed like there was a lot

of demand even if we don't necessarily understand

why alone. Mhmm. Yeah. I I think that's,

I mean, typical in a software development project where you push back on because the more complexity you have in a project, the more likely there's there's gonna be a bug. So,

you know, there's things to mitigate that with testing,

but it's a legitimate concern if if, you know, someone comes around like, hey. You should have more than one channel if you're your peer. And, like, no.

And

And then there's an interesting thing, now that we're talking about multichannel,

that I have heard recommended, which is this idea that you have this one public channel between your peer that is maybe smaller than this large private channel you have so that to the gossip network, they they're not aware that you have this big That's interesting.

That you have this big liquidity channel between 2 peers, but they know they can still send a payment through it because it's just big enough that that that payment fits. Yeah. I haven't heard that that argument. So the idea But Tony can still figure out the private channels there. Yeah. And, actually, I I was sitting with Tony one day talking about,

if I would with edit well, he's essentially

doing, like, probing Yep. Private channels. He's done it to my notes all the time. Yeah. Short channel IDs. He just came with this whole list of them. Right? Like, he basically docks all of them. Yeah. One day, he just sent me a did he do that same thing to you? He sent me all these things. He's like, are these your like, are these your channels and UTXOs or whatever? Are you serious? Yeah. Yeah. He did not do that to me, but

he did I my understanding of of the project was that he examined the blockchain for things that looked like light. He used LDK for that. Yeah. He used LDK. So we're I think he tried to use LND, and it crashed, and he switched to LDK. Yeah. There's some database issues, I think, at the time. I think they've resolved those since Yeah. They did the compaction or whatever. But yeah.

So we we told them, like, yeah. You could do this. It eventually will not work once you have short channel IDs, which

or sorry, short channel ID aliases, I believe,

which were I think last summer, we got those in or is it around Oklahoma? Yeah. It was part of the 0Conf, but a really nice side effect of it is that

prior to them, you would basically docks your UTXOs

if you had private channels in route hints and invoices.

And because the channel ID was literally the transaction ID on chain. Right? Literally. Yeah. You could just It wasn't like any It was magic. Combination of, like, the the block. It was, like, put it in mempool dot space. Yeah. I think, like, the transaction number in the block and It wasn't exactly like, you couldn't exactly translate it, but it was, like, enough information to figure a lot of stuff out, if that makes sense. Whereas with SDID aliases,

it's basically a random number, so there's no way of tying it back to an on demand UTXO.

Yeah. Yeah. It's cool stuff. Mhmm. I'm I'm gonna pull us back for one second because Inaki

Wiss Finch came in with another question.

It's about the VSS.

Mhmm. What is conceptually, what's the difference between that versus, you know, using Zeus on multiple devices and connecting back to your own node. It's because there's nodes running on both. Right? That's the answer. Each would have their own node running. Yeah. Understanding.

I'm not as familiar with Zeus setup, but at least for Well, Zeus is, like, remote control for their home. I guess I'm going based off with you. Oh, that's remote control. Yeah. In this case, it would be more like, yeah, you're genuinely running it. 2 independent nodes that are that are the same keys. Yeah. You're not you're not calling out to a green light node. Like, then who is actually on there?

So

That makes sense. He actually answered his own question too on the bottom.

Anything else you wanna go into? You were rattling off a list of cool projects from Spiral. I don't think there's anything else. Like, a cool third doc to see if we're the same thing. Splicing.

Oh, PTLCs.

That would have to talk about that one. I'm not Do we have to close all our channels and then open them again? Yeah. Sorry.

Every everyone's a scammer. I'm rugged again.

I think what I saw, though, in the

oh, I could be wrong about this. It was There was some effort you don't have to for the Oh, do you not have to? Can you just transition them? There's been theoretical stuff, right, that people are saying we might not have to.

But for PTLCs, I you're probably right there. But for the the recent Taproot stuff they're doing with with channels, I think you don't have to close them, but I could be wrong. I was sold the vision that my channels, I was gonna pass them down to my grandkids.

Well, in black space, it's scarce. You you don't wanna close. On chain's so cheap. So well, I guess not with ordinals now. It's still it's it's cheap for now.

Yep.

There, we got MBK in the house. Hello. You happy you got a mic now?

I mean, I shouldn't be talking. This is all lightning.

Do you have do you have anything that you wanna you want covered here? You've been sitting with MBK has just been quietly sitting on the couch for the majority of No. It's very minimum hackling. This discussion.

I guess fees are kind of Do I support, LNRL?

We do not.

Are you? I don't I mean, you could use it with LDK if you want. A lot of people don't like it, but it's actually quite useful. I'm sort of unopinionated about it. I'm sort of indifferent, I would say. It's a hack.

But as I can help people that wanna do a good design, they wanna add it, but I feel like there's enough, like, market install base now for it. It's like it's like everywhere. But is it needed? I have lightning euro. Yeah. But you also use a custodial Albi wallet.

Yeah. So I'm trying I'm trying to do the normie I'm trying to Because he's sitting there. He's like, it just works. It just works. He's never had a lightning channel. That's right. This one by

all I wanna do is for, you know, like, if I'm, like, managing a $100, $500, who cares? Right? I mean, I'm gonna just download 3, 4 wallets. One of them is gonna work, and it's great.

I mean, I've been sending money on Nostril, like, all day, every day, and it just works.

I mean, you can use lnurl with LDK if you want to. But do we even do we need lnurl and postcode12?

Like, is that even I I think that just the there's this massive gap that's gonna happen in terms of, like, just the adoption of bolt 12 and every single ending drop of that on every single sort of client. It's a massive install base out there. With lnurl?

Yeah. Of lnurl.

And, and it's nice to have your

like, people know they can send me stats to nvk@nvk.org.

I guess that's a bit when, like I'd love that. So is there something is anyone thinking about human readable bolt 12?

There was something called That's probably the strongest argument. It's the DNS thing. Right? I mean, DNS thing. Something by You probably could do it with Bold 12 as well. There's something called, like, lightning address, but the is that right? That's lnurl. It's just Oh. That's what he's saying. And we with something like that, you're saying for Yeah. This is translation. Right? I mean, it it shouldn't be that hard.

Like, lightning address is an ln URL, human readable. So something similar for both 12%. Yeah. Steve definitely has, a vision for that. I don't think there's an exact, like, implementation plan, but he definitely wants the whole experience of you save someone's payment, like, in your contact info, and then you just go to pay Matt instead of going to pay Right. Locally.

And another cool thing is you can have a proxy. Right? Lnurl

proxy,

which is the lnurlp.

And then,

so for example, for the Albie stuff,

so, you know, I have my actual l a neural is the envyk at Albie. Right. Right? But then they support proxy. So all I have to do is just put, like, you know, like an identifier. It's actually like some JSON just saying, hey. If you get anything on this It's like NIP file. To to the Albi, then then Albi translates to whatever. But because it's on my domain, now I can have a a human readable,

at it's essentially DNS. Right? Yeah. For for lightning payment,

that goes to my domain then goes

to office domain and then goes to their node. Gotcha. Yeah. I mean Super useful and, like, easy for people to set up. Yeah. I could imagine just different approaches being taken. I I don't I'm not super familiar of exactly what Steve was thinking about, but, like, just the general concept of, you know, once you pay someone, you should be able to keep paying them again.

I suppose with, like, a bolt 12 offer, like, once you sort of scan it, you know it's from format or for whomever,

then if you're you're You're saving your contacts. Yeah. Essentially saving your contacts. Whatever. Yeah. This one issue you think about is, like, okay, if there's blinded paths in there, are those always gonna be in existence?

So you might have channels closed, and then those paths might not work. So that's something like a UX thing we have to kinda work aware. Oh, that's interesting. That's one implication where, like, privacy impacts UX. Like, that's always the thing in life. So does that mean you need a new Bolt 12 at that point? Yeah.

Exactly. You mean offer, you're saying? Yeah. Yeah. You would have to have a new.

Oh, so they're not really so don't tattoo it.

Well

Is it if, like, a routing note routing note goes down and you Well, that's tattoo it, you're screwed. Right? Depends on what your blinds are. Like, you you're gonna have yeah. Val told me to tattoo my offer on me. Hey. That was Of course, I said not to do it.

Yeah. Not yet. Yeah. Not yet. Eventually, you would wanna tattoo it.

Noted. I mean so I think there's also, like, privacy challenges still around line of apps. Like,

depending on how long they are, you might be able to sort of infer,

you know, where they're coming from. This is like a classic privacy hole that I hear all the time. Yeah. Yeah. Which is, like, the perfect is the enemy of of better. Mhmm. Right? Yeah. Yeah. It's like that shouldn't delay rollout. Like, it's still significantly better than the current situation. There's probably a different strategy. We can make, like, fake hops at the end of Yeah. One path. So you're maybe not the last one actually, but, you know, you you are the one. Or something like Mutiny and Sensi where you're, like, you just spin up a bunch of a bunch of, like, simulated nodes, essentially. Yeah. Well, then, yeah, you could it's that yeah. I guess that that could be a potential solution. And then blinded path through your own nodes. Yeah.

Does that even that would help, right, I think. It gives you plausible deniability.

Yeah. I guess, just in general, though, like, there there are

with any

solution that we have, there are can be challenges. And and so part of the you know, having this being a community process is to have people poke at it and prod and find these problems so we could address them and come up with a solution that's gonna work.

Awesome.

Yeah. Well, I appreciate you both both of you guys. Well, thanks for having us. Yeah. Thanks. This has been a pleasure. I'm feeling I'm on the bullish crescendo of my lightning right now. Great. Awesome. I'll let you guys know when I'm on the bottom again while having some conversation. We'll talk you down from the ledge.

Yeah. This has been an absolute pleasure. Before we wrap up, I'd like to end with final thoughts. Cool.

Final thoughts.

You know, know, come to our Discord community. How do we get there? L d lighting devkit.org.

There'll be a link at the bottom of the page.

We'd love any developers working on LDK or working with LDK to come and tell us what's good, what's bad, and help us improve it, contribute.

You know, we want more and more people outside of our core spiral team to be part of our community,

and our contributors. So more the merrier.

Yeah. I totally second that. And, yeah, we're really welcoming. Even if you don't know Rust, if you've never contributed to open source before,

you know, we still want you to come contribute. And, yeah, don't be shy. And, yeah, check us out and use it as well. Great. Well, thank you both.

I'm looking forward to this meetup tonight, and

are you guys gonna be in town for a couple more days? Or Yeah. Till Friday. Till Friday. Looking forward to hanging out some more.

Huge shout out to the freaks who joined us in the chat and who continue to support the show. I appreciate you guys.

As a reminder,

I will be ripping a dispatch with Steve Lee,

Friday morning.

So definitely join us for that and keep an eye out for that. It'll be about a year since we had him last on dispatch, so it'll be cool to, like, look back and and see how far we've come. Just go back to our previous conversation. I think we've come a long way in just a year. Yeah.

And

I think there might be 2 more dispatches by the end of the week,

in addition to that. So,

yeah, so just pay attention to Noster or Twitter or

the Matrix chat or subscribe on YouTube or Twitch or wherever,

podcast app. I don't know. You'll get notified. I'm just gonna drop a ton of episodes on you this week,

and, you can listen to them in your leisure. So appreciate you all. Thanks, Jeff. Thanks, Belle.

Stay humble, Stack Sats. Cheers.