Citadel Dispatch

Share on social media:

Video: https://youtu.be/j7R6CLnWI4M

0:0:00 Odell Intro
0:4:48 Lightning Services & Liquidity Providers panel with Ryan Gentry, Roy Sheffield, niftynei, João Almeida   
0:51:36 The Future of Lightning  - with Christian Decker, Hannah Rosenberg  
1:23:05 Signatures - with Jonas Nick, Andrew Poelstra, and Nadav Kohen  
2:03:50 Covenants - with Jerem Rubin, Burak Keceli, Sanket, hosted by niftynei and Mike.  
2:43:17 Tradeoffs of Lightning Implementations - Christian Decker, Matt Corallo, Olaoluwa Osuntokun  
3:35:30 Defining The Standards Of Taproot & Multisig - With Keith Mukai, Jameson Lopp, Stick, Oliver Gugger, Afsheen Bigdeli  
4:23:10 Preventing Attacks On Bitcoin - With Peter Todd, Bryan Bishop, Luke Dashjr  
4:48:10 Olaoluwa Osuntokun - Keynote

twitch: https://twitch.tv/citadeldispatch  

bitcointv: https://bitcointv.com/video-channels/citadeldispatch/videos

podcast: https://www.podpage.com/citadeldispatch  

telegram: https://t.me/citadeldispatch

support the show: https://citadeldispatch.com/contribute

stream sats to the show: https://www.fountain.fm/

join the chat: https://matrix.to/#/#citadel:bitcoin.kyoto

[00:00:01] Unknown:

Hello, guys.   Good morning, Miami.   By a show of hands, who was here last year?   I can't see any of your hands, so that's a bad idea.   Well, we've come a long way from last year. Last year, we were in a little tent. We called it the Fostome.   It was more of a tent than a dome,   but it was very active and we had a lot of people there and people were very excited about it. So this year, it was important for us to do it bigger.   Might have overshot it a little bit. It's pretty, pretty huge.   But at the end of the day, I hope you fill up this stage every day. We're gonna have it today, tomorrow,   Friday.  

Really fantastic lineup. Absolute all star developers,   open source contributors joining us.   I imagine since most of you are here bright and early on the first day   that you understand the importance of open source.   I was gonna ask you how many of you are open source contributors to raise your hand, but I'm not gonna be able to see your hands. So   I just wanted to say that I really do appreciate all the work that all of our contributors do in this space.   They are what makes this this movement possible.   Open source,   you know, has   obviously two main benefits to society.  

One being that we don't have to trust the code we run, that we can verify it ourselves,   that it's independent   of any corporation   or entity that's in control of it,   and that at the end of the day, this code   can all be modified,   distributed,   improved,   and will outlive any of the individual creators. It's very viral in nature.   And   I just   am absolutely moved by everyone who continues to work in the space,   work in open source,   oftentimes   for very little compensation   when they could have,   you know, a big paying job   with some major corporation   that is KYC ing you   and trying to control everything you do and lock you into a system.  

I also wanna say just a huge thanks to the Bitcoin Magazine team for putting this together   and really trying to make this a first class experience for open source.   We have   obviously the largest Bitcoin event in history   happening in this venue today   or and over the next few days,   but this room   believe there's about 1100 chairs in here, is larger than most conferences on its own, and we cannot have the largest Bitcoin event in history   without   the largest focus on open source in history.   So I'm really grateful for them to make it happen. This has been months in the process.   Big thank you to Cash App for actually sponsoring it,   because this was a very expensive room to book.  

And,   I appreciate you all for showing up because,   you know, this is a movement of people.   Without   people,   the code is just words.   Right? We need the people to actually run it, build it, use it, support it,   and that's what makes this movement great.   I love you all. This is a very big moment.   We're gonna have a lot of fun together.   We have some really great programming today. Today is gonna be more technical focused.   The next 2 days will be a little bit more accessible and a little bit more mainstream focused, but we have some really   all star all star open source contributors that will be on panels today.  

And, I'm looking forward to it, and I hope you're looking forward to it as well. I got this big screen that's just me in front of me, which is kinda weird.   I have 5 more minutes,   but I'm not I don't think I'm just gonna, like, walk on stage and just keep talking. We're running a little bit behind,   which is natural for these types of things right in the beginning. So we're gonna get started   and,   keep on building. I appreciate you all. Thanks, guys.  

[00:04:46] Unknown:

Welcome to the open source stage. Matt did a great job stalling opening for us, doing his thing.   Welcome, everybody.   Let's do quick intros for the people,   the people of the audience   specifically,   and you, the viewer. Yes.   I'm just so happy to be here with everyone.   Zhuang, do you wanna maybe say your name correctly and also give a quick intro? Let's maybe,   we have a little bit of time, but,   maybe keep intro short so we can get to the the good stuff. I'm Zhuang.  

[00:05:22] Unknown:

I work at OpenNode. We basically do payments   in the Bitcoin space.   One of the first to do lining. I'm happy to be here.  

[00:05:32] Unknown:

Cool. I'm Lisa, also known as Nifty Nye. I work at Blackstream   on core lightning, recently renamed.   Yeah.  

[00:05:41] Unknown:

I'm Roy.   I'm building Breeze. Breeze is a lightning wallet and a platform   to interact with the lightning economy.  

[00:05:49] Unknown:

And I'm Ryan Gentry.   I do business development at Lightning Labs, where we develop L and D and, you know, liquidity services, which is the topic of the panel. Perfect. I'm glad you I'm glad you're able to make it. No. Absolutely. Thank you for having and I'm I'm Michael Tidwell,  

[00:06:05] Unknown:

moderating this great panel of candidates here, attend or whatever, panelist.   I I run infrastructure   at Zebedee, a gaming platform company.   So,   let's let's jump into it. And, I think the first thing I wanna do is   let's maybe talk about a little bit of history of LSPs.   You know,   this you know, I have no idea what an LSP is being fairly new to lightning myself. Maybe someone on the panel, someone maybe Roy Yeah. Can break down.   What is an LSP? Who who even made up this term? What what is this? That's a good question.  

[00:06:40] Unknown:

I don't know. Someone came up with a term.   LSP is a lightning service provider.   It's kind of,   the way that   everyone can plug into the lightning network.   Similarly to the way that you have an ISP and you plug your router in your home and you're plugged in into the, in Internet,   the same way we need an infrastructure in Lightning that allows you to be connected to the network   in as seamlessly as possible. So that's why wait. I remember. I coined the term LSC.   Yeah. So   that that's why I came up with this   concept of a a Lightning service provider, and that's the service that facilitate this connectivity to the Lightning  

[00:07:25] Unknown:

Network. Great. And   I I just wanna say it it seems I I feel like we could talk about this stuff maybe for, like, an hour and a half because just because we're we're all doing   pretty different things with lightning, like, LSPs and and and whatnot. Like, for instance, Zebedee is doing custodial   LSP stuff, and   Breeze, on the other hand, noncustodial.   And we have a lot of cool things in between. I mean, there's so much to dig into. Yeah.   I I kinda wanna maybe maybe we can kinda piecemeal this and kinda see where it goes, but, because these topics because within LSPs, there's there's so many different kind of, I guess you can   say,   use cases   and and and implementations, I guess you could say.  

Maybe we start with with   non custodial breeze route and then kinda work our way to what everyone else is doing. Yeah. Okay. Sure.  

[00:08:16] Unknown:

Sure. Not not not to shit on custodial solutions, but the only way that you can do   Lightning is in a noncustodial fashion. Lightning is the extension of Bitcoin.   Bitcoin   all the properties of Bitcoin of being censorship resistant,   open,   borderless,   etcetera, etcetera.   We need to bring that to the to the lightning network. So the only way that you can do   really   lightning is in a non custodial fashion, and and and the function of an LSP in just in that   topology is   how do you, as a user, how do you connect to the network? You actually need to run a node. Right? The node is the entity that facilitates your participant   in the network.  

So you let's say you were able to run a node, and in Breeze, for example, we allow you to run a node on your mobile device.   A node   can do anything with the inside the lightning network without   the ability to plug in to the network. So the LSP is the bridge between the network   and the end user node. And the way that the   LSP needs to connect the user to the Lightning Network is by opening a channel.   There's an entity in Lightning Network,   which is called the payment channel. The LSP needs to open a payment channel and provide liquidity   to the end user.  



[00:09:39] Unknown:

So so for the other panelists here,   does anyone   have a different take? Like like, for instance, the thing that Roy just described, does it scale? Does anyone have any, like,   maybe   counter objection or slightly different angle that they would want to talk about here? Or do does everyone just 100% agree with Roy? I'm just curious. Anything? I think the the the key thing that Roy said that I definitely agree with is,  

[00:10:03] Unknown:

you know, when we think about lightning, we think about there's the core of the network, which is largely service provider nodes, big nodes that are doing routing, and then there's the edges of the network, right, which is generally the users, right? And so some users will be   operating on a custodial node, some will be on non custodial,   but that function of connecting the core to the edge, that is the service that's provided. It's connecting you to the broader lighting network, which you know, I particularly work with a bunch of like a cross section of a bunch of different LSPs,   like everybody on the stage, Lisa aside.  

But   we   there's all sorts of different use cases and different things that people are doing on lightning from sending funds   to emerging markets, from playing games, from playing podcasts, etcetera. And the function of making that connection seamless of making sure that you can get from stats from the edge of the network through the core to some other destination like that function at its core is is what the Lightning Service Provider does.  

[00:11:02] Unknown:

And I would say it depends on the end user too. You know? If you're talking,   of a big company, publicly traded   company, they might not, at this time, be ready to run a non custodial,   you know, infrastructure.   They need some compliance stuff. You know? The the stuff we don't like, but that is necessary.   So they might come, in this case, to us, you know,   because that's   that's what they need to show to the regulators to, like, oh, we're legit. We're running a service that   complies to all the stuff that you need. So at the end of the day, it really depends on the end user. Right? From   for me, from my perspective, obviously, I would want this to be all noncustodial.  

But sometimes,   you know, if you're like McDonald's,   they cannot run a noncustodial service today because they don't have an empty up, for instance.   They're in the food business or real estate business, maybe. They're not in the finance business. So it it really depends on where your,   you know, where your goals as a company. Like, do you wanna waste time pursuing that license, or do you just wanna get a quick shortcut and get into the big plugged into the Bitcoin network? So I feel like there's service for everything.  

[00:12:08] Unknown:

Lisa, did you wanna or Nifty Nai, did you wanna chime in on anything here?  

[00:12:12] Unknown:

And so, I mean, when we're talking about liquidity, I think one thing maybe it'd be interesting to kinda talk a little more,   broadly about, like, what is liquidity   on lightning?  

[00:12:25] Unknown:

Be before we jump on that Yeah. Yeah. Let me ask a quick follow-up for.  

[00:12:31] Unknown:

Got it.  

[00:12:32] Unknown:

Which I still don't recognize you even though I've known you for years. The the hair is throwing me off.   So so do you feel like   companies will probably even long term will probably be noncustodial, and then maybe, like, your end users, like, your actual   nonbusiness users are gonna be noncustodial, or do you not see it that way?  

[00:12:51] Unknown:

I feel like there is a transition phase. Right? Right now, they need to go through these services like what we do. Like, eventually, long term, the goal is   to be able for the business to build self serve. Right?   And, ideally, the utopia is like every business runs their own infrastructure. They're in control of their money. I mean but the reality is I don't see that happening very soon.   So, like, 2 weeks, 2 years, 20 years? I wanna give a timeline. That's like asking what's the price of Bitcoin to be here. Well, I was gonna ask that next. You know?  

[00:13:22] Unknown:

Okay.   Well, may maybe we jump into the other l,   the liquidity.  

[00:13:27] Unknown:

Oh, yeah. So Totally.  

[00:13:29] Unknown:

Why don't you  

[00:13:31] Unknown:

tee that off? Yeah. Totally. So, like, I mean, I think one thing that's, like, useful so I understand when you're talking about liquidity service providers is exactly what service they're providing. Right? Like, what is that liquidity   that the l and liquidity service provider stands for?   And it kinda goes back to how   the lightning network is set up and what, like,   it's when we're talking about liquidity, we're literally talking about   Bitcoin that's being committed to lightning channels. Right?   And there's kind of this, like, inherent   problem with moving money over Lightning Network, and that is   who and where is that Bitcoin that's been committed to Lightning Channels locked up? Who's got it?  

Who's got the ability to use that locked of Bitcoin to pay someone else? Right? This is, like, becomes a kind of complicated problem. Right? There's only so much Bitcoin in the world. We well, what is it? Do we hit 18? Is it 19,000,000?   19,000,000   was the thing? So there's only 19,000,000 Bitcoin.   A lot of that Bitcoin lives in,   cold storage or exchanges   or, you know, people's, like, wallets at home, whatever. And then there's even a smaller part of that, like, ends up getting locked into Lightning Channels. Right? So I think one thing is, like, okay, there's only so much Bitcoin available to be used,   Lightning, etcetera. Okay. So then you've got the amount of Bitcoin that's locked into Lightning channels.  

Then in order like, once you're operating on the Lightning Network, your ability to send and receive payments,   sending payments is, like, I wanna say a little bit easier. You can buy some Bitcoin, lock it into a Lightning channel, and then send it. So that's kind of like sending Bitcoin, sending Lightning over Bitcoin to some extent is bring your own stats. Like, you've got some money and you're probably gonna, like, put it in and send it out somewhere else.   The harder problem is receiving money on Lightning. This is this is, like, tends to be and you guys should definitely correct me if I'm wrong. This tends to be kind of the gap. The liquidity service providers,   fill in for that edge network that Ryan is was talking about earlier.  

So   the,   the work of figuring out, like, okay. We only have so much Bitcoin locked into channels or, like, as a service   provider. You know? If if someone wants to receive a payment,   the liquidity service provider has to figure out how to get   Bitcoin to them   from   whatever channels etcetera. They've they've got Bitcoin locked into already, etcetera. So we call this So this problem of, like,   getting the ability to receive Bitcoin over Lightning,   we call that inbound liquidity.   Inbound liquidity is, like, kind of a valuable difficult thing to get on Lightning.   Part of the reason for this is you have to convince someone else to make that Bitcoin available to you   before you can receive payments. So LSPs help solve this problem. And, again, please, like, help correct me if I'm wrong here. You guys have a lot more hands on experience with us than I do. But getting LSPs are the the service that provides basically the ability to receive and send, but the receive part is the really difficult part of,   payments over lightning. So,   some of the work that goes into that is, like, okay, where do you have all this Bitcoin available? So, like, if you have Bitcoin available such that you can then pay it out to people. Right? Someone else is gonna pay you on the other end, but,   I think another, like, this is a little bit of a tangent, but sort of similar.  

Another thing about Bitcoin liquidity on Lightning is that I would call Lightning a over collateralized   network. If you wanna send a bitcoin from   your node to 3 hops away   because Lightning is routed,   you need 3 Bitcoin   of Bitcoin already locked into Lightning   before you can send 1 bitcoin 3 hops away. So every payment that's made over lightning requires a multiple of bitcoin to already be committed to the lightning network.   So liquidity management and how do you so then so, you know, you kinda step back a little bit. It's okay. Like, we need a lot more Bitcoin on the network in order to make payments work than the actual volume of the payments that are going through the network   currently as it stands. Maybe we'll come up with some really fancy ways to do rehypothecation  

[00:17:51] Unknown:

on lightning. We don't we don't like that word any different. But today. They're not.   So you mean there'll be 22,000,000   Bitcoin? Yeah.  

[00:18:00] Unknown:

Maybe we'll expand the Bitcoin supply but like there's this anyway, this is like the like sort of philosophical problem about liquidity on lightning.   So, like, then, you know, you're doing liquidity. It's like, okay. You're providing liquidity to people. People. Like, how much Bitcoin do you have? How do you attract more people that have Bitcoin that isn't on lightning   to bring their Bitcoin into the lightning network such that we can use it as payment rails to move, you know, value around between people,   etcetera.  



[00:18:26] Unknown:

That's a lot of talk. So so you made it pretty clear. Inbound liquidity is one of the biggest challenges right now for onboarding new people for it's it's it's one of the biggest challenges right now. And I'm I'm curious. Maybe we can talk about   how is this challenge being addressed, the inbound liquidity   challenge. You know, and and what what are   what are we doing to, you know, tackle this problem because there's a couple different ways. Right? So So one thing that I think is was really interesting,  

[00:18:53] Unknown:

last week when Kraken   finally turned on their node and   got on and joined the Lightning Network, their node, like last I looked, they had like rocketed up to something like number 10 in total capacity on the network. Everyone here is probably guilty of helping that. Not a failure.   But I think what was what's really interesting is like the inbound liquidity problem   is   generally   absolutely agreed   with Lisa that it is like the scarce resource and the hard thing to acquire. But then you have an entity like Kraken where people are like hey, we want them to succeed, we think there's gonna be a ton of fees to be earned by routing payments   to the Kraken node,   like let's allocate a ton of capital to them or they don't even have to pay for it, we'll just kinda like optimistically think that that's where we're gonna earn a return from. It's like it's like if you're so cool and popular, it's like life is easy for you. You know what I mean? I know. I don't know anything about that. That must be nice.  

So I think that's been like a really interesting thing, and we've seen that a couple times where   there are like new services that pop up on Lightning and they ask like how can I go and get connected to the network? And we're just still in these early days where kind of the best solution still is like put up the bat signal on Twitter and say like hey, we have a new node, can you please connect to us and the community will generally   open the channels to you.   As it matures and the network gets bigger, I think it's fundamentally, it's a market problem.   As Lisa said, well you're trying to convince somebody to allocate capital to your direction, and like what's the best way to do that? Well, you just pay them. Right? I agree, because right now it's I feel like for  

[00:20:31] Unknown:

Lightning companies or Lightning service providers, there's almost kinda, like, right now, an excess of capital where it's like, I don't wanna just deploy this randomly, but when I see a Kraken,   I suddenly have plenty of capital to deploy. You know? And,   I think I think we're kinda past, like, the 2019, 2020, 2021 where we just wanna open up random channels to everyone. We wanna be a little bit more thoughtful on that, so It has it definitely has matured for sure.  

[00:20:55] Unknown:

I I would say there are 2 different issues like connecting to routing nodes to other hubs in the network and onboarding end user. Yes. These are 2 completely separate problems.  

[00:21:05] Unknown:

Would you think that that's, like, the core and edge distinction? Yeah. Yeah. And then end user can be,  

[00:21:11] Unknown:

like a service, like OpenNode as well. Like but yeah. So let's say an edge   onboarding edges and connecting to other nodes   in the network, these are completely 2 separate problems. And and   I don't know if it's easy to send in the Lightning Network right now because in order to send, you need to first receive. And then before you're able to send, you need to receive and and to solve the inbound liquidity   problem.   So I think there are what what's cool about the inbound liquidity,   problem that is it's being solved for end users at least. Like, we want we don't have enough tools to manage liquidity   efficiently currently in the Lightning Network, but at least to onboard users,   there are set of solutions   that, were put into place in order to facilitate   this, out of the box inbound liquidity issue.  

One of the solutions is what we're doing at Breeze, opening 0 confirmation channels. So we're actually utilizing   the liquidity of the end user in order to open   liquidity,   to allocate liquidity   to the user end. So we open a channel and we push liquidity, the same liquidity that the user used to top up the wallet. We use it in order to provide   inbound liquidity. That's one solution.   Another solution is pool solution like pool from Lightning Labs is the ability to lease   liquidity   and to open   a channel   which is a list for by default,   a month, 2 weeks, what's the default?  



[00:22:44] Unknown:

It's we have range, but there's a duration for 2 weeks, a month, 3 months, and a year now, I believe. Okay. That's very cool.  

[00:22:50] Unknown:

And the 3rd solution from   Lisa I think worked on it, it's liquidity ads where nodes can announce that they are willing   to   rent you liquidity for such and such   price.  

[00:23:07] Unknown:

So we have pool, we have Breeze with the model where if I download the Breeze wallet, I get inbound liquidity kind of by being a user of Breeze.  

[00:23:16] Unknown:

You have liquidity at I'm actually a little bit unfamiliar. Would you like to Yeah. I can talk about them a bit. So liquidity ads is a proposal that I wrote for the lightning spec, so it's specified.   That means that we are working with other lightning implementations so that, hopefully, it'll be supported by every node on the Lightning Network.   It's basically act a way to   I call it like a billboard system of advertising   that you've got liquidity that you're looking to deploy.   This billboard ad that you can put up, you can put in, like, how much you're looking to get for the capital that you have available. So you set your own rate of how much that your   available capital is worth to you, and you can set that. You put it into a little advertisement.  

Those advertisements go into something in lightning we call the gossip network, which every node on the network sends and receives.   So so you can advertise. You put a little bit of information, this little kind of, like, classified ad   called liquidity ads into your gossip goes out to every node on the network. So if you're running a node right now, you're currently getting all the liquidity ad data. It's on your node. Whether or not your node exposes that to you is a different question, but if you're on core lightning, you can see them.   They're also available to see on lnrouter.app,   which is like a little there's a little dashboard. You can go look at all the liquidity ads that are currently available.  

Anyway, so this is the way you advertise, like, hey. I've got some capital. I'd like to deploy it. Here's how much I want you to pay for me. And then you can if you're trying to buy or get inbound liquidity, you can go look at all the nodes that are offering liquidity, where they are on the network, whether it's worth, what they're offering to you or not, and then   decide whether or not to take them up on their ads. So it's a it's super decentralized.   I have no information for you. It's been out for maybe, like, 7 months now. I have no information for you about how many people have used it, or how much capital has been allocated using that market because that data only exists between the buyer and seller.   You can go look at I think the number of ads is, like, we're close to, like, 15, 20 these days.  

So it's, like, small but growing.  

[00:25:18] Unknown:

Yeah. I wanna talk a little bit custodial with you for for but before I do that, I wanna jump and and wrap up maybe some pool because we didn't really talk about pool much. Where do you see the leasing   liquidity   industry, the leasing channel market? What what do you what is it like now? What was it before? What's what's it gonna become? Maybe you can talk a little bit about that since you're familiar. Sure.  

[00:25:41] Unknown:

So   what it was previously was, like,   before we had,   you know, channel leases as like a formal kind of financial product on lightning, it was all handshake agreements between, you know, people on the stage, right, saying like, hey   message you on Telegram, hey can you please open 1 Bitcoin channel to me, like we're expecting   a lot of volume this weekend or something like that. Right?   That obviously doesn't scale if we think flight in network is gonna be tens to hundreds of thousands   of nodes,   businesses   being able to interact. So turning that kind of interaction into more of a market interaction saying, you know, I will pay you   x amount or x percent of the capital that you, commit to me,   as long as you keep that channel open for say a 3 month period. Right, and I think the cool thing that that both pool and,   the liquidity edge construction does is that that lease term is actually secured by Bitcoin script. Right. So if the channel is opened,   it actually, you know, those funds can't be decommitted from that channel.  

Bitcoin itself will not allow that channel to be closed until the duration is up, which I think is a really cool construction.  

[00:26:49] Unknown:

So so it's like I can either   use, like, something like pool or like a commit or whatever to get, like, inbound liquidity,   or I can just start an exchange and get really popular and get a bunch of users, and they get free inbound liquidity. Yeah. Or just, like, a bunch of Twitter users and just say, hey. I need inbound liquidity. Or we can or we can download reason. Or we can  

[00:27:09] Unknown:

so so so I guess The final thing that I wanna say on that though, which is which is really interesting,   is,   we've seen   in pool, the lease rates are public.   If you're running a node you can download all the data and read through all the history. And so we've seen over the last like couple months or this year that like   demand is starting to is like really starting to pick up, rates are starting to get, like, pretty sustainably high,   which means that there is now, like, you know, well maybe in the early days there was an overabundance of supply,   like demand is starting to kind of pick up and push prices up, which should in theory then induce kind of more supply coming on the network. Because if you can earn, you know, 6% annualized on your Bitcoin for opening a channel to a node that wants it, like, that's a pretty good deal. Or you can trust all your money with, like, a custodial  

[00:27:59] Unknown:

you know? I I'm not gonna name names. Kinda like, hey. We magically give you 6%, and we and they they take this is like the I mean,   this might be the only thing I can think of that's, like, noncustodial, actually, like, providing a service where you can get a little bit of income on your Bitcoin potentially. Right? Absolutely. And, like, you know And that's key. We need to break a myth here. Like, there's a misconception  

[00:28:19] Unknown:

that Lightning is free.   Yes. And and in order for Lightning to be successful,   the the routing fees need to go higher   and and lightning needs   basically, the the entire thing about liquidity   is is why would people allocate liquidity to going back to what Lisa said, like what's the reason that people will put their liquidity in lightning? They want to generate yield, right?   So if people put liquidity   in   lightning and they they are able to generate yield, then people will put more liquidity in lightning. So there there's a circle here of like traffic   brings liquidity,   liquidity provides yield, yield provides more traffic, traffic provides more liquidity. So we need to start thinking about lightning as an economical tool,   and   lightning, like long term, if we all want Bitcoin and lightning to be successful,   it can't be as cheap as it is now.  



[00:29:21] Unknown:

Thank you.   Can you scoot forward just a little bit? What's that? Just scoot forward a little bit. I need to tell   you. These guys   think, like,   noncustodial lightning will scale, and I just wanna talk, like, real between you between Zebi and OpenNode right now about how, like, Lightning will actually work in the future. Actually, we've, full story about liquidity.  

[00:29:40] Unknown:

There were a trending that we're seeing. So we're working, like, pretty big digital wallets that today in our world.   And we're doing is they actually are connecting to us saying, yo,   we need to connect for launching our product. That's to some private channels because they don't want to announce first their node on network because they don't wanna get attacked like the OS. Mhmm. And then so we're doing we actually sign contracts, like legal contracts about channels, which is smart contracts, dumb real contracts? Contracts. Yeah.   Like, real contracts.  

So it's it's a it's a trend, we're seeing. Like, we're actually, like, signing contracts about opening channels to these service providers.  

[00:30:17] Unknown:

So so, you know Oh, yeah. Yeah. It's it's good. That's see. That that's a sign of maturity of lightning. Yeah.  

[00:30:23] Unknown:

And I think we're gonna see that more often in the future. One one thing on the on the fees, which I it's you're absolutely right on, but I just I just happened to be looking at the numbers,   last week. So   Visa, Mastercard   kind of average rates that they charge for domestic payments is like and you would know this better than me probably is you know, 1.29%   plus 5.5¢,   for per payment.   I looked at, like, the top five biggest nodes on the Lightning Network, and it just so happens   that the average fee rate,   across those 5 nodes is, like, exactly   90%   of that. So it's it's the the 10 x difference. It was, like, 13 depths or something Okay. Which I think is just, like, a very interesting   way that, you know, this this free market decentralized ecosystem has kind of coalesced,   at a rate that is, you know, typical venture capital wisdom   is, you know, in order for something to, you know, a new network to disrupt the incumbent, it has to be 10x better Yeah. In fees. And so I thought that was just interesting that that is kind of where the rates are right now. And it's happened it it happens very naturally because fees are your only 2 currently within the Lightning Network  

[00:31:31] Unknown:

to to say, like, how do I want the liquidity flow   to be. Like if I want   the liquidity to flow from one end to another,   I need to have   lower fees.   And if I wanted the liquidity to flow in the other way from B to A,   if I don't want the liquidity to flow from B to A, I need to set high fees.   So   it's it's it's it's basically represent, like, the opportunity   cost of   of the liquidity. So   and fees are the only way to control   the the how  

[00:32:06] Unknown:

how bitcoins are flowing within this lightning network. When I when I analogize lightning to to normies,   I talk about how the channels are like roads and your fees are like your traffic lights. Okay. Right? Where it's like if you if you don't want traffic to flow down this way, you gotta hike the rate, which is like turning the light red. And if you want traffic to flow, you lower lower the rate and make the light green,   which I think is accurate. Yeah. Yeah.  

[00:32:32] Unknown:

Nice. I,   I love that analogy. Really good. Yeah. He runs red lights. Yeah.   Better better than my beads on a string analogy. Well, you know, but we it takes all kinds. Yeah.   I I I did wanna talk a little bit I wanna I wanna involve this this gentleman right here   and and say, what are what do you think the challenges are? You know, we we talked a bit about noncustodial   liquidity, lightning service provider challenges.   Although it doesn't fit Roy's definition to a t, the we can maybe caveat it with the non, you know, custodial Lightning providers. What what do you think the challenges are  

[00:33:10] Unknown:

for people like you and I, stuff like that? I think the risk of custodial Bitcoin is the biggest challenge. I would say it's there's a huge risk to, like, hold Bitcoin. It's something that you don't want you don't wanna do.   You know, and once you're holding Bitcoin from someone's else, there is compliance risks. There is all certain of legal stuff that you have to   to go through, especially if your company is in the United States.   That's why a lot of people do not make their company in the United States.   But I would say the biggest challenge is definitely the the user onboarding   today.  

Obviously, Kustodil makes it easier. It makes it simple.   Is it the the solution? I don't think so it is. I think you're you guys are doing a really good job on that.   But so far, we're still in a transition period. Right? And if you want to involve certain parties in this economy, we need to make tools that are,   you   know, somehow,   easy enough for them.   And it's a transition period. I would say, obviously, long term, the idea is to everything to make a trustless system   noncustodial.   But right now, we still have to go through this   Transition phase. Transition phase. Like, people still need the dollars.  

You know?  

[00:34:26] Unknown:

What about hot wallet,   cold wallet kind of concern   that concern you?   That's what I was saying. It's about the risk When you look just explain the others that when you lock liquidity   in lightning, it's being locked in a hot wallet currently.  

[00:34:41] Unknown:

Yes. There's definitely so, yeah, it's basically a hot wallet where your Bitcoins are exposed somehow to, like they're online. Right? They're exposed to the Internet, to the outside world.   While when you're doing cold storage,   you know, the Bitcoin, your your secret, your c, your password,   it was never,   like, interactive maybe with a computer. So there is no way for anyone to know that password.   And so when you're locking up funds in Lightning,   those funds are somehow   exposed, or there is a there is a chance,   that, eventually, they might get stolen or not, depending on security practices. Right?  

And but I think we're coming up with tools like the remote signing, you know, things that are improving. You know,   the the the software is is going through another phase now where, like, okay, Things are being pretty,   risky now. Let's let's decouple the stuff   and try to make the signing stuff like a cold storage offline,   where you like because you every time you do a transaction aligning, you have to update the channel. And to update the channel, you need to sign a transaction.   So, eventually, that software needs to have access to to the signer.   The problem here is the signer. Right? You don't want to expose that entity to the outs to the Internet because then you have a threat. If you expose your password or you're not exposing your password, but there is   there is a way that eventually someone,   if they know enough about you, might be able to get that password. And when you do cold storage, that information is not accessible anywhere. But with the remote signing tools, I think we're,   we're getting there. Yeah. We're getting there. Not there yet, but we'll get there. We're getting there. On the Hot Wallet risk, one  

[00:36:23] Unknown:

interesting thing. So,   we have a service liquidity service we provide called Loop, not to be confused with pool. Just you spell it backwards. You spell it backwards. Yeah. Something.   And so Loop is, a submarine swap provider where it's a it's a bridge between on chain Bitcoin and off chain Bitcoin,   where if you if you need more inbound liquidity, you   send funds to Lightning Labs, and then in a noncustodial way,   we return the funds to you on chain. One interesting use case for that,   more so than just needing to acquire invalid liquidity is actually risk management. Mhmm. Right? If you wanna make sure that the amount of capital that you have on your node stays low that's on your side of the channels. One thing that we're seeing a lot of folks do is just continually make sure to loop out to send funds   out of out of their custody and return it back to their on chain wallet, which I think is an interesting thing that, you know, as the network has grown,   has become something yeah. Like, you know, all of a sudden, certain providers say, man, we have, like, a 100 Bitcoin in this node. Like, we gotta be careful. We gotta, like Start looping out. Start start looping out and start using some risk management practices, which I think is very interesting.  



[00:37:28] Unknown:

Cool. And and we we've talked about a couple of things. We,   remote signing and the what in in terms of the future of LSPs and and things to look forward to,   what kinda like, I know we have   Nifty here,   Blockchain. We have   Ryan,   Lightning Labs that are working on implementations of Lightning,   that kinda help enable some of these things. What what what can what can I'll tell you from a user, like, from a He's gonna tell you what he needs, and then you'll have to call it. Yeah. Exactly. The guy that's running an LSP,  

[00:38:00] Unknown:

I need   better control of my liquidity.   I need better flexibility   to manage my liquidity. So I think in that regard,   I'm looking forward to splicing.   The ability splicing is the ability to change the capacity   of the channel dynamically   without closing the channel.   And, basically, if you let's say, I'll give you a very simple use case. Let's say we have a user. The user is is using Breeze to get inbound liquidity.   So we open   a one BTC channel to the end user. The the Bitcoin are on the user side. The user used the entire BTC to to pay for stuff. And now I I got one BTC   locked in the channel on my end of the channel. And the user stopped using Breeze for some reason. I don't know why it's a great product, but   but   they stopped they stopped using Breeze, and now I got liquidity locked on my end of the channel as an LSP.  

And I need to reallocate this liquidity because I want to onboard new user using this   BTC or I want to put this liquidity somewhere else where it generate   a much better yield than than the user that doesn't use   Prism anymore. So in order to take this liquidity out of the channel, I need a way to splice out, I need a way to dynamically   configure the channel to have a lower capacity   so I'll be able to reallocate this liquidity   someplace else.  

[00:39:23] Unknown:

Yeah. So any implementation that doesn't support splicing obviously hates Bitcoin. So what are we gonna do to fix this problem? Correlating is working on splicing.  

[00:39:32] Unknown:

The great news about so the cool thing about liquidity ad stuff is a lot of the base, the background work we had to do to make liquidity ads happen,   lends itself real easily to making splicing happen. So we are actively working on making splicing happen.   Hopefully, that will come out at some point.   In 2 weeks? 2 weeks. Yeah. 2 weeks. So look for it in 2 weeks. We're great. Yeah.   So, yeah, we hear this. And I'm like, man, it's so much fun to think through all the ways that splicing lets you do wild stuff with your channels when you get it going.   Yeah. The way that we wrote, like, some of the so the precursor stuff we had to do before we get liquidity ads is this thing that,   calling collaborative channel opens. It used to be called dual funding, but that got a little,   let's see, the namespace   collision started happening so we're calling it collaborative channel opens now.  

Anyways, so all that work that we did to make that happen, you can use cool stuff where you can splice across multiple channels on the same transaction   with multiple peers,   on Lightning, decentralized,   it's like cool stuff. So we're hoping to bring that to splicing   real soon.  

[00:40:40] Unknown:

That's the plan. Thank you, Lisa.   Brian?   Yeah.  

[00:40:46] Unknown:

Same. 2 weeks.   One is like another another side of this and as an infrastructure guy, I imagine you have thoughts on this.   One really funny thing that happened like a year ago, as I remember talking with a bunch of lightning companies about kind of like what they what they wanted from l and d,   in the year 2021.   And it was the first time that instead of it being, you know, new features and and new techniques and and new cool bells and whistles, it was, you know, can we have,   accounting software? Yeah. Can we have, you know, like, a more scalable database? Right? It's like very, like, adult requests instead.   And so I think that's like the other lens of this is running the infrastructure and and scaling like your back end and, you know, like the post stuff,   that we're working on, that kind of making sure that,   just your nodes stay online, that they're, you know, easy to manage, that you have all the data that you need,   as well, like, you know, data that you need for reporting requirements and, you know, accounting stuff, like, all of those kind of boring,   tools as well as something that, you know, is is increasingly more in demand as lightning companies get bigger, succeed, raise money,  

[00:41:54] Unknown:

and and and get more kind of That's Ryan Wade. He's saying me wait.   So  

[00:42:00] Unknown:

I said 2 weeks. Yeah.  

[00:42:02] Unknown:

Yeah. I I am curious, though.   Maybe this is something that anyone can talk about. Does   Bolt 12 or Taproot   affect LSPs? And if so, what way what what does what's better? Because I know, like, for instance,   LMD is a little bit more or sorry. Not LLD. Lightning Labs is a little bit more focused on,   supporting Taproot.   And   and I was just curious. Maybe we can talk about that a little bit. How in in in its relation to,   providing service like LSP?  

[00:42:32] Unknown:

Well, so I think Taproot, just from, like, a fundamental level,   just opens up, like, a a brand of much bigger design space for what can be done,   on lightning. I think it it enables a lot more use cases just kinda upgrading the channel commitment types and and things like that to supporting Taproot. It just it it it's more of like kind of like a a platform upgrade, so to speak, the to think of. Right? And I think,   you know, that's kind of like a little bit of a of a longer term thing where you can think of, you know,   for instance, I know one thing that that roast beef is working on, is the concept of dynamic commitments   where, like, right now if you wanted to upgrade a channel,   that's a a a normal, you know, pre Taproot channel, you would need to close the channel and then reopen a new Taproot one and spend to a new Taproot output.  

You know, working on a proposal to be able to allow that to happen. If you think about that at scale, right, there's something like 80,000 channels on the network right now, public channels, like 80,000 bitcoin transactions closing channels and then reopening would be like pretty heavy.   But with dynamic commitments being able to do that kind of on the fly and upgrading your commitment output,   without changing the channel is is, you know, a cool thing that then allows for, you know, wacky things like, you know, our proposal yesterday,   Taro, which which leverages it will be Taproot Channels,   where you can send, you know, assets that aren't Bitcoin,   you know, say, you know, a a Fiat backed stablecoin or something like that, you could send those   over the lightning network.  



[00:44:00] Unknown:

Those channels require tapered outputs. Right? So things like that. And that proposal actually increased the demand of liquidity inside the network because these assets move between one node to the other, they're being   Bitcoinized.   Bitcoinizing the dollar. Yeah, exactly. That's the meme. So we need more Bitcoin   collateral in order to facilitate new assets   that will increase the demand of having more liquidity in the Lightning Network.  

[00:44:28] Unknown:

Yep.   Nifi or John, did did you wanna chime in on  

[00:44:33] Unknown:

I would say privacy. Right? I think it's the Yep. I mean, the big one here. It's the basic one. Taproot will bring privacy to lightning, because today, you can literally look at on chain and see what channels were closed and kinda figure out liquidity and what's happening. And with Tapware, it's gonna look like another transaction.   So I think that's a big win. With,  

[00:44:54] Unknown:

That's well,   we're gonna talk about privacy more on Friday. I'm doing a privacy panel. We'll get way into that. I'm gonna push back and say that just upgrading the Taproot   outputs isn't actually gonna solve the privacy problem. It's   I think the biggest thing is moving to blinded routes in bolt 12.   Right now, no one cares about on chain footprint. If you're handing them an invoice, it tells you where the payment's going, what you're paying for, how much it's for. Like, you don't even have to look at the chain if you give someone an invoice.   Like,   so I think Taproot's cool. I think, like,   lightning's gonna get to Taproot soon.  

Upgrading it, doing dynamic commitments is, like, an awesome thing. Miners might not like it so much, as the people running the channels, but, you know, that's fine.   But yeah. Anyways, like, Taproot's cool. It's coming.   Really excited about the,   novel engineering that Labs is doing with Taproot stuff, and excited to see how that goes. But  

[00:45:54] Unknown:

yeah. Okay. We have a few minutes left. Do you wanna do closing thoughts? Do you wanna maybe start with Juwan? I wanna ask Oh. URL versus ball 12.   Oh, okay. Well, let's rephrase the question real quick. Instead of doing closing thoughts, let's just do lnurl versus ball 12. Let's get into it.  

[00:46:12] Unknown:

Let's let's let's I'll I'll I'll I'll sit here. Y'all y'all go for it. Yeah. Just from a service provider, there's a lot of demand for this type of stuff.   So I know lining at Lightning Labs is a position.   See, lining has the the other position. So I'm   just curious to hear both your thoughts about why   you want to invest in Bold 12 and why you don't want to invest in Bold 12 right now. Just curious. I'm the moderator now.  

[00:46:41] Unknown:

So, you know, like, I like, Lalu Lalu published his his thoughts,   on this, and I think he stated it well. It's like we're,   you know, a small team. We have something like 26 people. There's there's only so many engineers,   and, like, the priority is   is doing Taproot stuff. And I think in particular   one thing that we've talked a lot about   is   responding to the developers in particular that are building on our stuff. And we haven't had a bunch of developers beating down our door saying, this is wrong, we need you to focus on Vault 12 instead,   Right? Because they're kinda happy with lnurl.  

Right? And I you know, like, it's it's it's bad business to tell your customers that they're wrong.   And so that's you know, we're we're focused on Taproot, and I think that's that's gonna it. I think I don't I don't and I I wanna be clear. Like, I don't think we think whole 12 is necessarily   a bad proposal. I think blinded routes are great. I think the static invoice is great.   There's a bunch of good stuff in there. It's just not the priority for this quarter.  

[00:47:44] Unknown:

I think we need both. I think we need both   will facilitate payments between   peers in the network without the need to have an HTTP web server.   And Allen URL is great for   for custodial services that has that have online presence, and it's great for merchants that have web presence. So whenever you have a web server,   you can definitely build on ln, ln URL, but it doesn't solve   the problem of the the ability   to send payments to other user in the network without   creating an invoice first. And for that, we need bolt well.  

[00:48:23] Unknown:

And you still do have to, like,   generate an invoice, Right? For both of them. Like, you have the static part, but you still need to go and actually fetch You need a pointer you need a pointer to to begin with, but the pointer doesn't need to be, like,  

[00:48:38] Unknown:

an an HTTP server. Right? Yep. It's like AMP. What's the difference between, like, the essential core difference between both wealth and AMP? It's the ability to have proof of payment. That's, like, for me the big difference between both. And you guys have   AMP  

[00:48:53] Unknown:

and you don't have both 12. Well, but I think it is a little bit different because you still do need to do   invoice fetching with both 12. Right? Like, you still do need to, like, get a secret to pay whereas with amp it's actually static like there is no interaction required you can just pay to a  

[00:49:10] Unknown:

receive the pop key from somewhere. You again, you need a pointer. Hey.  

[00:49:14] Unknown:

Not not to not to interrupt. The family conversation here,   because I I I love this. And and and, you know, I feel like,   we we we should have a bolt 12, l and euro pay kind of discussion, maybe. Fight.   We need we need fiat, Jeff. We we we need yeah. We need we should like, WWE people start sliding in, bringing in chairs and stuff. But   I we're we're out of time. I wanna I just wanna give everyone   a few seconds just to do, like, a closing. How do people know about you if you wanna show your Twitter, if you wanna   let people know how to follow you, whatever it might be?  



[00:49:49] Unknown:

Yeah. Yeah. You can find us, open note dot com or open it on Twitter.   You can find me, Zhuang Almeida. It's a hard name, so you're not gonna find it.   Yeah. You can find me on Twitter.  

[00:50:02] Unknown:

Yeah. I'm nifty n I   f t y n e I, if you wanna,   follow my Twitter.   I also work with core lightning. So core_ln   is our lightning node implementation. I work at Blockstream   who obviously is also on Twitter.  

[00:50:19] Unknown:

Yeah. You can find me on the Breeze various handles at Twitter, Breeze_tech.   Breeze.technology.   That's our website. You   can join our Telegram group,   Breeze.  

[00:50:33] Unknown:

Breeze spelled b r e Without a c. Yeah. Without  

[00:50:36] Unknown:

an e at the end. Yeah.  

[00:50:38] Unknown:

Yeah. I'm Ryan Gentry.   Ryan the Gentry on Twitter.   Follow us on   on Twitter as well at at lightning,   and the website is lightning dot engineering.   Thank you, Michael, for,  

[00:50:52] Unknown:

such a well moderated How can we find you, Michael? Yeah. How can we find you?  

[00:50:56] Unknown:

I'm Mike 20 spelled out with a 1 on the end. It's so obvious.   And,   I'm   not that popular, but for some reason, they have tons of scammers. I'm not giving away free Bitcoin. And when when when's the Tapcom? The next Tabconf? If you well, not to shill too much because we're at a conference, but,   Tabconf is a technical focused conference in Atlanta, Georgia. It's gonna be in October. Tabconf, tabconf.com.   Yeah. Thanks for helping me show that, I guess. Yeah. Just go on.   Yeah. Oh, alright. Thank you, everybody. Thanks for coming.  

[00:51:36] Unknown:

Alright.   So this is the future of lightning development panel. Sadly, we lost our our illustrious moderator,   who couldn't make it to Miami in time. So instead, I get to moderate these these two lovely folks.   So why don't we start with Hannah and we can do quick intros  

[00:51:56] Unknown:

of who you are and what you work on, and then we'll dive right in. Cool. I'm Hannah Rosenberg. I work as a developer advocate at Lightning Labs, and I've been,   say, in the Bitcoin space a while and obsessed with Lightning since it came out. So delighted to be here talking about it.  

[00:52:12] Unknown:

Yeah. Hi. I'm Chris. I,   been in this space for a long long long   time, 20, 2009.   And my hobby became my job. So now I'm working for Blockstream on for Lightning.  

[00:52:28] Unknown:

And I'm Matt.   Sadly, Christian predates me a little bit, but I did get into Bitcoin in in 2011.   I have the the illustrious   claim to fame of I actually wrote the 1st payments channel implementation   anywhere long before lightning and before we had routing or or in fact bidirectional payment channels.   And I don't think anyone ever used it. But that's okay. Oh, that's good. You're you're the only one. We had a student project working on it. So  

[00:52:53] Unknown:

Oh, alright. Well, good. It was it was usable. Good job. Thanks. I might have tested it once.  

[00:53:01] Unknown:

So we're gonna we're gonna   talk very briefly about,   kind of the history of lightning and how how it's grown, and then we're gonna get into   how we see it maturing   and and   going from there.   So I don't know if who wants to start with Hannah, you can start with that one. This one. This I think the past year  

[00:53:21] Unknown:

just since we were I was at this conference,   last year and until now, like, just watching the explosion in lightning. And it's been really interesting to me   to watch lightning progress from, you know, just a proof of concept where everyone was like, is this even going to work?   To, you know, then being very much in the hobbyist   enthusiast territory,   you know, where you're on the command line and, you know, only people that are, you know, nerdy enough to be on the command line can use it. So then we get much more user friendly stuff going on. And then now it's moved from   hobbyists   more into, you know, businesses really attempting to use this in their products and services and just spend this huge explosion, and and it's been really amazing to watch and to think about where it might go from here.  



[00:54:08] Unknown:

Yeah.   I would I would go further and say, like, yeah, it it's specializing. Right? So it it's it's gone from hobbyist, but they still exist. They're still there. They're still running running ClubNet and it's still routing a lot of payments.   And we have so I I now work for   for, I guess, Block is now our name, not on Cash App, but but, you know, Cash App now it's deployed   deployed lightning,   and that's that's a whole different world. And we just had the LSP panel and the mobile lightning world and the the LSPs also need a whole different set of things.   So let's let's kinda split up the future of lightning development by those categories   and then kinda dive in from there.  

So let's let's start with mobile. So,   you know, we just had a bunch of discussion about LSPs and what they need, but maybe let's look more towards the future and talk about, you know, what what do these mobile clients themselves need. Yeah.  

[00:55:02] Unknown:

Yeah. And I,   LDK is a fabulous   tool for mobile. That's really cool. And we're also talking about the problems,   with mobile payments,   enlightening, sort of sort of an app having to be on, you know, to receive a payment, which is a big issue at the moment. And then just trying to shove a lightning node   into a mobile application is certainly quite a challenge.   But that's why   you know all the time you know it's like sorry I'm just gonna go off on this tangent, but it's like I love that, you know, I've spent so much time being obsessed with lightning and it's only been in the past year that when people come up to me and ask me, hey, Hannah, can you do x y and z on Lightning? I don't have to tell them theoretically, yes. I can tell them, yes, you can, and here's the library you should use to do that. And so that's been a really amazing change in the past year. But there's still   this big issue,   with with mobile payments that I don't know if any want to dive into that a little bit. But essentially, I think one of the problems there is just getting an app to, you know, because you have to be online to have payments. And one of the issues there is just how do you get that app to be online to receive payments? How do you solve that problem? And then shoving a note into a mobile application is not a problem. Yeah. Yeah. I I think we do see a lot of experimentation going on especially now, with regards to how do we want to integrate lightning into  

[00:56:25] Unknown:

mobile apps, into web apps, into whatever.   And, the experimentation we're seeing right now is, is going in direction of do we want to really want to shove a full node into, into a mobile app,   potentially segmenting   your funds across a multitude of app, basically locking in, the users into an individual app so making it hard to experiment.   Or do we want to have a more centralized node   that is still operated and run by you and where we just remote into it and, and I think those those are the trade offs we are currently seeing explored and we will see, how these work out in the future.  

[00:57:04] Unknown:

Yeah. And and we also see, like, you know, we were talking about the the online requirements. I mean, obviously, if I I guess I can say this, you know, Cash App's, like, almost all of their payment failures are just the app wasn't open. It was being sent to a mobile client. The app wasn't open, and they didn't get the payment because the app wasn't open.   So having having better logic there and then,   enabling more you know, we've kind of seen this this first generation of mobile wallets that all kind of have this simple, you know, we took a lightning node or at least a payment channel and we put it in an app,   and we shipped it and it works pretty well and we have this LSP and we wrote out payments through it and whatever.  

But, you know, we haven't gone down the route of, like, okay, well, what if we have, like, a server assist more server assisted lightning node, like,   green light and like some of the other things core lightning is working on,   and what it you know, do we have,   better protocols for,   papering over this,   on chain requirement? Right? So I I had that proposal, whatever, 6 months ago, and we're still long ways from implementing it   to do use onion messages as a base for doing,   on doing payments   such that you can kind of hide the fact that the nodes have to be online   synchronously to receive the payment.  

And and you can actually do   offline kind of payments, but, like, you know, it goes out and it sits pending, and then, you can actually receive it without it sitting pending across an entire route across the lightning network, and holding that capacity   for, you know, potentially hours or days until the user opens their phone.   So there's still, you know, we we finally have lightning on on phones, but we still have a lot to go to actually   fix a lot of these UX issues that we've run into.  

[00:58:53] Unknown:

And Yeah. And it So I say that, you know, lightning is is now usable,   like in production in real services but just barely.  

[00:59:02] Unknown:

Yeah it's it's definitely not smooth and and there there is a lot of infrastructure that we are working on   and I'm speaking for all implementations here of course not just just core lightning.   That   where we are learning from the experience of operating lightning nodes   of,   of basically   providing users with the ability to to make more of their lightning nodes   and   this experience will flow back into the spec process as well   and inform where the directions are going to go in the future.  

[00:59:36] Unknown:

And that   it is going to continue to be interesting, you know, as the the amount of resources required   to kind of maintain a lightning node   will only continue to grow as we have multiple different completely divergent use cases for lightning. We have, you know, whether it's people trying to run it in enterprise   and who want, you know, features that might help them, people trying to run it on mobile. And then you want to add onion messages and, like, onion message mailboxes so that you can do, you know, be offline all the time. All of a sudden you have all of these new features coming in that all the lightning implementations are at least kind of mostly need to support or at least look at it and and add chunks of it so that things can be interoperable.   Just the the amount of resources required to maintain a lightning node is only gonna continue to increase.  

It's already whatever   I think all the major implementations have at least 3 or 4 engineers full time on it, and that presumably will only continue to grow.  

[01:00:36] Unknown:

Absolutely. So so there is definitely a scaling up of the engineering side of, of things,   but I do think that, by us basically, as as Lightning implementations, concentrating on a common kernel that sort of builds the basis for all of the applications that we build on top. And I've been often asked what what sort of is the coolest thing you can imagine doing with lightning, and I usually   say that I'm not the right one to ask. I'm I'm I'm the kernel guy. I'm not I'm not the cool fancy UI guy. So,   but I think that, that keeping that kernel small will help us basically provide a basis for for whatever comes next   and whatever   maybe these guys will build here.  



[01:01:17] Unknown:

Yeah.  

[01:01:18] Unknown:

So let's talk a little bit about, you know, we talked a little bit about mobile, let's talk about kind of LSPs. Obviously, we we just had an LSP panel,   but but what   features in the lightning protocol   might be needed,   for   looking towards LSPs and but the future of development   that   we have to do on a lower level might be needed for   those   services in the, over the next few years?  

[01:01:45] Unknown:

I think very much of the groundwork is,   is already started   with with the liquidity ads, which is, which is a way for you to signal the availability of funds and the, and the readiness of of allocating those funds to a, to a channel that you'd   that somebody would like to open.   And I think that is sort of the direction that   I would like to see things going forward   where we have an open marketplace where everybody can participate,   where there is no mediator,   where we can   just exchange our interest in   opening or closing channels and what   the set of costs are for for that.  



[01:02:25] Unknown:

I mean, I guess that divides   LSPs a little bit even further. Right? From,   from from service providers who might be providing service to,   hobbyist nodes or plug in nodes or always online nodes versus service providers who might be providing services to to mobile where, you know, some people might expect to use your experience where your client accepts the 0 cons thing. Right? Where suddenly you you need to actually know who your counterparty is. You can't just, you know, go to a liquidity ad and and select whoever.  

[01:02:53] Unknown:

You do actually have to have some counterparty you have some amount of trust in. But but I mean that's that's very much part of signaling. Right? Their kind of channels are basically just a feature that you can signal.   Having an identity attached to a liquidity add is something that you can use to basically make a decision of hey is this provider   well connected in the network? Do I do I trust him to be a good,   good counterparty for my channel?   And that is   basically just an additional information that we have to convey to whoever might take you up on the offer.   So I don't think that different protocols here are in the solution.  



[01:03:35] Unknown:

Yeah. No. I so I think   it is ultimately up to the people building the user experiences, building the apps,   what kind of UX they want there.   Obviously, exposing   different   possible trust relationships to users tends to be a pretty poor user experience.   Like, hey, you can pick between these nodes, and here's some information about whether you should trust them.   You know, PGP Web of Trust kind of failed for a reason. PGP is great, but the Web of Trust part never went anywhere. Well, you know, the average user,  

[01:04:08] Unknown:

you know, at least I think going forward in the future, right, the average user doesn't, you know, want to know anything about what's going on underneath. So it's important to extract that away for people as the Lightning Network continues to grow in use. But also with the different ways to do liquidity, again, you know, there's different use cases and different, you know, different users are gonna have different,   you know, things they care about,   in get gathering liquidity. And why do we need the liquidity? Is this a business that's accepting incoming payments? Is it a routing node? Like, what's the use case? So it's just things are getting just bigger and bigger. So it's, you know, now we get little pockets and different use cases here and there. Yeah. And, I mean, I think  

[01:04:46] Unknown:

in the medium term and definitely in the long term, one thing I'm I'm really looking forward to the most   is a proliferation of more different lightning apps and different lightning user experiences. And I think Yeah. You know, certainly that's that's kind of our pitch. Right? I mean, speaking from the LDK end, it's kind of our pitch of, like, look, we're gonna, like, do all the hard parts for you, and then you focus on how do you want to build a user experience around lightning? How do you want to, you know, do you wanna have 0Conf with which nodes? And do you want to use liquidity ads? And do you want to use this or that and whatever?   And so, you know, maybe I'm a little biased, but like I'm looking forward to a world where we have, like, you know, some   apps and some desktop clients, or   browser extensions or mobile clients or whatever that use greenlight, and some of them that that   let you choose which node to connect to and expose this whole, like, market place of liquidity ads, and some that, like, abstract a lot of that away, and then some that, like, just always connect to the predetermined LSP or whatever. Right.  

And kind of this this   Cambrian explosion, I hope, is coming eventually, where we can have a lot of different options, and we can kind of see what succeeds in the marketplace while all still having,   you know,   this common base of, you know, one of these lightning implementations that's robust and tested and and has implements a lot of these features so that users can pick and choose kind of which ones they want. Kind of developers can pick and choose which ones they want. And the more tools that are out there, you know, the better to fit different use cases and all of this stuff. And it's yeah. I I also foresee sort of this explosion where I just  

[01:06:20] Unknown:

imagine, you know, 5, 10 years from now, we'll have we'll be using lightning, you know, on the back end of quite a lot of different services, whether it's, you know, buying things online,   streaming things,   authenticating,   for services, etcetera.  

[01:06:35] Unknown:

So Yeah. Definitely.   So so I definitely do share your your sentiment that, that we sort of will have a common core that we can pick and choose from.   With Greenlight, we chose to   take a bit of a different cut, where you guys are doing API level composition, basically.   The thing that, that we want to do is basically provide a core node,   hence the name,   and, and allow users to, basically, then connect to it and, and experiment with different use cases.   So we are going back to, basically, this topic of special, specialization   where,   where we as the lightning developers are sort of in charge of, of operating lightning node, the stuff that we do best, and freeing developers from actually having to even learn all of the intricacies   of,   of building   both a beautiful UI and UX   and managing a lightning node that has has to be bundled with with your app. So,   and hopefully by by basically removing this this need to bundle   a lightning node with your app, you're also freeing the user to basically experiment and jump from 1,   front end application to another one   And, whereas if you bundle the node with with the, with the app itself,   trying out a new app means setting up a full, you know, so  

[01:07:58] Unknown:

Yeah. I mean, that's that's   always that that kinda highlights that debate that's been around forever in the lightning world of, like, do you have, you know where do you put the the node? Right? Do you have kind of the, I would say, the earliest designs and the earliest focus was kind of you everyone would host their own node at home on our Raspberry Pi, and everyone would give kind of part partial remote control access to that node to every app or whatever via, you know, this   this the LND has the macro and system and   and Corelightning has some similar stuff. Now you can do it over onion messages too.  

And you have kind of that world, and then you have this kind of movement towards well, you know, people actually seem to really like this UX of having a a node or at least having payment channels locally in in Moon or Breeze   or or Phoenix,   or maybe there's a few others.   And then,   kind of, maybe moving back,   like, kind of the the core lightning, the the green light design's a little bit in between. Right? It's, hosted, but some of the signing is local, so there's less trust in the server.   Or, you know, you keep it all hosted locally and do it. So I think,   you know, as much as there's   value in there being a standard and everyone doing the same thing, I think we're just gonna see different experiment. We're different we're gonna see different things. We're gonna see people use green light, and that's gonna be great. And then we're gonna see people who continue to have the the   channels on the phone, and that's gonna be great for for those. And so, you know Well,  

[01:09:27] Unknown:

and and and we have by no means seen all of the possible combinations. Right? No. A lightning node is very complex. It has very, very many, components, and you can basically distribute these components however you want. Right. With with Greenlight, we chose to have the node itself on, on a hosted system   and the signer and the front end on on a different device. Maybe some, some other combination   makes more sense. Yep. And, and we're just starting to see how these deployment strategies can work out.   And,   I'm very much looking forward to to seeing how all of this works out. Yeah. So we spent a little time talking about  

[01:10:03] Unknown:

mobile and then a little bit of time talking about   LSPs and getting into this kind of mobile and and server assisted model.   Let's let's switch gears and talk a little bit about, like, what future designs and what future things have to come for the kind of enthusiasts to plug that nodes,   this world. You know, what   what what do we need to add to make that even better experience, and and where does that world go in the next year or 3?  

[01:10:28] Unknown:

Yeah. Yeah. Pubnet is is awesome,   especially, I think, because they're just enthusiasts that, like, test things out for us. You know? Like, they're just trying all the things, and then they report back. You know? You yeah. Go in the, Telegram groups, you know, and see what people are having trouble with, and it it's fabulous. You know, to have this group of enthusiasts that test things out. I think there's a lot of tools,   you know, for,   you know,   for those enthusiasts, you know, things like Umbrel and, you know, my note and all those sorts of things.   And I think a lot of them,   wants   to, you know, they get to sort of   build with lightning. Right? And so when you make things that are really reliable,   that they can just reliably   use this to run their node or to manage their node and have these tools for liquidity. And then they get to experiment with building things on top of that. And that's really, really valuable, I think, to have that constant experimentation and testing   in the space.  



[01:11:23] Unknown:

Yeah. I think there, there is a point to be made that that we definitely need more tooling to to surface some of the information about your node as well,   to really have an objective measure on, on what works and what doesn't.   For the longest time we have, we have heard that rebalancings work, rebalancings don't work. How do how much do you spend on rebalancing? Should we make rebalancing free?   How much privacy do we leak with that?   Do we even care about leaking some privacy if it's not our own payments?   Or do we use rebalancings to provide cover,   traffic for really private,   transfers?  

So all of these kinds of,   of,   details, that we want to surface to the user,   to help them make an informed decision about whether something is for them or not is something that we definitely need to work on and   make available to users   in the future to help them   make their own experiments, basically.  

[01:12:24] Unknown:

Cool. Yeah. I don't think I have very much to add here because this is the one market that LDK just, you know, I think LND, Core Lightning work great for this market, so don't we don't really focus on it. Focus on your market. Yep.   So let's let's talk.   We have a ton of time left, but let's talk really briefly about enterprise, and then we'll see if we can talk a little bit about spec in the future too.   So what what do we   you   you know, I we have a little bit of experience on the Cash App side, but, you know, what what do we need for enterprises,   you know, as we just saw Kraken launch, Cash App only launched whatever a few months ago.  



[01:13:02] Unknown:

As these enterprises, big enterprises, start really coming online in a big way, you know, what do we need for the next year for them? This is sorry. I'll jump in quickly. But this I love this one because this has been the past year of my life. I've seen a lot of this, and people are asking me, like, okay. You get businesses   that, you know,   need a really reliable service. Like, okay. We wanna use lightning. We need something really reliable, and, you know, we are expecting this volume or that, and we need it to be scalable. And then just like, you know, the amount of times I've had to explain to why you can't use Amazon Web Services horizontal scaling on, like, a lightning node. You know? Like, these sorts of things. Or you just I think   scaling that infrastructure,   for some of these use cases is gonna be something that'll be important in the next year or 2 as, you know, bigger businesses take this on.  

And then just, you know, reliability. You know, if you're tinkering with something and it works 90% of the time, you know, that's that's awesome. If you're a business and it only works 90% of the time, that's a big problem. So I think, you know, reliability and scalability   are big things for for businesses that are trying to take on lightning. Yeah. Absolutely. I mean, one of the,  

[01:14:11] Unknown:

one of the prototypes we had, we had internally for a long time is basically a system that, that is truly highly available for liking nodes.   And, Val,   recently published a a system that very much looks like it.   Where you have where you have a set of boundary nodes and a virtual node behind it. And that that is definitely something that, that we are looking into because   this reliability and availability   is paramount for for big businesses. Imagine that if Amazon was unreachable 1% of the time. Right. All the money they would lose by just not being able to process payments. For a 100th of a percent of a time, they would still have Yeah. A huge problem. And and and this kind of this kind of innovation,   is is is something that, that that we definitely need to look into, and we've come a long way.  

We we've very early on had a failover.   A clear hat, had an implementation of failover that, that could take,   30 seconds to recover if I'm not mistaken,   which is good. I mean, 30 seconds,   that's that's quite good. We,   we can now,   basically reduce that to a couple of seconds,   failover.   And with high availability setups,   we can ensure that no single payment gets lost,   because if any particular node is offline at the time,   the sender will basically retry through a different route. And as long as any of these is online, then then you can you can still process payments. And that also gives you operational flexibility,   because it means that you can basically just   restart a node or upgrade a node and, and if, and do operational,   management of of the node while still being, being overall available.  



[01:15:58] Unknown:

Yeah. That's that's something that we didn't kind of appreciate going into LDK. We kind of built this thinking about kind of the mobile world and thinking about, like, people who want to integrate, especially integrate Lightning into existing on chain wallets. You know, you wanna hook it into your existing chain sync and your existing key store and blah blah blah. And that's kind of where we came at it, and then, you know, Cash App came to us. We didn't   pitch them, really. We'd explain what what LEK was, and they came to us, and they said, hey. We're actually we wanna use this. We have a ton of you know, Cash App's a little unique. It's a lot of Bitcoin exchanges are more kind of standard infrastructure, and they're set up to run a lot of daemons and interact via RPC. Cash App's not. They're a big company with, you know,   separate services for everything already in place that they already use for all of their existing   web   and and whatever services.  

And so they came to us and they said, you know, we want to use Total Decay with this, we think it makes sense.   And   so they ended up building a lot of that stuff using their existing   platform. Right? So they already had high availability stuff and failover and all that kind of stuff. So they built   a Lightning node custom with LDK doing kind of all all the   Lightning specific stuff into their infrastructure and as a part a core part of their infrastructure instead of kind of having a daemon they talk to. And so then we have like the hand availability stuff that that we've   shipped that they've looked at testing.  

It turns out once you start adding too many route hints in the the QR code just blow up and it it so we need we need bolt 12. We need the the onion messages so that we can request an invoice or   because it doesn't really you get too big an invoice for a QR code   or or l and URL. I guess both work in this in a kind of server assistant setup,   But,   yeah. So that's that's something that   we didn't anticipate, but turns out LDKs works fairly well for them or at least they're pretty happy with it.   So  

[01:17:56] Unknown:

Awesome.  

[01:17:57] Unknown:

I don't know how to read this clock. It went to 0 and now it says one minute. But Yeah.   But it's going up. Yeah. It's not 11:30 yet. So I think we can keep going for a minute. Let's let's   take another minute and talk about, the future of kind of the spec process,   the the bolts process. You know, we talked a little bit about kind of having a common core and these things that that all the lightning node nodes implement, and then having users kind of experiment   using those different kind of building blocks that exist within lightning.   How does that fit into the future of how, kind of, the bolts evolve,   and then there's now this new blip process   to standardize some of these extensions.  

How do we see that process evolving over the next few years?  

[01:18:43] Unknown:

Well, I think we have to, you know, see how it goes. Right? We just started using, you know, GLPs and all that. And I think that that gets more and more important as we get more and more activity, you know, and more and more innovation on Lightning. Trying to have a a method in a process   gets, be very important.  

[01:18:59] Unknown:

Right. Yeah. I mean, we've   already we've already seen   issue, you know, things getting exposed to users where it's like, well, you you wanna receive a payment. Okay. Now you have to pick,   and you have to negotiate with the sender. Do you wanna receive Onchain? Do you wanna receive Lightning? And now there's, you know, some apps have added. You can you can pick lnurl, and then you can pick bolt 12, and, like, the user has to know these things, and they have to select the one that the sender can send, And like so, you know, that this there's there's a certain value to to standardization,   but then kind of how do we balance that with   experimentation and letting people run wild and and, you know, we don't know what the answer should be. So how do we balance   having a standard that people can rely on with   enabling people to experiment and try new things so that we can find a solution that works better in the market. Yeah.  



[01:19:50] Unknown:

So so it's it's always been sort of this this, this process of expansion first during   for from the for the lightning specification.   I remember when we first met in Milan 2016,   we all had different implementations. We all were experimenting on different, things,   and we basically sat down and hammered out all of the different, different trade offs and came to what now is,   is is the bold process   and, the set of documents that we have for the bold process. And,  

[01:20:29] Unknown:

so I'm pretty happy with the way it works. Basically, giving giving everybody the ability to experiment. You're the only one who's ever expressed happiness about the way it works. I've heard people think it works poorly for very different and divergent and opposite reasons, but you're the first person to ever say, oh this works great. Oh, I I definitely have my pet peeves too. Overall, the process works. It's Well, I mean, we're building and things are getting built, so it can't be that bad. Right? Yeah. Yeah.  

[01:20:56] Unknown:

But I'm curious you're talking about this expansion and then consolidation. Where do you think we are right now in that?  

[01:21:04] Unknown:

Probably just about to start the next expansion.  

[01:21:07] Unknown:

Okay.  

[01:21:08] Unknown:

So with all the excitement going on with all of the different use cases that that are being presented, with all of the different,   ways to,   to achieve the same thing, we are, we are now sort of seeing what, what this will eventually, look like. And from these learnings, we can then go back to the table and basically say, okay, this is the way we are going to do do it because of these trade offs that we've learned, while experimenting with And and and what so, I mean, obviously, the the big debate is that the invoice format and payment formats and payment protocols,  

[01:21:42] Unknown:

being a key example of that. Are there other ones that you're thinking of too here?  

[01:21:50] Unknown:

Yeah. I mean, part part of that discussion is, is the use of whether we want to use the Lightning Network itself to do negotiation of of payments. So the whole, onion messages process,   over   over the l n URL stack of, protocols is definitely something,   to be to be looked at here.   We are looking at replacing the gossip protocol. We were just talking about, this before that we have this gossip protocol that   grew organically,   for the last couple of years   and has   has shown its age by now   with several different implementations sort of interpreting it slightly differently as well.   And so it's time for us now to basically go   and try to find a new protocol that sort of encompasses all of the good and leaves all of the bad behind.  

So  

[01:22:42] Unknown:

inter message dependencies should be dropped. So you'd say we're we're kind of at a different,  

[01:22:46] Unknown:

place in some of these different protocols is like we're Yeah. Absolutely. Yeah. So it's definitely different lanes that expand and contract in in different times. Yeah.  

[01:22:55] Unknown:

Awesome. So I think we're getting waived off. I still don't know how to read this timer, but   so, yeah, thank you, guys. Alright. Thank you. Thank you.  

[01:23:09] Unknown:

Greetings everyone. Welcome to the roll your own crypto panel where we have a bunch of   cryptographers   or people that work on signature libraries   and, you know, they're kind of unsung heroes when things go right   and if things go wrong,   they end up like Sony completely,   pwned.   So I'd like to first, like, get started   in what is a signature? How does it work? Like, you know, are we are we using DocuSign here in Bitcoin Core? Like, what's going on?   How do signatures work, Pionis? Like, what are the functions? What's needed?  

[01:23:47] Unknown:

Mhmm. Okay. So what is a signature? A signature is something that in Bitcoin authorizes   the spend   of a coin such that the person who received the Bitcoin,   can spend the coin and no one else. And   this   idea that no one else can spend the coin we call that, unforgeability.   So we say the signature scheme,   is not forgeable and,   that means no one   except the person with a secret key belonging to a public key can   create a signature over a certain message, and in the case of Bitcoin the message is usually some   variant of a transaction hash.  

[01:24:35] Unknown:

Got it. Got it. So   how has that maybe changed? You know, we recently activated   Taproot.   There's a bunch of new interesting   signature   interactivity   stuff I'll like to get into eventually. But what's the difference between ECDSA   and Schnorr?   And can you briefly touch on anyone here, can you briefly touch on, like, the discrete log problem?  

[01:24:59] Unknown:

That might too.   Go. I'll take that.   So as part of the new Taproot upgrade to Bitcoin, we have a new signature algorithm   called Schnorr.   The previous algorithm that was used in Bitcoin was called ECGSA.   And so as Jonas just said, right, the point of a signature algorithm, you take the message, which is your transaction,   you mix it up somehow with secret data in a way that anyone can verify. And the idea is that you have this unforgeability property. So only the person who have access to the secret data is able to sign the transaction. And if any part of the transaction changes, the signature is no longer valid.   And the specific way that that's done is by an algorithm called ECGSA,   which uses a whole bunch of   crazy moon math involving elliptic curves and complicated algorithms and stuff.  

And   in the Taproot upgrade, we have replaced ECDSA   for Taproot output with Schnorr.   And the difference between the two is actually fairly subtle.   They both use elliptic curve. They both use a sort of linear ish equation. They both have a very simple algebraic expression, which if we were doing like a math talk I could write them both on the board and you'd almost wonder,   what the difference was.   And the difference is the difference ultimately comes down to history, I'd say, which is   that back in 1989 or so when EC   Schnorr was first developed by Klaus Schnorr, who is still a professor in Germany, by the way,   He developed this signature scheme. He put a number of patents on it. 1, that was the number. And   he then tried to collect royalties on the signature scheme and because it wasn't widely used anywhere it got no use. Right? Nobody wants to start using a cryptographic scheme that you have to pay to use basically and that's always been true pretty much for the history of modern cryptography.  

Then nobody used this. So then,   a few folks   at NIST and particularly Neil Koeblets, I think,   developed ECDSA,   where they took the Schnorr signature algorithm, they rearranged it a little bit, and they made it just different enough that it no longer violated the patents. And so this then became a standard both because there was a big standard body behind it and,   also because it was patent free. And that was kind of the design. Right? It was supposed to have all the efficiency and security and all those good properties of Schnorr, but not be encumbered by this patent. But as it happened,   well, in practice that is true. In practice it accomplished all of those things. But   Schnorr's system, by being kind of designed for for cryptographic   with cryptographic goals in mind is a fair bit more elegant.  

It has a security proof and   a,   theoretical model, which is much more plausibly related to real life.   It   also has a bunch of algebraic simplicity and that's the big thing that I think we'll get into a bit later that makes it possible to do all sorts of cool advanced tricks like multi signatures and threshold signatures and adapter signatures,   and all these different   new signature types. You can build them on top of Schnorr, and and it wasn't really practical to build them on top of ECDSA.  

[01:28:00] Unknown:

So   what is the difference between   multi signature and threshold signature?  

[01:28:09] Unknown:

Yeah. So kind of what was alluded to is one of the things that is much simpler to do now that we're using instead of ECDSA   is that you can have,   so I think most people who use Bitcoin are used   to having, like, a public key and that's like an address. It's where your funds are stored And then your private key is like the secret you know that then you can generate a digital signature in order to spend those funds from that address.   And now you can kind of have shared ownership of a single pub key.   Most Bitcoiners are well, some Bitcoiners are probably aware that you can have shared ownership   using   a Bitcoin script.  

It's usually called multisig,   and that's kind of enabled by just putting multiple public keys on chain.   But what these kind of new protocols enable is   a way for multiple people to share,   just one public key that kind of represents all of them. But everyone who isn't involved doesn't need to know that it's multiple multiple people. It just looks like a normal public key.   And then,   multi signature is when you have say, like, 2 people and both of them need to kind of work together in order to generate just one signature for their one key.   And then threshold as the name suggests would be something more like you have 3 people, but only 2 of them are needed in order to generate. So it's like a subset of,   the parties involved in making that. Yeah. So in some sense, threshold is kind of this general thing and multisignatures   are just,   the special case where everyone needs to sign,   which is kind of confusing because object multisig, like, the way that we previously had of doing multisig on Bitcoin or what's called multisig is actually a threshold signature.  

But yes.  

[01:29:58] Unknown:

So I think it's,   it's a different   state of mind now to perceive, like, the change from, like, a multi signature to now what's more like a interactive aggregate signature.   Can we briefly expand on how it works? The combination process, like, what are these rounds I hear of?  

[01:30:20] Unknown:

So right now in Bitcoin, if you want to create a multi signature, you use a check multisig opcode or in the Taproot world how it's called, check   sig sig add.   And,   the way that,   you are able to spend a coin is that you need to So everyone who is,   involved in that setup   needs to agree on a message which would be some kind of transaction   in our   case and,   then they just   sign with a secret key and send the signature   to some person that will aggregate the signatures   and,   then broadcast the transaction to the Bitcoin network, for example.   Now, if we want to use, the tricks,   that Nadav mentioned,   doing a real multi signature where   even though it's multiple people,   there is only one public key involved and there's only one signature,   the setup becomes a bit more complicated   because now,   we call this,   signing process   interactive,   because there are now multiple rounds involved,   Which means that,   the potential signers first   send some data around,   then   they receive the message and then they sign and,   this way we have like a a 2 step   process, you could say, in order,   to create a multi signature.  



[01:32:01] Unknown:

So are there some challenges,   I guess, like, if I had, like, a key and a safe, or   do they need to all be online, like, in certain instances? Like, how does this, like, look for, like, the average person? Yeah. There are,  

[01:32:16] Unknown:

some challenges   definitely which is why   we when designing these things we try to remove these   challenges   as much as possible but unfortunately they cannot be   removed entirely   in our universe,   in our laws of nature as far,   as as we know.   So just yesterday we published a Bitcoin improvement proposal draft   on the Bitcoin mailing list that,   contains a standard for how to create,   these multi signatures.   It's a 2 round variant,   as kind of the state of the art   research that we did previously. It was 3 rounds   and,   it tries to explain   all the different footguns. There aren't that many but you still need to understand if you want to implement this.  

I'm not talking about users or anything, I'm talking about implementers of this specification.   There are a few things that you need to be absolutely aware of. You need to read certain parts of this,   Bitcoin Improvement Proposal. I think   if you boil it down it's just 2 or 3 things.   But if you follow them you will be able to create a Schnorr signature, so a signature for a transaction   that spends a Taproot output.  

[01:33:41] Unknown:

Got it. Got it. So what are some attacks? You know, I hear this thing called rogue key attack or some guy named Wagner, like, what is?  

[01:33:51] Unknown:

Alright. Yeah. 3 months to 10. Yeah. I'll I'll take the rogue queue 1, and then I'm I'm gonna Alright. I'm gonna make you talk about Wagner. That's a hard one to explain.   So the way that these signature schemes work, both ECDSA and Schnorr is that you have this what's called a linear equation. We have some secret data, you have a message digest,   you have, basically an ephemeral key that we call a nonce. You put them together into a simple equation, you add all the pieces together, and you're off to the races. And   when I say add there, I mean, like, something a little more technical than than familiar edition, but still it behaves algebraically in the same way. Right? If you add 3 things together, it doesn't matter what order you put them in. You can rearrange them, all that good stuff.  

So what a rogue key attack is   is when you take one of these multi signature schemes   that Nadav and Jonas was talking about   where you combine   3 keys from 3 different parties, say, however many you want. Let's say you have 3 parties, they all combine the keys into 1. So the goal is you have one key, one signature, but you have 3 people behind it. Right?   And   the goal, of course, is that you don't want   you want the one key to actually represent the 3 people. Right? Like, certainly, they should believe that, but also it should be a true belief.   So what you can do during setup, if you're participating in this, say that we wanted to do like Vivek and me and Jonas, we're all doing one of these setups. The idea is that we would each throw a key in the pot, we would add them all together, and then we'd have our combined key. And then later when we're signing, we would each do a signature. We'd add the signatures together and then we get a single signature. We actually have to do that   in 2 stages. We throw some nonces in the pot, add them up. We throw some signatures in the pot, add them up. Everything's great. The rogue key attack is where what I can do instead is I can wait for both Vivek and Jonas to give me their keys. And then what I do is I make a key and then I subtract their keys from my key. And then I put that in the path. And so if you've been following everything what gets mixed together is my key minus Jonas plus Jonas minus Vivek plus Vivek and what's left is just me. And so all 3 of us, well all 3 of us contributed something and we added up something from all 3 of us, but I kind of ginned things up so that everyone else's contributions would be canceled   out. And now if I want to go move the coins without consent from either of them I can go ahead and do that because ultimately the final key is just me. So that's a rogue T attack. And the way to avoid it is to do what's called a re randomization   where when we mix the keys together we need to,   rather than directly adding them, we need to first multiply them by a random factor and you have to choose that random factor in a way that   that whenever I try to change what my contribution is it changes the random factors for every other party. So I can't wait for everyone else to do stuff and then contribute my thing. We have to   have to mix contributions from everybody. And so if I try to gin sync up my active ginning it up will change   3 randomizers   and thereby undermine   my gin.  

So that's the RoTEA attack. So that's one thing that we've had to address as we've developed these multi signature schemes.  

[01:36:56] Unknown:

Wagner Okay.  

[01:37:01] Unknown:

First, perhaps, just to be clear, these attacks, they don't apply to the BIP that,   were proposed yesterday.   We're talking about this I think because,   these kinds of schemes they have a history   and these attacks were discovered   on the way,   to   to the standardization   of of these schemes. One of these attacks would be a rogue key attack, but there are also other   attacks. Perhaps you are aware   that,   given   some byte string and a hash function,   let's say SHA 256,   it's very hard to find a pre image   or an input to that hash function that hashes   to a specific output.  

That is hard.   However, what not many people are aware of is that if you have a sum of multiple hashes   that should sum into a value, a specific value, then finding the pre image for that sum of hashes   is actually not that hard.   And, in order to find these inputs to the hash functions, you can use Wagner's algorithm, but there are also,   more   efficient algorithms out   that have just been discovered,   last year. But this attack,   actually appears quite often in crypto systems that, we are interested in in in the Bitcoin world.  

[01:38:33] Unknown:

So just to I'm not sure if this is going to be helpful. This is a very technical thing. But one example of where that would appear is when you're trying to   do a multi signature,   what you're combining is a linear combination, of course, of secret data, but also the hashes of the transactions.   So if you can find a number of transactions   whose hashes all add up to the hash of another target transaction,   you can potentially get signatures on a bunch of good transactions   where the good ones were chosen   such as those signatures could be added up to get a signature on a bad one. And so that, and that is actually connecting this to a real system gets pretty hairy and technical, but because of this linearity property   that I haven't defined, but I'm gonna keep coming back to over and over, You can you can use this very abstract   Winger attack and actually produce forged signatures using it,   in some   long, like some previous   iterations of of this kind of research.  



[01:39:29] Unknown:

So now that that state of art research is out,   what are some efficiencies gained? Like, I like to sync my full node and,   you know, really brag about it. Is it faster now? Like, what's going on?  

[01:39:44] Unknown:

So it won't change,   past transactions, obviously. So the the kind of current sync time,   isn't all that affected by by Taproot. But new,   transactions, if people are using Taproot,   are going to,   well, I mean, Schnorr itself is just faster to verify already on its own,   by a little bit. But then,   with kind of the new standardization   process,   you can also now kind of aggregate a bunch of signatures that you want to verify   together in a way that then you can verify them all at once in a way that's faster than verifying each signature individually,   and that'll lead to,   I mean, it it will mean that   as opposed to the universe in which we didn't implement Schnorr,   we're we're faster than that universe in in syncing.  



[01:40:37] Unknown:

So I can essentially   verify maybe one signature for a whole block or one signature for entire, like,  

[01:40:46] Unknown:

15 multi sig, something like that? Well, all of them do have to be Schnorr signatures. So people who are still using EC and VSA, you still have to verify each of those individually. But I believe, and I guess correct me if I'm wrong,  

[01:40:58] Unknown:

that you can kind of just batch in as many of these Schnorr signatures that are using the same standard together. And kind of get benefits that grow with the number of signatures that you're verifying at once. So there there are actually there are 2 pieces to that just to to clarify. So one is this notion of batch verification where if you have a whole pile of signatures in a block and they're all snore signatures, you can verify that much faster than just verifying each one in a row.   And if you've got, like, 3 or 4 of these, you can probably verify it, like, twice as fast, but if you've got a 1,000 of them, you could potentially verify it, something like 8 or 10 times as fast. It's not a simple curve. It can just give you a multiplier, but it gets better the bigger your batch is. The other cool thing though that we'll see with Schnorr signatures is because we can do this multisig   kind of constructions,   oftentimes you won't even have so many signatures to verify.  

And I think that's probably in practice where we're going to see the bulk of the savings is in the signatures that aren't even on the blockchain because they no longer need to be. Yeah.  

[01:41:55] Unknown:

I think   one of the,   more immediate applications of this multi signature   technology   is   opening and closing lightning channels   because there you are already in the setting where you have a 2 of 2 and,   the Lightning Network,   already is a very interactive and, stateful process, very   different to, like, hardware wallets signing in your,   bank using your bank vault or or whatever.   And   this would, I think,   benefit,   Lightning quite a bit because right now you need to, write 2 public keys to the, chain as well as 2 signatures when you want to close a Lightning channel,   And, with   multi signature   schemes, you can reduce that to 1 public key, 1 signature, which would make it cheaper   to, use Lightning.  



[01:43:00] Unknown:

Are there any other cool applications,   with these? I know Nadav works on DLCs.   I know, like, there's also a preimage   or hash reuse along the path.   What what's possible now?  

[01:43:15] Unknown:

Yeah. So one really exciting   application,   that is made much easier by Schnorr signatures,   is a variance that I believe Andrew came up with called adapter signatures. Oh, yes.   And they kind of allow   you to,   say, bake in some more   logic   in into your signatures than just kind of saying like, yes, this person can spend this, you can kind of make it a bit more complicated. So essentially, what DLCs do is we utilize adapter signatures   in order to,   make   Bitcoin   payments   that,   pay different amounts depending on   what, say, an oracle says happened in the real world.   So say like if, someone won an election or something like this then, you know, there might have been multiple candidates, people can put money into a Bitcoin address   that will pay to a different person depending on who wins that election or all sorts of variants on this kind of thing.  

And, I believe this also affects lightning. You can essentially   perform lightning routing in a much better way than previously   or than it currently is done   using these adapter signatures. And one of the main benefits of this is that you don't have to use,   Bitcoin's native   scripting language, you kind of bake it all into the math of the signature itself and it all kind of just looks like normal signature activity on chain,   but it kind of makes it so that only the people who need to know kind of do the math and and do all of the contract   logic and everything else.  

Really, you only use the Bitcoin blockchain   for the actual transfer of funds, which is what it's best at.   Yeah.  

[01:45:05] Unknown:

So one thing that we've been dancing around through a lot of this conversation is that there's not just a scalability benefit here, there's a privacy benefit as well.   So one place that the privacy comes from is just like, just from using multisix directly. That already gives you a privacy benefit if you've got one key that potentially represents multiple people and potentially represents some complicated policy where it could be a threshold or   some other arbitrary set of signers. In the lightning case, things get a lot more interesting because as you say, with these adapter signature constructions, you're able to start embedding some kind of non trivial logic into the signatures themselves.   And   adaptive signatures themselves,   what they are one way to think of them is a form of verifiable encryption. And what I mean by that is that I can take a signature,   I can encrypt it in some way where I can prove that the data that I'm encrypting   satisfies some algebraic properties that let me hook it into some other cryptosystem somewhere or something. But ordinarily, the point of encryption, right, is that you basically completely scramble your data.  

And   if you   the idea is that this intended recipient can decrypt it and get the data out. But until they do the decryption, if they don't have a decryption of queues, there's nothing they can, they can't even tell that it is encrypted data, right, it could just be noise.   With verifiable encryption,   you can,   you know, provide some more substance to that. So in particular,   when you are using the lightning network,   the way that your payment channels work, well, the way that Lightning works is you're actually chaining multiple payment channels off of each other and you have these paths through Lightning Network and you're routing money through all this.   And along a certain path,   you have to maintain this,   kind of fixed identifier. I think it's an invoice ID or something in the UX. But what it is in the current lightning indication is it's some hash, some random hash of some data.  

And this hash is put into the scripts in all the payment channels and it has to be the same and that's how the payment channels are linked. The idea is that when you update 1 payment channel, it causes a preimage that has to be revealed and the revelation can then be used in the previous payment channel, which then, you know, and everyone before that. With adaptive signatures,   rather than using script to require that your signature has to come along with revealing this hash privilege,   you can use this form of verifiable encryption. You can say by signing, you can say my signature itself is an encryption key or a decryption key, more importantly, it's both.   So by signing this update to this payment channel, I am now revealing a decryption key in the form of a signature   and that decryption key can be used to reveal some secret data, which I can then take and use in the previous payment channel and chain it forward. And even cooler is that you can actually re randomize it at each step. So now rather than having a whole path, we have the same random ID in each one   that somebody who had a God's eye view of the network could tell that it was all one path. You now have this re randomization where even the people in the path itself   might not know where it starts and where it ends because there's re randomization happening at the hop after them and the hop before them. So there's a privacy benefit there even within the Lightning Network. So  

[01:48:10] Unknown:

That sounds interesting. Pretty cool. So we have about 15 minutes left, and,   I'd definitely like to discuss scriptless scripts,   MUSIG   DN, or perhaps even CISA.   And   then, there was a recent paper put out,   and also some libraries from, Jesse Posner   regarding a threshold scheme called frost.   So,   let's try to rush through this.  

[01:48:39] Unknown:

Well, scriptless scripts generally refers to the use of adapter signatures. So I think we've covered that one.  

[01:48:46] Unknown:

Makes sense.  

[01:48:47] Unknown:

Well, I have one more minute. Okay. Yeah. Go for it. I'll be quick though. I promise. Yeah. I was I was on another panel a couple of weeks ago, and I gave a 28 minute answer to the question, how long have you been writing software? So, but I'll try to   I'm sorry, I'm doing it now.   To finish my spiel about adaptive signatures. So adaptive signatures give you this kind of,   this verifiable encryption property, which you can use in the Lightning Network just to feed data through there. But what you can also do is encrypt other signatures, for example. So you can do arbitrary forms of atomic swaps and stuff   where you   where you have, say, 2 transactions on 2 different blockchains,   for example, and you want to swap. Right? You're trying to trade some Bitcoin for some something worthless. Right? And the the worthless thing has its own chain. Right? That they do usually.  

And,   so you want to do this fairly. Right? You don't want, you know, one person to give their money away and then the other to just take it and then walk away. So the way that you do this is you set things up so that when the first person signs to take their money, that signature then decrypts a signature that gives the other asset away on the other side. So you get this atomicity   in that form.   Another   more general application of this would be something called a 0 knowledge contingent payment.   ZKCP.   ZKCP. Thank you.   Where   what you are encrypting rather than being another signature or something is basically some arbitrary piece of data and you provide this extra object called a zero knowledge proof. And a 0 knowledge proof is a very general, very powerful cryptographic object, which are very slow to create. They have weird security models. There's lots of questionable things about 0 knowledge proof. But the cool thing here is we don't put them on the blockchain and we don't need them for long. They're kind of an ephemeral thing here. So what I could do is supposing   say that   I   meaning of trying to come up with a noncontracted example. Right? I have some satellite imagery. Okay? And I claim that I found some oil deposits. Okay? And I'm trying to sell those to Chevron   and I don't want to just give them the satellite images because then they'll take it and run away.  

And for some reason they're really into high-tech, like bleeding edge cryptography and wanna play games with me, even though that's really not what they do.   And, so what I can do is I can take this satellite image, I can somehow   describe the   evidence of oil in   a verifiable computationally verifiable way and produce a zero knowledge proof.   Well, I'll take the image, I'll encrypt it. I'll produce a 0 knowledge proof that what I encrypted is a satellite image, which satisfies these criteria, which Chevron agrees actually indicates evidence of oil. And Now we do a 0 knowledge contingent payment   where the 2 of us jointly create a transaction   where in order for them to take my money,   I have to sign a transaction and my signing of that transaction,   well, I know it's going to give me the money because that's the transaction that gives me money. My signing will then decrypt the image,   which Chevron knows will be what they expect, and so we can execute a transaction that way, even if the 2 of us don't really trust each other, and even if, like, nobody should trust either of us. The the zero knowledge proof will step in there. So this general framework of of playing games like this with adaptive signatures is what we call scriptless scripts.  



[01:52:01] Unknown:

Got it. Got it. So we're gonna take a step back. Actually, no more music DN. I think we got our z k p, crypto cat out of the way.   Let's let's take   a bit more   applicable thing. Like, I know, you and Tim Rufing also work on   half ag music too. What are these,   advantages and, efficiencies potentially gained for things like lightning gossip? Can you touch on this? From, aggregation?  

[01:52:29] Unknown:

You mean? Okay.   I think would make first sense to distinguish what we call signature aggregation   from, multi signatures or threshold signatures.   And, for us, the main distinction   is that in multisignatures   or threshold signatures,   you only have a single message.   In the,   Bitcoin use case,   that is   dependent on the input that you're spending,   or dependent on the coin that you're spending, which means you have some   set of people and they have shared ownership over a single coin.   Now when we go to the signature aggregation world,   there are multiple signers and each with different messages.  

Right? So this corresponds to a transaction with multiple inputs,   and,   this transaction must have multiple signatures,   and each signature will be over a different message   because,   because the signature is used to authorize the spend of a different coin.   So we call this, these schemes,   signature aggregation.   What they are doing is they act really aggregate   signatures and,   this doesn't have privacy benefits,   in general at least, but it has   scalability benefits   because,   a big part of transactions   right now are actually signatures.   So   what would be   we could try to aggregate these signatures into a smaller signature.  

And,   there we again basically distinguish   2 different types of schemes,   mainly half aggregation   and full aggregation. And full aggregation is a bit simpler to explain because,   that works by   or or the output of the full, signature aggregation algorithm is a single signature. So in an ideal world,   every Bitcoin transaction would have a single signature,   unlike today where,   there's a signature for every input, basically.   But creating these   signatures   has   similar   interactivity   properties than,   multi signatures.   So it's not so easy to do, and how to exactly do that is, still an open research problem.   For half aggregation,   we don't get the benefits of having only a single signature in the end. We basically   are only able to aggregate half of the original signatures together,   but this process is non interactive,   so anyone can do that. And,   that would be something,   that could be added to   Bitcoin consensus perhaps,   at some point   in the future,   but,   it may have also implications   on protocols   on top of the Bitcoin network such as,   Lightning   because, Lightning, at least right now, gossips a lot of signatures around to prove,   that nodes actually have open channels.  

And these signatures are just bare single signatures,   So what could happen is that instead of each sending a single signature for,   in order to do a single proof   that,   a channel exists,   some party, could be anyone, could just aggregate   these signatures into a single half aggregated signature then,   in order to reduce,   the size of the messages that need to be sent around in the Lightning Network.  

[01:56:32] Unknown:

Fascinating.   Hopefully, we'll get that sooner than later.   Alright. Nadav, what is frost?  

[01:56:40] Unknown:

Well, frost is a specific   proposal for threshold signatures on top of Schnorr.   I believe it stands for   flexible around   optimized,   what's the s?  

[01:56:56] Unknown:

The signing signature. Something threshold.  

[01:56:59] Unknown:

Oh, Schnorr threshold signatures. There we go.   Yeah. So essentially,   it is,   so it's a 2 round,   proposal meaning that,   well, I   guess there's a pre computation you can do so that it kind of looks like there's only a single round where,   that kind of   looks like normal signing where you just do something once, like, everyone generates their,   part of the signature and then someone puts it all together.   But really,   there's also kind of like a setup round. So there's a setup round and then a signing round. It's maybe a high level way to think about it.   Essentially,   what you do is,   everyone kind of generate or has their own   private key is how you could think of it or or secret share and then, together they they   have one private key.  

It's not as simple as just adding all of those keys in a pot,   but you you do a little bit more math and you end up getting   a key which   then could in theory be derived by any, say, 2 of 3 participants or 3 of 5 or t of n.   But then rather than actually doing that because you don't want people to just know what this private key is because then they can sign for the group. So what you do instead   is you collaboratively   any,   2 or 3 2 of 3 or 3 of 5 or whatever threshold you want   of all of the people can get together and collaboratively generate,   like, they each person generates a partial signature   using their own   secret share and then it's all put together   and if you have   at least t people, at least 3 of the 5 people, for example,   then you generate just one normal looking Schnorr signature for the one kind of group key.  

And   it's kind of done in a a simple enough way that it it works well with a lot of other   things that you might wanna do.   I actually I don't know if it works with adapter signatures. I imagine that you would be able  

[01:59:10] Unknown:

to hack that together if you wanted or similar approaches could Adaptive signatures mostly only work with 2 of 2 set up. There's not room to do a threshold.  

[01:59:20] Unknown:

Right. Right. Right. Right. Okay. Yeah. Well, it   kind of is   similar in nature to how multi signatures look, but it's   done more generally.   And I guess if Jonas wants to talk about the trade offs between using something like music and frog. We can have a bonus round about blind signatures or ring signatures if you'd like to.  

[01:59:41] Unknown:

I think one thing that's also,   interesting   to to get across is what are the different stages that these proposals are,   right now. Because people in the audience might be interested to to use this eventually.   Mhmm. And,   so   what we're mostly talking about right now is only the lowest level that you're really interested in,   which is   the cryptography part. Right? But there are more parts before you can actually use this in your wallet. Right? There needs to be standardization   first of the crypto scheme,   And,   in for multisignatures,   we are   as I said, we we published a standard yesterday   for Frost.  

I would say there it's, a bit more early, but there are also standards,   progressing,   that will be eventually usable with, Taproot and tweaking and and whatnot.   But then there is also the other layer of how does this integrate with wallets really, that you can have multiple wallets   independently,   or independently implemented   from different vendors that work together and create,   such a signature.   And,   that is, I think,   a really interesting thing in the future how to exactly do that.   And,   that might be more difficult for some schemes than for others. Right? For multi signature, which is a more,   specific scheme, n of n, that might be a little bit more,   a little bit easier to do for,   wallet implementers than something, for example,   like, like Frost.  



[02:01:23] Unknown:

And you asked about blind signatures? Blind and ring. Whatever you think we can kill a minute 30 with. Okay. I say ring. Do rain. I I I'd say blind signatures. Let's do it. Yep. Blind.  

[02:01:35] Unknown:

Okay. So what blind signatures are, they,   are basically a client in a server protocol   where the server signs some sign signs some message   that came from the client without knowing what this message is.   And also such that the signature   won't be,   correlated   with, the message in the future or even the signature in in the future. And,   how is this used?   This can be used for example for Federated e cash or e cash in in general, which is I think one of the interesting   direction that the Bitcoin community   is is looking into where you have much better privacy,   guarantees than anything you could achieve with, blockchains   or   or Bitcoin   in particular,   but you have other   trade offs. And, these blind signature schemes, they don't need to be   part of,   Bitcoin consensus,   which means that we could use can use more exotic schemes   that don't have the trade offs,   of interactivity   that we discussed with,   multi signatures or complicated setup like in, threshold signatures,   but, we can have more,   exotic cryptographic assumptions and then,   have a simp a scheme that is simpler to implement and harder,   to mess up,   and also that has properties like threshold blind signing, where you have a whole federation   that would,   require a signature,   on a token or whatever,  

[02:03:17] Unknown:

yeah. So that's, that's I think the  

[02:03:20] Unknown:

the the way how you could use blind signatures in in Bitcoin.  

[02:03:24] Unknown:

And,   this is essentially Mini Mint or similar applications.  

[02:03:30] Unknown:

Yep. Exactly. It is.  

[02:03:32] Unknown:

Well,   I guess   that's pretty much it. I'd like conclude this panel. Let's get a huge round of applause for Andrew Polstra, Jonas Nyck, and Nadav Cohen.  

[02:03:50] Unknown:

Thank you so much for joining, and, Lisa, thank you for coming in last minute as a co moderator.   I I wanna start off by   I I I would assume   a lot of people here don't know what covenants are. I, myself, have never even   really studied covenants   really, really deeply. I know about them, obviously, but   I wanna take this time where we can all learn you can essentially teach Lisa and I about covenants. This can be an educational panel so then the audience can learn with us what are covenants.   And I wanna start with when I first started doing research, I said, what was the first covenant?   And what came up with what came up on Google was the first covenant was between God and Abraham,   and the way this this covenant is satisfied is   Jewish men got circumcised.  

So I wanna know   how how does this relate to Bitcoin? Maybe we can start there, work our way from, you know, a few 1000 years ago, and work our way here to Bitcoin.   Just kidding. But,   like I said,   few minutes on the clock. Let's do very, very quick introductions,   10 words or less kind of thing, and let's get rolling into the education. So let's start with Lisa. Hi. I'm I'm Lisa, also in.   I work on Nikon. Is we need mic for Lisa.  

[02:05:10] Unknown:

I'll I'll introduce myself in the meantime while we figure that out. Hi. I'm Jeremy. I like Bitcoin, and I like covenants, and I hope Bitcoin can one day have covenants.  

[02:05:20] Unknown:

Amazing. So my name is Burak.   I'm a Bitcoiner on Bitcoin dev. I think I started in Bitcoin, like, 5 years ago or more or less, you know, initially exploring and building around mining, wallets, payments,   and I initial and and I, you know, finally ended in this covenants rabbit hole. So it's it's a really interesting place.   Exciting  

[02:05:41] Unknown:

times. Yeah. Hello. I'm Sanket, and I'm excited about governance. And I like Jeremy, I want to see governance in Bitcoin.  

[02:05:49] Unknown:

Cool. Anyone on test the mic?   Hello? Hello? Okay.  

[02:05:52] Unknown:

Hello?  

[02:05:53] Unknown:

I think there's feedback. So so so,  

[02:05:56] Unknown:

Misty, if if you want, for now, if you, when you have a question, we'll just, yeah, we'll just repeat. Alright.   And then in in the sake of time, maybe we just kinda skip a little bit of the 2000 years of history of covenants and just kinda jump in it, for the sake of time. So,   how do we where are we at right now? How do we get here? Like what is a covenant in terms of Bitcoin, Jeremy? Yeah.  

[02:06:20] Unknown:

So one of the things that I use to explain covenants is that Bitcoin UTXOs, which hopefully we know what those are. That's like a a coin that you have. It's a little bit like a treasure chest,   and when you open it up usually   you get some coins out and you can put those into whatever new treasure chest you want, and that treasure chest could have whatever locks you wanna have on it. A covenant is like when you open it up, and then instead of gold coins or something, you see it's like Jimmy Hendrix's guitar, and it says please only put this into a guitar case in the future. And you're like, okay. So if I open this up, then you're gonna leave a little note maybe that says, yeah, when you open this up, please put it into a guitar case. Maybe after it's been opened 10 times, you say something like, take it to the guitar shop to get tuned. That's a covenant. It's like you open up these treasure tests, and then you find something that maybe has some additional restriction of what you can do with it, and that's maybe a little bit heady, but you can imagine in Bitcoin we would have something like, hey, open this up and then move it, and then after you've moved it you have 6 months before some other action can happen. Once you take that action, you have a 2 week grace period, that type of thing when because we're only thinking about Bitcoin. You can't transact Jimmy Hendrix's guitar on the blockchain. I I like that analogy. You have to put a guitar in a guitar good guitar case that's kinda like provisioning it. Did you Hello? Hello? Hello?  

[02:07:35] Unknown:

Hello? Hello? Can you hear me? Oh, great. Oh, sorry. Okay. Cool.  

[02:07:39] Unknown:

Try to do a quick end so Do do do a quick intro. Yeah. Yeah. I'm Lisa also, and I work on lightning at core lightning at. Cool. And I I didn't really do an intro for myself. So we'll we'll we'll be asking the questions here trying to learn with you guys about these covenants. I'm I'm Michael Tidwell. I work at Souty as an infrastructure engineer.   And and what you missed is,   Jimmy Hendrix guitar case. The the analogy here is if I give you this guitar, then you have to put it in a guitar  

[02:08:05] Unknown:

guitar case. Can't say that word today. Is that kind of Yeah. Like, you know, you have a special object, and you've gotta, like, preserve something of it's gotta be in a guitar case. You have keep it under some sort of special rule.   And, you know, rather than just, like, you know, gold coins that you could take out of your treasure chest and put into another treasure chest of your choosing, you You gotta keep it in something that has a special format. So is this I mean,  

[02:08:27] Unknown:

I think, like, most people have heard of NFTs,   which are, like, non fungible tokens. Right? So how are you gonna take Bitcoin and make it look like a guitar?   Like,   you know, like, like, why you know, the nice thing about Bitcoin is every Bitcoin is a Bitcoin. Right? Like, you can exchange 1 Bitcoin with another person. We call that fungible because you know that when you get Bitcoin it's the same as, like, any other Bitcoin and all Bitcoin is, like, pretty much equal. Right? So I'm willing to transact on Bitcoin   because I know that I'm gonna get Bitcoin in return. Right?  

Like, if you're turning Bitcoin into guitar, like, how does Bitcoin become a guitar, 1?  

[02:09:05] Unknown:

And, like, 2, like yeah. Isn't that, like are you making, like, NFTs then? Like Yeah. Yeah. So we're just using the guitar as an example of something that has some additional restriction. Mhmm. An example of Bitcoin that's more like a guitar might be Bitcoin that you intend to give to your spouse when you die. Mhmm. And you might wanna have an additional covenant on that that says, well, if you claim access to this because you're claiming that I'm dead,   maybe there should be some time out period where I can say I'm not actually dead. And that would be more like, you know, there's some restriction on that. But why are you giving your money your Bitcoin to your spouse, Jeremy? Like, I don't have a spouse. I see. Thanks.  

[02:09:42] Unknown:

Otherwise, my spouse would have all my So so let me let me ask kind of, like, a higher level question. Do covenants do covenants currently exist in Bitcoin?  

[02:09:52] Unknown:

I can go with this, And the answer is we don't know.   Like,   Bitcoin script is,   like, complicated. We have this opcode called op check sig   which allows which is most fundamental opcode to Bitcoin where you check a signature, then the transaction has valid signature with respect to   the given public key.   And by its nature, this opcode   relies on some data from the transaction itself.   And in some way,   the the data from the transaction is available to the script.   And given all the different op codes we have today, there may be covenants may be possible.   We just don't know how to do them yet.  

Good way might be to cleanly add support for covenants, but do we have covenants today or no?   I don't know. Like, for example, Andrew Postra has a good blog post on if you just had op cat, which is looks like a simple op code where you just add 2 concatenate 2 elements on stack,   with that, you can have covenants. Like,  

[02:10:55] Unknown:

yeah, just the nature of Bitcoin script itself is, like, I we can't answer this question. So I I would actually take the side of saying, that we that and this is maybe an important second topic is that we do have covenants,   that like, a a lock time, check lock time verify, or check sequence verify, in my opinion, are a covenant because it's saying here's a coin   that you can only spend after a certain amount of time. So it's something beyond just who the owner is about how the coin can be spent. I would consider that a covenant. The   thing that we're that we're talking about when we say we're not sure and we usually shorthand covenants for this is covenants that really restrict   where you can spend the coin to,   not just the how.  

And,   that yeah. We don't know. As far as I can tell, we don't have them  

[02:11:38] Unknown:

at this point, but maybe somebody would find something we could do. Right. But, but by by the definition that we're kinda talking about, it seems   covenants, by definition,  

[02:11:47] Unknown:

have some kind of condition on how they're spent or how Bitcoin is spent. Is that is that okay as a layman term definition? I think you just wanna add more so than something like a simple list of signatures. Okay. Because that that's kind of like that's just who owns it. Because because that's every Bitcoin. And you can say that's a covenant, but that's just like who owns it. It is like an additional restriction.  

[02:12:04] Unknown:

Okay. And, Brock, did you wanna add anything? Oh, I think, we don't have NFTs on Bitcoin yet, but you take those or NFTs when you think about it. And I think, yeah, here's Jeremy's saying guitar analogy is, you know, the stuff. Yeah. You can constrain   in how they can spend. Right? Mhmm. And, yeah, and you can do covenants with some additional codes like checks not tricks, but the entry barrier of that doing that is extremely high. Right?   But, you know, covenants, in short, is pre committing to a transaction in advance of creating address. Right? In short.   And I think from what I, like, observe from the community, I think we'll get there at some point. Right? But the question is really in what capacity?  

We we are seeing many competing ideas and proposals,   and more and more to come. Right?   But, you know, each proposal have a different level of complexity   and, you know, flexibility.   You know, each have their own trade offs. It will be interesting to see which ones pay the way for Bitcoin.  

[02:13:01] Unknown:

And can we talk about some of the proposals   that for covenants? I I know, what, in   2013 or some some Greg Maxwell made a post back in the day. There's been I don't know if that was quite a proposal, more of just an idea, but what proposals currently exist today   that are covenant proposals, I guess, you could say?  

[02:13:20] Unknown:

Is that for me? Alright. So anyone that wants to answer. I have a favorite one, which I'll tell you about last, but,   there are a lot of I think one thing that's important to understand when we say the word proposal, it means different things. So there is a BIP, which is a Bitcoin improvement proposal,   and that is a proposal that is it is, like, very structured,   and, they can be at different levels of readiness. And so when you talk about a proposal,   there's also a sort of idea, right, of, hey. What if we did this? So there are a lot right now of what if we did this's.   And as far as I'm aware, there's only, like, one   or maybe 2 things that are kind of more on the side of, like, here is a concrete thing that we could do.  

So in the the scope of things that are, like, here are ideas, people are talking about what if we added, like,   a   language that itself in scripting was maybe, you know, like a lisp or some sort of, like, actual programming language to Bitcoin, then we could compute   any arbitrary covenant we ever could want. We could say all the possible covenants we could express. That's something people are thinking about, but nobody has, like, a code sample that you could run and try with. And then, there are some maybe, like, application specific covenants that are, like, rather than this big general purpose thing. Like, what if we just had a covenant that let us manipulate   Tapscript and manipulate the tree that we've seen? There's one called Taplyk update verify that people are getting maybe a little excited about. There are some other ones people have talked about as well, but all those things are kind of in the space of, hey. I've got a cool idea. Don't know exactly what it would look like.  

The the 2 that have, some potential for covenants that are in the more concrete   phase   where it's something maybe that could be considered for merging,   and activation at some point in the next, like, year or 2 would be check template verify, which is the proposal that I work on. And Anyprevent, which is one that is in the Lightning community primarily, but has applications for covenants that are not, like, if you said we can remove covenants from any prevout, the Lightning community probably would do it because they're focused on it for a different application. So it's sort of a side effect.   And so for Check Template Verify,   I like covenants, and I think that generally covenants   are something we should explore, But a lot of people in the community, like Greg Maxwell in this original post where he shared it, had a lot of reservations around, are covenants good? Are they bad? Can they have bad, you know, bad things happen? And so when I designed CTV in 2019,   I said, can I make a covenant that is the simplest possible thing that   that basically if you don't   want CTV, then you will not want any covenant system ever, at least in terms of functionality? Maybe you'll disagree from a product management point of view. But if you say, CTV is bad, here's why CTV is bad, then we can rule out all covenants forever.  

But if you're like, CTV is good, like, well, we'll get something done maybe, and then we can talk about the more sophisticated things. So so it's like CTV is, like, the smallest unit of covenant where it's like, hey. If we can prove that this is bad, then we know covenants are bad. But if this is good, there might be more opportunity. Yeah. I I think that's how I would describe it. And just in terms of, you know, like, the doneness of the proposal, it it is in a form where, like, you could merge, activate, and release it, you know, starting now if you wanted to. So it's more in the category of product management decision rather than there's still an engineering question around how would we actually implement this thing.  

[02:16:43] Unknown:

I Yeah. I think that's I think those are all really interesting things about how we, like, kinda move Bitcoin forward, etcetera, and, you know, this covenant proposal covenants will have to go through that process at some point. I think, like, as, like, a as a person who works on Bitcoin stuff though, I'm gonna be honest, like,   I'm not totally I think covenants are cool   technically. There's literally cool stuff I think that they enable   but I'm not totally sold that we need to make Bitcoin more complicated and add more   ways of making it harder to spend bitcoin.  

So maybe I think there's 2 things here is like, you know, there's much different proposals about how to do covenants.   I think maybe we could talk about, like, what's how accessible are these? Like,   how, like, in terms of, like, you know, like, is it are these things that like everyday bitcoiners are gonna are we gonna make it easier for the is this gonna make it easier for them to, like,   secure their bitcoin?   Is it like   I don't know. Yeah. Like, if like, why  

[02:17:44] Unknown:

what about coming into, like So so let's let's start with, like, the major,   like, beneficial use cases maybe, where y'all can talk about, like, one one that you're interested in, for instance, is security. Like, how how does this benefit us?  

[02:17:57] Unknown:

Yeah. I think, yeah, we have some very I have some favorite proposals like CTV. I think it has many it enables many use cases. I think the primary one my favorite one is channel factories so that you can, you know, open thousands of channels in a single UTXO. And you you don't necessarily need to close them because they can they can source you in more liquidity later. But also I also, Tableau update verify also can, potentially bring, you know, channel factories as well,   so that you can open it's a shared UTXO model. You can open, like, tons of channels as well. But I think when you wanna close them, you only close the channel you are interested in as opposed to CTV when you have to you have to declare all channels first to call some. But, anyway,   I think,   one other interesting use case of CTV is vaults.  

You can, as well as channel factories again.   But I think, you know, overall, when you look at covenants,   everyone can benefit from it. Like, if you're a Lightning enthusiast, you can benefit   because it can bring l 2 to channel factories and noninteractive channel setups. If you're a self custody guy, great. It's for you. It's it's great for you. I mean, it could bring bring Vols to Bitcoin,   and I don't know, some sort of advanced self custody.   If you're, you know, Bitcoin scaling nerd, it's good for you. Maybe it could bring later on, you know, some points to Bitcoin, maybe trust those SPV side chains and us.  

[02:19:16] Unknown:

Yeah. So,   yeah, first responding to Lisa's question,   where, like, why are we adding this complicated stuff? So, like, definitely, it should be determined like, defined by what use case you're adding.   So in this case, we have some scaling benefits by proposals like coin pools where one UTX source would be this is not specific to check template verify or any single proposal, but with generally   some governance. Suppose we could have coin pools where you have one UTXO, which is controlled by multiple parties.   Like, if you imagine Bitcoin scaling to the world, we need some sort of coin pool proposals.  

Then secondly,   vaults.   And I'd like to, like, distinguish between CTV vaults and more powerful vaults.   And I think,   like, for   at least for me, covenants are kinda   like the end game.   Like, I like, we need to have some sort of self custody solution more powerful than you   than what we have today. I would not be comfortable, like, storing   huge amount of Bitcoins in what we have,   like, in the recommended security setups today. For example, in   governance, which were suggested in the original paper by our favorite professor,   we had a design where even if you lose your cold keys,   you could still, like,   get in a race with the attacker and try to burn your phones. So that offers a new level of security, which we currently don't have with,   like, any form of governance. Or even with CDB, we don't get that form of security.  

And so there are these new use cases which governance   enable that we that we don't get if we don't have them. Secondly,   it is often. That's the most fundamental part. Like, if people are using covenants, and if you're not using covenants, then it doesn't affect you. Like, new proposals, sure. They do affect you. You should care about a few things when new proposals are suggested. Like, is your full not doing more work than   what it is getting like, is are there any denial of service concerns,   about it? Maybe   like, you could do weird funky stuff with, covenants, but when we suggest proposals, we should make sure that, you know, those concerns   are addressed properly.  

So  

[02:21:36] Unknown:

Before   just just to kinda rephrase what we're talking about. I mean, we've talked about channel factories, so opening up thousands of channels in one transaction. Right now, if you open up a a channel on Lightning, that's one transaction. Right? So we we're we're talking about general scale.   We're talking about,   vaults,   which enable security. You you even said right now you don't feel comfortable with what's available. So you would actually   you you feel uncomfortable being a Bitcoin right now with the current technology is what is what you're saying, and and and you would feel more comfortable with vaults and and covenants that enable those things. So  

[02:22:11] Unknown:

those are those are some of the bit did you did you wanna add anything? Well, yeah. I I was just gonna add maybe 2 quick points. Sure. One is that, like, I hope in the next couple years we're able to add, like, tens or 100 of 1,000,000 of more Bitcoiners.   And even if we're, like, coming up with better things in the long run, I would really like if the story that we have for every one of those users coming on is that we get them started with something that's more secure or more scalable. And I think that that's why I, at least, you know, people critique that I say maybe, like, urgency, but, like, I try to do these things with urgency because for every user coming in, I wanna give them the best that we know how to do. And the second point that I would make, which is like should we be adding more complexity,   is, you know, like, sorry. The complexity is already here and people are doing these things, but either in more centralized,   trusted,   trusted means not trustworthy,   maybe a linguistic quirk, but using a trusted party   ways,   and these things I think are just completely worse. So if the market's already adopting solutions like that, we should do something that reduces the amount of trusted parties required for things people are already doing. So  

[02:23:13] Unknown:

now are you convinced?  

[02:23:15] Unknown:

I mean, it sounds like we're making a trade off here between complexity   and some amount of, like, security or, like, functionality. Right? So,   yeah, I don't know. I no. I don't I don't know if I am totally convinced. It is opt in though. Right? Well, actually,  

[02:23:30] Unknown:

just on the specific word complexity,   the the the protocol, for example, for opening up lightning channels with covenants is   simpler than the protocol for opening lightning channels without covenants. And so that's something where, actually, by having a slightly better technology, we can reduce complexity in other parts of the stack. So the overall complexity goes down. So I have a question for you, Lisa.  

[02:23:51] Unknown:

Is there   and maybe there's another way, but how do you how how can you open up and scale Lightning in terms of opening up a ton of channels without covenants? Is there another way?  

[02:24:02] Unknown:

Right now, every channel is represented by a UTXO.   Mhmm.   Which I I would say that's kinda simple in terms of, like, when people are in a channel, they understand what they own. It's a shared UTXO. Right? So maybe the complexity in opening it is a little hard, but the simplicity of what you own when you open a channel is very straightforward, I would say.   So, like, it's an on you know, it's on chain thing. You can go look it up on a block explorer. You can see where your channel funds are.   Yeah. So, like,   that's so it but that the limit on that then is that every channel open must be represented by an on chain  

[02:24:40] Unknown:

output. Is this, like, dichotomy or is this, like, trade off here, complexity versus scale? And is that kinda how we would see this, or is that not is that a bad   simplification?  

[02:24:50] Unknown:

Well well well, so one one of the things that I try to emphasize is that,   when you create a channel,   let's say that there are,   the maximum is something around, like, 20,000 people trying to open channels in a given block. Like, it's it's probably a little bit less than that, probably more like 5,000 people trying to open up channels. Sure. Probably, like, 4 or 5000. Yeah. That would be, like, the maximum. Right? And then what's interesting is as soon as you have 5,001 people, you will now over a long time have an infinite list of people trying to open channels.   And so you end up in a world where everybody who wants a channel is now not gonna have a channel. They're gonna have to go to, like, a trusted service that says, yeah. We're not gonna rug you on opening this channel. And then that, you can't look up in a block explorer either because it's and then you might say, oh, well, we can only support this many users. So I would rather have a pathway to supporting a larger number of users where they have to do something slightly different than, say, we're bounded by this constraint of Bitcoin, and we can only support top tier users at this amount. And I think we can still support people who are willing to pay for that 5,000 per block space if they want it, but now we're able to grow the pie and support more users overall. So so the human humanitarian  

[02:25:59] Unknown:

Jeremy Rubin wants even poor people to use Bitcoin. I'm for the.  

[02:26:03] Unknown:

Okay. Understood. So again, like  

[02:26:06] Unknown:

Thank you. This is  

[02:26:08] Unknown:

this is often, so you can still do what you are doing today. Like   and as long as what other people are doing with their UTXOs, you should only be concerned that it does not increase your verification costs, which can be evaluated per proposal.  

[02:26:21] Unknown:

It It actually should decrease your costs because, like, if there's 5,000 people, presumably, like, you know, half of them are probably okay with using the more scalable thing that, you know, it doesn't decrease block space demand, but it, like, lets you have more priority for if you really do need that space for an immediate open.  

[02:26:36] Unknown:

Yeah. But I guess, like so it sounds like if we're adding all this if we're but then you're changing the model then so it's not one UTXO per channel. Right? It's something else. So now you need, like,   more tooling and more,   like, ways to see, like, the visibility, etcetera. Right? So I think, like, adding adding cabinets is more like, you need more there's gonna be more we need more infrastructure for these things. Right? Yep. It's kind of what I think. We need more tooling for these kind of use cases.  

[02:27:04] Unknown:

And I think that this is sort of the,   and maybe this is, like, the magic of CTV as a covenant solution is that the thing that CTV expresses   is purely just a list of transactions that would get played in the future. And so there's no sort of really complicated infrastructural need for something like a Lightning node. All you have to do is say, okay. We're aware of these things that are pending transactions,   and we're able to see that they're CTV, so we can prove that they would happen in the future. And then you would just count those as fully confirmed rather than just sitting in the mempool unconfirmed. And that that's the only difference. For the more interpretive things, like, even things based in, like, any prevout or, like, those types of channel factories, well, then you've gotta, like, be, like, constantly, like, rebinding and scanning and things like that. And those have a lot more infrastructure requirements. But in terms of, like, an immediate migration path, we can, like, probably get something working pretty easily and then do the more complicated stuff in, like, the span of, like, decades or whatever.  

[02:27:55] Unknown:

I I kinda want oh, sorry. Go for it. Sounds good. Yeah. So, like, in terms of,  

[02:28:00] Unknown:

like, like, I know we are discussing CTV   a lot, but in like, I just like   to, like, you know, highlight   one of the things where,   like, I'm sort of,   trying to address to the crowd who think that   covenants or, in particular, some form of covenants are dangerous. And,   CTV in one proposal is, like, motivated by the design to avoid certain set of covenants, which we call as we don't have the time to get into it, but recursive covenants or unenumerated   covenants.   I think rather we should, as a community,   like, regardless we should have CTV or should not have CTV, we should try to address those concerns of people who are   against,   like, recursive covenant because they enable   new use cases, then,   like, c t it is independent of the issue of CTV, but I don't want the motivation for CTV to be,   oh, look. We are trying to avoid these dangerous things. The motivation can be, look. This is simpler. That's why we should do it. It's fine. But there are a lot of people who are advocating this because   they want to avoid something,   seemingly the dangers of recursive covenants. And if you refer back to the post from Greg Maxwell, you'd see that,   he does not say that there are dangerous thing. He actually chats in some way challenges everyone, like, what dangerous things can you do with governance?  



[02:29:19] Unknown:

So, yeah, I can't get into the technical details right now, but that's just Well, I I I kinda disagree. We're we're already over time, and I say we just keep going till we get kicked off because because I think this is kinda interesting. On time. So Yeah. So so, I mean, if y'all are cool with it I mean, if the audience is cool with it, I I I think this is super important to talk about because I was actually wanting to bring that up, the recurse like, let's play devil's advocate just a little bit here and talk about maybe some potential security issues with covenants, maybe are addressed with the idea, you know, with CTV or with other ideas. What what what could go wrong   with covenants?  



[02:29:57] Unknown:

Is there potentially a bounty? You know? Like, you know what I mean? Like I I think one thing that, like, look look, I actually believe in, like, doing this process to get towards as much covenants as we can do. So, like, I'm on board with that. I think I just wanna be a friend to the people who are, like, more conservative.   And I think a fair thing that they can ask is, okay, it's not enough that you can say there's some argument that, like, these things aren't bad. Please prove to me that it's safe.   And until we get to that level   of sophistication,   I think that a more conservative approach is ultimately what the community wants,   and   I am trying to cater to the community more than I'm trying to do the thing that I want, even though I I might want something more personally.  



[02:30:39] Unknown:

Overall, I just want something that's gonna let us do at least, like, half of the cool things. Okay. So I kinda disagree. Yeah. I kinda disagree with this over here. Let's, for example, take the example of, this is not a good analogy, but just for argument's sake, let's take the example of the tap root. If we   just, like, tried to address a subset of community that said that this is not quantum secure, for example, and we modified the route to, you know, do something dangerous and try to get everyone in. We would not have this proposal that we have today. Instead, what we work towards is, like, addressing concerns of people like, look. Quantum computers are going to come tomorrow. And even if we have them, we have bigger problems. Right? So it's not a fair critique because that would also make a complicated solution where a CTV is simpler. So coming back to the point, I think we should, like,   suggesting the community,   like, a wrong idea might get like, might backfire in future. Maybe earlier people believed that Bitcoin is free and had businesses built on top of it. And maybe today people think that, you know, recursive covenants are not secured and that's why we are supporting this. I,   like, I think I agree that CDP is simple and that is a good enough merit, but  

[02:31:50] Unknown:

we should also, like, address the community that, look, this is not dangerous and maybe we need more time for it. That's okay. Yeah. So so so I think one thing that's kind of interesting about that is that, like, you might you can agree or disagree, but at any point in getting the community convinced on the more complicated things, there will be a checkpoint   where you pass people being comfortable with CTV's functionality.   I agree with that. And then if that's true, the question becomes once we've surpassed that threshold,   how much time do we get to the point that we actually might want to go to, and then how many users come on board with, like, less secure, you know, custody solutions in the meantime between those two things. Why why would people be uncomfortable with this recursive stuff? Like, what are we what's the undiscomfort  

[02:32:32] Unknown:

that we're   like talking about here? So,  

[02:32:35] Unknown:

let's Good question. Yeah.   So this recursive covenants in particular,   they allow you to, like, wall guard on your coins. Maybe you can you can get into a covenant that you cannot escape out of.   And this, like yeah. This sounds dangerous. Right? Why would you put your coins into something which you cannot get out of? Like, you know, you're just We're not trying to make Bitcoin like Ethereum.   Yeah. Or maybe like you,   like one of the concerns is like just the US government goes to Coinbase and says put all your coins in this covenant, and it's a recursive covenant. So whenever you spend those coins, you need the signature of,   like, a cc. And whenever you want to transact you have to send a copy to them, and now they have everything. Why are we building this technology to help? That's a valid question. Right? And that's why people are scared. But the bad news is they can already do that today.  

They can just do it with what we call multisync.  

[02:33:30] Unknown:

But but the well,   I was gonna say I think to address the question, I think it's like the idea of the recursiveness. It's like   you you pretty much have, like, a deadlock on that contract, which does what? Does that break Bitcoin, or does that just break that transaction? What does that actually do? Yeah. You know what I mean? So so I think that rec recursive is just, like, a little bit of a stand in for, like, hard to analyze.  

[02:33:52] Unknown:

And I think we're okay with any covenant that we know how to analyze to show that it's safe or that it's good or beneficial.   And   that that I think is is why, like, for for for certain purposes, something like CTV is okay because it's very easy to analyze. So we're saying, okay. The analyzability of this is very basic. So we could say we know all possible state transitions. We're good. For me, the concern with recursiveness is that when you have these more flexible things, like, you might not have properly proved that the covenant is actually correct and there might be some sort of like Ethereum has these things with, like, you know, recursive reentrant, you know, contracts where you call the thing and then you call into the thing and then the number doesn't get updated properly and then you burn all the money or you steal the money. And those are the at least from my perspective, those are the types of issues that our ability to prove and reason about these things. Like, we would need a lot better tooling and infrastructure to do it, safely. So so so no loops are,   like, enabled? Is that, like, a easy layman way of Yeah. No loops. It's you gotta know the entire Yeah. You you know the you know the Yeah. The whole span of the tree of possible states. And and that's a huge trade off to get that analyzability. There are other things that also might have some similar analyzability, but are more flexible.  

But on all the choices, I just did conservative,   for this. And, you know, I I do think the conversation and defining the properties and not just having, like, one big stand in of recursive bad, you know, like, is is really important, but it's the analyzability I think is really the the thing we need. Yeah. So we can have analyzability  

[02:35:17] Unknown:

in, like, per particular smart contract basis. If user just want like, if they want to shoot themselves in the foot, they can do that today with   They should know if they're shooting themselves in the foot. That's that's, I think, the thing. Right? Yeah. If you if you are dealing with these type of things, you should know. Like, for example, there are, I think, could be things in lightning contracts which you can mess up. Right?   So, like You would hate that. Yeah.   So whenever you're dealing with scripts,   you can mess up. It's just the the thing sounds scary. It's like if you mess up, your coins are gone forever.  

There are also similar, like, risks associated with smart contracts today.   So it isn't that we are adding some new thing which was not, like, some new attack vector which was not present today. And as I mentioned, like, for example, using maybe just a single signature today with music, maybe covenants are already on the way. Like, we  

[02:36:06] Unknown:

like, what what I I think the thing with lightning is actually kind of interesting   with   just with people enforcing it, and if you've got automated things running this, it's just a question of like, is it the Bitcoin blockchain shooting you in the foot, or is it the automated services you have that are doing it? And I think for an end user, it might not be terribly different.   The the the covenants and this is similar to what we said earlier. It would just be like while we're shifting it to something that requires less signatures.  

[02:36:39] Unknown:

I have, like, sort of a do we have time for, like, good? We're going till they kick us off. Okay. Yeah. If you're in the back and you're like, we need to kick us off, worry about until When they when they cut off the mics, we'll walk off stage. Okay. Sounds good. So, like, the so my question is, like, is this kinda maybe this is, like, totally not related, but I'd really like to hear   so Lightning Labs just released this thing   that they're gonna add to the annexes of Taproots, which is like a whole new UTXO tree   and, like, a whole new scripting language,   this thing called tarot.  

Is that a covenant?   Like, maybe this is too I know it just got announced yesterday. You guys haven't had a chance to look into it. Is that are those covenants? It's like coloring it's kinda like coloring Bitcoins. Right? Is that is that does that count as covenants? Has, like, labs, like, basically launched covenants on Bitcoin already with their Taro stuff and their color coin things? Or is this stuff that we're talking about covenants wise, like, totally different?  

[02:37:37] Unknown:

I I have reviewed it, so I don't know if you guys have had No. No. I didn't have Okay. So, Jeremy,   you've been you haven't been doing any talking on this panel. Why don't you go ahead and Yeah. Also, I know I've talked too much, so like that's fine, like hopefully one of you had read it, but I've read it. So,   I would answer that   it is not   Bitcoin   validated covenants. It is client side validated covenants, which means that you're free   to if you own one of these things, you can definitely   burn   all the coins, and that will, you know, escape because you've just messed it up. Mhmm. But if you're running the the software, you will generate artifacts that somebody else could verify.   And that and, also, also, just a technical note, they're not in the annexes, which is important for something. But, anyways, they're   they are   they they internally can have their own covenants and things, but there's always a top level clause which says basically, well, you're free to mess it up if you want to. And so Bitcoin does not have covenants, but in their system,  

[02:38:38] Unknown:

it is kind of a covenant, if that makes sense. So if you could do covenants that way, why do we need to change the Bitcoin script itself if we can You could not build a vault with, with Terra. I see. So the one of the benefits of adding covenants to Bitcoin, like,   as   of   infra- inside, like, the Bitcoin infrastructure   itself is that now we can express things about Bitcoin, like your Bitcoin   hoard so to speak,   whereas adding stuff like the project that Lightning Labs announced,   doesn't give you that level of control is my understanding.  

[02:39:14] Unknown:

I'd say that's a correct understanding. I just wanna just to kinda   put a cherry on top of in terms of the devil's advocate stuff for CTV or whatever, I I just wanna include Barak here just a little bit here. I know I know you're currently using blockchain product liquid. Yes. What is something like CTV potentially missing   that you would wanna see? Or or what where how are you using covenants? Or how are you using liquid where it's maybe not even gonna be satisfied by some of the stuff? Oh, yeah. I think we can I just wanna Yeah? We can already, I think, emulate CTV in to some extent in the element subcodes, but I think  

[02:39:46] Unknown:

with CTV, that emulation would be more efficient because you can do, like,   the channel factories, for instance, in 1 byte   as opposed to, you know, 100 lines of bytes. Right?   I think, you know, elements of codes, right, are less controversial to maybe to bait pay it on some of them to pay the bill for Bitcoin because they are pretty much not well tested yet, but they're being tested.   And elements is based on a Bitcoin core code base and I think are less less controversial   to my observation. Like, things like c from stack for checking arbitrary signatures and caps, like data manipulations. And maybe some arabatics, right, could maybe potentially come to Bitcoin.   But I think CTV, I think, is really simple. Right? And from what I observed, like, from the community,   people don't really Bitcoiners don't really want these highly expressive, I mean, very complicated   proposals. Right? They rather   powerful yet simple proposals. And I think, you know, when you think about it, covenants, this whole thing is really a spectrum. Right? I think CTV per I mean, it fits really in this middle of the spectrum. Right?  

Whereas, you know, we could have, very expressive stuff, on the high high end of the spectrum, but it doesn't really make sense to, you know, merge into Bitcoin.  

[02:41:04] Unknown:

Thank you. And,  

[02:41:06] Unknown:

in   60 seconds or less, what does CTV need to cross into Bitcoin? What does it need going forward?   Maybe you can talk a little bit about that  

[02:41:16] Unknown:

very quickly. So there's a website, utxos.org/signals.   This is kinda the best effort that I'm doing, which is just, like, making sure more people in the community want it, and if anybody doesn't want it, they express in a coherent way what their opposition is.   Right now, there's, like, a 130   people in organizations who have been, like, yeah. Seems good. There's, like, 2 people or 3 people who've been, like, I don't want it because I think we have enough to work on with Taproot.   That's been the main, you know, kinda complaint. I think there are other people who might say they don't want it for various reasons. They like, I would really like to see more people   give one of these things like, oh, we don't want top group because of quantum things so that we can actually rebut the arguments. If you don't make the argument in the, you know, right forum, then it can't be rebutted.  

And then beyond that, I just need to do, like, a a binary release and pick some parameters, and that's it. You know? And it's like then the community can decide to signal for it. We'll do a soft fork just like Taproot.  

[02:42:11] Unknown:

Lisa, did we learn anything? I learned a lot. This is really informative. A ton as well. Yeah. I really quickly wanna go through,   show how people can contact you, your Twitter, whatever.   Lisa, we can start, and we'll work together. I'm on Twitter at nifty,  

[02:42:26] Unknown:

n I f t I n e I, nifty nye.   Also work on core lightning. That's core_ln.   So I'm just there.  

[02:42:33] Unknown:

I'm, at Jeremy Rubin on Twitter, and,  

[02:42:38] Unknown:

yeah, you can find me there. Yeah. I am Burak. Like, simple as that. Burak,   b u r a k. You can find me on Twitter and Medium.   You can also check out Bitmetrics on Twitter. It's a Conan based AMM on liquid.  

[02:42:50] Unknown:

Hi. Sanket.   Sanket 1729 on Twitter. And to final shout out, if you have any complaints   or concerns against recursive covenants, feel free to find me and DM me at all platforms. I'm always available to address those.  

[02:43:04] Unknown:

And I'm I'm Michael Tidwell, and Mike 20 one spelled out with a one on the end. I had the the worst username ever.   Thank you all so much for coming. Give it a round of applause. Thank you.   Alright.  

[02:43:21] Unknown:

Alright. So,   what's this lightning thing you guys work on, and you wanna give a brief introduction of who you guys even are?  

[02:43:30] Unknown:

Yeah. I guess I could start. So hi. I'm Matt.   I have worked on various things in Bitcoin over the years. I now work on the LDK project as a part of the Spiral team at Square. I guess we're blocked now.   So we have I guess we're unique in the the lightning implementations here where we're not actually a lightning node. We are a toolkit to build a custom lightning node.   So we support various people building different lightning nodes using LDK to do a lot of the hard work.  

[02:43:59] Unknown:

Yeah. Hi. I'm Chris. I've been in Bitcoin for 1 third of my life. I just realized,   since 2009.   And I'm now working   for a block stream on, core lightning and of course the specification,   which is probably why we are all here. Definitely.  

[02:44:17] Unknown:

Hey. I'm Lalo, cofounder and CTO of Lightning Labs, working on Lightning, for a while now too. Kinda like it involved in some of the earlier stuff on the spec side. I'm like we developed Relmd, which is an implementation of lightning. You know, one cool thing about it, it kind of runs everywhere. You can do it on mobile, iOS, Windows, free BSD, random other BSD you've never heard of, and, and obviously, you know, we participate in spec stuff as well. Let's, actually quickly get a round of applause for Lightning Labs for their recent  

[02:44:40] Unknown:

huge round of capital that they just raised. Right. Right. Right.   So   what's exciting now,   what comes to mind for me is   Bolt 12,   route blinding.   What's new in lightning? What do you guys care about,   these days?  

[02:45:04] Unknown:

Well, 12, obviously. I mean, we all got hats. Yeah. So that's what why. I like the decisions  

[02:45:10] Unknown:

around here is we just go by the hat.  

[02:45:13] Unknown:

And it's just the hats. Just the hat. Right there. Just the hat. Oh yeah. There's technology we don't know tech behind it. No. That's that's hard. No.   Yeah. I mean, I mean, Bolt 12 is awesome. You know, it has a few different parts. So like onion messages   by itself is cool, so the potential to to be able to do, you know, we have this this great network.   Obviously, it's not set up for high bandwidth messaging, but, you know, being able to use it to provide some privacy for   senders doing stuff like requesting invoices. Right? You have, like, lnurls really great if you   wanna know the client's IP address, but sometimes you don't care and you don't want that information,   so stuff like that. And then route binding, so improving privacy across the board there, plus Taproot with PTLCs. Like, we have a lot of these kind of small incremental privacy upgrades coming down the the pipeline,   that are all gonna be pretty great, and then hopefully, a bunch of UX improvements   on the side with that,   from messages and and other stuff that we can build using them.  



[02:46:15] Unknown:

Absolutely. And, one one of the more exciting things, that that I'm,   seeing in the near future is, the update of the gossip protocol too.   So the gossip protocol has been growing organically for the last couple of years.   We've seen a couple of places where we could improve it and try to improve it. But now the protocol is pretty much in monstrosity   and needs to be overhauled completely. And, while we're at it, we can we can add a lot of new features.   For example, we can, we can decouple now the or there's plans to decouple   the on chain footprint from the actual channel,   which, should help us make, make the entire network much more private.  

And, in combination with some other things like route hints, we can can actually make this network,  

[02:47:00] Unknown:

much, much more, compact and much more usable for the end users as well. Definitely. Yeah. I'd say things I'm excited about are kinda, like, generally just Tapu related stuff, you know, as far as, like, being able to, you know, use Moochic 2 and also kind of, like, actually make, you know, certain components a lot more compact, basically, and certain things around kinda, like, make HLC a little bit easier to to handle as far as, like, not even payment hash. I think one other interesting thing would be kind of like, you know, the actual transition to Taproot. Because, like, say we have, like, you know, 80,000 channels, you know,   rather than kind of, like, everyone, like, open and close a channel at once, it's kind of, like, okay. Well, we'll kind of, like, you know, have another spread off chain and defer that. So 2 2 we need we still need to transact it eventually. We can at least kind of, like, defer that a little bit further out. Right? That'd be really cool because then people can just update, and all of a sudden they're they're way up to use Taproot stuff. Then the bigger thing is, like, the pTLCs, which actually fix a bunch of your issues as far as, like, privacy in my network. Today, you actually have the same identifier in the entire route. So therefore, I'm in 2 different places. We can arrive. We see what it is now. It's actually going to be randomized. And PTLCs can put things like DLCs as well, too. I think this year is going to be a lot of stuff working on the spec side. And I guess what I think is there's just so much stuff at the end of the day, too. And everything is almost immediately implementable as well, too. So you kind of have to say, okay, maybe some restraints, see what we're gonna do, whatever else, how we can, like, allocate our resources as well too. Because, you know, at the end of the day, like, you know, even though there's things a lot bigger, there's still a few people that really know this stuff very intimately, but we're trying to make that a lot, you know, a lot more widespread. You know, we will work I worked with Andreas and Renee on the Mastering Lightning Network as well too. Definitely get that. You know, if you haven't got it already, it has a bunch of really good information about as far as the Bolt as well. Because the boats are kind of, like, you know, written for people like us, basically. And you need kind of a little bit more accessible thing. Okay. Like, how do the feature protection work? How do, like, you know, writing work, things like as well. Teacher education getting a lot better. Just generally a lot to develop our education getting really good these days as well. So  

[02:48:38] Unknown:

Yeah. How how could I forget, of course, splicing,   which which we've now built the groundwork using with the dual funding proposal,   which basically allows us to collaboratively create a transaction   among a number of peers.   And, looking a bit for, further on,   I I think we, we are all waiting on on l two being a possibility.   Of course, it was had to be me mentioning l two here  

[02:49:04] Unknown:

because I'm known as the l two shell. Yeah. It's gotta get l n. And any prev out is required as, like, a soft work for that. Correct? So so any any  

[02:49:13] Unknown:

is, software that we need for, for Bitcoin on chain,   Though there are other mechanisms that we could, that we could use, of CTV in combination with,   check from stack or TX hash from and check sig from stack. Both achieve the same goals,   so we were pretty much just sitting and waiting for, for either of these 2 to happen and to give us that that capability of doing some some really interesting, child stuff. Exactly. Like, for example, multi party channels,   where any number of participants can basically share ownership of a single UTXO   giving us   a couple of more orders of magnitude on top of lightning. Definitely. TLDR, we all have about 5 years worth of engineering road map right now, and we'll start delivering this stuff. I don't know when we get to it. So maybe the sort of the head of, of what we're planning to do is go getting further and further away from us and Yeah. But to do list keeps growing. Like  

[02:50:09] Unknown:

Right. And I think one cool thing about lightning is, like, you know, there's certain things that can improve the protocol that aren't necessarily, like, kinda, like, protocol level changes. For example, like, in the past year, we've seen a lot of people actually working on things like pathfinding, which is a big thing for improving UX as well too. It's one of the things where, like, the the specs stage, you know, get from a to b doesn't really tell you how to do so. Right? So we've all been kind of, like, pulling in the gaps. Then some some people do, like, you know, some newer kind of, like, probabilistic approaches as well too. Nothing else can be really cool because, like, you know, once we can move larger amounts of payments and also, like, payments, like, reliably gets a lot better. Because, like, the worst thing is, like, someone tries and obviously it fails. Right? I think we're getting a lot better now. You know, people are also getting, like, really widespread deployments with, like, cache app as we're getting a lot more data. Now it's like, okay. Like, you can actually use Lightning now, which sounds really good for, like, developers and companies who can now say, okay. Well, I actually have distribution and keep a lot of fabrication versus, you know, picking from, like, 5 different wallets that, you know, all are a little bit different. So I think that's a really good thing as far as a mature user experience, you know, with kinda, like, things at the edges. Like, people can just update, protocol wise or sorry. Like, you know, algorithm wise versus protocol wise as well. And then more research across different types of routing, because there's different things you wanna optimize for, whether it's, like, speed of the payment, or maybe you wanna optimize for lower fees because you're, like, rebalancing or doing something in the background. Maybe you wanna optimize for privacy, which is somewhere that like how to do a good private routing is not something that's had really a lot of research. There's some intuitions, you can throw some ideas around, but no one's really kind of done a take a fork taken a formal approach.  

[02:51:17] Unknown:

So there's even angles where, like, we need more academic research in that sense. Like, academics have shown that a lot of the routing algorithms we have today are very non private, but how to fix it, a little less so. So, you know, there'd be a lot lot of room to improve there too. Definitely. Yeah. There's there's just so many different venues where we can actually make progress and try to start experimenting.  

[02:51:37] Unknown:

And, it it makes me a little bit giddy because it sort of is this huge playground where we can explore new, new trade offs and and sort of try to improve.   And and that's one of the achievements that we that we got by basically lifting off of the chain,   by no longer being on the consensus layer where every single change has to be approved by the entirety of the network because it is a strong consensus algorithm we have to run on the, on the base system.   But by lifting off of the chain, we can actually get this freedom to experiment   and, and basically get,  

[02:52:07] Unknown:

get different parties, try different trade offs, and then sort of come back to the table and sort of discuss what, what worked best, what didn't work, and sort of, sort of come to to a more creative picture of of what we what we should do going forward. Yeah. Yeah. There's so many problems. It's easy to get, like, nerd snipes. Just kind of, like, you know, go very, very deep in a particular, you know, problem. I think one of the cool thing I've seen over the past maybe, like, 2 or so, there's been, like, a lot of academic papers now. Like, I actually do stuff. I got, like, a Google Scholar alert. Like, every day I see a new paper, basically. And I got, like, a real research and I post in there. So really cool just, like, seeing people kind of recognize that this is, like, a thing to be working on. All the kind of interesting sub problems where, okay, I can do path planning. I can do kind of like, graph analysis. I can do channel selection. I can do optimization. There's so many different problems we're working on. And it's like you're saying that's just it's so fun to be able to, like, pick and choose all this different technologies and, like, kind of solutions, to take a look at.  

[02:52:52] Unknown:

So it seems like all the hype is currently taro. Can you talk about shit coins on lightning?  

[02:53:00] Unknown:

I don't know if my friends are like that. I mean, you know, people can feel what they want to do, but something that I was working on for a few months now, kind of inspired by like, okay, what can we do with Taproot? Right? So kind of like starts from these through the realization, okay, well, Taproot has, like, a script tree, so you can commit different paths. Okay. Maybe there's, like, a multisig, there's, like, a time line, something like that. So, okay, well, what if we committed other data in that tree? Right? So, okay, well, now that we have that other data, like, how do we actually structure it? It's kind of the thing where it's, like, this enables you to basically have, like, you know, you can hold assets within kind of a single cap rate output, basically. So I have, like, my Bitcoin, and I can potentially have,   you know, a 1000 different assets. Maybe I have, like, a, you know, holographic cards, baseball cards, something else like that as well too. And the cool thing about it is, like, it's, like, very kind of, like, a Bitcoin like. Right? So, like, rather than kind of, like, try, like, entirely new VM or other things where it's, kinda, like, reuse the existing Bitcoin script VM itself. So you can you effectively kind of, like, have this, like, virtual graphics embedded in the Taproot, script tree basically with a similar kind of, like, asset witness and output, you know, format. You use some some things as far as, like, multiple some trees, different ways to do, like, proofs. But, you know, the idea is, like, once you upgrade, basically and the cool thing about it is, like, it doesn't actually require any base layer base layer level changes. Right? So once it's rolled up, people can actually just upgrade and start using it, you know, on their own. And the cool thing also is that, like, because it's actually based on, like, the Tapuite script tree, like, if we have some, like, certain type of components, maybe, like, the, Tapuite update verify, that can actually constrain, you know, transitions basically because if you can recompute the entire commitment, basically, you can recompute the script tree, then you may say, okay, well, it must look like this. Right? So I think it's really cool where it's, like, even if Bitcoin doesn't actually know why explicitly, covenants can still eventually kind of, you know, manipulate the thing that's going on there. Right? The Lightning part of it is that, like, you know, given that it's actually based on Taproot and also has, like, a scripting layer in the actual system itself, this is what we're kind of like you're playing or pros and doing is kind of like having the assets at the edges, basically. Right? So having, like, an entire the network upgrade, basically, and you have a bunch of questions as far as, like, you know, routing, liquidity, blah blah, things like that as well too. So, like, only if the sender received or updated you actually do this thing. This is really cool because now you actually retain all the architecture of Bitcoin itself because now everything's actually crossed through Bitcoin the entire time. Right? So maybe, like, a router is okay. Well, I know what happened. I'm getting a lot more activity. I'm getting a lot more routing pieces. I'm getting a lot more revenue. That means a really cool feedback cycle as far as the network effect. We're looking at more demand at the at the edges, basically. Use more capacity, which means more running activity, which means more energy, which means more activity as well. I'm really excited about that. So you can shit coin. I could route your shit coin, and we could still be friends. Exactly. You know,   but, you know, indirectly, maybe it's gonna, like, actually improve, you know, you're writing no docs right right revenue as well too. Because you can say, okay. Now with this, maybe we can start positioning against, like, more directly, like, credit cards or something like that. Right? Because maybe people don't want that fiat balance. Maybe they want kind of, like, other currencies, something like that. But now it's okay. Well, Bitcoin line, it can be the massive crossing in network for everything else, kind of be the monetary backbone. You can do whatever you want to the edges, and the the support protocol just stays Bitcoin fully, and and that that makes a lot simpler as well. So you're gonna have to worry about other things, you know, as far as, like, you know, processing, different chains in the internal network, time locks, forks, things like that. That's all a nightmare. So it's the strike pitch but not not centralized?  

Yeah. So so in theory, someone could take this and build a, you know, strike like thing as well. And I think that's a beautiful part about protocols and so then they can open protocols well too. And we published some, BIP drafts. You know, some of them, you know, working with others. Definitely working on putting some additional details, but the idea is anyone can basically start to use this thing and build, you know, the strike in Nigeria or, you know, wherever else they really want to. So it's kind of really the cool thing about open protocols where people can just start to use it and improve it, and then, you know, it goes from there.  

[02:56:02] Unknown:

What's going on in LDK land? I remember you and Andre were lecturing me at Socratic last year about   waking up mobile wallets when they're needed, async await. What's new, man? Yeah.  

[02:56:15] Unknown:

Oh, that's kinda loud.   So, yeah,   our our whole   pitch is kind of to improve the ability of mobile wallets to   But now you want them to add Lightning   and there's not really an option for them. They can start reimplementing Lightning from the ground up. We just talked about how we have 5 years of stuff to do, and all of us have teams of, you know, 3, 4, 5 people full time maintaining a Lightning implementation, keeping it running, and adding all the features,   that we want to add. So obviously, that's a pretty big ask for most mobile wallets. Our pitch is kind of like, here, we're going to do all the hard work for you. You can integrate this. You can run it.   And and our pitch being on mobile means we have to, like, fix a lot of the issues with mobile on lightning today. And anyone who runs a big lightning   payment processor today knows that a lot of your payments fail because they're going out to a node that's on a mobile phone and it goes out and then the phone is not currently on the Internet. It's sleeping. The app's not open in the foreground or the phone's locked and all of a sudden the payment bounces. Because turns out these phones are super, super battery life conservative. Anytime the phone's not on, it disconnects the wireless, it disconnects the LTE modem, and you can get no CPU access.  

So   this is a major problem. You have payments that just fail, you can't actually receive a payment unless your phone is currently open and on the app. It depends on the device, but that is obviously a pretty unusable user experience.   So that's, you know, we were talking about exciting things about, you know, onion messages, and I think there's, as far as I know, the only proposal to do   relatively decentralized or at least trustless   Offline payment receipt in Lightning   was something I   proposed kind of loosely a few months ago, but it depends on Taproot and onion messages   and LSPs. So this, you know, it depends on these things that we have that are, you know, probably a year or 2 out because we have so much stuff to get done.  

And then we can start fixing these more fundamental problems that a lot of people are facing today that that really hurt the user experience of lightning. That really destroy it for a lot of users.   And so, yeah. We we have a lot of work to do.   But but that's, you know, so things are are going well. We have Cash App shipped with LDK.   You know, they we were sitting there talking about mobile, and then Cash App said, like, well, we have all this complicated back end infrastructure. We wanna integrate our Lightning node super tightly with that.   And taking LND or Core Lightning off the shelf and running it is cool, but we want it actually really, like, we want the logging to go directly to our logging service. We want the database to go to the our database service, and we want blah blah blah. And so they built a node, you know, from scratch using LDK, and that wasn't   too hard for them. You know, you just kinda plug the things into the right place,   and they've been pretty happy with it. It seems to work pretty well.  



[02:59:14] Unknown:

That's awesome.   Christian, what's up with Core Lightning and plugins?  

[02:59:20] Unknown:

Can you talk about this CL boss thing I always hear about? What is green light? Can we start calling it sea lightning by the way? Or Yeah. I I I keep slipping up and and calling it sea lightning. But no, core lightning it is. So Hard core. Yeah. Hard core. Yeah.   So, yeah.   Core lightning, has always been sort of the,   the the bit of, the   the Lego block kind of, kind of node where you can, where you can switch out individual parts Or at least that has always been the goal.   And we, we started building out plugins. And some of the functionality that ships with with core lightning itself is actually a plugin. So so pay, the pay command, for example, is implemented in a plug in, and you can swap out the logic relatively easily. And, we've gotten some feedback from researchers that are looking into into how to optimize payments.   And and they could just take the, the pay plug in and reimplement it with their routing logic and, and and basically   experiment with that quite easily without having to have all of the knowledge actually assemble a full node.  

And, we're going a bit further with that, now with a new project called Greenlight,   where we are actually taking the node and exploding it into a different a bunch of different parts and reassembling it, running it on different infrastructure,   the main node itself running on our, on our infrastructure. But the keys are kept on the user side, and the front end is kept on the user side. And so this is this is a different trade off from from what LDK does,   in that we don't try to bundle the note with the with the app itself, but we try to have every every user have one node and sort of remoting in, which allows you to have a multitude of interfaces.   And,   the way we approach the, the issue of,   being able to accept an offline, an offline payment is that as, you can have any number of, front ends, but you can also have any number of signers present. And as long as any of them is present, you can still receive a payment,   an incoming payment.  

And so I think that,   that,   this is this is an interesting setup where we can where we can sort of redistribute   the,   the,   competencies and sort of we specialize in in doing what, what we do best. And app developers don't even have to learn about, about how to run lightning notes himself.   It's one trade off.   But I see a multitude of different ways to sort of redistribute these parts in the future, making more interesting setups possible,   where we can, where we can   actually tap into a multitude of different use cases as well. And this has been ingrained in in core lightning for the longest time. We've all already, always had the HSMD,   as a separate process because we were eventually hoping to to make it a hardware, security module, and now we're doing that step of of going in that direction of actually splitting   parts out and   and distributing,   responsibilities.  



[03:02:16] Unknown:

That's a great segue actually. The next thing I wanted to ask you guys,   no one ever shuts up about WASM.   I'd like to go around and ask how you think WASM   is, useful in your implementation   and how you approach remote signing as Christian was alluding to.  

[03:02:33] Unknown:

Cool. I guess, go this way. Yeah. So WASM definitely very cool. So we actually use it for this new project, that we had called, LNC Lightning Node Connect. Basically, the idea was, okay, like, I want people to have to kind of, like, have, like, a web application to kind of, like, securely connect that outdoor lightning node. I think before, people had, like, these, like, giant QR codes sending out makruins, all sort of roles. So we kinda, like, devised this, you know, protocol, kinda, like, devised off of, something called PAKE. So, like, password authenticated key encryption. So you just basically put in this kind of, you know, like pairing phrase, basically. And you have, like, a secure tunnel from your node into the browser itself. Which is really cool because I you can kinda have, like, a more native experience as far as building web app, keeping it like that as well. So what we had to do with Wasm at that point, we actually compiled, like, you know, most of L and D into Wasm, basically. Because we had a bunch of, you know, crypto as far as, like, you know, ECDH, things like that as well too. And all that's actually now in Go. Right? So we actually have, you know, a bunch of, like we have we have, like, a full gRPC client in Go. We have all the TLS stuff in Go. We have, know, all the Pake stuff as well too. I think it's a really cool way to kind of, like, be able to distribute things. It's kind of like this intermediate,   you can say, like, you know, IR binary layer, basically. Right? So it's kind of cool because you basically have an even language component which is kind of like, you know, single, you know, slightly modified interpreter VM. It can, like, just shoot that pretty easily. You know, for Go, it's kind of like a little bit larger. You have to, like because, like, you actually link the entire standard library, is a little bit larger, but we have a thing now where we're kinda, like, you know, doing, like, a just in time load of it where you can kind of have your own load as well too. Things will be flexible as far as, like, being able to, like, do more things on the web. I think the the dream is kinda, like, basically have, have, like, a fully, you know, Wasm, node in the browser itself have, like, a wide clanks. And now at that point, it's okay. Well, you know, user kinda, like, have, like, a very, like, sleek onboarding experience. They download maybe   I think once you have that, you basically have, you know, the potential to do things like, you know, streaming payments on the web itself, stream for video, you know, do the upvote thing, you know, destroy paywalls, things like that as well. So I think it's going to be really powerful moving forward.  



[03:04:10] Unknown:

Yeah. So, we're definitely looking forward to having some parts of, c lightning running in WASM.   Core lightning,  

[03:04:17] Unknown:

sorry.  

[03:04:19] Unknown:

I keep slipping. And,   but,   but what scares me about WASM is basically that that now it's possible to build to to have a full node run-in in a browser tab. And really want to get into the habit of suggesting users to enter their   seed phrase into a browser tab,   that might be just impersonating   your actual wallet.   But then again, like like said,   it is basically a requirement for for us to have something like a browser extension or something  

[03:04:52] Unknown:

like that. So, yes,  

[03:04:53] Unknown:

we we will probably not run the full node in inside of of a browser window   in the form of, of WASM. But we're definitely looking into having having sort of the, client libraries talking to core lightning and the signers   run-in   a in a Wasm context, be that a browser extension or a or a browser window,   such that you can still   remote into your node, whether that's, self hosted or or or we managed for you. And,   and that's definitely something that, that we need to do if we want to, if we want to reach all, all the all the users that we want to reach. Yeah.  

[03:05:30] Unknown:

So Lalo said that the the dream is to to maybe eventually have a a lightning node run-in Wasm. So so we have that. It works.   You can you can take LK. You can run it in Wasm today.   We've tested   running some nodes in the browser. It's super lightweight.   It doesn't it doesn't weigh anything as long as you're not downloading the full graph data. So if you you maybe have a smarter way of doing routing,   and you're not routing a lot of payments, you're just like a personal node sending and receiving things. It's super lightweight, it costs nothing.   The Wasm binary is pretty small.  

So, yeah, it works great.   You know, we LDK doesn't take any stance on   whether people should do things. We just provide the tools that they can do them.   You know, certainly there are   obviously, run you know, down having your keys for your Bitcoin in a website tab is pretty sketch. Having your keys for your Bitcoin in a Chrome extension or   in React client where it's actually a   JavaScript web platform but a separate application on your computers is maybe a very different world.   So so yeah. We we do that. We support it. You can take the whole thing and run it in a in a web browser if you want.  

[03:06:44] Unknown:

Cool. I I don't handle, like, Bitcoin access PP network? Is that kind of an RPC thing in that context? Or Yeah. So so LDK does not  

[03:06:52] Unknown:

we have some some, pre built things that you can sync the, the chain via, like, Bitcoin Core.   But we otherwise just have a general interface for, like, hey, provide us graph data. And there's actually 2 different interfaces. There's one that's more like, and then there's one that's more kind of like Bitcoin core or like full node like.   So you can kind of like however you want to sync the blockchain, we have an API that's like pretty similar to the way you're already syncing the blockchain, and you just kind of feed it chain data. Okay. And then we tell you what you need. Can you serve it over DNS yet?   Full Blockchain data over DNS? No, but you can download the Headers over DNS. I do run a service to do that. So that's also fun. Or over wireless.  

I don't know if NVK is here, but he he's been doing, like, Bitcoin stuff over ham for a while, so you could do that too.   That might not run-in a web browser, though. Yeah. Ham ham radio is gonna be hard to run it. How do you get to the web browser tab to talk to your satellite dish? Yeah. That that might be hard too. You need a dongle?  

[03:07:48] Unknown:

Right. You know, one type of thing about, like, kind of like layer, like, kind of protocols. People know about the Nutrienne protocol. It's kind of like a way to do, like, like, clients on Bitcoin. And the cool thing about it's actually kind of stateless. Like, the older protocols kind of, like, had you kind of, like, communicate with a node and kind of, like, you know, mess these filters interactively. But this, I basically download a filter. Right? So now, like, you know, one cool thing you can do with that is, okay, well, I can put that on like a CDM, maybe HTTP 2. I can download the headers, the filters on the blocks, basically just over the HTTP system itself. That's really cool because now, like, the browser already do HTTP. It's kind of harder to do kind of, like, you know, more advanced, like, you know, you don't really have, like, raw TLS, or TCP talk or something like that. So it's actually just, like, kinda, like, have that and download all the data over HTTP. It's gonna be super cache everywhere c n wise, so that could be like a cool way to kind of, you know, kind of navigate from the trade off security wise where we're okay. Like, we don't want people just to hidden, you know, some massive API like Metamask or something like that. They can actually get the data. And the cool thing about pow is, like, you know, it's objective. You can verify that, you know, you can verify the hashes, what are the numbers, you know, things like that. So it's a little bit, you know, better as far as security monitors compared to like everyone using, one centralized API that can just lie to you because there's no really assurances, you know, with, some of those other systems. Oh, yeah. I also provide the the bit 157 header chain via DNS. Oh, gosh. Oh, gosh. I downloaded that over DNS. You could do that guy. I forgot about that. Yeah. I mean, I I I find it really interesting how we, how we sort of started out with, with this, with this really small set of of transport protocols. Mhmm.  

[03:08:58] Unknown:

And, by the way that that that the Bitcoin metadata is structured, we can actually just swap out the the transport layer and, and offer different services,   DNS Yeah. Or HTTP  

[03:09:10] Unknown:

or, well, the Bitcoin protocol. Yeah. And, like, you know, in the people, I'd say, in the Bitcoin, it kinda, like, evolved that way, but there are other ways to do it. Like, for example, Matt's done a bunch of work in the past before he's, like, improved block properties, things like that as well too. So, like, you know, protocol work is just it's super fun. I mean, there's just so many things we can do. It's just  

[03:09:26] Unknown:

kind of, like, you know, all these puzzle pieces. Gotcha. So I think we all are grateful to wear bolt 11 got us.  

[03:09:33] Unknown:

But Some of the stuff I've learned.  

[03:09:37] Unknown:

You know, some of the application developers have even taken it into their own hands with certain things like lnurl,   lightning address.   I know right now there is a priorities contention going on,   between Bolt 12   and AMP.   Can you summarize   AMP   and maybe when or if we have a spec for it and the trade offs? Spec?  

[03:10:01] Unknown:

I mean, yeah, there's a spec, it's just kind of a little bit dated. It's actually pretty up to date now, but like, you know, AMP is basically people probably heard of KeyCents, which is kind of where you like spontaneous payments, you basically push payment over, right? That works by kind of including a preimage in, like, the onion pill which encrypts the endhop, and they basically decrypt them, and then they use that preimage to settle the actual payment itself. Itself. AMP is kind of like, you can say like the multipath analog of that. Multipath payment is basically a way to kinda like split people up in different pieces. This basically uses kind of something called secret sharing. So basically, I take the pre which I I, you know, kind of, like, extort it into a bunch of different different shares. I send you all those shares, then only after you have that final share can you extort it back. Basically, you get the pre which is everything else like that. Right? So So it kinda gives you, you know, push payments in, like, a multipath fashion. Right? And the one thing it has as well too, like, you know, given that, like, the the actual center's gonna actually make the preimage, you can have, like, a static invoice. It's kinda, like, you know, fully enclosed. Right? So, basically, given the invoice, I can just pay it over and over again. So, it works by kind of, like, having the identifiers. So you have, like, a payment address, or, like, payment secret, basically. We call it a set ID. So, like, you know, you this is, like, now your main identifier, and then every single new payment actually has a new set ID over there. Right? So it basically gives you, you know, spontaneous push payments, but also kind of like a a reasonable, you know, invoice around itself. And obviously, the bolt 12, you know, but 12 has a lot of other stuff, you know, with it as well. So Ambulance is kind of like, you know, okay, do the payments or whatever else. I think, you know, book 12, it's kinda to me, it's kinda like an invoice negotiation protocol. Right? It has a bunch of other things as far, like, negotiating invoices, all of this, like, option or, you know, refund stuff. You have this new format, things like that as well too. While this one is something that we can be deployed today because it kinda, like, just mostly, you know, at the edges. And obviously, like, maybe, like, you know, an address change in Bitcoin took a while to actually, you know, you know, work properly. So maybe the bolt 12 step back has a little more of a barrier, and there's other things that kinda, like, have, you know, similar functionality to ln and r overalls. I guess it depends on kind of the trade offs. If you want something that's more opinionated in the protocol or if you want something that's a little bit more at the edges, then people can maybe do what they do. Because things like l and address or whatever else, like, you know, people can update those on the fly and just release a new version versus kinda, like, you know, requiring, like, larger changes as well too. But, you know, Bushwaddle has a lot of cool stuff into it, but I feel like, maybe we can break it up and kinda, like, you know, do it a little more quickly and then see exactly how the use cases, turn out, like, you know, talk to the people via, you know, well operating services as well to see exactly how things can evolve in the future. Is it true that the main differentiation  

[03:11:54] Unknown:

is AMP doesn't have, like, a proof of payment? That's what I often hear.  

[03:11:58] Unknown:

Yes. So   I think to me I think the whole proof payment thing, it depends on what you mean, because I feel like I've been using Lightning for a while now. I've never had a thing where a service is asking for a preimage. Does it even know the preimages?   You know, is there even actually, like, a standardized format as far as, like, you know, actually serializing what a preimage is itself? So I think it really depends on what you want there, but that is true where, like, you know, I know, Boat 12 has a way you can worry. I think there's, like, a sender key, and you can use that key basically to, like, sign something to basically prove that you paid it. Well and because it's spontaneous payment, you know, there's not kind of, like, a way to, like, give you that capability. But once you add things like PTLCs, there's actually a way to do that because then you can   like, have a key in the invoice and kind of, like, add that to you the payment that you're sending out, there as well too. So kind of thing where where, like, you know, this is better for maybe something like a donation where I'm kind of, like, you know, pushing you money, maybe the kind of streaming thing. Maybe if I'm doing something where, you know, I want recourse, maybe, like, you know, I need, like, a shipping number or something like that, maybe you need that as well too. But I feel like at this point, I think this course is kind of missing that. I haven't really seen, you know, anything like that. Because I feel like, say people are There are some other, like, the You're probably asking for an invoice number. Right? And then you can go from there. If you wanna do an external signer, a verifying external signer, you need proof of payment. So actually, AMP and key send,  

[03:12:59] Unknown:

are   basically break stuff like green light, in, like, a secure model. Or if you or if you just wanna have a hardware wallet that's doing actual signing,   you need to not have that pre image in the onion.  

[03:13:10] Unknown:

Otherwise, you you have to, like, do more hops to have the onion decrypted on the thing. It it it's a lot more painful there. Yeah. I feel like for me, preimage is one of the things where it's I think us as developers think it's cool because we actually have a thing, thing, but then I feel like practically I've really seen people really demand it that much, which is because there's that extra step of, okay, how do you serialize it, how do I interpret it, versus just telling them, you know, what's my invoice number, which is probably what you're doing anyway. But I think it's definitely cool for me. I feel like we need to, like, you know, mature the concept basically and just, like, say, okay, what do we exactly do we need? People know Connor, who, you know, needs to provide stuff. You have this massive matrix, basically, you know, there's basically some type of payment. Right? For example, like, if I have the preimage, that proves that, like, someone paid maybe gave me the preimage, that doesn't really prove that I uniquely paid. You kinda, like, maybe need some digital signature scheme along that as well so that it's okay. Well, I have the preamble and I have the signature that's approved so I can pay as well too. But I think there's kind of, like, you know, a gradient as far as, okay, well,  

[03:13:58] Unknown:

proof payment as check reimburse is paid. There's proof payment. Okay. There's like a cryptographic proof basically that no one else could actually forge or produce. So definitely some nuance there. I think that's There's also just very different. Like, what what are you trying to accomplish? Right? There's, like, are you trying to do donations? In which case, like, key send AMP, Bolt 12 are all options. Are you trying to do, payments to a store? Well, key send and AMP aren't really, like, Bolt 12 or like Ellen URL or Bolt 11, but no one wants Bolt 11,   are options. You know, are you trying to do a payment to, like, a non custodial mobile? Okay. Now you need, like, Bolt 12 and then maybe some extensions on top of that, And like, lnurl and keysend in the app. Don't   do anything for you there.  

There's a lot of   different potential things you want to pay, and different ways you want to pay in from different clients to different clients. And Bolt 12   forms a good base to build basically all of those. But then there's also, you know, more immediate term for different specific use cases.   There are good solutions like lnurl is great if you're paying someone who runs, like, an HTTPS server, like a web store. You know, keysend,   is is great for for donations.   AMP is is cool, but I'm gonna say something a little controversial. Oh. MVP doesn't actually really matter.   Payment doesn't matter. Does not make a big difference for for payment success, for payment I don't know about that. It it like, the your your biggest concern is network flow. But, I mean, but but you can say, like, there's certain payments that you can make with MPP that you could That is true. Yeah. Yeah. That is true. Those are yeah. I mean, do are you are you donating   $10,000?  



[03:15:28] Unknown:

Or just someone has fragmented payments. Doing a payment for $10,000. You might be. But specifically in the donation context. In in in the donation context, I I do have a point. I do have reason to to to want a proof of payment by the way. I I want to be able prove to my tax office that I agree. I just want to prove. Another another complication.  

[03:15:48] Unknown:

But for for for most for the most common values of lightning payments today, MPP doesn't really make any sense. For smaller amounts, def and I think it's always an interesting thing where, like, you know, we had MPP, then we had 1 boat. Now you have, like, really big there. We have, like, 1 or 2 MC channels as well. So, like, if I'm sending 1 strategy through, like, a 200,000,000 strategy channel, probably gonna work as well too. But I think the interesting part of MP is, like, you know, people are trying to do kind of, like, more, you know, complex kind of flow analysis for, like, you know, trying to have, like, the optimal route of, like, you know, particular, you know, things like that as well too. I think that's really cool in that domain. But sometimes, maybe, you can probably just try it if it's a very small amount. But I think once you get, like, much larger amounts, basically, you know, people doing, like, 1 b to c plus. Maybe they're doing, you know, things like loop like moving, you know, larger upfront around it. I think maybe that's more. There's kind of, like, a theoretical thing where you can say, okay. If you can split the payments, enough liquidity exists. In theory, you can get there eventually. But eventually, maybe, is a good UX wise. The bigger problem is the flow is the question. The the whole idea of of of doing main cost flow from from is basically based on as as you approach the minimum cut in the network.  

[03:16:41] Unknown:

When it comes to liquidity,   you have to have to get more optimal.   If you if you have a min cut that that is basically like 3 bitcoin and you want to send 10 10,000   satoshi,  

[03:16:53] Unknown:

Yeah. I do the work. Yeah. But If if I approach that, that min cut, you you basically are forced to to become very clever. The problem is if you approach that min cut, suddenly, it doesn't like, the your individual payment doesn't matter. It's the total flow through the network. Right? You have so much flow through the network that the gain the the relative gain of doing   something more complicated for an individual payment is substantially less. Like, you just your your payment has to be a small fraction of the total flow,   and thus, you don't really and because it's a small fraction of your total flow, you don't have to be quite as optimal on the individual payment.  



[03:17:29] Unknown:

Yeah. That that's true. But, interesting enough, your own capacity and the capacity on the recipient's end is usually the the actual main code. Right. So so if if you if you had a negotiation mechanism,   onion messages,   where you could sort of gossip this information back and forth. You could potentially  

[03:17:47] Unknown:

figure out quite quite quickly if a payment is possible at all because Right. It's either you or the recipient who is going to limit your capacity. Right. Or similarly, you're, like, you're MVP ing just based on your channels. Yeah. But, you know, I think as Matt said as well, like, payments have a lot of different parameters. So maybe, like, depending on the payment size, depending on, like, in latency as well. You know? I think there's gonna be, like, in the future probably different algorithms people will choose based on maybe payment size or kind of their own parameters. And it's kind of like a wide open thing where it's like, you know, you can do whatever you want, basically. And I think the cool thing is, I think, intent wise, as your algorithms algorithms are developed, maybe the routers themselves, like, are which is, like, more or less depending on the be which, like, you know, the client's getting smarter. So, okay, like, you know, is the edge gonna get smarter or kind of, like, are their internal routers gonna get smarter and smaller? Like, you know, manage the liquidity better, deep, you know, the balance as well. Definitely, you know, still really wide open, I think, and really cool to see, like, you know, more research in this area. Because, like, you know, this is the kind of thing I can say probably have the most leverage, increasing payment UX basically in speed and latency. That just makes it work, and that's what makes it, you know, seem magical. So so as as Samantha was pointing out before, there there there is a wide a wide spectrum of of different preferences users might have when it comes to payments. Right? If I'm, if I'm if I'm standing in front of a point of sale, I really do care about latency. I don't want to be there waiting for for a minute or so until my my payment goes through.  

[03:18:58] Unknown:

If I'd, if I'm interested in just doing some exploratory probing,   I don't care about latency.   If I,   if I care about, about getting the cheapest possible payment,   I might spend some more time actually computing the, the the the optimal route there. Mhmm.   Or if I'm   if I'm just interested in making sure this payment   goes through no matter what, then, then I might use a different, different algorithms.   And   there's not just the algorithm side, but also how do we expose that to users in a in a in a understandable fashion. Yeah. So for for example, we always took the stance that users shouldn't care about,   about fees too much. We,   before each payment, we give the routing algorithm. We give it a budget,   and it's free to do whatever it wants to do inside of that 0.5%   budget we get we give that algorithm   and part of that we actually use for for skating our roads by increasing c l t b's by basically   by by allowing ourselves not to take the just the cheapest route because   cheap cheap routes are easy to predict if Yeah. If if you see a partial payment and you know, oh, that's probably from this guy because I am his cheapest path. So  

[03:20:13] Unknown:

you're leaking some information there. Yeah. I think that's interesting for it as far as like cheap payments and privacy. For example, like, you know, they're kind of like these like 0 fee nodes, like not basically like completely 0 fee. And I think the interesting thing about it is they're kind of like a black hole because they circle payment attempts. Right? But if I was wanting to kind of monitor payments, wouldn't I just have completely zero fee notice as well too? So maybe you should want to avoid them because, okay, skin in the game. I would pay you to, like, you know, have some signal that you're not just collecting my stuff. So we go negative fees maybe? Yeah. Like, are you selling my data because it's 0 fee or something? Like, I don't know. Like I mean, yeah. Like, I expect chain analysis to properly cost what my payment and what my payment anonymity is worth to them. And if they pay me enough, I will de anonymize myself to them. Yeah. Yeah. They just I need them to pay me. So Yeah. I I would just stream my logs to them.  

[03:20:54] Unknown:

Well, how does that affect,  

[03:20:57] Unknown:

I guess, the channel DB? Because if there is, like, 0 fee, you're doing more payments. Right? If you're logging all that info I mean, you're getting forwarded more, probably. Yeah. Exactly. Or getting more forwarded. So there's nothing in lightning that, you know, you need a sufficiently sized disk, but it's a small amount of information per channel state update. And there's nothing and the total size of the things you need to be, like, actively dealing with as you update the state is constant size. So there there's no real scaling issues there in terms of history and logic. Funnily enough, the, the There are some application issues that need fixing. But sorry. Funnily enough, the the more limiting factor here is having to touch the disk at all. Right.  

[03:21:32] Unknown:

Having having to basically just flush out to disk and make sure that all of this data is actually written to disk, even even a relatively quick, SSD nowadays, that takes time as compared to just operating in in RAM. And that that is one of the reasons why,   why onion messages was created because,   the,   onion messages do not have, have to have   the node touch the disk at all. You can basically forget all of the information that an onion message told you. Maybe a reply might fail if if if if you're restarting in between.   But, but basically just removing that extra load that is currently used if you do   communication via key send or similar protocols,  

[03:22:14] Unknown:

is, is is a huge win already for us. Yeah. And I I think one open question that when I knew I was, like, you know, some people were saying, okay. Well, should it be free? Should it be priced? How do we, like, rate limited as well too? Because, like, at least, like, you know, attaching HLC, there's kinda, like, some cost. You know? Obviously, it's not the most efficient unit in the world, which is kind of a thing where it's like, okay. Like, you know, if I wanna be forwarding, you know, all of these, like, images or videos for free, basically, can I, like, charge for that? If if you can charge for the main business, it turns out, like, can now all of a sudden, like, it makes you, like, you know, make money off of routing, but you also make money off, like, forwarding bandwidth as well too. Let's not. Let's not. Bandwidth is a cost to light. Oh. Yeah. But the cost is already there. Every single payment is 1.3 kilobytes already. Right? So The the main device is trivial. Yeah. The main problem with, with, basically saying that PSEN has a cost. It has a cost, but the cost is more in 20 x by the network itself. The cost is mostly the wear out of my disk. Yeah. Yeah. Yeah. So so it's it's not like imposing a minimal cost to the sender of of a key send message,  

[03:23:09] Unknown:

makes it makes it so much better than than an audio message,   because the cost that this on that that is Keysend, is is having on the network itself is much much much greater. Yeah. And part of that is having to touch the disk, part of that is disk square, part of that is having to keep state across  

[03:23:29] Unknown:

over time Sure. Until the channel is closed. Yeah. But then, you know, you can raise, like, your mini HTLC if you say, okay, well, I want to do one more payments alone and things like that. But I think it's just, you know, worth at least kind of, like, weighing some of the trail from Like, they're gonna have a cost where it's okay. Like, free forwarding of messages. Like, maybe we try, like, an OC incentive wise. Can we wait a little bit of that maybe with, like, kind of, like, some, you know, congestion algorithm or we actually charge for App and Gecko. But if you can charge for it, maybe that's just, like, supplemental income as well too. Maybe you kinda, like, get this whole new new Internet, you know, thing from, like, Silicon Valley,   along along the way. Oh, we need that compression audio. Yeah, exactly. Get it loud, dude. That'd be nice.  



[03:24:01] Unknown:

Well, mid length. That's all, folks. We're done. Oh, but oh, we're right out of time. Time where it is. I didn't see that. Yeah. It is still counting up.  

[03:24:12] Unknown:

Yeah.   I I guess before we head off,   seems like the whole Lightning Network is mainly just Umbral people. Do you have one thing you wanna tell them, if anything?  

[03:24:22] Unknown:

Like the plans or the node runners. Yeah. I mean, hey. You know, we love y'all, basically. Right? Like, you know, I think it's really cool to kinda, like, have, like, grassroots community of people helping each other out, kinda, like, you know, spreading up knowledge. I think it's kind of a cool hobby. It's, like, oh, I'm, like, doing my part basically for the network compared to kind of, like, just, like, maybe something that isn't really contributing at all, or that's just kind of, like, you know, more, like, speculative or something as well too.  

[03:24:41] Unknown:

We we we need a world where we have a lot a lot of those to balance out the fact that we're getting increasingly more of these large,   you know, custodial sort of like cash up or whatever running very large nodes. Like, we need Absolutely. We need lots of to  

[03:24:55] Unknown:

to balance that out. Yeah. Yeah. So keep doing it. Definitely. Feedback from ClubNet has been awesome, and we need more of that.   This is where this is what gets us gets us going. This is what basically helps us develop lightning further. And this is the feedback that will get us, get us to a place where, where all of this is actually stable and not siloed into some weird big company.   So,  

[03:25:20] Unknown:

keep on doing it. Yeah. The users. Yeah. We're here for the users the other day. Yep. Well, awesome. Thanks, guys. Cool.  

[03:25:28] Unknown:

Good one. We're here to talk about defining the standards of taproot and multisig.   Why don't we start by doing a quick introduction for Emily across the  

[03:25:36] Unknown:

stage? Let's start with Keith. Alright. My name is Keith Mukai. I'm a contributor to the seed signer   DIY hardware wallet and the Spectre desktop, open source Bitcoin wallet software.  

[03:25:48] Unknown:

I'm Jamieson Lop, cofounder and CTO of Casa. We help people be their own bank,   using   multisignature   aspects of the protocol.  

[03:25:59] Unknown:

Hello, everybody. I'm Stic. I'm cofounder of Satosh Labs, the creators of Trezor, and I occasionally,   occasionally   contribute to Bitcoin Core as well.  

[03:26:11] Unknown:

Hi. I'm Oli. I'm with Lightning Labs on infrastructure   stuff.  

[03:26:18] Unknown:

And I'm Ashin. I'm the VP of engineering at Unchained Capital, a collaborative custody financial services firm.   Alright. So the reason we're here today is that all of us separately have an individual need for multisig and the products that we offer to customers and to software users.   But all of our needs are a little bit different. And   before Taproot, there was a pretty standard way for implementing multisig using op check multisig and op check multisig verify.   Now that BIP 3 40, 341, and 342 have been activated and Taproot and Tapsculpt are live, there's a sort of new way of doing things. Actually, there's several new ways of doing things.   And   there's no real hard standard to find. There's a bunch of different recommended paths.  

And as all of us were evaluating which path to go forward with, each of us encountered a different set of trade offs. And we want to talk through the trade offs that we experienced, that we ran   into, and how we all came to a sort of consensus, if you will, on the way forward for implementing multisiv untapped root in the absence of a standard.   Actually, let's talk about that for a bit, the absence of a standard.   There's, like I said, 3 bps, 3 40, 3 40 1, 3 42   that govern the Taproot, Tapscreed upgrade.   There's nothing in there per se that draws a line in the sense that this is the Taproot way of implementing multisig.  

Do you think that was an error or an omission? Does it make sense to have a BIP? Does it not make sense to have a BIP? What are the pros and cons there? Yeah. I mean, that that's  

[03:27:45] Unknown:

Keith.   The only way to go is,   the the BIP   approach is for when   everyone needs to agree for this thing to   work. But in the Taproot world,   we're adding so much flexibility   that it doesn't make sense to say this is the one and only or the one of the 3 only ways that you can go.   You know, without getting too technical, it's like the old world was   it it's a it's a train. You get on at a stop, you get off at a stop, but it's on rails and we all know where it's going and how it works.   And now in the in the tap were tap route world,   it's more like,   if you flip to the, the public transit tab of Google Maps, you know, and it's like, oh, you can walk a mile, take bus 10, hop on this train, and get your destination. Or you can ride a bike, 3 miles, get on this bus. Right? There's so many different ways that you can go,   and there's no way for any of us or the core developers to say   this is the one way that you need to go.  

And so all we can do is figure out,   you know, for each of our individual use cases   what's the best way to go and make sure that we don't   lock people in to a dead end path they can't escape from.  

[03:29:06] Unknown:

I mean, this is the reason why we're here, I think, is because we're seeing parallels,   at least I am,   with our users where if you were around and you were building   during the SegWit activation period,   there was a rallying cry from a lot of users like, win SegWit, win SegWit, win SegWit. And that was fine because   I've   seen developer teams at multiple different multisig companies   implement   SegWit version of multisig with a handful of developers in maybe 1 or 2 weeks.   And it's straightforward.   Really, it's like from a script   perspective,   it's pretty much the same as doing old school legacy P2SH.  

And so now   what we're seeing, of course, is   users   with the rallying cry of Win Taproot, Win Taproot, Win Taproot. And unfortunately, it's just not the same, straightforward path,   as we'll get into,   with a deeper dive here.   This additional flexibility   that Taproot gives us is great. But whenever you have additional flexibility,   take for example,   extreme example of,   like EVM smart contract   style languages,   that extreme level of flexibility   creates   a huge   design space.   And when you have a huge design space, that means there's also going to be   a lot of foot guns   and ways to implement things poorly. And we want to   prevent people from running into too many pitfalls.  



[03:30:46] Unknown:

Right. I I think you captured   that   very nicely, Keith. And,   why I'm I'm here is that we   we had this discussion earlier with,   James and and other people from,   Angel Capital   that we want to get into the room together and try to figure out what are the best options, for for everybody. I mean, the   the organizations that need MultiSig for their businesses to thrive   and hardware wallets, creators so they could can be used in this complex setup. And it wasn't very very straightforward   to to see which options to to choose. And what I really like about Bitcoin in general that there is this,   there is this, not this approach of design by committee and everybody's just, you know, using what the committee came up with, but there are these discussions and part of this discussion is happening right now. So  

[03:31:42] Unknown:

yeah.  

[03:31:44] Unknown:

Yeah. And the results will probably be just a list of new VIBs and proposals   and yeah. So   just just  

[03:31:53] Unknown:

grow. Yeah. And I think I'll add to Keith's statement. It would be nice to have a BIP in theory and practice, just the process of going through drafting a bit, and getting consensus from all the different stakeholders.   We've taken a tremendous amount of time with no clear path forward. I think any dip that we would all come together on, even if we were all in unanimous agreement, would be status informational.   There are several different ways to skin this cat, and I wanna dive into that now actually.   I'm thinking of first off the trade offs that James and you must have been thinking through at Casa versus Ali with lightning.  

For those of you, I mean, it's easy to think of lightning as payment channels in a gossip network, but at its heart, it's multisig. It's,   construct between yourself and your counterparty.   Casa's the same way. You've got your customers and you've got Casa.   I mentioned in talking through the different trade offs that you   encountered and the migration path because you both have existing products and existing customers using multisig.   How you envision the path forward for them and enabling Taproot for your users?  

[03:32:52] Unknown:

Yeah. So, you know, Lightning, you're essentially getting   a 2 of 2   multisig   smart contract.   And   these are generally   between 2 different parties. Obviously,   one party on each end of the channel. And it's a highly interactive type of protocol. You're generally expecting   the other   end of that channel to be available   and communicative   and so, you know, you can send messages back and forth with each other.   However,   in a   vaulting solution, you know, something that's more cold storage,   where you're going for an extreme level of security at the expense of convenience,   then you   can't really have the same   high level of interactivity.  

Basically when you have more interactivity,   that means you're probably gonna have to be going back and forth and back and forth between   either the different entities or just, the different key holders   in that particular Vault.   So one example   of a problem that we would run into with interactivity   and a larger   multisig quorum, say something like a 3 out of 5 or higher,   is   you may not know   when you start to sign   a given transaction,   which of the other keys are going to be participating   in that transaction.   And if you don't know which keys are participating,   then if you start going down one of the potential design paths for Tapscript,   which is trying to be more efficient and more private and creating all of these other logical branches,   you have to know exactly which one of those leafs, like all the way down that logical path you're going to be going   because you need to be signing that data and all of the keys need to be signing that exact same data. So   if you change your mind after   signing with 2 of the keys,   now you're in a lot of trouble   because   you now have   a partially signed transaction that's not going to become valid. You have to go back, start all over and get that different   Tapscript   path   and sign with however many keys that quorum requires. So that's just one of the potential   considerations which   it's not gonna be a problem for something   like Lightning,   because   if you have to start over again, it's not a big deal. We're talking   milliseconds, maybe seconds of lag  

[03:35:31] Unknown:

time. Yeah, exactly.   As you already mentioned, the situation   is pretty,   given in in Lightning that you have these 2 parties that communicate anyway. They're they're supposed to be online to to, establish the channel. So you can just add this,   non exchange,   a few new messages, or maybe not even new messages, which is the new data in existing messages, and you can come up with music   multisignature   pretty pretty easily. In fact,   there are already quite   concrete   proposals out there, either mailing list posts or even pull requests to   the vault.  



[03:36:15] Unknown:

Oh, sorry.  

[03:36:18] Unknown:

No. Yeah. Okay.   So there,   requests to the Bolt spec, and, basically, the decision to go with, music 2 was   an easy one. So there are a few places in in Lightning where this can be applied. The most obvious one is the 2 of 2 multisig for the funding transaction.   But there are other signatures in the protocol for the gossip, for example,   and also some of the revocations   pass could be music to set up.   And there, I guess, the main   goal is to,   get some additional privacy because you no longer have to   reveal what keys were were participating,   and they also get a nice benefit in the size. So, for example, in gossip, you can there are currently 4 ECTSA signatures that could potentially be cut down to 2 or even a single one depending on the,   use case. Yeah.  



[03:37:20] Unknown:

So what I'm hearing from you, Jameson, is the liveness and availability and coordination issues made mUsig   not the preferred option for you. Whereas, since these aren't an issue necessarily for lightning counterparties,   MuSig made a bit more sense. Right?   Yes. Exactly. I had a whole thing about, how the other consideration with USIG was, that hadn't been standardized yet. And this morning, a USIG 2 draft PIP was submitted, so that's out the window. I   guess we'll have to review it after the after we get off the stage.  

[03:37:50] Unknown:

Yeah. And and that's basically   it how,   the the lightning   the development stage looks like. It's basically waiting for music to be finalized, waiting for music to be implemented,   And then, I guess things will move forward from there. Yeah.  

[03:38:07] Unknown:

And I'm curious, Pablo and Keith,   Did you did music factor into,   your software development or hardware development plans at all from the start? Did you decide to take a different route   when you were evaluating things? Yeah. Maybe I can start.  

[03:38:22] Unknown:

We had this discussion with Jameson and he already, like, hinted at it that the main problem with this   more complex scheme is interactivity,   and the problem with the hardware wallet is this usually usually offline.   And,   it can be connected,   for a limited amount of time.   And, if something goes wrong with the setup, maybe you just change your mind and you want to use different set, then you need to start again.   And, especially if your hardware wallets are not located in one location, but they are spread around the world, then this might become a problem.   So   the most straightforward option is to use the simplest   Hopi checksig ad using KFM   keys, which is, like,   a straightforward upgrade from what we've been using earlier.  

And the other option is to use,   second option described in the BIP 30,   342   document,   which,   describes how to use several k of k multisects.   But then you have to to choose   which k of k setup we want to use, and then there are a lot of,   a lot of user experience challenges.   So if the setup is too complex, you need to present it in a way that the user understands what they are choosing from.   And also,   also,   again, if you change your mind, you need to you need to start   from the beginning.   And there are also ways how to use   music,   and, there were other,   other implementations of music that uses   nuances,   and this   also was an option, but it seems the world is getting into music 2   music 2 option, which still can be used with hardware wallets,   but   under certain conditions. For for example, if   the the hardware wallet is the last signer in in the chain, so it sees   everybody else commitments and signatures that it can participate,   but that's   not probably the use case for,   for businesses like like Casa, where somebody needs to start the chain of, signatures.  

So, yeah, these are the considerations.  

[03:40:50] Unknown:

Well,   I think at the end of the day, the hardware wallets are gonna have to support all the options.   We may be able to prioritize on the easiest, which is   replicating the k of n world,   you know, in in the Tapworld,   Tapscript world,   but that's the least satisfying option. And that's just taking what we already have and just doing it a slightly different way, but not really getting any of the benefits that we were all excited about for Taproot.   Like for for seed signer, the goal is always optionality.   So we don't have a single   user in mind. We don't have a single use case in mind, and, you know, I think that's probably likely for all the hardware wallets.  

So   while we will have to prioritize   which approaches we support first, I think the long road in the long road, we just have to support all of them.   And, you know, there's no free lunch. Like, if we want some of the benefits,   there's gonna be a part of the user experience that's just worse just because of the nature of it. So   like with, between seed signer and Inspector Wallet,   with with this discussion of, you know, picking the right k f k path,   for this option 2,   we could have the Wallet software   send all the paths that you participate in, and you just sign all those paths.   But if that takes 2 minutes for your little, you know, $50 device to sign, and then on seed signer, you have to hold it up to the camera because it communicates over QR codes. So like, if I need to show 500 QR codes back to my laptop,   you know, I'm gonna get a tired shoulder. But   if that's the way to do it, that's gonna be the pain. But but it'll be up to the user to just to decide that their that level of pain is worth it for them.  

And then the same thing with music where,   yeah, if your if your seeds are, you know, buried in different countries,   and you need to do, you know, 3 rounds, like,   I either get a lot of frequent flyer mile miles or that's not the best use case for for that approach.  

[03:42:55] Unknown:

You touched on something there that I wanna dig into, if you don't mind. So,   theoretically,   or they're both hardware WAD devices, hardware signing devices. Mhmm.   But under the hood, you're running on top of a Raspberry   x86,   and you got a PCB and a build materials to worry about. What's the difference between the software development life cycle and hardware development life cycle, and what impact did that have on your implementation of multi site on Taproot?  

[03:43:24] Unknown:

Yeah. So,   at first, we thought that the CPU power might be the limiting factor, but it seems that's not really the case.   We use USB communications,   so we   we don't have to deal with the problems,   like you mentioned, with the stability of the QR code transmission.   And,   so that's why we focus mostly on can focus mostly on the usability   side of side of things, how to present it, on on the computer.   Sorry.   And   I I get lost lost in trend of thought.   So   can you please repeat the the question?  

[03:44:14] Unknown:

Like Sure. So Yeah. Keith gets to run his code on Yeah. X86 standard software. You actually have to Mhmm. Get printed circuit boards and bake your code in silicon and deal with a supply chain that Keith doesn't have to worry about. I'm wondering about the trade offs that,   both you had to deal with when choosing   what method of multisig to on tap you to implement   and the ship time between when you made the decision and getting in the heads of your customers?  

[03:44:41] Unknown:

Yeah. Yeah. So so so like I said, we initially thought that this might be a issue, but it in the end, it turned out that that's that's   that's a nonissue, that even even our processor that is maybe 10 times slower than than the Raspberry Pi still have plenty plenty of of power to  

[03:44:59] Unknown:

students. So this, doesn't require an addition to the the hardware itself? It's it's also just a firmware that can,  

[03:45:06] Unknown:

like, music can just be implemented on top of the existing hardware then. Yeah. Yeah. And, also, we we have this advantage that we can ask,   for for the data   again and again and again and again. So the the memory limitation is probably   not not that big of issue because we can we can stream the data,   hash it, maybe compute the Merkle tree, and then if we need, it again,   then we ask for it again and compute the Merkle tree if we were served the same data. So we can circumvent that problem by   asking it again, which is not a problem since we are using fast,   fast connection.  

On the other hand,   you at C Designer, don't have the problem with RAM because you have plenty of RAM. So  

[03:45:52] Unknown:

you have other things to worry about. Yeah. We're we're running on the what used to be a $5   Raspberry Pi 0, and now they're impossible to find in the market. So sky's the limit for what they cost on on eBay now.   But we're also looking to expand to   alternate hardware profiles. Because   if you can't source a Raspberry Pi 0, you can't build a seed signer, so all the work I'm putting into it, you know, isn't helping anyone.   And   I I don't think our approach to Taproot would affect our hardware choices. I think it's more that   the hardware that we end up supporting   will affect the user experience.  

And   if you're a user that can only source, like, a really weak chip that we support, then you'll just have a bad experience. You'll be waiting a long time for computation,   but it'll work.   And I think it's just, you know, like I said, optionality. If you can if you can buy the the Cadillac processor, good for you. If you can't, it'll be spinning a little while longer.  

[03:46:52] Unknown:

I guess, kind of related to hardware,   have you played around with or are you familiar with with, like, what are the actual bandwidth limitations when it comes to the animated QR codes? I'm sure, like, the the quality of the screen, the quality of the camera.   I mean, a screen is only gonna be able to refresh so often.  

[03:47:11] Unknown:

Yeah. So and it it goes in 2 directions.   So so far, the Raspberry Pi camera has proven to be really good.   So Inspector for a big PSVT,   it shows an animated QR code. And however many frames it takes, it reads in the animation.   But to prepare for doing demos today,   I printed out the QR code as a single static image, and so it's much bigger.   You know, it's like I I can't I don't even know how many, you know, QR blocks across,   it was. And   the the Raspberry Pi camera could still scan it in. You know, it was like a a one of 2   spend to 3 recipients with change coming back, and 2 self transfers,   in this PSVT, and it could scan it.  

But then the problem is   crappy laptop cameras. The built in cameras are garbage.   And so we hold up this little 1 inch screen to the to the laptop camera, and, you know, people are just, like, trying to find the right focus distance.   And before we had a brightness adjustment,   the only way I could get my brother-in-law to scan the screen was to hold a pair of sunglasses in front of it to cut down on the the glare, and that finally   worked. I I I took a picture of that and and tweeted that out as kind of a,  

[03:48:28] Unknown:

at least we got it to work.  

[03:48:31] Unknown:

Yeah. I remember we had we had the same issue when we were trying to to show the QR code on Trezor, that the contrast of OLED display is just so high   that these,   crappy cameras, they just can't focus on it because everything is just so blurred.   So one one of the ways how to fix that is actually increase the the brightness. So  

[03:48:53] Unknown:

I assume we are doing the same thing. I mean, the solution was instead of rendering white and black QR codes, we render shades of gray and black. So that's a lower contrast. It's similar approach. Yeah.  

[03:49:05] Unknown:

Yeah. So, I mean, you know, Multisig is obviously more complex than single signature.   A couple years ago, I did a number of tests on different hardware,   to to see like how well it could handle not only just multisig but like really, really absurdly large Multisig,   setups and transactions with many inputs and so on and so forth.   And and now what we're talking about today is just ramping up the complexity, you know, potentially   even by orders of magnitude if people start to get more creative. So you can only   imagine   where we're gonna start to see bottlenecks,   where we're gonna see parts of the user experience start to kind of crumble   under,   you know, larger data payloads,   more computational complexity.  

And,   and it's actually kind of funny because in the grand scheme of things, we're still talking about fairly tiny Bitcoin transactions. Like, compared to most other computing,   you know, general internet related computing stuff, this is a drop in the bucket, but it's still,   it's reliant upon so many other moving pieces that, you know, something is probably gonna break.  

[03:50:18] Unknown:

You just touched on something that I wanna dig into with both you and Ali, actually, which is that multisync, one of the great benefits of it is that it provides users with peace of mind. You remove a single key from being a single point of failure.   So the thing is, if you've got a working multi sig setup, if it's not broke, why fix it? I know a lot of your users are asking you when Taproot. I'm sure you're asking yourself, why Taproot, and what's the path forward? How do you get from here to there?   Let's talk through how you work through those decisions.  



[03:50:48] Unknown:

Yeah. So, you know, we've been evaluating.   And in in the perfect world,   our users   would have   access to using, you know, MUSEG   and basically have aggregated signatures   so that from a on chain   perspective, you would have the best level of privacy.   You would also have the the smallest on chain footprint, which is also going to have,   lower transaction fees. You know, that   aggregated signatures is like the holy grail,   I think for any multisig   type of setup. But because of some of the aforementioned   reasons, we don't really see   a straightforward path, at least in the near future,   that is going to allow us to   retain the same user experience,   and be able to, you know, add all of these other benefits.  

So,   you know, we prioritize   security, of course, above pretty much everything else, and then we're generally prioritizing,   user experience.   And then the things like better privacy or smaller on chain footprints are, they're nice to have,   but you know, it's more important that people can be confident,   that their money is going to be there and is going to be accessible then that they might be able to save a little bit on fees or have, you know, better,   privacy against certain,   surveillance actors on the network.   So I think it's most likely we're going to be going forward with the naive way of basically reimplementing the current, m of n,   you know, checksig,   type of functionality   just because of simplicity. And,   simplicity, you know, the the KISS principle, keep, keep it simple stupid. That's how we,   prevent   as many foot guns from getting introduced.  

And I as a wallet engineer who have seen many people shoot themselves in the foot over the past decade,   that is what I'm generally more afraid of,   than I am of various types of attacks and, you know, people stealing,   Bitcoin.  

[03:53:01] Unknown:

Yeah, I actually have a huge respect for,   for the challenge of doing that in a in a hardware wallet setup. So, I see it, how much complexity that adds.   So on on the lining side, it's it's   comparatively easy. And as I mentioned before, the the plan is more or less laid out. There are many, many steps to go to a   fully Taproot Music, PTLC   enabled lightning network.   But the the main challenge there is probably that because there are so many steps,   and you touched the same code so many times, it will take a long time to to get there. And   these upgrade processes with compatibility,   backward, forward compatibility   will just   be a lot of effort.  

But and,   the advantage is that the user experience   doesn't really necessarily have to change because, as I said, the communication is already there between the peers. So the the user basically gets free   upgrade   in terms of,   better privacy. You can't actually see the the public keys anymore.   Cheaper transactions because the signatures are smaller   and also,   less traffic on your note because, yeah, fewer signatures are sent on the Gossip network.   But, yeah, to to get there, it will be a multiyear   journey, and we'll probably learn along, a lot of things,   on the way. And maybe   something that we think now we'll do in a certain way, we'll do completely different because, yeah, we're just   collecting experience with these new protocols. And and, yeah, the design space with Taproot and music too is is so huge and large. And, yeah, I mean, that's that's why we're here. But,   fortunately,   yeah, as I said, that that in in lightning, the the plan is more or less there and now just need to need to attack it and actually   start implementing.  



[03:55:06] Unknown:

That's that's pretty exciting phase, to be honest. Yeah. I mean, I think in general you you should expect that   all Bitcoin development, not necessarily just protocol level development, but even people building on top of it,   they're going to take a   measured and conservative approach because   this is, you know, this is financial engineering. You should really approach it similar to something like aerospace engineering   where it's, it's a mission critical,   system   and it's more important that you are methodical   in how you go forward evolving whether it's the protocol or the wallet software   or even other layers, on top of that   because,   one mistake can be catastrophic, and we want to avoid catastrophe.  



[03:55:58] Unknown:

Okay. I wanna talk through how Pablo coordinated   with everyone on different options for how   multisig would be implemented on Trezor and what the pros and cons for each of us would be. But before we do that,   you raise something, James, and I would like to dig in with everyone, which is foot guns, potential   gotchas or booby traps with the new implementation.   Was there anything that jumped out at you when you were reviewing the bps and talking with the standards that you were wary of or concerned you, whether it's,   say,   seed phrase recovery or whether PSVTs and descriptors were adequate to handle the new multi sub construct, anything at all, they jumped out and said, hey. I have to think about this. There there would be dragons here.  



[03:56:39] Unknown:

Well, I gave   a a whole talk at MIT a few years ago,   which I believe was focused on   what I consider to be one of the bigger foot guns   in the design space, which   has to do with recovering wallets. More specifically, it has to do with how do we describe   the spending conditions for a wallet.   And I think everyone   in the room is probably familiar that,   you know, you have a seed phrase.   You keep that backed up and you can always recover from it.   That's all you need, right? Maybe a derivation path,   maybe a script type. But really, if you have the seed phrase, you should be okay, like you should be able to figure out some of the other parameters,   and essentially like even have to semi brute force   recovering your wallet. I've done that for countless people. It's   not too difficult to do. However,   if   you start creating   non deterministic,   script   locking   conditions,   by which I mean putting like random   or semi random numbers or other data.  

The most specific example of this would be, like, time lock   related data into your   scripts.   How are you going to be able to recover that, you know?   It's no longer   data that can be deterministically   re derived from a seed phrase or really anything else or at least nothing that we have a standard for.   So,   wallet descriptors   I think are a great path forward,   and a standard that I hope that all wallets will eventually adopt. I think only a handful of them currently support importing and exporting   those descriptors.   But wallet descriptors   are not necessarily enough unless we all   agree to like only use the current   wallet descriptor   language and we never evolve it any further.  

So while we hear,   I think,   fairly often from customers asking for things like, you know, can you help me time lock my coins? You know, I want to do like a   20 year trust or whatever. Make sure that I'm never   ever going to be able to   to be afraid and like panic sell or anything like that.   And it's an interesting idea.   However, I think when you start analyzing it from a security perspective, it actually has a number of downsides. And one of those downsides is   how do you recover those funds if you don't know the exact locking conditions. So I don't know. Maybe or maybe we even need like another,   v2 of wallet descriptors   or a way to   describe   semi deterministic   data. Maybe you could have some sort of script template that says, Okay, I'm going to do time walks, but I'm   going to minimize the design space. I'm going to minimize the potential values of those time walks so that you could kind of grind   all of the possible values in a few seconds on a CPU and be able to   find,   I guess the the right path to recover your coins. But, like, this is a whole potential area of exploration that I don't I haven't really heard anybody even talking much about. Yeah.  



[04:00:12] Unknown:

Yeah.  

[04:00:13] Unknown:

So first, let me talk,   about   how we implemented the protocol in in Tresor. Like,   obviously if you want a hardware wallet you want to connect it to a computer and Tresor was created in   2014   and we came up with our own protocol because it was years before there was such things as   log descriptors or PSBT.   And,   part of that protocol was also multi sig protocol,   which   worked out for us.   But then the other hardware came out and they came up with their own protocols for for single sig and multisig. And for single sig, it's probably not that of issue, but for multi sig, you don't really want to have a multi sig wallet that has to speak, like, 4 different languages if it wants to communicate with, 4 different hardware wallets.   So   then when Andrew implemented,   p PSBT   to create, like, a Esperanto   of of this,   of this hardware,   wallet languages.  

And,   slowly, it got improved by the PSBT version 2, which removed some of the flaws, that PSBT version 1 had. And when, the top route got activated,   I just had this urge to talk, with people at, at Casa and Anchett Capital. Let's get into the same room and try to figure out how to do multisync,   so everybody can use it and we don't repeat the same mistakes that we did in the past that everybody   invented   their own protocol and their own ways how to use MultiSig.   So that's when discuss discussion started last last year,   and we came up to with the idea that already we have mentioned that first, let's start with this naive way, then consider implementing k of k, but then you would need to share,   which   which subtree do you want to work with. Unfortunately, PSBT version 2 has way   how to,   how to communicate communicate and share that,   And I think that's that's really the way forward.  

Of course, we would need to improve the wallet, the scriptor language as well, and there has been some unofficial extensions   as well.   But I think it really makes sense to have a lot of discussions in that area as well because,   ultimately,   we are balancing this,   security, usability, and privacy   things,   and we cannot compromise,   on each other if we are going to forward.   So  

[04:03:01] Unknown:

so yeah. I think that that also that is a good example of, like, why standards are helpful,   at least from a developer standpoint.   Any of   us who are building wallets and also want to support   as many of the hardware key management devices as possible,   It was a lot more effort, for our engineers to integrate   Trezor's own API and Ledger's own API and so on and so forth. And these days,   with new hardware devices coming out that already support PSVT, that already support the animated, the UR spec,   We've already done it. So, like, there's almost no work for us to to do when we're going to add a new device now if if they're supporting   those standards. And   that makes it   a much more tenable proposition   for us as a company to add support for these things because we no longer have to ask ourselves the business question of, well, are enough people going to use it, that It's worth the   engineering hours and so on and so forth. So this is I think it's great for all companies in the space.  

You adhere to the standard, you're more likely to get adopted.  

[04:04:19] Unknown:

Yeah. So maybe we have a chance to actually get,   adoption across, a lot of devices faster because we already have something like PSPT and PSPT version   2, which is now need to find out how we call these new fields, what they contain, and and find consensus on that. But at least, like, the main   transport   protocol you could call, PSPT is is there and is in use and shouldn't really fundamentally   need to change,   And and also on the libraries are there. So I hope at least on that front, we have have some some head start.  

[04:04:55] Unknown:

Yeah.   And from the the software side for, like, Spectro Desktop,   it'd be great to initially offer the different flavors. You know, these three approaches we've we've been talking about today, it's not the full fledged   madness flexibility   of a full tap tree,   but we could say, hey. Do you want flavor 1, flavor 2, flavor 3?   And at least in the beginning phases of this, like, we all know what that means.   We'll have you know, most or all the hardware wallets can support those those different flavors.   But then beyond that, if we want to support   fully flexible,   you know, decide your own   complex script however you like,   I get it as a Bitcoiner, it's hard for me to say   this open source Bitcoin project should put limits on what you're able to do. Right? That that just sounds that sounds wrong. That's not that's not how we do things.  

But if we wanna throw open the doors to full flexibility, it it's gonna be foot guns 80% of the time.   So I I don't know how to solve that problem.  

[04:06:00] Unknown:

Yeah. I mean,   Casa is is kind of the opposite in that term, because we intentionally   do not   expose quite a few aspects of the Bitcoin protocol to our users,   because we   decided that there's too much potential for something to go wrong.   So   I kind of see   it from a software   development standpoint.   I see it as what we   need to do. 1st, we have to decide on standards. We have to figure out what best practices are for various things. And then we need to build those into the software.   And I see it as actually building   the   user experience as like guide rails   of like we, because we're so deep into this, like we see all the pitfalls,   but the average user,   they haven't been in the space that long,   or they just don't have the time to get that nerdy   to think of everything that could go wrong. So instead, we build the software   so that they can't veer off in one way or another. And like that,   that is, I think, is the best way that we as developers   can protect people.  

Even in a system like this that values freedom,   and along with your freedom comes responsibility and comes   the potential for screwing up, there's a lot that we can do to guide users on, at least somewhat safer paths.  

[04:07:33] Unknown:

I I think you can do that as   a company offering a service. Yeah. Right? And and you're trying to offer certain guarantees that you can support.   But like I said, I think it's it's difficult for something like Spectra Wallet, something like Sparrow, Blue Wallet. Mhmm. If Bitcoiners want it to happen,   it's open source. Right? If we say no, fork the project, somebody else makes it happen. Yep. You know? So it it like I said, I don't I don't know what what's gonna happen in the next couple of years.  

[04:08:03] Unknown:

Yeah. Someone, mentioned this, this morning in the context of lightning that there's always some,   a phase of,   a lot of new possibilities.   So the design space grows, expands,   people are trying out stuff.   And then at later point, the you could see, okay, what are people actually using? What what, what what works, what doesn't work, and then you have its contraction   and back to defining new standards.   And it seems like we're we're in this expansion now because we we have this,   kit of new possibilities,   toolkit. We can, yeah, just do whatever. But, of course, if we already,   have some ideas what we we definitely should and should not do, that, yeah, would would help as well. Yeah.  



[04:08:53] Unknown:

So one of the things we've been talking about and talking around is the importance of building open source   and building for our users   and building towards a standard in the absence of a BIV. I'd like to actually talk to you the nuts and bolts how that process works with,   with tablet multisig because I think it'll be instructional for Bitcoiners in the future. This is not gonna be the last time that we run into this issue where there's something that all these different stakeholders need to coordinate on   and provide value to the users with in the absence of official firm technical guidance.  

For me, at least, it started with reviewing BIP, 342,   going through it, and wrapping my head around Tapscopes and saying, well, okay. OBCheck multisig and OBCheck's multisig verifier out. And I think about that time, I got a GitHub notification from Pablo. So take it away from there, Pablo.  

[04:09:44] Unknown:

Yeah. You you mean should I recap what was happening from Sure. Just do it quick from the top. Let talk about  

[04:09:50] Unknown:

well, what were you thinking? What were your concerns? And  

[04:09:53] Unknown:

Yeah. Talk to you. Exactly. So,  

[04:09:56] Unknown:

so first, I had the discussion within my team because there are people that are much better with cryptography as as I am. So   I was, like, telling them we should we should have a have a look,   what what what how this music works and,   how these different,   different schemes   work, what what are the implications.   And at that point, we we realized that, the music, there are, like, several music standards, and we were a little bit confused because I always assumed it's just one thing.   And then we   realized that, there are different caveats to each other, and some of them were not, not being developed anymore.   And then the music too was,   seemed like it's the way forward, but it was not finalized at the time.  

It was just finalized yesterday,   I thought. Drafted. Sorry. Sorry.   So   as as you can see, there are a lot of moving parts   and we didn't want to be the one to say, alright. We are going to,   go   this path forward because we, ironically, we don't even have the MultiSync in our product. I mean, the Trezor suite, we just support the MultiSync on devices because we want,   Trezor to be used in   institutional organizations,   and that's when we realized we should should have a discussion with,   with Jameson from Casa and   technical guys from, from Manchin Capital   because, ultimately,   this is,   or these are the, you know, environments   where treasures are being used in in in multi sig. And we wanted to know what were your thoughts about it. And we already had this hunch that   interactivity might be a huge problem.  

But at the same time, we wanted to to hear if there is,   there is any solution. We are not, not seeing that.  

[04:11:55] Unknown:

And at that point, I think it lands on Jameson's desk. Jameson, take it from there.  

[04:11:59] Unknown:

Yeah. Well, you know, whenever we get pinged   by hardware manufacturers about   potential changes,   you always just freeze up for a second,   Especially because   as a multi vendor,   multi sig   wallet   software,   we have a lot of different dependencies.   And as I alluded to earlier about now it being a lot easier   to add support for new hardware if they're supporting the standards,   there are still additional complexities   where   once you're taking on the maintenance and support of that hardware,   if anything changes   about   how it just operates on a regular basis,   then   you may need to make changes   just to remain   in compatibility with it. So   we were   wanting to make sure that we're all on the same page   and hopefully   a worst case scenario would be like if Trezor decided to go down one standard and Ledger did another and Coldcard did another.  

Because then   we would be kind of reverting back to now having all of this conditionalized   logic on our end that's going to be even harder to maintain.   So   always happy to work with people just to try to keep some semblance of sanity.  

[04:13:32] Unknown:

I also feel like this is a little bit of an easier   challenge to tackle. You know, you said, like, what could we learn from this for for future,   coordination issues?   I I mean, I feel like if you put 20 Bitcoin engineers in a room,   it'll be fairly straightforward to agree, like, hey. These these three options make sense. This level of priority makes sense.   Okay. Maybe the priorities are different for for the lightning case.   But it just doesn't seem like there's anything   hugely controversial   about, you know, putting putting your your, your flag in the ground.  

[04:14:07] Unknown:

Yeah. And I mean, also,   I think there may have been some questions early on of, like, do we need to actually do a BIP? Do we need to write something formal?   And I don't think this really   rises to the complexity   that's required for something formal. What we're almost really more talking about may turn into something,   in the future,   maybe like sort of like   script templates   or, you know, best practices for common use cases, common Bitcoin scripts.   I can see that becoming a thing, if we start to see a lot more crazy experimentation   where   it's only a matter of time before   some people do some really awesome but ultimately stupid things   and lose   coins.  

Either they get   stolen or more likely they get locked up in perpetuity   because   of some poorly constructed script.   And   that's great, because we're going to learn from those experiences.   Hopefully, they'll get incorporated into our kind of common knowledge and best practices.   And then perhaps,   if this   space, this design space, continues to evolve, then we'll get to the point where it will make sense   to have   maybe a better version of wallet descriptors   or just a sort of   library   of recommended script templates. I mean, it's   kind of like hearkening back to the whole,   like EVM smart contract space.  

They have standardized some of their like more common   types of smart contracts there, because their design space is so hugely complex.   There have been   innumerable catastrophes.   And if you're   going to roll your own smart contract, that's almost as risky as rolling your own crypto.   And and that's kind of what we're talking about here, when you're, you know, constructing more complex,   scripts.  

[04:16:09] Unknown:

Yeah. Almost have, like, a a taxonomy classification.   Like, here's our here's our basic script. Maybe you fiddle around the edges with it, but we kind of understand that species of it,   and then have have the, you know, other species documented and at least to give a kind of a common language and a a starting point.  

[04:16:29] Unknown:

Yeah. I really like the idea of sharing this, you know, best practices because there is a lot of lot of work being done but not shared, I would say. And a lot of experience didn't just somehow, you know, die somewhere. And   I think this is, something that should be really done.  

[04:16:49] Unknown:

Okay.  

[04:16:51] Unknown:

So we have less than 4 minutes left on the stage, which is a shame because I really want to grill Ali on music 1, music 2, and music DN just for my own benefit while I hadn't cornered.   But instead, I thought, why don't we go around and share   what you're most excited about about Taproom Multisig and what you're most, I don't wanna say, concerned about, but what you've got your eye on? The good, the bad, and the ugly.  

[04:17:16] Unknown:

So, yeah, just also catching up the   the previous question, what our plans are or, how we approached it. So, basically, we have, in L and D, a bit of a different situation because we are not going to use, the secp256k   library because we need everything to be in Go for,   the reproducible build. So we went ahead, Lalo went ahead and   we   And then he also created a PR for the music too, which, yeah, was by our   draft now.   And then we went ahead and end to end integrated these functionalities into LND and offered them as an RPC to to the developers. So with lnd 0 15, it will be possible to use, Tapscripts,   sign for Tap scripts, and also music too.  

So we wanna put this, toolkit into as many developers' hands as possible so they can also try out and then help formulate these,   standards because, yeah, we might just not know yet what these standards all will look like.   So yeah. And so that's why I'm very excited about Taproot because we can actually give it to a lot of devs,   in in a very,   hopefully, touchable manner soon.  

[04:18:40] Unknown:

Yes.  

[04:18:43] Unknown:

Well,   one potential   construction that I've been thinking about for a while   is kind of building escape patches.   So   like we said, you can create this arbitrarily complex   tree of logical branches that you can go down to figure out   how you wanna spend your coins.   Well, you can that that means that now you're no longer locked into a single   security model or architecture,   that is just like these are the keys.   Instead,   you can you can put in conditions that will only activate   in other conditions. So like a relative time lock, that's like if   several years have gone by and these coins haven't been spent,   then perhaps we'll activate some other spending conditions.  

And, you know, it's both   exciting and scary of   how you might be able to screw that up or make your security worse, but I think that there probably is a safe path,   to go down there to   to give people some additional peace of mind and,   you know,   other ways for them to be able to recover from certain,   catastrophes?  

[04:20:04] Unknown:

I'm gonna piggyback onto that for my one good thing and one bad thing. The good thing I think is what I'm looking forward to is increased privacy. Right now, it's a little bit too easy to look on chain and differentiate   a   open lightning connection or a casa multisig or an unchained multisig.   The idea of having the happy path being completely   indistinguishable from any other transaction and the escape hatches, you called it being   more visible, at least for now, when, CISA.   That's really what's most exciting to me. What's concerning to me is   the same thing you raised. This is aerospace engineering. If it's not broke, why fix it? We have a tremendous duty of care to our customers to make sure that funds aren't lost,   that they're not just getting the most benefit out of the latest technology upgrades, but that they they have the same peace of mind and security stability that they were able to depend on from OV Chip, while they still verify.  



[04:20:58] Unknown:

What I really like about   what's happening right now is that   this   this opens so many new options. And like you said, the design space is so great, so so great that other people are now thinking out, alright, so if the design space is so great, so how do we work in that new field? Because earlier,   when these updates,   were incremental, it was like, alright. So I just changed this little small thing here, and now it works out. For example, we had this xpubs which didn't encode,   how you should derive from them. So we came up with different prefixes.   But now, like, this doesn't really make sense,   because it's so much more complex. So the more descriptors were created, and   we we can't afford to do these small steps anymore and we just want to need to   hold back a little bit   back to the drawing board and design   new standards,   how we could effectively operate in these new options that we are,   working on. And PSBT 2 is one of one of such things as well because,   yeah, we we we have to start doing things right   because the the monkey patching is not, helping us anymore.  



[04:22:21] Unknown:

I'm just looking forward to the UI challenges. Yeah.   You know, I've I've spent the last 3 months,   trying to explain Bitcoin   to a potential new user on a 1 inch seed signer screen. Right? Like, what information do I need to convey? What can I hide? How do I explain it? Mhmm. And I think the the complexities that we've all been talking about, both, you know, having   the UI on something like the Spectre desktop side and then how that talks to and what you see on screen on your hardware device, I think it's gonna be incredibly difficult and just tons of fun.  

[04:22:58] Unknown:

Alright. And that is well over the time we have. I wanna thank all of our panelists, Keith, Jameson, Pavel, Ali, and I wanna thank you, the audience. You've been great.  

[04:23:10] Unknown:

Maybe you should clarify.  

[04:23:12] Unknown:

Hi. I'm Peter Todd.  

[04:23:16] Unknown:

Hi, everybody. So this is a panel on preventing attacks on Bitcoin, and,   we have a a nice group of people here with us. Luke Junior, the infamous, core dev,   Brian Bishop, the former CTO   of the bank,   as he calls it, and Jameson Lop, from Casa. The real Peter Todd. No. Okay. Okay. We'll stick with Peter Todd. Infamous troll.   So I guess,   you know, it's a start.   We're gonna talk a little bit about the development   Bitcoin Core, obviously, as the foundation   keeping all of this running and working.   There is potential for shenanigans there. And,   arguably,   past examples with things like,   Gavin Andresen,   Mike Hearn, and the the   whole Bitcoin XT,   block size wars   that, culminated in 2017.  

So I guess, to start, I guess,   go this way, and,   what are each of your thoughts on   a way where you can see somebody involved in the development process kind of trying to pull a fast one and,   you know, make things go wrong.  

[04:24:36] Unknown:

But we saw it last year when   the Bitcoin community had decided to go with if they to deploy TETRAO, and then some developers decided, no. We're gonna do a speedy trial instead and basically ignore what the community had come to consensus on.  

[04:24:52] Unknown:

So,   if that wasn't, clearly audible to anybody, you're you're talking about the speedy trial deployment   with Taproot last year and the   complete refusal to consider bit 8 in the deployment?  

[04:25:06] Unknown:

Especially after the community had already come consensus on it.  

[04:25:10] Unknown:

So kind of like,   arguably, developers   stepping away from   community consensus   arguably and kind of doing their own thing in defiance of that? Right.   Okay.   Brian, what what's your your best brainstorm on how to kill Bitcoin?  

[04:25:30] Unknown:

Well, in the development process specifically,   I'm quite interested in deterministic builds and build signing and and things like that.   I think that's a really interesting area for preventing some attacks on Bitcoin, certainly not all. But, essentially, the idea is that if you are a user of Bitcoin, you have to download the Bitcoin software somewhere.   How do you verify that you're actually getting the real Bitcoin software?   How do you verify that   this is the one that everyone else is using? If you just download something from the first ad you see on Google, you might be getting something quite different from what everyone else is getting.   So with   both deterministic builds and also build signing,   And, specifically, it's multi party build signing. You're able to verify through techniques such as web of trust and others,   whether the,   code you are running is actually the one that,   you think you are running. I think that's a really interesting method.  

If you don't do that, there are all sorts of interesting attacks that can be done against you.   For example,   you know, you you, travel to a country, not the United States. You have a hotel. You have Wi Fi,   and you're downloading Bitcoin software.   Well, if you are not using HTTPS, if you are not verifying hashes and signatures on on the binaries that you're downloading,   it is possible for attackers to intercept your connection   and replace it with a version of Bitcoin that maybe steals your coins or does other nefarious things, such as spy on you or something less drastic than stealing your coins, which are still problems.   So that's one of the attacks I find on the development  

[04:27:11] Unknown:

kind of the whole point of deterministic builds is just you have   each developer independently   build from the source code what what they assert is, like, the latest build, and everybody kind of just cross compares that and signs it so that you have all the independent machines used to build that software,   like, cross compare. And if anybody has   a result that deviates or something. Like, it's   not just trusting one source or claim to something.  

[04:27:39] Unknown:

The the fun part about that is knocking out areas of nondeterminism in your in your build process. Because if you have something that changes based off of the environment that you're building on, for example, a different operating system or or something,   then the binary that you're gonna generate at the end of the build process is gonna be different. So you need to eliminate all the sources of variability in the build environment.  

[04:28:01] Unknown:

Peter Todd, how how would you kill Bitcoin?  

[04:28:04] Unknown:

Well, I tell you how I'd kill bitcoin.   I had sowed discontent   throughout   the community,   throughout   the GitHub repositories.   I would   be so angry   about every little thing that I would make people afraid to suggest even the slightest change.   And then we would have to ossify   and we could no longer upgrade any of the protocols.   So it would take a very long time,   but   bitcoin would not be able to improve any more. And therefore,   it would become stagnant,  

[04:28:44] Unknown:

and people would move on. Ossification, good or bad. But but I mean, that's suspending Bitcoin. That that's not attacking Bitcoin, Peter. That that's defending it.  

[04:28:53] Unknown:

No.   That that is why it's the perfect attack is because many people consider it to be a defense.  

[04:28:59] Unknown:

I mean, that, you know, that kind of though ties into, like,   Luke's concerns with speedy trial last year with the entire taproot activation. I mean,   how how do you really   ascertain in a situation where you have the sense of disagreement and confrontation   in the development process,   like, the difference between   an attack on Bitcoin and just legitimate disagreement. Like,   where do you draw that line? How do you assess that? And and more importantly,   how do you react to that?   Like, if if you can't really ascertain whether something is an intentionally malicious action,   then you're you're kinda stuck in a rock and a hard place. Like, you engage in good faith and try to settle something that could be a dispute or in your reaction,   maybe actually inadvertently   become the attacker yourself.  



[04:29:54] Unknown:

Can you steel man why you're saying, speedy trial was an attack for for for Luke? Well, I mean, Luke, if,  

[04:30:02] Unknown:

you wanna take that one? Or   I'm just supposed to be moderating.  

[04:30:06] Unknown:

Is is oh, for the first part, it is minus   the   the ability to reach our software, which is presumably already come to consensus within the community.   And secondly,   the community had already decided to move forward with TeptuEdge with the 50 deployments.   And the developers who are pushing to the trial decided to essentially disregard   what the community had already determined and come to consensus on I'm just going to form something else without even getting community   behind.  

[04:30:38] Unknown:

That's right. We didn't actually start with the bay for Taproom, did we?  

[04:30:43] Unknown:

No. No. I mean, that's   the entire   process was really just arguing over activation once everything was finalized, and nobody could agree. And, I mean,   you know, to kinda throw   the idea out here in how to mitigate that if you view something like speedy trial as an attack,   the potential for user activated soft forks and   the viability of actually coordinating that and hitting   enough of a a level of adoption that that's actually gonna affect something.   It's not just gonna be a few people in the corner that everyone ignores.   Like, what are your guys' thoughts on that going forward versus   what happened in 2017?  



[04:31:26] Unknown:

Well, I mean, from your perspective,   does an attack   require malicious intent?   Because I think in hindsight,   you can certainly say that certain things   were attacks on various principles   that most of us hold dear when it comes to bitcoin.   But really, the problem was that just some of those attackers   simply didn't hold those same principles.  

[04:31:55] Unknown:

Well, I mean, that's a a sticky question.  

[04:31:58] Unknown:

Look at Gavin Andresen. I mean,   was he an intentionally   malicious actor or just had a very different idea of where Bitcoin should go?  

[04:32:09] Unknown:

Well, has he disavowed the   signature   that he claimed was real?  

[04:32:14] Unknown:

Has that happened or not? I'm actually not sure. I a lot of people just kind of quietly stopped mentioning that and didn't really   come out and say they were wrong.  

[04:32:28] Unknown:

Well, that was an interesting attack.   And, you know, if if you take the story at face value,   the attack here was someone, said that, hey. I can produce the signature   for a certain key. And I'm gonna prove it to you,   and we're gonna go to the store first and buy some hardware.   And we're going to we're gonna pick out a box on on the shelf, and you're gonna you're gonna help there.   Actually, I think part of the attack was that he was not there. It was just, hey, here's a new box of a new computer and new laptop. We're gonna put in some software to do signature verification,   and this is going to prove that I am in control of this key.  

Now, apparently, what happened was   there was software that was installed   on the laptop that actually,   I believe it had a bug, a very subtle bug that when you look at the code and you're glancing at it, you're like, yeah. This is signature verification.   But anyway,   because of the way the bug in this code worked,   the signature verification was always gonna say, yes. It is a valid signature.   And so that was a very interesting attack,   and we haven't heard much since from that particular individual.  

[04:33:34] Unknown:

Yeah. I mean, I I do believe that,   Thomas from Electrum actually checked the download bugs,   from his server   and found no downloads of of genuine Electrum software when Craig supposedly   showed the signature to Gavin.  

[04:33:51] Unknown:

Interesting. I didn't know he kept logs. Good to know.  

[04:33:54] Unknown:

Yep. But,   I don't know. I think   from a,   like, class of attack   standpoint,   it seems like   social   slash mimetic   slash   narrative   have much greater potential,   or at at the very least,   it's more difficult for me to reason about how to defend   against them.   It's a much bigger gray area,   whereas we can talk about all types of technical attacks. And usually, the defenses against various technical attacks are very logical and straightforward.   But this much more fuzzy   social   attack vector   is something you just sort of have to to deal with as it comes.  

[04:34:45] Unknown:

You know, I was recently, in Austin, Texas going to some Bitcoin conferences related to, like, South Buy and everything.   And I have to say, I was really impressed by the number of new developers that I met there that introduced themselves to me as anonymous developers. You know, they gave me their pseudonym, you know, and they and I asked them, oh, do you do you just use that? And they they said, yeah. And the reason for that is as a Bitcoin developer, maybe that's the optimal strategy.   If people don't really know who you are and you don't maybe you don't even attend conferences.   Maybe that helps protect it. Maybe that helps protect Bitcoin.  



[04:35:18] Unknown:

Yeah. That is   something I hope to see a lot more of going forward. I mean, I I know you wanted to kinda touch on this, but the,   like, insane litigation   from people like,   Craig Wright,   directed at a bunch of core developers and the, legal defense fund that Jack,   graciously set up recently.   That   is   without some kind of mechanism to finance legal defense against things like that,   that could very easily just burn out and push developers out of the space because   are you gonna wanna be here and contribute to Bitcoin if you just have to burn money constantly to defend yourself against ridiculous litigation?  

[04:36:05] Unknown:

Well,   that's an interesting   point because I I think   the the litigation against COBRA,   shows that even being anonymous is not necessarily protection   against a legal attack. Mhmm. Well, you know, I I suppose COBRA could have   stayed out of the whole thing, you know, never,   touched any of the court orders or   hearings or whatever.   But at at some point, I guess because   they're operating a website, you know, that is a property that could be seized or or otherwise  

[04:36:44] Unknown:

And there's a name tied to it somewhere in the registrar even if it's not public.  

[04:36:49] Unknown:

Yeah.  

[04:36:51] Unknown:

But I mean yeah. Like, that that is a a huge way that I think you could slowly   erode   Bitcoin's ability to to deal with, you know, the shortcomings that it has. Like, actually solve problems like privacy scalability if   developers don't wanna work on it because you have to worry about the crazy egomaniac   just throwing 1,000,000 of dollars at you in court.   Like, that   you know, death by a 1,000 cuts.  

[04:37:19] Unknown:

Well, that's partly a conundrum, which is bitcoin.org,   you know, is someone's property,   and it's   where people go to learn about Bitcoin.   But at the same time, though, you know, maybe there shouldn't be a single place called bitcoin.org   where people can go learn about Bitcoin.   But when you do that, the conundrum   is suddenly there's all this room for fraudsters to attack people by saying, no. My website's, you know, the main Bitcoin one. Maybe I call it bitcoin.com,   for example.  

[04:37:50] Unknown:

Yeah. I mean, it's All I know is bitcoin.page   is the one and only official Bitcoin website. Is that yours?   Could be anybody's.   Oh,  

[04:38:01] Unknown:

okay. I mean, you know, all of this kinda just keeps   slowly sliding in the direction   ask you guys a I'm gonna ask you guys a question   and hear your thoughts on whether or not this constitutes an attack. And if it does,   like, how do you think it should be dealt with?   This   this growing narrative over maybe the last 2, 3 years   of Bitcoin isn't money.   It's not competing with the dollar.   It's just a a financial asset or a collateral,   and that's how people should look at it instead of looking at it as money.   And, like,   is pushing a narrative like that an attack on Bitcoin?  

Like, trying to just push and brainwash people into not directly   using it,   you know, as a native value transfer network   and trying to just keep framing this narrative and get people thinking, like, no. No. You just park this somewhere with a custodian   and get a loan against it in dollars. Or, like, don't think about competing directly as a a money or a payment rail. Just think of it purely as number go up   and and that's it. Like,   is that an attack?  

[04:39:22] Unknown:

I don't think I would classify it as a tag.   Even if you look at Bitcoin as money,   that's just how these people are deciding to use or not use their money.  

[04:39:33] Unknown:

Yeah. I mean, I think it makes more sense   if you're positive rather than negative about the narratives.   So   if you want yield generating asset or whatever and that's your use case, then go for it. But if you start being negative   and you're saying, no, you can't use it as a currency or as a money or whatever, I mean, the rest of the the users on the network who do want that are just going to ignore you   or perhaps   swarm upon you on Twitter, depending on if you're in the small minority.   This is, I guess, the mimetic warfare   and why social media can be a very   negative place to hang out, if you're trying to push views that are controversial.  

And they're going to be controversial if you're  

[04:40:33] Unknown:

Bitcoin has a very impressive   social immune system that has been developed. And   if you try to coerce Bitcoiners,   try to change the protocol unilaterally,   the immune system will spit you out and reject you. And that's just a really fascinating social phenomenon.   Now it's just really interesting to see that in process.   It might actually be one of Bitcoin's great assets, really,   is is this just layer, this immune system of people that defend Bitcoin voluntarily. You know? And they're not coordinated at all, but it's all people who believe in Bitcoin.  

[04:41:09] Unknown:

Is it an attack on Bitcoin   to donate   $5,000,000 to Greenpeace with stipulations   of exactly how it must be spent in   performing   a social narrative?  

[04:41:22] Unknown:

Yes. I I would say so.   You know, that that's actually   if you wanna get into that real quick, the last couple minutes,   I see the potential for that very quickly to spiral into government lobbying.   Sure. Legal bills,   regulations,   and,   you know, that kinda gets into a sticky territory   laptop.   If jurisdictions   really just start dominoing   in, say, the West   and,   you know, enforcing   take that off grid and disappear,   to do that in secret.   I I for I think it was a a Chinese   group of researchers, but I I actually saw a paper last year. We're just looking at the modulation   along the power lines from the grid to your house.  

They can see that you're running,   an ASIC   just based on the unique signature of that over the wire.   So   how would we react in that type of situation?  

[04:42:38] Unknown:

The passing would be a lot of mine   who are already on solar,   not exposed to the grid.   And if they have really bad, there are other alternatives like  

[04:42:59] Unknown:

I mean,   does anyone up here on stage actually think we could pull off a proof of work change,   get consensus on that?  

[04:43:12] Unknown:

If the situation was dire enough, I think we could do a proof of work change. If the whole chain is halted, if there is some sort of catastrophe,   if SHA-two fifty six is broken, I think we could come together to figure out a solution.   But it's hard. And, you know, it's very unlikely that that would happen.  

[04:43:31] Unknown:

I mean, you you have the problem of if even if we   wind up with consensus that something's wrong with shot 256,   then   what do we replace it with?   And that's the whole next can of worms.  

[04:43:46] Unknown:

Obviously   a quantum proof algorithm that will make everybody happy.   You know,   there's going to be   challenges over the long term. I'm sure there will be some   insane   attacks   or   just weaknesses that become uncovered   over the decades.   You know, kind of I was joking about the quantum computing stuff, but   it is   likely that at some point in the far future,   we will have to have discussions   around what to do with the really, really early pay to, pubkey coins   And like whether or not   they should be somehow,   like, protected   or whether we should just consider it to be like a new form of mining if people start to be able to crack them. You know, it's it's an interesting long term,   issue.  



[04:44:45] Unknown:

Might not. Might not. Uh-oh. Uh-oh. Did the mic die?  

[04:44:53] Unknown:

Good. There was no stage.  

[04:44:56] Unknown:

Might also note that, it's not just the very old beta Puff TV   of coins anymore. All of them capture points are also similarly effective.  

[04:45:08] Unknown:

Well, I mean,   honestly, I don't I don't   think that should be looked at any differently than an exchange hack.   Somebody gets those coins and they're able to confirm them in a block.   That's really a fundamental,   you know,   quality of Bitcoin to go tinkering with just because of being nervous that these many coins were just acquired by  

[04:45:34] Unknown:

some nefarious actors. That's fine. We'll find them when they start publishing their rap videos about, how gangster they are.   Seriously, check them out. They're awesome.  

[04:45:45] Unknown:

And that's why it's relevant that it also affects Kepler coins is that this could potentially be nearly all points from Bitcoin at some point.  

[04:45:53] Unknown:

Well, you know, actually,   factoring,   the discussion on tap redesign,   I was very hesitant   when when that first   got pitched just the the raw pub key.   But the reality is when you look at   on chain address reuse   and then also think about the fact that any kind of light wallet   I mean, even if you have a wallet, you're connecting to your own full mode. Like, there's still some network communication   that could get played with that's just passing the master pub key back and forth in most wallets cases. So   in some way or another,   most coins already do have their public key exposed either through address reuse or just the balance fetching mechanism on the back end. Oh, yeah. I mean, fundamentally different from exchange hack where it's just a minority of coins that are effectively different from exchange hack where it's just a minority of coins that are   But, I mean, if if you still have your coins in a   a raw pub key output   from 2,009,   2010,   and you're not moving them at some point,   all   you know, those coins are lost. Those those people don't have the keys anymore.  



[04:47:06] Unknown:

Possibly, though, and you you never know what assumptions you may make. Though kind of going back to classes of attacks on bitcoin,   and related to this,   is it an attack on bitcoin if you build a wallet that intentionally   does not follow good practices? Like, there are still wallets out there that are only one single address. They won't even do deterministic   address generations,   and and thus, all the money keeps coming in and out of the same address, thus exposing the users,  

[04:47:37] Unknown:

to to this issue. Well, it's definitely an attack on Bitcoin users. Yeah.  

[04:47:42] Unknown:

Mhmm. But didn't didn't we decide backstage, though, attacking Bitcoin users is attacking Bitcoin?   Alright. So I guess we're, down to the last,   20 seconds.   Anybody have, some smart ass comments,   your your one trick to to guarantee Bitcoin's invincibility?  

[04:48:02] Unknown:

Bitcoin is the greatest bug bounty program of all time. Good luck.  

[04:48:17] Unknown:

Alrighty.  

[04:48:25] Unknown:

Cool. My clock started.   Hey. My name's Lalu, so you may know me as Rose Pfeiff. I'm the CTO of Lightning Labs. I'm here to talk to you about Taro. A few different Taro, so we'll get into kind of like this Taro, the one that we release a little bit later, and then kind of go from there, kind of explain kind of the high level exactly what it is, the motivation, how things work, and also kind of how it's different from other solutions. But now we can get into  

[04:48:45] Unknown:

I don't know if the spine is clicking.   Alright,  

[04:48:52] Unknown:

Here we go. So first, I'll go into exactly what is tarot itself, how actions created in structures, and then how to transfer to them, which is a bigger thing as far as the way it works generally, what are the universe, and obviously the most important thing, kind of like how does it integrate with the Light network and stuff. Right? So first, we'll start, exactly what is Taro. Right? You know, here's the little shout out. So Taro is actually a root vegetable with a tap root structure. It's eaten across many parts of the world, you know, Africa, South America, Asia. It's actually one of the most, like, ancient kind of, like, staple crops going back 1,000 and 10th of 1000 years. That bottleneck was actually something from, like, 6th century. It's a great source of, you know, manganese, potassium, and also fiber. So here's, you know, for the Bitcoin vegans, Bitcoin vegetarians. Actually, Nigeria is one of the largest producers of taro in the world as well too. On the right, you can kinda, like, see some different depictions. That's the actual taro plant, you know, these chips here. And bottom line, it's something I eat, you know, way back in the day. Like, it's kind of like yam, I would call it Nigeria, and egg, that's like a big meal, basically, kind of like a very easy thing to do, and it's really tasty as well too. But, I guess you maybe you mean, the other tarot. Right? So what tarot is, it's basically kind of like a new protocol we developed at Lightning Labs, you know, over the past few months. What it is, it basically uses tack which kind of like allow individuals to issue assets, you know, on the actual Bitcoin chain itself. Right? And does it in a cool way because, like, given that you use the tap root structure, whenever you see an output, you don't actually know what's actually, you know, held in the asset itself. But But also, it actually uses the Taproot trip tree to basically allow you to commit to effectively an unbound amount amount of assets in a single, in a single output, which is really cool. And one of the most important things is that, like, the protocols oriented, so it can actually be transferred over the, like, network. Right? So for example, now I can basically I can in theory, paste someone on Bitcoin, basically, with my own, like, mining wallet. Maybe they receive, you know, something like a l USD or USD on the other side as well too. So this is a really big step from kind of, like, you know, moving forward. Bitcoin is actually as far as kind of, like, Bitcoin being the massive project center for all of the other, you know, currencies and assets of the world as well too. Then all of a sudden, like, everything is still Bitcoin center, but at the edges, people can kinda opt into these new protocols as well too. I think it's really gonna bring, you know, expand the network effects of Bitcoin itself, also bringing more and more people into Bitcoin. And also, like, a lot of them, like, kinda, like, either way into maybe they're initially doing the stable coin, and beyond that, they get into more into the core Bitcoin itself. But now let's start to dive into some of the details.   So what is Taro? Right? So it kinda like has, like, a cool background, you know, in addition to being, you know, a nutritious   vegetable. It's the the taproot asset representation overlay. Right? What's an overlay? Right? So what we mean by by asset overlay is basically is basically something called embedded consensus. Right? Embedded consensus. So rather than kind of, like, you know, including all the data executives in the chain, like, think like, you know, Omni and counterpart things like that, which kind goes to chain itself. So we basically commit to kind of, like, hash of data into the chain itself. Right? And we say better con consensus because we basically, okay, like, we're gonna, like, make up rules as far as how things work and then interpret them and kind of, like, add additional validation logic and and alongside this as well too. So effectively, it's using Bitcoin kind of, like, most secure these are, like, blockchain in the world as a publication system, basically. I'd commit the data to the chain that we interpret ourselves. This is really cool because all of a sudden, now we don't have to worry about double spends or, you know, we need we don't need a consensus network. We're gonna need a proof stake or else. We just use the Bitcoin as is today. Right? And the one kinda like a little trick, you know, in tower, basically, like, rather than actually commit out to all the data on the chain, outright, we actually and set commits to things in the the script tree itself. Right? And as you see in a little bit here, this this is really cool because this kind of, like, you know, has, like, a very nice structured commitment format but allows it to be, very sensible as well too. And so Tower supports 2 different types of assets. One is basically normal assets, like maybe things are divinibles. Maybe these are things like, you know, cool points, beef bucks, or, you know, USD, not really of realms. Also supports collections, which are kind of like, you know, like a limited edition, kind of a collectible asset. And maybe it's like a holographic beep beep star card, maybe it's a baseball card, things like that as well too. So you can basically do both of those things, you know, within, the actual protocol itself, which is pretty cool.  

So, people ask me exactly, you know, why Taproot? Is it actually needed for Taproot? Is it just, like, a marketing thing? You know, it's actually you know, it's it's essential in my opinion. Right? So some people have in the past, something called paid contract password p 2 s h. Right? The way it worked, it basically kind of like you have, like, a key, then you have some data, and you basically, you know, high level, you don't get lost in the math, you know, or these stuff. Basically, you can kinda commit to some data within a public key itself. Right? This is really cool because the public key to a third party observer looks like just like a normal public key. I don't really know what data is actually included with it as well too. There was a paper, I think, by Timo Heineke in, like, 2013 or so, but it never really got used in practice. I think his use case is kind of like using it as, like, a receipt, basically, like, you know, you have, like, some, like, metadata, and you could use that manager to drive Bitcoin interest. Now it would give you kind of proof of publication. It never really came on as well too. But, you know, one thing about, like, you know, doing something like this, just far as, like, you know, p 2 s h loan or p or paid a contract cash alone is that you kinda, like, intermingle the actual contract details or the action details lying inside the script and stuff. Right? So let's say I was kinda committed to, like, the metadata in the in the actual script. All of a sudden, I need to kinda, like, have that directly on all my other scripts. That's why it's gonna, like, bloat me with the information as well too. But the cool thing about Tapware is, like, Tapware kinda gives us, like, a very structured commitment format. Right? And, like, the way the way Tapware works is that, like, you know, you can actually commit to several different things, but the things that you don't reveal don't actually need to be published onto the chain itself. Right? So this is, like, okay, like, you know, well, what if we actually commit to other data within the actual Tapri Tree itself? That's kind of where the idea has been born somewhat. Right? And the cool thing about this, as well, too, we can actually have a, separation of layers, because we actually have a new asset script or a kind of scripting language in the tarot system itself, too. So we see Bitcoin scripting, we have asset scripts as well too. This is really cool because for example I can have an asset and maybe it'll require like multisig or other information as well to actually properly move it. So it's definitely, like, you know, really cool, way things are set up.   So here's kind of, like, a however overview of the way things work. Right? So it's basically this new data structure. I'm calling it new. Maybe someone has invented it. Maybe it's a Bitcoin talking from 2012. I don't really know, but for now, we'll say it's new. Right? So it's basically something called a Merkle sum of sparse Merkle tree. Right? And what a Merkle sum, tree is like, you know, people have seen Merkle Merkle tree before. You kind of, like, have, like, a series of items. You hash them up pure lines. You have, like, an initial root a hash itself. Right? But the merkle sum property basically allows you to, like, commit to what exactly is, like, a value. Right? So now, alongside of committing to a hash, I'm also committing to a value. So let's say I have, like, a series of elements. They all have, like, a value of 1. The root of the tree commits to 4. Right? Now listen, I can say, okay, well, prove to me you have an element of the tree. You give me the actual, hash of the data itself. You also give me this value. Whenever I combine the proof up, I actually add that value along Tariff as well too. That's a really cool thing because in the in the concept, Tariff will be using this for things like, okay, I want I want you to prove to me that you have 5 beef bucks. Right? You can basically prove that to me as well too. The other thing we use in Taro, this also lets me ensure ensure that whenever we do transfers, there's not actually asset inflation going on. Right? I wanna make sure, okay, you sent me 5, you should have 3 left. Right? You're not actually making anything out of thin air on the on the other side. Then the other part we have is a sparse Merkle tree. So this is kind of like another thing. Sparse Merkle tree is effectively like an index,   going left or right depending on that 1 or 0. So if it's 0, I go left. If it's 1, I go right. And then we go all the way down to 256 levels because it's 256   bit tree. We get into, like, a unique location within the tree itself. This is really cool. The one other cool thing about Sarsaparco tree is the way it works. We can actually do, like, a very efficient proof of non inclusion. Right? So, you know, for for in this case, like, one other thing I discovered just now is, like, all the elements are initially nil. Right? So for you for me to prove to you that's not something's not in the tree, I show you a path down to a nil element. Right? And that means, okay, well, it's actually in the tree. This is really cool because otherwise, you know, if you're doing it from Merkle tree because it's insertion ordered, I mean, we need to give you a bunch of other leaves aside and things like that as well too. The other cool thing about a, sparse Merkle tree is actually history independent. Right? Meaning that, you know, if you and I insert elements into a tree in arbitrary order, we get the exact same root hash. Right? So you can almost view it as kind of like being able to, like, you know, maybe do like a git clone iplot on my commits on top of it. We check the same head, and we know things are are correct like that. So this is how it kind of looks on the right over here. So in the top, you kind of have my initial pub key with the script group. That's kind of like the way Taproot works. We have the regular Merkle tree, so you can kind of see I have like, hash for a preimage, a delay or 2 or 2, whatever else. Then we get to the tower part. Right? So the tower part is actually now a series of other nested, you know, sparse Merkle trees. Right? So first, we have the first level, and that's where we have, like, all the assets. So bringing up by 25 $1,000,000 and a 100 cool points. Right? And, you know, so we'll have, like, kind of, like, an additional leaf for every single asset we have here. This is kind of where you get some this is where you get some of the scalability. Because If you look at other systems, whenever you're actually making assets, you need to manifest   fully, like, a massive map of the asset onto the chain. So if you have, like, a 1,000,000 entry, you basically have a 1,000,000 items in the chain as well too. Maybe it's gonna cost $100,000 to make an asset in this case. But in Taro, it's basically one transaction. One transaction can move an unbounded asset and also create an unbounded asset as well too. So once again, we're using this, like, in a very cool tree scale and property to amortize all of these   So if you see that I have, like, you know, 10 big bucks and the 15 big bucks, and then when I hash those up, I get 25 as well too. And then the the final layer is basically this, like, asset, you know, tree, or leak TLB. Right? The TLV is a format we made from lightning protocol. It seems like a protobump. It's kind of like an sensible key value, you know, system, so it's really cool from that point. And the way everything works is that, like, you basically need, like, an asset ID. Right? So it's kind of one of the tricky parts I think we found that really, you know, cool, which we can do. You know, typically in other systems, there's kind of like a global system or maybe the contract system system is actually aware of, like, a contract hash or an asset ID. But in tower, we basically need all the asset IDs to be unique. So it's okay. Well, how do we get a unique value? Once again, we basically use the blockchain itself. Right? Something called bit 34 back in there, but kinda like, you know, fix an issue in Bitcoin itself. Basically, make sure every single transaction is actually properly unique. Right? And the way they do this, the combinational dot can now commit to the height, you know, of the actual block, which makes things unique. They don't need to get to that too far. Now because we worry, we say, okay. Well, we can use that first import, you know, call the genesis point, apply the asset tag, which maybe is like the name of the asset, maybe it's like hash or something else. There's some asset metadata as well too. Then all of a sudden, we can basically use that topic unique identifier. Right? We can actually ensure this is, like, you know, globally unique because we know the assets are going to be repeating.  

You know, and so we know Jess's points are going to be repeating in the chain because you never repeat a txid. That's kind of how we do something to get, you know, global unique, you know, asset IDs. This is really cool, and there's some other things as well that you kinda, like, can manifest asset IDs in the in the similar,   tree and also kinda do thing where I can, like, you know, issue b bugs v1 and then v2, but I still have v1 and v2 be actually fungible along part of each other.   So one of the questions, okay, like, exactly how do transfers work. Right? So I mentioned a little bit earlier that, you know, things are kinda, like, you know, Bitcoin like, and they kinda, like, you know, really take up from, like, Bitcoin,   design principles as well too. One of my goals, you know, in creating this new system was to make it very friendly to Bitcoin developer. Right? It it should be, you know, it should full bear your name. I don't wanna, like, learn some new language or VM paradigm. I just wanna like, you know, do use all my existing tooling. And when we set things up, basically, everything can be reused, for for the most part. Right? So, like I was saying, alongside the TL, we actually have like inputs and outputs. Right? The outputs are kind of, like, you know, my splits, similar to the UTXFR. They all have inputs. Right? And the inputs themselves are actually like a new, another version like a witness. Right? Depending on what you do, maybe you need kind of just to prove to me that you're part of something else, else, but pilot with the basic inputs and output similar to Bitcoin is like a witness. Right? So the one question, okay, like, exactly, like, okay, we're just gonna add for reliability. What do you wanna do as far as the VM? So it was like, okay, you know, I I feel like one thing I think happened to a bunch of other product in past. Like, they got a little bit copied as far as the VM design space, and that, okay, well, you can do anything. Right? But I think one kind of, like, you know, kind of a good trait as far as the protocol is try, like, simplify as much possible, make things, you know, as really simple to kind of control yourself to have something that's, like, a little more elegant. So what we end up doing, we actually have tap root within tap root. Right? So first, you basically have the top of the tap root key that's, you know, showing everything, and committing to asset itself. But in the actual script, we then what we do, we basically make a a virtual. It should act like a one input, one output. Use a merkle sum commitment of the apples and all the inputs as well. So verification says, okay. Well, you know, this this value should be equal. Right? So I have, like, 10 over here and then 10 over here. This so, like, if you give me, like, 10 to 15, I mean, basically, I know you're inflating something. Right? That's a really cool thing. Then we basically take that transaction. We actually run it through the regular Taproot script VM. So we basically gain all the capabilities of Taproot today, without really having to, you know, write new new code, and we and we know this stuff has been very well reviewed as well too. So basically the version 1 system, version 2 depending on how you're how you're counting it. In the future, we can actually add new functionality. So, you know, we could add Wasm. We could add an entire new VM or we can basically even introduce things like we can add covenants or even add new app codes at at the, tower VM layer, which is really cool as well too. So one other thing we wanna make sure, like, we wanna make sure that this this thing's actually, like, very familiar to people and it's, like, very easy to use. Right? So we actually have this address format. So if if if you if I was trying to send to you a tar asterisk on chain, we just use the Vic Vic 32, like the similar format that we use for separate addresses. And there's a complex of information that's actually encoded in that, like, address itself. That's all the information I actually need in order to recreate the, the the script tree and then recreate the output key that's attached to that on chain as well too. Right? So using the internal key, which is a part of TypeScript, you ask a script key, which is kind of like exactly,   you know, how your unlocking works, and also ask an s I d. I can reconstruct the tree base again and create an output and then be able to send you that output on chain as well too. This is really cool because it enables client support. So when passing through some of the private versions, like, you know, they actually use something called Oportun, which when you act you have to had to actually scan the entire chain, kinda like looking for these updates to see, okay, anything, you know, spying for me at all. In this case, I can basically put that address into my, you know, my neutrino filter, which is lacking. From there, I can say, okay, well, I received an asset. Let me go and then get the the 100 proof, and I could be able to suspend it as well too. So what where I think that we did make things things a little more like client friendly as well too, like, so every single asset can, like, define by its proof. So as I mentioned earlier, it's kind of like a Genesis point. The Genesis point is basically what's used to, drive asset IDs. Right? So, you know, so for in this case, beef bucks are defined by every asset kind of like, you know, that's, descended from this particular Genesis point. Similar to their words, like, you know, Bitcoin is depend descended from the Genesis block. Anything that doesn't have genesis block in is in the Bitcoin chain. Anything that doesn't have, you know, my out point and it isn't, you know, beef box as well too. Right? So this the so this kind of, like, lets you kind of, like, you know, prove and also put provenance directly at the kind of, like, head of the protocol itself. So anytime I'm, like, you know, sending something something else, I can then use that to verify to make sure I have a legit asset. I'm not getting a scam, I'm not getting inflated, or anything else like that.  

There's another, you know, component in the system we're calling a universe. Oh, cool. These are the updated slides. Right? So question is exactly what is universal. So I had mentioned a little bit earlier. You actually need to kinda, like, bootstrap,   what's effectively, in my knowledge, like, knowing that the chances point a particular asset. Right? So this is kinda, like, actually, like, an on chain structure that indexes into the set of spent hot points and then map that metadata that is basically the proofs, into the chain itself and then also the proofs of the witnesses, you know, as well too. Right? The way it works though, like, within the BIP, you kind of, like, define, like, some special rules as far as how you, after you create the output, the initial asset matching transaction itself, when you require the second, output of the next transaction to actually commit to the root hash of which is what the universe is itself. This is really cool because obviously now I can actually watch instead of outpoints on chain. So when thing new things are being created alongside things, as well. 2, the other cool thing about universe is that, you know, once I have this commit and I have the extra data, I can then audit I can, like, audit the supply of, like, a particular asset. So I can say, it's okay. Well, there's 1,000,000,000, you know, beatbox in existence, basically. Right? I can then use this to verify anytime something's been created and make sure I'm not accepting 2,000,000,000 There's only 1 billing, with with that as well too. So the cool thing is, like, you know, someone can kinda maintain, like, canonical universe. You can view this kinda like a federated matrix server, maybe copy a git repo. But the same time, because SMTs are, history independent, I can collect all data myself and also make sure I'm verifying that we have the exact same path. So this is kind of, okay, well, everyone's kinda run the number to supply all your assets in real time as well, which is another really cool trade environment as well. Then you can say, okay, well, I can also kind of combine multiple assets, multiple universes into a multiverse, which is kind of like a assets, maybe some of the history as well too. So running with this system in there, which is, calling a POC universe, which is a key way to kind of aggregate a bunch of proofs, you know, as far as, transverse off chain. Right? So you kind of have, like, a federated system. Maybe it sounds like making a game, and the game is closer to any way. Like, maybe we have, like, some trading card games as part of the game itself. The operator can basically run this POC universe. We can actually save a bunch transfers. Because with a single transaction, they can do effectively an unbound number of, transfers within the system as well. There's different, you know, things that are occurring around as far as making it possible to exit things as well, but also different flavors for our security model. So here's the big question. How does tower work on l on l n itself? Right? So, you know, in the past, we did some things, you know, around, you know, like Litecoin swaps on Bitcoin. It sounds like way way back, you know, the 2 chains. I mean, people remember that. But, you know, we're kind of taking a different approach here. Right? Rather than actually having all the assets in the core of the network, the assets are basically fully at the edges. Right? Which is really cool because now, like, the core of the network doesn't actually need to update. They're still using Bitcoin as normal, basically. They don't even know this thing is actually updated. Right? But instead, we actually push the complexities all the way to the edges and basically have, just Alice and Carol and their initial   first and last mile being aware of the the the assets themselves. Right? This really cool because now we don't actually need an entirely new network for every single asset we're creating. Right? We basically use, you know, the $100,000,000 or, you know, 3.7 k BDC plus that's probably out of date already, you know, on the network of today. Right? This is really cool. Now we can actually, you know, retain all the network effects, actually reuse all that liquidity. So now we have, like, more demand transfers, which means more demand for activity, which means more free revenue, which means the network grows, becomes more useful. Now there's a, kind of, like, very cool flywheel, basically. Once again, keeping Bitcoin at the center. Now this kind of positions Bitcoin is kind of like the global, you know, crossing layer for any other value. Right? I don't really care what's at the edge, but any any in any case, everything is actually crossing in Bitcoin. People in the in the short network in the short network, they're actually actually getting all the routing fees in Bitcoin as well. And that's, like, a really, you know, dark part about the way things are set up.  

The other really important thing is obviously multi hop. Right? Multi hop is kinda like what changed everything when Lightning came out. Okay. Because I like to correct channel, it's not really cool. We wanna be able to make sure we're actually riding across the entire network. So, you know, if you recall, actually, Tara has, like, a scripting system within within itself. So we actually remap the existing HLC structure in the Tara scripting system and actually then just have HLCs working normal. Right? So now my multisig commits to a, a asset tree which basically out of your mind and your balance. HLCs now manifest, you know, both on the HLC lib and also on the entire layer as well too. We then we then actually use this actually handle a multi hop, whatever way it works. And the thing the way it works is kinda like you you can do, like, kind of a little trick of, like, the invoice kinda does most of the work. Right? So today, like, whenever you're using Bitcoin, maybe you're using, like, lightning. Maybe it stays, like, USD on the left side, but then you actually get a Bitcoin invoice. Right? Someone quoted. Right? Some converted happened there. People would probably just pay it. They don't really think about it. Right? But the way this works is, like, okay, now, like, if I'm sending from Dave, Dave gives me an invoice. That invoice now has that USD amount, basically. Now it's my job to kinda, like, you know, route everything properly with the network in order to date. So if I send too late, Dave's gonna cancel back. It's okay. I want a 10 set. You you just send me 9 set. Right? So it's a pretty elegant way of kind of pushing and collapsing the edges, also making sure that everything is primarily on the wall as well too. Really excited about this. And, like, so it's giving us a kind of a series of extensions onto the Bolt protocol. Right?   You know, maybe kind of a book format. We can kind of, like, add additional metadata to, you know, funding and also HLCs as well too. So it's kind of a really cool thing where people can opt into it. If no one people wanna use it, that's fine. They can enjoy, you know, the increased transfer and the the increased demand activity from all these new tower tower transfer, but now all of a sudden, we can do things, like, you know, go up more directly after credit cards. Maybe if people can, like, you know so I get in theory, I can send, you know, BTC, and the merchant receives USD at the other side. So now everything's fully onto the, actual Bitcoin system as well. The other thing is, well, too, this is gonna really dramatically reduce any of the cost on and off ramps. Right? Because now all of a sudden, it's already kind of, like, you know, in the, Bitcoin lane. Right? They don't need to worry about, like, going to an exchange, build that separate over can actually do a bunch of really cool things. The other cool thing, by the way, is how it works because it's all, like, in a fully Bitcoin input and output, we can actually kind of, like, have, like, non custodial swaps of anything, you know, on the actual Bitcoin chain itself. What's a swap? It's a multi input, multi output transaction, basically moving things back and forth, and that's Taro. And if you think this is cool, we're hiring at Lightning Labs. You know, many different positions, you know, researchers, engineers, people on front end, managers, talent engineering as well too. You can check out our job listings on the website and also maybe email us if you don't see anything that's on there that you think is cool and you wanna kinda, like, get into.  

But, yeah, that's Taro. Thank you.