support dispatch: https://citadeldispatch.com/donate
EPISODE: 136
BLOCK: 855113
PRICE: 1582 sats per dollar
TOPICS: roundtable discussion following the Rust Bitcoin Summit at Bitcoin Park
new to nostr? check out https://primal.net
website: https://citadeldispatch.com
nostr live chat: https://citadeldispatch.com/stream
nostr account: https://primal.net/odell
youtube: https://www.youtube.com/@citadeldispatch
stream sats to the show: https://www.fountain.fm/
(00:00:04) VanEck CEO on Fox Business Intro
(00:03:55) Rust Bitcoin Summit Overview
(00:04:02) Guest Introductions
(00:06:05) Rust Bitcoin Project Origins
(00:10:58) Rust Bitcoin API and Development
(00:16:08) Bitcoin Dev Kit (BDK) Overview
(00:24:07) BDK 1.0 Release and Features
(00:31:11) Lightning Dev Kit (LDK) Overview
(00:41:00) LDK Node and Integration
(00:47:52) Contributing to Rust Bitcoin Projects
(00:55:01) Funding and Supporting Open Source
(01:00:00) OP_CAT and Bitcoin Script Discussion
(01:10:00) Potential Risks and Benefits of OP_CAT
(01:27:01) Activation and Consensus Challenges
(01:39:00) Mining Centralization Concerns
(01:56:00) Alternative Opcodes and Vaults
(02:11:00) BitVM and Future Bitcoin Ideas
(02:14:05) Project Roadmaps and Contributor Needs
(02:41:08) Closing Remarks and Final Thoughts
[00:00:04]
Unknown:
Pounding the table because eventually the Fed is gonna start easing here. That's great for gold and that's for Bitcoin. What I said is Bitcoin is growing up and will be eventually half the total market cap of gold. So that's about 350,000. So quite a ways to go from here. The Super Bowls, if central banks adopted and, you know, it's part of the monetary system, then, you know, in the millions, but I don't like to talk about that too much. What more than 2,000,000? More than 3? Yeah. Like 2.9. We've got some model, which is you you have to look at the assumptions. Right. Well, yeah, there are always big ifs there.
[00:00:40] Unknown:
Where are you as an ETF guy
[00:00:43] Unknown:
with all kinds of different ETFs? Everything from fixed income to, you know, who knows? Staples, consumer cyclicals, etcetera. Yeah. Where do you put your personal money right now? I like longer term trends because I feel like, okay, it'll be a bumpy ride, but I like to have conviction about something that's gonna happen in 5 or 10 years. To me, there's no doubt that Bitcoin is becoming adopted the way gold is. I just think it's it's it's it's obvious. Now, I think you have to have your own diversified portfolio and kind of having a huge overweight to Bitcoin is a personal decision, but I I just see that rising. I'll give you another example, India.
The Indian economy is the best macro story. Everyone says the stocks are overvalued. I get it, but it's doubtless. The Indian equities have done as well as US equities over the last 10 years and will continue to do well. Correct. He but he was a gold bug. So Of course, the founder.
[00:02:09] Unknown:
Yeah.
[00:02:12] Unknown:
Happy Bitcoin Friday, freaks. It's your host, Odell, here for another Citadel Dispatch, the interactive live show focused on actual Bitcoin and Freedom Tech discussion. That intro clip was Fox Business with the Vanex CEO, humbly calling for a $2,900,000 Bitcoin per his model, says that Bitcoin will be worth half the market cap of gold. I'd like to remind the VanEck CEO that Trump said that Bitcoin is gonna be worth more than gold, so they can argue about that. And Michael Saylor called for a $49,000,000 Bitcoin, which if you're wondering what the environment was when I started doing 200 k by conference day in all caps, it was kind of like this. And it kinda makes me wanna just go $200,000,000 by conference day, but I'm gonna stay humble and not do that this cycle. Just stay on the stacks and and and focus on improving your skills. Guys, we have a crazy rip today.
Bunch of legends in the house. This is the tail end of the Rust Bitcoin Summit at Bitcoin Park. Obviously, last week, there was, quite the circus in Nashville with the Bitcoin conference, and, we also had a bunch of really great content and people here at the park. But we're a little bit masochist here at the park. So, of course, a Rust Bitcoin Summit was planned for the week following that, and And these gentlemen just wrapped on that. So without further ado, let's get to the show. I mean, I think we're gonna probably have, in total, maybe 15 to 18 guests, on this rip, and they're gonna cycle in and out. Right now, I'm looking at 7 people.
The rest are eating lunch, and they're gonna come in and out. Tobin, why don't you pick up the mic? We have Tobin Harding here. How's it going, Tobin? What's what's what what was the Rust Bitcoin Summit?
[00:04:14] Unknown:
How you doing? Good to be here. Rust Bitcoin Summit was a get together of programmers who write in the Rust program language, who worked on Bitcoin all day, and who wanted to come to Nashville.
[00:04:27] Unknown:
Let's go. And and who the hell are you?
[00:04:29] Unknown:
Me. I'm Tobin. I live in Australia, and I work in Rust on Bitcoin all day.
[00:04:35] Unknown:
And, I mean, you're also a rider like freak. Right? You you
[00:04:38] Unknown:
you listen about dispatch and rabbit hole recaps. So Dispatch tends to go for 3 hours, so sometimes I get bored. But, yeah, I listen to the actor.
[00:04:47] Unknown:
Well That's so interesting. You know? To the show. If if you're listening right now, hopefully, we won't make you bored. We have Andrew Polster here. How's it going, Andrew?
[00:04:59] Unknown:
Hey. Good to be here. I'm Andrew Polster. I'm the founder and, comaintainer of West along with Tobin, couple other people. So I'll try to share the mic. Yeah. Why don't you why don't we pass it down and everyone introduce themselves,
[00:05:13] Unknown:
because we have a lot of people here.
[00:05:16] Unknown:
So hi, folks. I'm Jose. I contribute to Buzz Bitcoin and BDK. We are welcoming contributors, so go hang out on GitHub. We have, like, very nice, contributor friendly, new, issues. So, yeah,
[00:05:32] Unknown:
come and join us. Awesome. Yeah. I'm Cody. I work at Feddy and, on Feddy Mint.
[00:05:40] Unknown:
I'm Dan Gould. I work on PayJoin DevKit and Rust Pay Joins to better Bitcoin matching.
[00:05:47] Unknown:
Rob Hamilton. I am a Rust Bitcoin and Bitcoin devkit prospector,
[00:05:51] Unknown:
and will be build our tech on the bank watch.
[00:05:54] Unknown:
Yeah. Hey. I'm Matthias de Bernardini. I'm, building on top of BDK and Rust Bitcoin, working at Anchor Watch with Rob. So yeah.
[00:06:05] Unknown:
So how the hell are we gonna structure this conversation, gentlemen? Why do we have Rust Bitcoin? Where did it come from? How do all the Do do you have a mic? I got my there's mics for me.
[00:06:15] Unknown:
I I wanna know how
[00:06:17] Unknown:
Russ Bitcoin, this project from 2014, turned into the basis for all of the applications built on Bitcoin. Now, you know, Cash App's using it. Well It's, like, uses it. It's everything. Well, first of all, I mean, dispatch has mostly a technical audience, but it's also a lot of technical curious people. And I think one of the things in the space that we want to see more of is, just more new open source contributors. I like to say, like, our our birth replacement rate is not great right now. Like, the devs die before enough new ones are born. So what the fuck is Rust?
Let's start with that.
[00:06:51] Unknown:
I'll I'll take that one. So Rust is a new programming language, you know, in terms of, you know, the history of computing and all of that. You know, you have Python, c. Those are, much older languages. But Rust is relatively new. And the purpose of Rust was to allow people to make programs that are both performance and secure. So for the longest time, you pretty much had to choose between 1 or the other, whether your program was very secure or it was very fast. And it was hard to sort of have your cake and eat it too. And this fellow at Mozilla, working on the Firefox, browser, I think his name is Sheldon Graden? Graden Hore. Graden Hore. Yeah. Andrew, the mics exist. Yeah. Yeah. Yeah. Talking to mic people. Those people. And he was trying to was working on this, on on the browser, and there was a very difficult problem that, they were trying to solve.
It was I believe it was the, the CSS render in Firefox. And this, part of the browser is very important because, you want it to be really, really fast so that your page loads. And the issue was that they had a number of implementations in c plus plus which is what Firefox is written in, and they pretty much all of them had one issue one way or another. Either they could get hacked, you know, just loaded with vulnerabilities, or it just wasn't performing enough. So, this this fellow went back to the drawing board and took all of the, you know, learnings of past 20 years at at the time and just combine them into one programming language and just start to work on it. And that was the sort of the beginning of Rust. Would you would you say that Rust is
[00:08:57] Unknown:
the hottest programming language out there right now? Like, I feel like it's it's hyped a lot. Like, people get really excited about it.
[00:09:04] Unknown:
It it does get hyped a lot because people are very excited about it for for a lot of reasons. The the biggest one is that you can if you learn it, you can start making applications that are both, memory safe and performant. And you can kind of have your cake and eat it too. I mean, there's there's caveats to that, but, people are definitely excited about it, which is which is positive. You know, in any new language, you desperately need, incomers to just come in and and adopt the language.
[00:09:41] Unknown:
But it it it does get hyped a lot. I don't know if,
[00:09:44] Unknown:
it's the most hyped up language.
[00:09:49] Unknown:
I mean What is the most hyped up language? CSS.
[00:09:52] Unknown:
CSS.
[00:09:55] Unknown:
I mean, Dan, look, if we don't take the what Mike away from this guy, he's just gonna talk the whole time. Yeah. Yeah. I'd say one of the really valuable things for it is that you
[00:10:05] Unknown:
by programming in Rust, you can eliminate entire classes of errors that you would get from programming in other programming languages, and some of those are, like, the most common production errors. Something on the order of, like, 70% of production errors end up being a, like, a memory error of some kind. And simply by the fact of programming in Rust, you can very reliably remove those classes of errors. So for really, production important materials like stuff around Bitcoin, if you can just eliminate those before you even deploy the application, it's very valuable, especially, like, when we're dealing with people's money.
[00:10:38] Unknown:
There's is there is trade offs. There's no silver bullet. So everyone starts off as a massive fanboy, but eventually, you hit an edge case in the language and it's annoying. But it is generally a fun language to write. But, yeah, we shouldn't be present it too much like it's all hollow because the air is so hot right now. But, yeah, there is downside. We don't need to go into all the negatives for their own negatives.
[00:10:58] Unknown:
Okay. So Rust Bitcoin. What is Rust Bitcoin?
[00:11:02] Unknown:
Well, Rust Bitcoin is a project I started in 2014 or so. So the the Rust language itself had its 1.0 in 2015. But prior to that, it was, I mean, it was originally created in 2008, and there were various iterations of the language prior to 1 point o. Really big things are happening. It's not like the Gmail beta where, like, everything changed for 10 years of beta. Right? Yeah. Rust language was dramatically changing pretty much right up to the week of the void. And I heard of this. I heard that Mozilla was using this for Firefox and their CSS renderer and and whatever and thought it was a pretty cool thing and wanted to stay with it. And at the time, I was already into Bitcoin. That was kind of the thing that I knew that I didn't have to go googling around to get stocks for. So that's why I started writing. And I was just kinda keeping up with the language evolution. If you look at the Git history of of Rust Gitcoin, you'll find also for syntax that no longer exists and didn't exist in in Rust 1.0 because it was basically a way for me to play with language features and, on on something that I was familiar with in in a problem domain that I had experience tackling with c and c plus plus and these other languages.
And in those early days, it was really just my personal hobby product. I was using it to scan the blockchain to like answer random problems that popped into my head. You know, like what's the average transaction size or, you know, stuff like that. And, and you can even find I was making PRs and and filing issues with the Rust compiler. That's an early RFC in the Rust programming language, which if you search for my name, you'll find it. So probably the worst RFC they gave a number to. But I fixed, like, 20 bugs in one shot by basically proposing that we remove a bunch of stuff from the language that didn't really work. Unfortunately, I wasn't the only one who did that, and there there are a bunch of missing things in Rust.
But, Yeah. Rust picked one of really just a toy for for the longest time. And, and I don't know exactly when it became a a big thing that we would have a a summit for. But there are definitely over the years, a couple of people showed up who knew Rust, who weren't writing c and translating into Rust the way that I was And weren't just like playing with obscure features and copying bad ideas from standard lib like I was. And they helped clean it up. And then later we had things like the BDK project, that started using Rust Bitcoin seriously for real. And, and then I realized that I should stop screwing around.
And at some point, I will actually stop screwing around, but I definitely definitely realized that I should stop.
[00:13:31] Unknown:
Awesome. Alakos, you gotta hand the mic. By the way, now we have we have 13 Bitcoin developers in the studio right now. We
[00:13:41] Unknown:
have I was gonna say, Alakos, if you wanna take on the question, you've joined in a little late. Like Yeah. That is question of why, like, why Rust Bitcoin? Why you wrote it in Rust? You could maybe take the the the the baton on that and say why,
[00:13:55] Unknown:
you know, make another wallet library in Rust on Rust Bitcoin. Would that genesis happen maybe? I think that's a great idea. The person who was just speaking was Steve Myers, a maintainer of of BDK, a Bitcoin park member who runs our our bit devs. And, now he's handing the torch to to Alexos Fellini, do do pronounce your last name correct? Yep. He makes that cool, NFC hardware wallet now. Yep. What do we call that again? What's his what? Oh, portal. Portal. Yes. Portal. So, Alex, go to Yes. I miss
[00:14:29] Unknown:
more than actual conversations. I'm not gonna repeat much stuff, but, yeah. So Rust is cool. Rust gives you a lot of security guarantee. I guess you already talked about that. Correct. And so was made in Rust because when you start a new project, you, just look for the best tool to get the job done, and I guess Rust was the best tool to get job done. It started as kind of an internal project I was working on with a bunch of consumer release and it also uses Rust quite a lot. So, yeah, it was just, I don't know, natural to to start using Rust for it. And there were there were, thankfully, great tools, Rust speak, Rust speak, or any. So it kinda made sense. I guess the language was good.
The people I was working with were familiar with it, and I was starting to learn it more and more. And yeah. And then the the ecosystem of us is developing was developing, still developing very well. So it makes sense to to be positive and and make BDK with that level.
[00:15:33] Unknown:
Awesome. I mean and I guess to go to where Dan originally started, so now, like so so BDK was was built with Rust Bitcoin underpinnings, essentially, and now there's a ton of projects that are being built on top of BDK, basically. Right? So there's, like, this whole ecosystem that's developing around this, and it's part of the reason why the summit exists.
[00:15:56] Unknown:
Yeah. There's a lot of dev kits now. We've also got Matt Corallo in the studio for, doing lightning dev kits. So maybe you wanna get a little bit of that because sort of the order of this was Rust Bitcoin, BDK, LDK.
[00:16:08] Unknown:
Yeah. So that it's Bitcoin devkit and Lightning devkit. Alright. Yeah. And then there's also
[00:16:14] Unknown:
Casu dev. Yeah. Casu dev kits in the room. Hey, join dev kits in the room. We're cornering the market on the dev kit. Fedi Min is Fedi Min is not dev kit. No We've been discussing mean Fedi Mint dev kit. We need to corner the market on the dev kit. Yeah. We have to log in and we kind of organize our repos the same way that you guys do. So I guess, technically, this kind of sister project, all these other things, kind of your sister project to BDK. BDK is on chain. LDK does lightning. And similarly, it's kind of a library designed to let people build, whatever they want based on using the Lightning protocol to build awesome wallets or awesome whatevers.
But he met now or several, I guess, Catu 2 has some options to use LDK to power the lightning, gateways.
[00:17:11] Unknown:
That has a bunch of mobile ones. Now
[00:17:14] Unknown:
I'll be getting node, which is a much easier, lighter weight API that you can get started with really quick, few lines of code, and you can have a lightning wallet in your app with LSP spec support. So we've got a lot of stuff cooking there too, but, yeah, there's there's just a lot of great stuff in the Rust ecosystem.
[00:17:34] Unknown:
Yeah. And the cool thing about Rust too is that we can kinda use this as sort of a baseline for all of the other languages as well because Rust is really good, support for exporting bindings in all the other languages. So it becomes a really powerful tool for have this be the base, like, have the reference implementations in Rust, and then they export bindings to TypeScript, Python, Java, Swift, all those other things that everybody else wants to do. So that's sort of what this whole summit was about for, like, how do we make the really strong core that everybody else, when they're building applications, can kinda build on top of.
[00:18:09] Unknown:
Love it. Phreaks, if you're listening and you're not in the Nostril Live Chat, the Nostril Live Chat is sidildispatch.com/stream. You do not need to have a Nostra account to use it. Feel free to throw questions, comments in there, or zaps. The show does not have ads, so please send me sats for my family. Cody, I mean, I you're the host here. I'm just the producer.
[00:18:35] Unknown:
Yeah. Maybe we could kinda cover what went on for the Rust Summit and sort of the big takeaways at the end of it. So what's the current state of Rust Bitcoin? What's of the one point o? Because a lot of our projects are versioning like BDK's cutting the 1 point o. But, for Rust Bitcoin, what does it look like for cutting 1 point o? Once they track for that and then we can kinda go back to the projects for the current state of them? Sure. I'll take that. So for Rust Bitcoin, as people who use the project are, grimly aware of, the the library has been changing very rapidly. The API has been changing very rapidly over the last year or 2 with the goal of getting towards 1.0. And for 1.0, we really want a API where we're using the features of the Rust language to create an API that's quite hard to misuse.
And better than that, an API where when you try to use it, it guides you by the shape of the API and and what functions are available and what conditions are on those functions into doing the right things. So that kind of complicated protocols, like, for example, building an address from a a series of scripts and then building a tap tree, for example. There's sort of only one way as a developer. Right? You've got a pile of scripts, and there's really only one way that you can put those together with the API to get an address out. Right? And that one way should be something that I mean, ideally, you just type stuff and then you get close enough that the pilot will tell you. And if not, you leave the docs sort of thing. And the library is not there yet. This is improving, with with every iteration for sure, but there's still lots of weird crafty things where you can do wrong things. So for example, in our our bit 32 module, bit 32 is a a way of deriving secret keys and public keys for wallets.
And the way it works, you have kind of the series of 31 bit numbers, numbers that are between 0 and above 2,000,000,000. And you can construct these in Rust Bitcoin with numbers that are out of range right now. And the API will let you do that. It's not going to tell you that you've done anything wrong. It will just do unexpected and nonstandard things when you do this. So there's stuff like that that we want to clean up. But as a consequence of this and a consequence of Rust itself having a gazillion crazy features for API designers, all of which have sharp edges and surprising limitations. You don't notice till months into trying to use them.
There there have been big changes to the library and and lots of simultaneously very fast changes and that we're changing a lot of stuff, but also very slow and that we wind up having kind of long arguments about individual piece of the API. So every 6 to 12 months, we we do a release with all of the crazy breaking overhaul changes that we've done. This pisses off all of our users who immediately have to rewrite their code. They'll find that there's some functionality they were depending on that we forgot to maintain when we were tightening up the API. And, and then they come to complain at us, and we're like, oh, well, we're in the middle of doing another round of that. But, yeah, we'll double back and, like, fix your things when we get around to it. We promise.
So the first day of the summit was Tobin and I going up there and and kinda talking about what we're planning to do to make everyone's lives smoother for the next few months. And we prepared maybe 0 minutes of material on this, and, nonetheless, we have 4 hours of of people yelling at us saying, like, it's not this, like, please, like, surely there's some way that we can do the the minimum thing. And, and where we landed, well, we we there's maybe 2 takeaways. So one is much of the ecosystem said, you know what? We're gonna freeze on Rust Bitcoin 0.32, and we're not gonna follow your updates for a little while until it stabilizes a bit. But the other thing is that kind of our first order of business in Rust Bitcoin is that we're going to pull the core components of the library, the structures that represent transactions and blocks and then the basic building blocks. We're gonna pull those into its own library called Bitcoin Primitives because that work, we pretty much nailed down what those look like. Maybe not every single feature, but definitely the core functionality.
We'll pull that out. We'll stabilize that. That will be a thing that never changes. And that will reduce a lot of the breakage because at least you've got that core library at the center and your dependence on Rust Bitcoin and its crazy changes are limited to maybe the edges of your library or or things that are easier for you to update.
[00:22:50] Unknown:
Yeah. I don't know much about that. Oh, more about what we did. Yeah. I don't know much about that. I mean, Angie just, like, hand handed Tobin the mic, and Tobin felt compelled to say something.
[00:23:00] Unknown:
Yeah. This is So, Cody, where next? Yeah. So then, the next day, we had BDK, and, so building off of the discussions of where we're gonna go with Rust Bitcoin, BDK is cutting the one point out. So maybe Steve, do you wanna get an update so I could I could pick up from there? So, yeah, we we kinda split the 4 days as from the bottom up. So Rust Bitcoin, BDK, LDK, the, Fedimint, and then what I missed. Yeah. And then all of the anything. Anything else. Like, all the projects. We have a lot of people. So in in addition to these space projects, we have a lot of projects built on top of these projects. But back to BDK, so we spent our day kind of like our our big milestone was hitting a 1.0. And for us, 1.0 actually, I should say 1.0 beta. We are probably a year late on this, to be totally honest, but, you know, designing you know, as Cassandra mentioned, designing good hard to abuse APIs is very hard.
And I think one of our contributions to the Rust Bitcoin team is that we just brought in a bunch of users that wanted to not learn the intricacies and just get sort of a nice simple wallet API. So doing on chain, you know, getting your balance, getting your, you know, making a transaction, doing RBFs, supporting, of course, descriptors with the full manuscript support, Taproot, all that good stuff. Just basically pulling all those components and bringing them together and making a nice easy to use API, but making a nice easy to use API is easier said than done. We also as part of this, like the, so Lloyd and Evan were sort of the 2 chief architect guys who had this great idea that, hey, What BDK started as was a simple single purpose make up single user library.
Hey. Maybe we could, like, break out some of these pieces and and, like, separate out a core chain tracking crate that did all of the the logic of managing when there's reorgs and things like that. And then just kinda the wallet piece is just sort of a layer on top of that. So, so the scope of what we originally intended for 1.0 sort of grew a bit with that entire rearchitecting. The initial actually, the initial, I think, impetus was just we wanted to be able to do asynchronous stuff. Like, we wanted to be able to sync the blockchain data to the wallet while the sync without blocking access to the wallet, like, say, getting a balance or making a transaction. That was kind of the initial, the initial threat we started pulling on that that ended up becoming, like, a year and a half long design and implementation project. Talk about it in February.
[00:25:30] Unknown:
Use the mic, Alexas.
[00:25:33] Unknown:
I think we thought about vk 1.0 in February of last year. Yeah.
[00:25:37] Unknown:
Yeah. Yes. I think we did.
[00:25:39] Unknown:
I think and I think I so much value. Yeah. I even had a t shirt made that said vdk one point o world tour, and it says 2023 on it.
[00:25:47] Unknown:
Here we are in, what is this? In August
[00:25:49] Unknown:
2024,
[00:25:50] Unknown:
but, hey. Yeah. I'm sorry for the reason. No. No. That's a good point. Yeah. The yeah. So, you know, we we one of the you know, our goals for this one point o, we know it's not perfect. Like, you're never gonna get a perfect API, but it it it meets the initial goals. It sets us up with a design that I think will take us forward into making future improvements. And it it gives, hopefully, it gives our users a stable thing to build their applications on for at least, you know, maybe the same of next year. And then whenever, you know, when when Rust Bitcoin is ready with something, you know, whatever their next big upgrade is. We already, like, have a big backlog of things we wanna get into, say, a 2 point o. So be prepared. But we will, you know, we're our focus right now with this beta is, testing much more tutorial style documentation as we do get a lot of new folks that are just building their first wallet potentially.
Yeah. So, you know, documentation, testing, and, yeah, just getting it ready to
[00:26:51] Unknown:
you know, for people to build and support products on that will be living out in the wild. I mean, I think a big mainstream success that we had announced this week was Proton. Yes. Thank you. ProtonMail created Proton Wallet on top of BTK. We call ProtonMail
[00:27:05] Unknown:
and are actually really, you know, true Bitcoiners, and they wanted to do an on chain self custodial. Of course, there's always trade offs, but they're trying to do sort of a mass market wallet. And they they have a great team to work with and they're very, you know they basically want all the privacy stuff. So whatever we can give them privacy oriented, they want it. They want us to put it in there. So that's, you know, part of this one point, it was also to help give them a stable API to break up, you know, to to build on and not break things while they're, you know, trying to, you know, they're they're gonna be supporting a huge audience of ProtonMail users that will soon have access. It's currently in beta, so you need an invite code in ProtonMail. But, you know, once they get out of beta, everyone's gonna have access to a Bitcoin wallet through our ProtonMail accounts, and they're gonna have a mobile app.
[00:27:51] Unknown:
It seems like the biggest thing they're missing, maybe I'm jumping the gun a little bit, though, is coin selection, and that is something that I think is missing in this ecosystem. I thought it was gonna say page 1. So b d k so b d k is so b d k completely supports coin selection. It's just,
[00:28:04] Unknown:
so much has gotta, like, implement it. It's more of a I mean, the problem is is Coin control. Coin control. So Coin control, just as a quick anecdote, we spun that up internally at AnchorWatch, and it was like, what? I'm I'm sitting next to Matthias here who could. It was like a day. Just really quick, like, one quick endpoint, and we have full coin control in our wallet natively. It was a very quick stab of a finger. The problem is, though, and I think they're gonna add it relatively soon,
[00:28:27] Unknown:
like, in advanced options. The problem is is fundamentally, coin control has a UX problem, which is, like, how do you conceptualize to I mean, this is like they're they're positioning it as my first Bitcoin wallet. Right? It's it's your first touch point into Bitcoin. They have I don't know how many users. They have a lot of a lot of users, and they've never used Bitcoin before. And how do you explain to them how to use coin selection? And so, like, why do you you automatically say join. You have a you have a queue in the background. Automatically.
[00:29:00] Unknown:
Up in coin control when you receive a pay join or when you set 1. Yeah. They I think they're more interested at this point in things like RBF because obviously, you know, fee rates might be low now, but in the future, they won't. Well, mempool dot space solve that. You just use the mempool transaction. Or maybe maybe, ShopBase Repair, and I think that might be higher on the purchase moment, but Andrew needs some Yeah. Well, the way I personally do point control. Right? So I have my my points are all controlled by a series of handwritten wallets. And I learned that I just don't ever need to spend more than 1 UTXO at once. And I don't ever need change. Right? So whenever I wanna move coins to a hot wallet, to my phone, or to an exchange or whatever, I just pick a UTXO, and I round down. I just, like, drop the last few digits, and that will be my fee. And I kinda wanna
[00:29:46] Unknown:
people solutions where you just throw away the clients. The question is why are you spending the clients? Yeah.
[00:29:53] Unknown:
I don't spend it. I I write fully collateralized options.
[00:29:58] Unknown:
I'm gonna go on a limb and say that you're not the average proton male user.
[00:30:03] Unknown:
Okay. But I would hope they support me. I I should mention we also have Big Key, which actually you know, Big came out earlier this year was it late last year as a mass market. Sure, BDK based, you know, meant for first users with, multi sig and hardware support for, you know, protecting the keys. So another example again of something Also, it doesn't have coin selection. Also, it does not have coin selection. Exactly. Has tight integration with exchange, but, you know, there's that's another, like, ecosystem thing built on Rust Bitcoin, EDK, Rust Mini Script, the libraries.
Yes. One of the one of the big ones I think that came out with EDK Day is it's very, very hard to make these primitives that work for a wide array of users. And so there's a lot of work that's being done at making it simpler, But there's, like, for example, like, we had a long discussion with BDK about how we could use BDK within the Fedimint wallet. Right? But it's like the primitive is a little bit different that we need versus what they need, and while we could probably roll something, the thing that they're designing for is something that's kind of most widely used, and they already got a good set of users for it. So and, I think another interesting thing that came out from the BDK day was that there's a lot of new users, and the first thing that they do is maybe it's because it's, like, SEO optimized or something, but the first place they land when they start working on Bitcoin development is in Bitcoin DevKit. Right? So either they'll land in your Discord or any of your other stuff. And then so a lot of the documentation that, BDK said that they would be working on is stuff where integrating it in with other projects. Right? And for our team, like, we we have folks that are focused on on language bindings who are also helping with the documentation.
That's the other reason, like, just for our sanity to have a stable API. When you're writing tutorial documentation, you it's very easy to keep the API documentation in sync, but if you're writing, like, a nice, easy beginner tutorial, you don't want the and we've had this problem, like, we're guilty of this where our tutorial no longer matches our API or any of our code because it's, you know, 6 months out of date. So keeping, you know, keeping the API stable for a year or so will help us have documentation that's valid for a year or so and that we can gracefully upgrade.
[00:32:13] Unknown:
So we have this problem for when we're discussing users using the software, but we have it all the way down. So we often well, first, when I came into Bitcoin, I thought, oh, this is not really that complicated. You know, we'll get on top of this in a few months. And then it turns out there's a few edge cases that you don't get until you've read the specific bit by the 3rd time. And so one thing we try to do in Rust Bitcoin is make it so that, a developer can come in and not spend 2 weeks reading the bit, pouring over the bit, getting frustrated and angry, but I can just come to the API and go, alright. I just wanna do more or less the basic thing. That'll do it correctly. But then we have someone else who has spent 3 days reading the BIP who's like, you idiots. That's not exactly correct. Mhmm. They're like, here it is. There's another function called underscore dangerous or something like that that you can get the exact behavior that we all think is wrong, but you can still do it. So we try to support people to do anything they want but make it obvious that you probably don't wanna do this unless you're really, really not doing. And that bubbles all the way up to the users. Right? Some of these things are hard. I just wanted to jump on that too that, you know, part of this breaking up our our crate our our Rust crates a bit is this, you know, we have sort of an opinionated wallet crate and then a chain crate which has all the little knobs and all the all the the lower level detail stuff. Now like for instance, for Fetti,
[00:33:31] Unknown:
we'll we'll most likely not use the wallet API because what they're doing is is not a standard kinda wallet, but we would use the chain crate. They just wanna, like, you know, use all the primitive stuff. So we now have that as an option that we didn't have before where it was no single purpose before. Jose, do you have something? Another takeaway, from the Rust Summit is that, we do have good API docs, but we need to have kind of like a cookbook.
[00:33:55] Unknown:
So something that newcomers can can see and and check how to do, like, common basic stuff on top of, Rust Bitcoin and BTK. And this is something that we are pouring some efforts on. We do have our West Bitcoin cookbook, and we have also the book of b k. And we were thinking of integrating this kind of, like, top level user friendly, docs and tutorials into a single one so that we can also link stuff and share, like, efforts between risk Bitcoin, BDK, Fedimint,
[00:34:25] Unknown:
LDK, and so on. So this is this is something that we are working on as well. I wanted to plug again also the language findings which falls into this, which is, you know, if you're a new person, you may not wanna learn Rust and you don't have to. We this is something that came up also in the Rust Bitcoin section was we know I think we have sort of a general agreement that, you know, if somebody wants to make you know, we'll we'll create a project, to support the Rust Bitcoin and then we also have for the you know, for people who don't wanna use the Vk wallet stuff, we'll have some just, like, primitive stuff from Rust Bitcoin available in other languages. That's like Swift, Kotlin, the biggie Swift Kotlin and Python are that kind of a lot of people use those, especially on mobile. And for BDK, we, you know, have extensive support for those languages as well as, like, examples how to actually build it for these mobile apps because, you know, we want more mobile wallets. Yeah. Well, maybe a a success story in Rust Bitcoin regarding trying to figure out how to support everything that's written in a bit, worth making things accessible and and understandable and also documenting it is what we did with the lock times in Rust Bitcoin.
The lock time story in Bitcoin is is pretty complicated. Right? There there are relative lock times that are absolute lock a lock time. They're lock times specified in terms of number of blocks, ones that are specified in terms of of seconds. They're kinda obvious edge cases there. They're non obvious edge cases. What does it mean to have a lock in seconds? But what it means is if you look at the blockchain and you look at the most recent 7 blocks and you take the median of those 7 blocks 11. It's 11. Sorry. Rob's telling me it's 11, not 7. And then there are multiple ways that these lock times are encoded. Right? So for every input, an absolute lock time is the code of personnel's action, but a relative lock time is encoded per input, like, about the age of the individual inputs.
And then another question about what happens. You have multiple inputs that have different kinds of lock times or or, you know, how do they mix? If multiple participants are trying to build this stuff, the lock handler encoded in a field of the transaction relative lock times called the sequence number. Well, there's a limited range of sequence numbers that actually represent lock times, conceptually. And then there's kind of a separate range of valid values that represent lock times when they're used in the check sequence verify or check lock time verify opcodes. And so for a long time in Rust Bitcoin, we were basically just using 32 bit integers for representing lock time, telling users that you gotta make sure that you're within the rules if you wanna use this. And some people, maybe it was kicked. I don't remember who exactly showed up and said we gotta make the proper API with proper types, and you can't construct the types unless you're you're putting the semantics of the bit. And I basically argued nobody can possibly know the rules for lockdowns. Like, it's it's not possible for you guys to do what you're doing. So you don't have your fun draft PRs and so on, but I'm not even gonna repeat what you're writing because it can't be done. And users don't want to use lock time. It should just stay within, like, really safe boundary, of of, you know, when you know, don't mix a lot of times and don't Mhmm. Use high.
Don't go close to the limits and so on. And amazingly, the the people who thought they could do it actually did succeed. And today, we have, a series of lock time types in Rust Bitcoin. And when I want to use lock times in Bitcoin, I go to the Rust Bitcoin docs and make sure that I can construct what I'm doing. I mean, I check that, the other the values that I want to use. I can actually use the Rust Bitcoin API to do what I'm trying to do. If I'm unsure what some of the rules are, typically, I'll check the Rust Bitcoin source code rather than trying to check the BIP and trying to check the reference code in Bitcoin Core. And if I even if I need to dig into the the BIP stuff, the API documentation for Rust Bitcoin have citations to the BIP for every rule that we have and everything that we do.
And that I think was actually a tremendous amount of work even if you don't care about Rust in making the bits themselves more accessible. So that, I mean, we went from from me saying that, like, no human could possibly understand this to now there's, you know, docs.rs slash Bitcoin, and you can you can look up the answer to whatever your question is. I'd say Rust Bitcoin also has very good examples. Like, they're extensively examples as well as documented. That's that's a goal we have for BDK is to have as many good concise examples for a lot of these things. Because myself, the first thing I'll look for is an example before I read the docs. And so a lot of people do that.
[00:38:52] Unknown:
I'm getting a warm fuzzy feeling right now because while this is a shared effort, I've put a lot of effort into that lockdown. So the downside is I put a comment at the top, and it literally says, if you haven't spent 3 days reading a bit, you probably don't wanna use all these functions. The downside that I didn't notice is I should have written, if you haven't spent, like, 3 weeks reading the docs, don't patch this module. Because every time I have to review it, it's so hard that I have to go back and read the PIP again. So just don't touch it anymore unless you wanna spend a long time going in. I'm glad I'm not the only one.
[00:39:24] Unknown:
I, I just wanna say, like, just to, like, Andrew's note, I think one of the success stories of Rust is being able to model a the problem space really well and sort of codify it into the Rust type system and just make it really concrete, you know, what's actually going on, you know, in in inside of our nodes, inside of our wallets. And, yeah, actually make it in a way, that that you can sort of write software with it really productively and actually get up and running, and put something out there for people to use and feel relatively good about it. You know? I think that's one of the big big success stories.
[00:40:07] Unknown:
Yeah. So something else that came up I noticed between a lot of the projects is that we've kind of used distinctions between, like, specification driven ones and then, like, the reference implementations. Right? And so I know, like, for LDK, LDK generally is, like, aligns with the lightning spec, and then there's LDK node, which is a reference implementation for it. And for the reference implement like, for Fedimint, like, there is no specification for it. There is the Rust implementation, and that's it. And for a lot of the Rust Rust reference implementations that we do, because we can export them with language bindings to other, to other languages as well. Right? Suddenly, you, like you know that when you get it, this is a correct implementation of what should be happening, right, either in the lightning spec or within the big one spec.
We've got Matt and Tino for from LDK guys. You guys wanna talk about the differences between, like, LDK node and LDK, maybe? Sure.
[00:41:00] Unknown:
So LDK is great. LDK tries to implement the specs all correctly and gives a lot of customizability to users. And, Yeah. Doing that is pretty powerful. It is, though, pretty big, and it's pretty it has different modules that need to be integrated to build a full lightning node. Which is great because they can be switched out. You can integrate lightning in your already existing wallet environment and stuff like that. But it's, not entirely trivial to get started. So the idea of the LDK Node project is to make it much, much easier to get started with a simple note library, essentially, with a smaller opinionated API surface that is much more controllable and gives more sane defaults that LDK already does.
Yeah. That's the core idea basically of LDK node to be a bit more, let's say, opinionated, a bit more conservative, but also a bit more fail safe for, users, essentially. And, LDK node comes with an integrated BDK wallet, so we are basically, not only Rust Bitcoin users, but also BDK users ourselves.
[00:42:18] Unknown:
Yeah. And, I mean, just Ilya said most of the work. He's not gonna brag about it, but I think the feedback we've had from people has been really great. It really is just one library you take as a dependency. It's in Rust, but supports many other languages through their great language findings, that exist in the Rust ecosystem. You know, you add this dependency to your app or your program or whatever it is and you call, like, 3 you call one function with a few configuration options, and you have a lightning wallet, bitcoin on chain wallet.
[00:42:51] Unknown:
You get the whole thing there ready to go.
[00:42:54] Unknown:
So it it really the the feedback we've gotten from people is that it it really just works super easy. You don't have to think about it. You get a you get a whole wallet. You get lightning support.
[00:43:03] Unknown:
Yep. And it's awesome. For, Feddy Mint, so, for a follow on to 0 dot 4 so 0 dot 4 dot 1, we have LDK gateway integration for that, and that was, like, extremely straightforward for just adding the LDK node initially. But then we have, like, this Fedimint specific stuff. And so, one of the another thing that came out of this was trying to figure out where do we have to fork it, where do we need to what can we use that we're not using yet. But just generally speaking, it's like a very effective note in a box that you just kinda drop there, and then you can add what you need on top of it. Matt, I don't think, so we covered, like, the origins for Rust Bitcoin and, BK. You wanna cover the origins for,
[00:43:41] Unknown:
LDK and Rust Lightning? Yeah. I mean, it was basically the same as as Rust Bitcoin. Right? I wanted to learn Rust. I wanted to learn Lightning, and so I started writing a lightning note in Rust, and it was just a toy. And then, then I kind of looked back and I spent a few months on it and was like, alright. Well, there's like a lightning note thing here that I wrote. What is this just a toy that I should throw away now now that I've learned a little bit about these things? Or, you know, should I find a niche in the market of lighting nodes that actually where this can add real value? And we obviously kept working on it. We decided this was great when we founded Spiral. We decided that actually this is something that the whole team should work on and dedicate a lot of resources to. And I think it's now probably by far the lightning node with the most engineering resources on it, at least working on the lightning part.
But so yeah. I mean, we, you know, we looked at it. We said, what exists in the lightning implementation market and what doesn't exist? And what exists and existed at the time and still exists today is lightning nodes, full binaries that you take and run on your server, that route payments, that do all this stuff and, like, you're an IP and RPC interface, but not something you can take and embed. So there's, Phoenix has their library that they use to build their app, and you can theoretically take that and embed it, but that's not really something they they primarily support. That's not their goal with the project. LND is one big honk and go binary.
In theory, you can run it in the mobile app, but it's pretty honking. It's takes a lot of resources. It it's a little it's not designed for it. Core Lightning is a multi daemon architecture, and that's not even you you can't get that thrown on the mobile. Good luck. But LDK, not only is it an embedded library, it's designed to run on any environment, whether it's mobile or server, but also Wasm. So, you know, we do all kinds of crazy stuff. Like, we stub out the TCP library so that it's actually an interface, And this lets people like Mutiny go and take lek, embed it in their WASM binary embed a WASM binary of it in the browser.
And when they wanna make a raw TCP connection out to a Lightning node, they can do that. They just have to stub it out and use a proxy that that proxies out your WebSockets. So we we stub out everything. Like Elias mentioned, this does make our API pretty big. We everything, every system call, every anything is configurable by the user, and that's just a lot of work to have to figure all that stuff. So that's why lpk node exists. But for those who want it, wanna do something super custom, wanna embed lightning in some really weird environment, that's why it exists and it works great for them. And it's the only game in town still.
[00:46:30] Unknown:
Very cool. Yeah. I think for now, one of the talk about? Why Cody's not wearing shoes. I took them off. Get it go. Make yourself a note. Is there Yeah. Is there more does Scott do more to this? No. They're right here. Yeah. Maybe let's go shoes. Yeah. Maybe let's go around again and for, what the contributor set looks like right now for each of the different projects. Right? Like, sort of, I think for people getting started within Rust Bitcoin and, like like we said, like, they kinda land at BDK, but, like, more on the dev side for contributors, right, of, like, what does it look like right now, like, for maintainers versus kind of, infrequent contributors and then, like, places where maybe you're missing, like, dev talent that you'd, like, wanna have? And honestly, on on Rust Bitcoin, because as I mentioned, we're changing the API so quickly and and doing so many crazy things. It's a little bit possible to new contributors. I don't mean that, like, we're mean. I try try not to be, you know, sometimes we're not You're not in you're not intentionally hostile? Yeah. Yeah. We're not we're not intentionally personally hostile with the environment is, like, when you show up and you're trying to do stuff and you're like, oh, well, for one thing, there's a lot of issues that look like they're straightforward, like, newbie issues where one of us just kinda, like, threw up an issue to remember something like, oh, you know, we should restrict the range of bit 32 numbers, right, kinda thing. And a new contributor shows up. They're like, oh, you know, create a a type wrapping a number, restrict the range kinda thing. Here we go. And then they do this and they get 200 plus comments on their pull request Mhmm. Saying that the way that they're modeling, derivation paths doesn't allow, like, infallible runs when you're trying to do a public derivation of a a path that only has public keys. And how we want to have the underlying representations being compatible so that we can use unsafe code to cast between our different wrappers of u 32 and how we have this mental model of how people should use the thing, which matches the bit to be clear and then match an actual usage. But, you know, we didn't write it down because, I mean, it should be obvious in the API. And so it will be obvious as soon as we get to it. And, anyway, instead of I mean, maybe we should be hostile. Maybe we should see, like, shoe instead of, like, offering individual critiques of these kind of things.
But what do we need on Rust Bitcoin? Right? But, I mean, what we need I would say we're actually not hurting for developer talent right now. And and that's a dangerous thing to say because we will be. Right? Tobin and I will get old, as we'll we'll kick, and then we're going to regret, you know, hoarding our stash of of Rust Bitcoin APIs. But what we can use obviously is more review. We can always use more review. We can use documentation and examples. Probably the the biggest thing is people who are using our code if they can show up and and discuss what they're doing.
And if they a lot of people try to use our code base and they they find that something's difficult and they'll kinda find a way to work around it. And at best, this represents a gap in our documentation, right, where they they really struggle because we didn't explain something. But at worst, there is actually gaps in our API. We didn't know that people were using it in a certain way. So what would be awesome is if the people using our crate could show up and say, like, this was a pain point for me, and I had to do this crazy hack. And, like, I did this, but it doesn't feel right. Or, like, I did this. And, like, I think you deliberately made this hard because you guys are assholes. And, like, we would appreciate that kind of feedback because most of the time, I think we're just oblivious.
[00:50:03] Unknown:
Yeah. One thing I would say is all open source projects, all free software projects always say this. We need more reviewers. And then when you come to a new project, you're like, how do I review this? I don't know all this stuff you're talking about. But you can ask well placed questions, and you can ask them by just looking at the diff. And then you bring up the code yourself and you look around it, and you're like, I can't see any reason why you'll do that. And so you can just ask the question, why did you use that type? Why didn't you use the type? Why have you put that function name sort of thing? And if the person doing the patch can't say, oh, it's because of x y z, then maybe they overlooked it. So, like, when we're totally infallible, we have to make mistakes all the time, some of us more than others.
And that that's okay. You know? And so a well placed question is really useful. So, yeah, anyone can come and review, look at the code, learn more yourself, and ask good questions, and, it's really useful.
[00:50:57] Unknown:
I I would just sort of second this for BDK. This is probably true for any open source project, especially, you know, Bitcoin, but probably any open source project. Like, start as a reviewer, ideally. We have a new full time contributor who came in, valued MAML, and he just started reviewing. And he just did really great reviews. Like, he just really looked at the code, thought about it hard, and, you know, just by doing that, became, you know, a full time maintainer on the project. The other thing is, of course, documentation since we like, if you wanna come and change your API, that's great. Love to have your contributions, but don't expect it to get merged for another 6 months or a year. So just have expectations with that. The stuff you wanna get stuff involved right away, it's gonna be documentation, examples, potentially side protocols.
You know, we're, you know, we provide a basic core wallet, but we need things like, you know, protocols for chain syncing. We have a a contributor here in the room, Rustation Rob, who, you know, built a compact block filter implementation for BDK and is integrating that, those kind of contributions. The nice thing about those is you can go You don't really need our review. You can go ahead and just write it and then help integrate it. We'll help you integrate it and, you know, get it into our docs. But yeah. Like, so immediate contributions, docs, side, you know, side add ons, you know, PayJoint's another example that, you know, and the Casu stuff. We have Casu, Rust contributor here. You know, those kind of projects are great because you don't really need our permission or or review. It you know, we'd we'd certainly love to help you, but, you know, for the core library, it's mainly gonna be documentations and testing at this point.
But yeah. So I think that's, you know, that's where we're at right now with BDK.
[00:52:32] Unknown:
Yeah. I mean, in LDK, we also all also really welcome any new contributors, generally. I would second, like, starting with review and just starting basically asking questions is is often the right way because, of course, new contributors also costs basically review time, especially in the beginning. And, so but most fresh contributors, I'm pretty aware of that. So it it's just great if a new contributor start off by reviewing and just, yeah, basically helping out with review. But in general, it's really great to to see that in LDK, we see a constant stream of new contributors, to be honest. And over time, a few really stick around and and make valuable contributions over the years, which is just amazing to see. So
[00:53:31] Unknown:
Is it worth mentioning at a high level, this thing we're doing, it's a meritocracy. So anyone can show up. And if you work hard, you try hard, you think about shit, you're not a total retard, then you can get there. And then we have things like this impression. Probably, you can say stuff like that, and people are gonna go, I'm like, god. That guy is like like, when they're looking at your face, they know you're just joking. It's a it's a proof of work thing. Yeah. Yep. Proof of work. But yeah. And also this is like when you're looking at someone, you get more information. Yeah. So we do these things so that when we're online, we can write messages that don't mean stuff. So if you see someone call someone spastic, then you don't have to be upset because you're like, oh, those guys actually ate together, and they drank together, and they know each other. And so that's that's the one we're doing this thing. I,
[00:54:10] Unknown:
we're, like, nearing the point where COVID and humidity stops listening to this little dispatch. So I just wanted to to be clear to the freaks, before some of you drop off, maybe. I mean, you should stick with us. I we have literally a room full of some of the most prolific Bitcoin developers in the world. It's kind of ridiculous and amazing. Rod, me, Harry, Josh from Bitcoin Park, we made the space available, but Russ Bitcoin Summit was possible because of of Tobin and Steve, Steve Myers. They they made all this happen. So you shout out to them, and then I'll just pass it back to Cody who's the host of today's conversation.
I think also, you know, should we go around the horn and and do Bitcoin price predictions? Like, I think that would be more. I get their free schedule. Predictions for a technical
[00:55:01] Unknown:
So much? I think we already said 100,000,000.
[00:55:04] Unknown:
Yeah. 200,000,000
[00:55:05] Unknown:
might count predictions. Anybody think that 2.9 just bearish?
[00:55:09] Unknown:
Yes. That's too easy. I go all the hands around. Without an absolute numbers. Yeah.
[00:55:14] Unknown:
We could do Oh, like, what's speak to you around. You're on.
[00:55:17] Unknown:
Yeah. Oh, that got spicy. Yeah.
[00:55:21] Unknown:
If I if I have one more thing just from the sentiment side, and this is also something You're the host. Summit that, I saw a lot is that I think where everyone here got a lot of good feedback from knowledgeable people who hadn't used their project before, like, documenting their experience with first coming to it. Right? So it's like when you first like, a lot of people we see this a lot with Fannie Mae. It's it's hard to get the feedback for it, but one of the most valuable things you can do as a new contributor is documenting your experience of first coming to the project and trying to set it up, trying to do it yourself. Because normally people, if they get stuck, then they just let go away. Right? But if that doesn't end up in a GitHub issue, if that doesn't end up in something being told to the Rust Bitcoin guys, the BDK guys, the Fedmek guys, then it's not something we can fix. And so I think everybody here at the Rust Summit had a lot of good experiences with people trying out their project from the other projects because they have they they don't know how specifically how to use LDK, for example, but they're relatively knowledgeable. So relatively knowledgeable Rust programmer runs into an issue, that's something that needs to get documented. And so anybody coming to the project who can open an issue like that, that's extremely valuable.
But, yeah, maybe oh, yeah. Jose?
[00:56:29] Unknown:
Before we lose folks, I just want to say how important it is to support open source. All of this is possible because we have, like, very big, and bright ideas. We have open sets. We have Grain. We could have a spiral who will kind of, like, help us organize the summit and also have a Right. Yeah. We also have Casa Michonne at Brazil who also supports open open source debts to also work on Buzz Bitcoin and related stuff. Right platform? Yes. Right platform as well. HRF. HRF. I might be missing someone. I'm here from Chaincode. Chaincode. Yes. Chaincode Labs as well.
K.
[00:57:09] Unknown:
Yes. Very important. Fund your open source distributors, and everybody should donate to Open Sans. Yeah. Give us There we go. Open sans.org. Is Riot Platform Riot Mining?
[00:57:18] Unknown:
Yeah. It was Riot Blockchain then. I thought they became Riot Platform. Okay. Are they Riot Mining now? I don't know. They're awesome. I just I don't know what the name is. Them Riot. Yeah. Know what else I'm talking about. Okay. Well, then you said right platform. I know I do what you're talking about, so I had to double check there. You wanna find out? I would just I would just add, yeah, we can go to Spicy. Foundry, because you mentioned Riot and Riot's Mount Mining, and Foundry is, you know, the KYC suit American based pool, who's who's been doing great work. This is supposed to be a compliment of them.
They recently launched their own open source, funding mechanism within their GUI. So any miner that uses Foundry can have a drop down, and I know OpenSats is supported. I believe HRF and Brinker supported. I think they're gonna add a few others. But that's just really cool. I think, you know, as a non dev myself, lowering the friction point to supporting open source contributors is incredibly important. I think a lot of people wanna support, but but it it's too difficult for them or they get overwhelmed, and then they get, like, decision paralysis, and then they go on and live their life and and don't make it happen. So the more ways we can make it, we can reduce that friction, and I think Foundry did a really good job with it. We worked with them pretty heavily in terms of it's literally just a drop down, and they they you can pick how much of your hash just like it's donated, which is awesome.
Cool. So, Opcat.
[00:58:44] Unknown:
Andrew, you wanna kick it off? Sure. Alright. So for those who don't know, of course, Opcat the concatenation off code for Bitcoin script allows you to combine 2 elements on the stack. That's all that it does. So if it's a pretty low level thing, I don't think it would really affect anybody. There would be any controversy about it. But, you know, it's a missing functionality. I think you should put it back in the Bitcoin. And, yeah, it's a pretty mechanical thing, I'd say. Right? It's just like routine maintenance of the Bitcoin protocol to add a little bit more functionality. But I expect we should be done that in the next couple of weeks. Yeah.
[00:59:21] Unknown:
Does anyone have a different opinion?
[00:59:24] Unknown:
Well, I think a big takeaway from the, Bitcoin plus plus that was in Austin about script and op heads was that the order of these things is, currently a sufficient argument against basically anything that you wanna add to Bitcoin is that it has potentially unforeseen consequences. Right. Right? And so one of the big announcements that Rusty Russell did at Bitcoin Pixel Plus was announcing his great script restoration project, which is a mechanism of basically writing the script interpreter in a way where you can define the effect of adding a new opcode into it. And so, for example, for OPCAT, if on the engineering side, you can prove before you activate it that this is not going to increase the worst case validation time for a block, right, then that gets rid of a whole class of arguments, which I think is sufficient for anybody now that Bitcoin is so big to halt any new opcode activation or any sort of functionality upgrade up, upgrade, just generally speaking. Right? So, like, on the in the Twitter sphere, is the fact that there are unanswered questions about this opcode, I think that's sufficient for them to say, no. I don't wanna support it. Right? Yeah. I mean, the concern is, like, edge cases that people
[01:00:45] Unknown:
that, like, Andrew can't foresee.
[01:00:47] Unknown:
Exactly. And the, the goal of Rusty's Great Script Restoration Project is what if we can define beforehand what this is going to look like and prove that there's not gonna be this edge case when it comes to increasing specifically, when it comes to increasing validation time of a block. Right. From a technical perspective, Cody's totally right. Right. There are some ways that we could extend Bitcoin that actually would break the validation model and or would make it harder to reason about the validation model. You can imagine adding opcodes that did, like, random disk access or opcodes that added extra metadata to your TXOs and meant that when you were checking whether coins have been spent or not, there's also a weird thing that you're doing.
One of the the biggest ironies of off cap, right, is that it very easy to reason about in terms of node cost. Right? It doesn't introduce any new ways to introspect transactions. It doesn't introduce any new ways to do transactions. All it does is take 2 elements in a stack while you're running a script and put them together. But if you go to a higher layer, it turns out that this allows you to get access to transaction data on the stack. And you do this by using the checksig opcode, which is an opcode that reads the whole transaction and and checks that you've signed all of it. Using offcat, you can kinda like in conjunction with checks that you can kinda pull the transaction data out of that. And as a result, now you can do things like covenants, and now you can do things like colored coins directly on chain. And you maybe could do like DEXs or some sort of multi asset thing. And you've gotta think about NUV, and you've gotta think about mining incentives. And the whole thing quickly becomes kind of intractable in in much of the ways Cody was was worried about from a techno perspective, but but here we're on a much higher layer trying to reason about economic incentives in a world where people are doing arbitrary stress. Yeah. Like, you know, because it's a line that
[01:02:44] Unknown:
whatever. Actually, you talk. Yeah. I was about to say the same thing. So I think the problem with engineers. And and my personal PMD on the pop cut is I don't care. Like, I personally don't have any use for it. My the thing I'm working on right now, I'm gonna use for it. So I personally don't care whether it's or not. So I'm not speaking against it because I I I don't like it or something. I mean, feel free to speak against it if you like. Well, I mean, yeah, what I wanna say is pretty much what Andrew said. So engineers kinda get stuck into this. I can prove there's no additional cost to that. That's okay. That's fine. But then there's, potentially unintended nuances that happen because of,
[01:03:23] Unknown:
new use case we should be able to. So Yeah. Yeah. Okay. So I've heard, very, very smart people in this room at other times, you know, not to quote people out of context, but, say things along the lines of, opcat may introduce non trivial NVMe v vectors. But, I've never I never understand what people mean by that. It seems like nobody's able to specifically talk about the MVP vectors. So I get it.
[01:03:46] Unknown:
I was having lunch, but we were listening to the the live stream in the other room. So
[01:03:52] Unknown:
You're gonna be back.
[01:03:54] Unknown:
So I didn't finish my lunch. I'm a little annoyed
[01:03:56] Unknown:
Thank you for your sacrifice. Yeah.
[01:04:00] Unknown:
I I think so unlike every other self work we've ever done, covenants might materially change the kind of high level things you can do with Bitcoin, like, Segwit enable some things with the, no malleable transaction IDs, you know, make lightning more practical, and a lot of things more practical, same with CSV. But the amount of new things you can do with those pales in comparison to covenants. I think we've seen this with a lot of discussion around, all kinds of ideas that people have for covenants both with CTV, so non recursive covenants. And now, there's more discussion about recursive covenants again. So, cat does enable fairly inefficient, but in theory, are arbitrary recursive covenants.
So, if you imagine and and I think it's important to recognize this because, you know, we can't screw Bitcoin up. We we really have introduced
[01:05:04] Unknown:
Meevil in a big way. We're we're kind of focused. Like, we really are at that point focused. Yeah. But, like, what are the I I we'll get there. Right? I just wanna set the stage a little bit. Yeah. Yeah. Well, I just just real quick, Matt. Like, MEV is minor extracted value. It's like adding different variables that miners can play with the chain to try and extract more profit, so it it fucks with everybody.
[01:05:27] Unknown:
Yeah. So, I mean, we've seen this on Ethereum. Right? So in Ethereum, creating a block template, so selecting the transactions that you wanna block is sufficiently complicated that there's 2, 3, maybe only one company that can really competitively build a block template. Right? And so there's really only 2 or 3 companies that can mine that would be able to mine Ethereum profitably, if it were proven to work still. Proof of stake, you actually have some other benefits that help here. You can stake non profitably or stake with less revenue, it's not really a big deal. If you're a miner, you're mining with less revenue than all your competition, you're gonna go out of business. You're fucked.
So, we'd end up with, you know, the same world that Ethereum has which, again, this is unrelated to their centralization, do you have proof of stake and stake centralization, Just the centralization of, just the centralization that is created through Mev and for Beeville results in there only being a few milliseconds in mine in mine. What does Maval stand for? Is it Just just Maval. Maval. Okay. Got it. That's what I thought. The actual definition of Mav is is much broader. It's super it, like, includes fucking everything. So it's kind of a useless term in practice. If you start talking to, like, a billion people, it it it's not what we're talking about. We're talking about something much more specific, and it's the centralization Got it. From Mev and those kinds of systems. So And Meville. It's a different term. Call it Meville. Sticking with it.
But, anyway, so to answer the original question, there are a number of different MEV vectors in Ethereum that create a lot of the MEV, but I think by far and away the biggest or maybe 30 or 40 percent of Mav is DEX volume. So people trading their random coins, some NFTs for, USDC usually, but often Ethereum itself. So the most immediate concern for Bitcoiners should be can and will someone build a DEX with this, and especially also AMMs, but just a gen general DEX might be problematic. And it's not clear with CAT. I think it's very unclear. Right? So there's, a lot of people who've argued, no, you can't build a DEX because the existing Colored coin protocols don't allow you to build a DEX with cat, but that's not an interesting threshold. Right? Because if you can build a DEX and especially if you can build an AMM, people will And so someone will come up with a different coin protocol.
And there are some I think I've seen at least 1 or 2 proposals for ones that are pretty bad, but in theory, you can kinda get a deck. You can get a dex, but AMM maybe. So so it's unclear. There's definitely been very little research into this. There's been, like, a few people talk about it on Twitter, and they seem to have different opinions, and it hasn't gotten very far. So that's the immediate concern. There's other forms of Mab that could pop up. Right? So there's base roll ups or things that people are clearly working to build, and if we see those become large, they will be a platform for for DEXs and AMMs, and we won't that it doesn't matter whether the script supports it directly. If you have a a base troll up, you can build that.
So there were various things that could happen with or without CAT. I think it's clear that CAT makes them much easier. So bit VM, it's not, you know, it's still very early research, bit VM, efficiency numbers, but currently the efficiency numbers look like it might end up being the case that with cat, you can practically build bit VM, without cat, you can't. So the current efficiency numbers for bit VM are, like, you know, if you wanna actually get a proof that hits the chain, you're talking about a week's worth of blocks or maybe more. So, like, maybe that isn't practical, but certainly with CAT it is. We've seen numbers that are, like, you know, a few blocks or maybe one block, and that becomes more practical. So, you know, maybe with CAT, we would see based roll ups, but without we wouldn't. It's kind of unclear right now.
And so I think there's there's a lot of ongoing research on several directions that will give us a little more clarity on what you can build with CAT, but also, I think it's, again, just really important to recognize that we, like, we screwed this specific thing up, we're screwed.
[01:09:57] Unknown:
Yeah. Yeah.
[01:10:00] Unknown:
There are 2 two points to add. One quick one. Right? Because as Matt said, there's not a lot of research into this, and I should show for the, start where a research grant related to OPCAT. If you have any ideas for how OPCAT can benefit or more importantly, confirm Bitcoin, you can look up this stuff where OPCAT research grant. They have a $1,000,000 that they're ready to give out for, for small kinda like 3 to 6 months research grants. I'm not affiliated with StarkWare, but I am sharing this research grant. So I should just kinda throw that out there. And then the other kinda more philosophical thing, right, is that the the threshold amount is describing where if we cross this line in Bitcoin and then we have all of a sudden, we can create DAX and we can create MEV.
This isn't, like, unique to op cap. We're kind of, like, beside this cliff in Bitcoin development.
[01:10:55] Unknown:
And It's also fuzzy. Like, it it is clear you can build base roll ups today. They just can't be bridged, so maybe people won't. There's cases of people doing, some of these existing centralized exchanges with, with, token, with ordinals, which could, in some cases, create Mev. You know, you also look at some of these other side chain protocols that that exist in merge mining. Like, merge mining could create substantial Meebel. There there are a lot of ways that we could create it, and it's not clear, you know, it's very fuzzy. It's not a clear line. It's not clear which things we add to Bitcoin would shift that line or not, but it is something we need to do a lot of research on before we make changes. Right. Yeah. And it is
[01:11:44] Unknown:
yeah. It is definitely a fuzzy line, and there are some ways like, there are external external incentives that you can create for Bitcoin. So for example, on the Ethereum chain, I I conveniently have the block counter in front of me. Right? I could write an Ethereum contract that will pay you out, 1 eighth for every instance of block 855-119 that you give me. And then miners, so maybe it has to be more than 1 ETH. I don't know what ETHs are worth, but, you know, maybe a 1,000,000. Alright. Well sorry. I'll give you infinity, so it's worth, you know, a Bitcoin.
And I'm gonna give you this for every instance of block 855-119. Then in theory, miner to be incentivized to stop and masking the chain and just create 855-119 over and over and over and keep extracting until all of my infinity ether are gone. Right? So without even changes to Bitcoin, I can construct things that that sure look like Meebo. But having them on Bitcoin
[01:12:43] Unknown:
no. I I don't think whether it's on Bitcoin is relevant and and totally. I mean, there's you can absolutely construct Meebel today. There are absolutely cases of Meebel that had existed where miners have been able to extract a little more value. You know, we see slipstream from Mara. You know, they accept nonstandard transactions. This is something where they had to hire a full time engineer, pay them substantial money, you know, find someone competent, and as a result, they get some very small additional revenue from doing so.
But that's a lot of work, you know. So that that is Meeval, but they invested way more money than they actually got. Right? So, like, there's the Meeval we see today is very very small. If you're a small miner, you know, you're talking about fractions of a percent. It's not gonna make or break your business. You know, your your margins are only a few percent. Right? So large fractions of a percent would make or break your business, but but, you know, fractions of a fraction of a fraction of a percent are not. And so the question is really, are we going to add things which create enough meevil where suddenly it's, like, really material, you know, where we're talking about half a percent, a percent of mining revenue change, that's gonna break Bitcoin incentives.
Right? But if we're talking about fraction of a fraction of fraction, that's okay, and we do see that today already. It's just a question of what new things are people gonna build in, and to some extent it's a question of like predicting, you know, what are people gonna build? I've seen people argue, no. No. No. Based roll people don't build based roll ups. They're not built on Ethereum because, there's financial incentives for people to build non based roll. If you can have a centralized sequencer, and then you can make money as the sequencer because you're extracting all the revenue, you're extracting all the Mav. And it's great. Like, okay. Yeah. I mean, if if people really won't build based roll ups, then maybe we're okay. Maybe we don't need to worry about that. But people can build them, and should we bet Bitcoin on the fact that people won't.
And then also, you know, we see a different community in Ethereum versus Bitcoin. Right? We see Ethereum people don't wanna build these things, but they also don't really have a lot of the same reaction to centralized parties who are extracting fees can't steal your money but are extracting fees as you often see in the Bitcoin space. And so instead, we've seen people actually building base products in Bitcoin. Yeah. We've seen, people building libraries to enable people to do that. So, you know, it's unclear. I mean, this is this is not things we've grappled with for Softworks in the past.
It's new, it's novel, and, like, it's something that the community broadly needs to discuss. It's not something that a bunch of developers in a room can decide. Like, the the Bitcoin community needs to decide, is this something we're okay with? Are these trade offs worth it? Are these risks worth it? Because we do get a lot of value. I'm excited about opcat. More so other script restoration things, other other covenants. I wanna use really awesome covenants. I wanna build all kinds of weird lightning derivative things and, like, a more awesome, more scalable lightning. I want people to have payment verticals that are somewhere between custodial and noncustodial that scale super well and let everyone have Bitcoin. But, also, I know we can't we can't take that risk if it goes the wrong way. So it's something the broad community needs to discuss.
[01:16:09] Unknown:
Yeah. These these are all great points. Right? So I guess we see on Ethereum that very bad thing that happened. There are a lot of very big differences between Ethereum and Bitcoin. Right? And I guess the one technical difference that off cat affects is whether within a Bitcoin transaction, can you introspect and constrain the transaction being spent. Right? So can you do covenants? Can you say these coins can only move to these destinations under these circumstances and so on? And, yeah, the the comment that, the Rob one h there. I'm not sure if he's related to the house and Rob h he's talking to. Yeah.
[01:16:46] Unknown:
Yeah. He's in he's in the room right now.
[01:16:50] Unknown:
I I was being strategically ambiguous. The so with with with how to calculate Well, there's this technical change. Right? Whether or not you can directly do covenants. Right? Upcap gets you that. Maybe in such an inefficient way that these covenants turn out like, the the, evil that you could create with these covenants is, is just too inefficient for you to actually make money. Maybe it turns out that transaction introspection and covenants aren't enough. Maybe we'd also need an account model or or something like that for these bad things to come to account. Maybe it's not hinted at, like, there's just,
[01:17:30] Unknown:
cultural differences. Right? We would need to have some sort of the kind of community in Bitcoin that would move the entire chain of proof of stake in order for these problems to occur. And we don't have a clear idea about when when No. I think it's the other way around. I think with the coins community, you're more likely to see these kinds of decentralized systems that create meable, whereas in Ethereum, you see centralized systems that avoid it. Because often, when when you add a centralized sequence or when you add a centralized party, you avoid the MEWL because that centralized entity just takes the MEWF and pockets it. But I think the account model thing, I've I've seen that come up a number of times, so I wanted to address that.
That's a really a red herring. Like, we've seen on Liquid, people have built AMMs. They're like, people can't build this thing because they want an account model. That's nonsense. Right? Instead, you're actually gonna create more Gmail. What you'll do so if you imagine, like, a a completely flexible script, Bitcoin scripts, you can do anything you want. You will build an AMM that just has one UTXO. Right? So, like, all of the AMM funds and logic are in that one UTXO, and then when someone interacts with the AMM, they spend it and they create a new UTXO, and now all the funds and logic are in that UTXO. And it's fine. That works great. This in fact creates a lot more evil because now miners need to write more Bitcoin Core, but I don't know if Bitcoin Core is gonna it. Write a bunch of additional custom software to handle this concept of, like, that much state and stuff in 1, UTXO where they now have to, you know, be able to rebase transactions. Right? So you'd be able to say, like, I saw this transaction in the mempool. I wanna include it, but there's this other transaction that first spent this AMM money, and now I need to, like, take that other transaction and change the input to the other one, and do do, like, transaction rebases, all kinds of complexity there.
So it I I I don't think that's relevant. In fact, I think it might very well make works. It might mean just more complexity on the side of miners, more private relay networks where small miners aren't able to get all the transaction data that big miners are.
[01:19:37] Unknown:
I'm I'm skeptical that it's more complex than the UTXO model because in the account model, you have, you know, maybe, you know, a 100 transactions and any 80 of them depending on the way that you order them. Any 80 of them you can include. Whereas in the UTXO model, you just have, like, one path. Right? You have one UTXO. So you have to have 100 transactions. No. You still have to, like, rebase them. You do have to rebase them, but rebase them is It wouldn't you're right. It's not, like, a huge difference. I think it's clearly the UTXO model is not
[01:20:05] Unknown:
less Beeville creating. There's a little more complexity. Mine is set to write a little more software. Hopefully, that software is not too complicated. And so it's gonna be okay, but they do have to do more work because they have to do this kind of rebasing logic. They have to I don't think that's more work. I don't think that's software. Well, I mean, it's just work that you didn't have to do otherwise.
[01:20:24] Unknown:
Maybe less a solution space, but I think I think it's less of a of a solution space because you do have those dependencies in the UTXO model,
[01:20:33] Unknown:
but it's probably the same amount of work. Yeah. It's just that you you remove the dependencies. Right? Like, you you create no dependencies because you have these covenants rather than actual dependencies. Just the miners have to do the work to rewrite the Well, that's the actual inputs. There's never no dependencies. Right? In a rich statefulness model where every transaction is manipulating a global Same kind of dependencies, I would say. In
[01:20:57] Unknown:
no. In in Ethereum, every transaction depends on every other transaction in principle because they're all manipulating the same global store. That's that's a point. Yeah. I I mean, specifically for just if you're just interacting with the AMM contract,
[01:21:10] Unknown:
the total dependencies and the total complexity there is is the same. It's just you have to actually rewrite Bitcoin transactions to make it make it work that way. Yeah. A a couple clarifying questions maybe. So,
[01:21:21] Unknown:
like, rough consensus, generally speaking, is that no legitimate technical question goes unanswered before the activation of it. So, like, a legitimate technical concern there. Based on the way Bitcoin like, pre script restoration project, is there anything that we could do for activating opcodes, anything like that, where we could answer the technical I mean, I gotta I've just focused on the engineering side, but, like, that's the thing that we can directly control. Is that are there any of those where we could feel confident with Bitcoin as it exists today, activating something new where we could answer every technical question for it, defining the behavior for it. Seems like a strong man. I I don't think
[01:22:04] Unknown:
so first of all, I think that answering the technical questions around OPCAT and other things are super easy. We're probably basically there. Like, the the actual, like, is this implementation fine? I mean, like, we could get there a month. Right? Like, we're probably already there. Whatever. The Meavil stuff and the higher level, like, is this gonna break Bitcoin stuff need I think we can still answer it. We can still address that point, but we need to do the research. Right? We need to sit down. We need to say, let's create, not just, like, talk about how it's hard to create, but actually go create the best token protocols we can that use off cat and then build the best, AMM or the best DEX we can using these token protocols. What's that gonna look like? Let's go, you know, have a conversation in the community about, like, are people actually gonna use based roll ups? My intuition is certainly more so than Ethereum, but I don't know. You know? I'm I'm just one guy. I know that the roll kit people told me to eat shit. They're gonna build it anyway. Right? So, like, where is the Bitcoin community here? Where is like, why aren't people saying this is bad, this is something we shouldn't do? Like, these are things that that the Bitcoin community can do broadly and also especially research. You know? Andrew mentioned the the grant from startware, I'm sorry, which I think is great. I think that's the exact kind of thing we need to be doing. We need to be funding people and and certainly finding people. Money is one thing. It's really about finding the dev talent, the research talent. But we need to be finding those people who are talented who can do this kind of research and analyze the problem and say, here's what we can build. Here's why it sucks. Here's what we can build in ways that don't suck. And then the Bitcoin community can sit down and say, okay.
I think the things that suck, that create evil, suck so hard that no one's gonna use it, and are they gonna use the decentralized options instead? Because that's really what we're talking about. We're talking about we want people to not use a decentralized option and use a centralized option instead because the decentralized option breaks Bitcoin, which flies in the face of everything the Bitcoin community loves to do, but that's that's really what we're talking about. It's really what we need people to want to do. Yeah. And then another question for this is,
[01:24:11] Unknown:
I think we've got, like, 12 or so different projects represented here right now. Is that have we come up to the limits of Bitcoin as it exists today in terms of development work and, like, stuff that we can do going in the future? And maybe, like, we could kinda go around for people to describe, like, how much they're doing, but, like, I know with Infangement, we have, like, a multiyear road map for Bitcoin as it exists today requiring no changes, where it's just more resources
[01:24:35] Unknown:
can get better results for users without any changes for Bitcoin. Certainly, as simple as Lightning, we have at least 5 years worth of features to show.
[01:24:43] Unknown:
Yeah. Same for us, but
[01:24:46] Unknown:
But I I think I I think it's a point to push back on that a little bit. Like, I know all of us have a 5 year roadmap, you know, if we ship opcat tomorrow, we're not gonna look at it for another 5 years. Right? But it is it does again because we're talking about we're we're really talking about a fundamental shift to the nature of what we can do with Bitcoin. And again, I think, you know, there are limits to the kinds of systems we can build today in Bitcoin that potentially get removed. And, again, there's more research needed, maybe it's not efficient enough to be practical, but potentially get removed. And we can start to talk about a lot more systems in the gray area between custodial and noncustodial, and that's really where Bitcoin needs to get to, you know. There's this, I guess Peter McCormack always loves to talk about this, kinda like what what do we do when not everyone can own a UTXO? Like, how do we get people on Bitcoin?
And you're not allowed to say custodial. Maybe you're allowed to say custodial, but I'm gonna add that restriction right now. You're not allowed to say custodial and and we don't have a good answer right now. Generated custody.
[01:25:47] Unknown:
Well, I mean I think that you used the word custody. I think you might have broken the one rule. There was just one. But I mean, the night the nice thing about Federman is you don't. It doesn't require a software. I mean, I I'll I'll be the monkey brain in the room, like, the left curve of IQ. I will say, like, the opcat discussion, to me, opcat feels like an attack on Bitcoin, and I'm a little bit conflicted because You just think that because it's Udi. No. No. No. Yes. And and and Andrew, who's incredibly high integrity, like, breaks the template a little bit. It's like it's like Udi and the degens. Like, I know And then Andrew.
Is Ethan. I love it. Yeah. Ethan's awesome. Integrity. And, but besides all of that, I mean, this is just leaving out the activation question. And, I mean, I would personally propose that the way we decide if we activate it or not is is which side zaps more. I think it's a good way now. Yeah. During the show. By the end of the pandemic. It's the best activation method for Bitcoin.
[01:26:52] Unknown:
Also, yeah, I'm still very curious what people's, over under would be, in terms of, like, a date, for activation. Is it 2 years out that there would be a 50% chance before or after a date?
[01:27:02] Unknown:
I mean, it seems like there's some movement towards doing great consensus thing up first. Negotiation notes. That's getting revived a little bit, and that's still probably a ways away. And so if we have that first, I mean, they're talking about a ways away before we start thinking more seriously about opcat activation being something other than a weak one.
[01:27:21] Unknown:
What's what's the number? 3 years? 3 and a half years? I'm gonna throw out 3. I'm gonna make a darker prediction though, which is that all this horrible cat stuff is within the next 3 years, people will figure out how to do it without cat, and then cat's not going to be the thing that pushes us over the edge because we bought, like, movie in the world that we're not sure how to navigate.
[01:27:44] Unknown:
Well, I mean so, to bring it back, like, if if you're an average user if you're an average user from a use case perspective, well, like, why would you want CAT?
[01:27:54] Unknown:
Again, I I think it really comes down to this, like, you can't own a UTXO question. There's obviously a lot of, like you know, there's a lot of people super excited about, oh, we're gonna do, you know, these these roll up things with BitVM or CatVM, I guess, now. And it's gonna be great because, we can have all the, like, Ethereum complexity and all of the CVM garbage, and it'll all be on the Bitcoin chain and it'll use Bitcoin as the native asset and people are excited about this and I don't really understand why. But if you are a Bitcoiner Surprise. Well, okay. So I'm surprised maybe. Number go up at least until people realize there's nothing there and then they get that. But, but, but I think if you're a Bitcoiner, you're like, I just want good money. You know? There's there's a lot of cool there's a lot of cool stuff on Ethereum. I don't know if it'll actually come to Bitcoin because, it never came to Rootstock, and Rootstock exists and has been around for whatever decade now.
But if you're just like, I want good money, I wanna I wanna transact with good money. I wanna do it with lower fees so that I can own a UTXO even though I only have $10. You know, how do we build something? There's there's a lot of proposals that are super early for using covenants, and I think, you know, like, with things like time out trees, things like ARC, they all have big drawbacks that I would say are in some for many of the use case for the the kind of naive use case of just, like, I wanna, you know, have everyone use this thing that they're kinda showstopper kinda drawbacks, but there's a lot of interesting research still to be done there. There's a lot of yeah. I mean, we need to dump a lot more technical and and brainpower into that problem.
And I think it's fairly clear that we've mined the, ideas out of current Bitcoin, and covenants gives us a whole new space to think about where we can potentially build some really, really cool semi custodial kind of thing, you know, like, Time Out Trees as the for those of you who don't know Time Out Trees, it's it's a proposal basically what you do. You you take lightning channel, take an LSB. The LSB opens a channel to everybody all at once in one UTXO using CTV, And then at the end of, let's call it 6 months, all of that money in that UTXO reverts back to the LSP.
So everyone, they got a channel from this LSP, but it's a time limited channel, so they can only use it for the next 6 months, and then they gotta make sure their money's out before the end of 6 months. And then they gotta open a new channel, put the money in the new channel. That's great. You just need one UTXO. You can have as many landing channels as you want. It kind of falls apart if you actually have to go on chain. It you can't really go on chain because you don't have enough money to go on chain because that's why you didn't have a UTXO. So, like, the average user is just, like, sending between them. Right? Like, just quickly it's like the rug pull stopwatch. Yeah. It's like yeah. Exactly. It's it's a it's a, you know, there's a time timer on the bomb, and it's gonna work for you at the end of the timer, and you gotta make sure you get out. It sounds very much like an MLM when you describe it that way. But I promise you it's not designed to be a policy scheme.
So but, you know, it it has a big show stopping issue, but also, it would let you actually use order custodial Bitcoin on chain in a lightning channel that in a way you can't do today. And so ideas like that, I think, are gonna be I should say, I I wanna end that sentence with the future of Bitcoin, but that's definitely not how I wanna end that sentence. But, you know, ideas like that are are are really cool and things that we need to be thinking about, things we need to be building. I think it's clear that we need covenants for that. So personally, I'm really excited about it. I spend a lot of time shitting on covenants because I think there's not enough of that. It's not enough people shitting on covenants, so I end up doing it. That doesn't mean I don't also love covenants and, like, want covenants for my own things I wanna build.
[01:31:48] Unknown:
You you made kind of like a a throwaway comment there about how, like, all the ideas are gonna mine out of Bitcoin, but then you'd be have covenants in a whole new world. But would you say that having bit the m show up in the last 6 or 8 months or whatever, that was a bit of a, like, was it new ground? Like, I was not expecting new ground of that magnitude. Do you? Yeah. No. Absolutely. Yeah. And, again, I mean, it it might be the case that the ATM is too inefficient to to be practical. I mean, I think that
[01:32:14] Unknown:
some people have pointed out to me that the Ethereum, the Ethereum roll up the Ethereum, optimistic roll ups have never had a challenge proof on chains, so they've never actually validated it. Okay? Oh my god. This is in large part because they have have a limited set of people who are allowed to challenge, so it's not not anyone can come by and challenge. And then in bit the m p 2, anyone can come by and challenge. It's optimistic.
[01:32:39] Unknown:
Very
[01:32:40] Unknown:
odd. That's what it works. Who knows?
[01:32:45] Unknown:
So, like, maybe maybe inefficient is fine. Like, I don't know if people went to fly it anyway and just have a limited set of people who can challenge. But, yeah, I mean, I think I think you're right. The BIVVIA was a very transformative idea in terms of what you can do with Bitcoin, but I think it is, to some extent the first new idea of what you can do directly on Bitcoin since Lightning. And Lightning was the first new idea of what you can do with Bitcoin in, like,
[01:33:15] Unknown:
4 years prior to that. So Since 2013 when every good idea was a Bitcoin Taco Yeah. Basically. People.
[01:33:23] Unknown:
I mean, Jeremy came up with payment channels first. Right? But, yeah, I mean, like, we had a ton of great new ideas in 2011, 2012, a few great new ideas 2013, One great new idea, and I don't remember when lightning was. Somebody yell it out. Nobody? Alright. 2014. And then 14/10. Then we had the PM. Right? So it seems like we're not getting a lot of new ideas. You may be right that, like, you know, maybe we just haven't figured it out yet. Maybe there's something there. It's gonna be perfect. We're all gonna use it. We're all gonna love it. But it wouldn't surprise me to some extent. But but VM surprised me. So
[01:33:58] Unknown:
Yeah. I mean, like, half of the booths at the at the conference were just a good yeah. Deripatives or at least, like, super, like, attacks, affinity scams for VPN, at least. Buy your token, BitPM, or something something BitPM. Buy your token. There's these money contracts, BitPM. Yeah. Yeah. Maybe let's start moving toward our wrap up for it and kinda go around the horn for what the current state is for the projects that are here within
[01:34:25] Unknown:
the Rust sort of Bitcoin ecosystem. And Let me finish my lunch now. Yep. You're good. My Elliot's too late to pay for.
[01:34:34] Unknown:
Yeah. Okay. So he looks like you're on the horn. And, one final thought is final thoughts on this, especially for, like, after the Rustic Point Summit, like, what your project looks like and where you want it to go. If you have, like, specific contributor requests,
[01:34:47] Unknown:
then, let's make those. But before we go to final thoughts, like, Andrew, like, how does this how would this get activated if you want opcat? Like, how do you expect this to get activated?
[01:35:00] Unknown:
So I think that we need like, we we do need to kind of address this question as a community of this. What does Bitcoin look like in a world where we have transaction introspection and therefore covenants? Right? So one way this gets resolved is just we just kind of figure out how to do covenants without any changes, and then we're across the we're across the threshold. I have, like, kind of a a weird conversation with somebody recently where they were talking about simplicity, which is a total rewrite of bit my script. And they said, like, how could you possibly propose simplicity when it brings all these new things to Bitcoin and will let you do all these know you the things and how you reason about it. And I said, well, if we have cap first, cap actually by itself lets you do everything. Right? In simplicity, it's just kind of an optimization, which is a weird thing to to to hear myself saying. That's a weird thing to be true, but I think it is true. So one way is that we just wind up stumbling over that cliff, right, without any further upgrades to Bitcoin. And at that point, right, there's no further harm caused by op cap.
Although as Matt hinted before he left, there is a kind of a fuzziness related to the efficiency of these things. Right? So maybe we find it tremendously inefficient way to emulate off cap by, like, using shot 1 collisions or something. And then off cap lets us do it, you know, unless than 2 to the 80 work. Alright. That's an improvement. And then a real covenant opcode would obviously let us do it without, you know, using 30 opcodes and and a whole bunch of other crap. So the correct way to get opcat, and I guess the the kind of optimistic path that I see, right, is that we do figure out that Bitcoin should move forward. Right? We shouldn't just, like, stay ossified where we are. Right? That's essentially what we have to do. Right? If if we want to avoid all the new functionality that cap gives us, it's not just cap you avoid. You have to avoid all faults apparently, according to Brandon Black, I think, on my panel and, at the big conference.
You also have to avoid, like, an opcode that can do a comparison of 2 arbitrarily length strings. You have to avoid arbitrary size arithmetic. You might have to avoid opmall. Yeah. There's various crypto opcodes you'd have to avoid. You'd have to avoid certain kinds of variable length encodings for for signature and public keys. There's there's a lot of ways to to to get what AutoCAD gives you. And the reason is that fundamentally, all of the scary stuff, all the scary transaction in respect to them already in OpCheksig. It's just that you can't get it out of Cheksig and make it do more than checking the signature, because of just like these these kinda accidents of of what computations you can do on your signatures.
So okay. May like, maybe we don't ever want to cross this line. And in that case, we can't do any of the things that I described, any additional upgrades. You need to be really carefully, super specific things that avoid providing a new general functionality. And we better hope that there's no further research that that lets you, you know, be able to do that off cap. Ultimately, we decide that we just need to bite the bullet and move forward, but that is something that the community does need to decide. And until we do so, off Cat is in,
[01:38:22] Unknown:
in stasis. So I mean, I feel like you very gracefully didn't answer my question. So one thing that I like, the way I look at it is, in in Bitcoin, we have this idea of soft forks and hard forks. Right? And the key difference between soft forks versus hard forks is soft forks are effectively backwards compatible. You don't have to go and update your node. They are sold as opt in changes to Bitcoin. And with a hard fork as we have with Bcash, a hard fork is the history of the chain is the same up until the point of the fork. And then at that point, you're basically split into 2 forward histories or or or the the transaction letters are just split going forward. And if you want to be on the fork, you have to then up update your your your Bitcoin software. You have to update your note.
I think there's, like, a little bit of a misunderstanding on the risks of a soft fork because we've never had a contentious soft fork. And with something like OPCAT, I mean, right now, I mean, I I think if if you look at what what the community is looking at right now with OPCAT, there is clearly not broad consensus on it. It would probably be our first contentious soft fork. So if if you did go through activation, what does activation look like? Well, you know, you have the Bitmain Mafia at 50%, nearly, like, Anpool's basically creating block templates for 50% of the hash, and you have Foundry at 35%.
So let's say you convince those 2 people, right? You can convince the CEO of Foundry and you convince Jiyeon, and they go ahead and activate it, but there's not actually a broad consensus for it. Basically, what happens at that point is is effectively a hard fork, but much messier than a hard fork. So I feel like that is the concern that's not really being addressed. And you would have no relay protection. Like it would be it would be an absolute fucking mess. Most users would be really, really confused. So, I mean, I think that's the core of the question. The core of the question is like, how much here are we just, you know, playing mental gymnastics over something that really in practice cannot be responsibly implemented on a protocol level?
And then, I mean, the second question would be, would it be cleaner to just do a hard fork? Like, why why isn't there just, like, a replay protection, OPCAT hard fork and then let the market dictate? Like, I would be I would be happy to have 2 Bitcoins again.
[01:41:04] Unknown:
I I too made a bunch of money off of eCash. So, well, to answer your first question about why are we not addressing it. Right? In some sense, we're addressing it by not proposing an activation. Right? Like because you're right. Like, right now, if you or I were to go on the mailing list and just, like, say, here's an activation parameters. Even if they were super responsible, and it was like, nothing's gonna happen for 16 months, and then we're gonna have 4 months of signaling, and then it will activate, you know, 6 months later or whatever. We can get people all the time in the world, but that's not going to address the question of is a community entirely on board, and is there a large faction of the community that is explicitly not on board and would try to go do their own fork? And in that case, you know, I wouldn't say this is a first contentious way. I mean, some of these aspects appear in the SegWit as well. Right. And that there was a lot of and there we kinda stumbled into it because on the technical side, none of us were really expecting SegWit to be contentious. It was a very boring technical change at its core to change the way that the commitment structure works within blocks.
And it's a change that made various things like chaining unchanged transactions together, much easier, which you think, like, a lot of the b cash crowd is like, you know, 0 comp should work kind of thing. Well, 0 comp works much better with SegWilly. We weren't expecting any of the the opposition that we had. And the reasons for that the reasons for the opposition are are still not entirely clear. Right? It may have been basic boost. It may have been some cynical b cash, that does make money by having a fork. It may have been some weird power play or or ego thing where, like, Roger or somebody wanted to be king of Bitcoin. I don't know, but we certainly weren't expecting it going into it. Right? And then we were in the middle of it. And and somehow or other, we got to the other side. Right? But here with CAT, we're in a more fortunate position. Right? Where we know there's nothing like ASIC booth related to op cat because it's such a tiny narrow technical change. So that's that's the relief. Right?
And if there was really opposition of the form, like, I just want to have my own b cash fork that that I pre mine a bunch. Well, that's I mean, those ideas are pretty much dead. There have been a 1,000,000 of Fort Coins, and they're they're no longer big. But what we do have is is this real opposition of the form like this changes philosophically what Bitcoin can do. And that's quite a serious form of opposition. Right? And if a lot of people feel that way, then we can't move forward. But what I will say, and you'll notice I continue not to answer your question. A couple years ago, right, we could have been having this conversation, and the idea of having covenants in Bitcoin was just like, Right? Yeah. Covenants is a bad word. Nobody wanted them.
And those attitudes changed a little bit around certainly over the years that Jeremy was was shilling CPV, but also just think vaults became more popular as a concept as as the Bitcoin value went up and and more people became long term holders. And there's also kind of this this idea that Matt was hinting at that maybe these Meeval things are not actually efficient enough to make people money. And, like, there are a lot of challenges of the form, like, show me the mebel. Right? Like, actually give me a construction for some terrible thing that you can do with covenants that would make any sort of sense that you usually go along with and that could make money. And, I mean, attitudes have changed a lot in the last couple of years. Right? We're now, like, we're seeing this as a contentious thing. Well, a few years ago, it wasn't contentious.
The majority like, everybody was kind of on the opposite, like, on the anti cat side. And now we're contentious, and maybe maybe, the over to the window continues to shift. And then it becomes less contentious, and people are pro cap. And maybe we can we can move forward then.
[01:44:49] Unknown:
But do you think I mean, I guess, like, my question is, like, do you think it's particularly dangerous to activate a contentious self work? Like, to actually activate it, to have a majority of hash rate, basically force it through. I mean, we had an interesting question. We do Chatham House rules, at Bitcoin Park. We had an interesting question last week, which was, until we at least partially mitigate mining centralization concerns, Shouldn't all these activation questions just be off the table? Because right now, like, I think you can obviously, it's a little bit hyperbolic, but you you can you can basically say this, like, Jeehan plus Foundry, things activated.
Like, as a Bitcoiner, as I mean, I know you've been a Bitcoiner longer than most people and have the majority of your savings in Bitcoin, like, you're heavily invested in this. I mean, you lost it all in a voting accident. I apologize. No. But, I mean, you have I mean, your whole career is in Bitcoin. Right? Like, if Bitcoin dies, like, it's like Andrew Polstra is a nobody. Like, you and and as Bitcoin succeeds, you're an absolute legend. Do you not do you not, like There's a lot of member whittles. Do you not agree with that as, like, I to me, it's just
[01:46:02] Unknown:
Okay.
[01:46:03] Unknown:
Count them both rules here. I feel like all of this is I I I just feel like all of this is, like, you're putting the cart before the horse a little bit. Like, it to me, it's just, like, every like, cool minds. Like, everyone just chill the fuck out a little bit.
[01:46:17] Unknown:
So regarding the the kind of like personal identity parts of what you're what you're asking me. Right? We know that it's well, many people believe that at some point in the future, we'll have quantum computers. Right? Right. And those will focus Bitcoin to change pretty dramatically. Right? So the mining incentive will get kinda wonky where our our random work will become quantum random work. So All of our Schnorr and ECDSA signatures get, like, immediately broken. And all of my expertise as a cryptographer goes up the window. Right. Everything I've done cryptographically is, like, appealing elliptic curves to do cool stuff. An elliptic curve, they're basically useless Yeah. In a post quantum world.
So that's what I lay awake at night thinking, like, at what point do I need to just ride off into the sunset and disappear? And then when I think about doing that, it's quantum computers. Right? Cat didn't even cross my mind that's, something cat related or or covenant related or scripting or whatever would, would be the trigger. I forget what the second half of your question was.
[01:47:15] Unknown:
I don't know. I just I just think mining centralization, we got we have a unique situation where 2 parties can can basically force through this change if if, like, Udi pays them enough. Right. And, like, that to me is incredibly dangerous. Like, I I I don't I actually I think the lesson from b cash the lesson from b cash wasn't that hard forks so dangerous. I actually I would much prefer a hard fork here. Like, I think a hard fork would replay protection, would be incredibly clean, and it it wouldn't you know, I I apologize for saying what I said about your potential saving strategy, but my family is all in on Bitcoin.
Like, I I mean, we can stop talking about you. Like, I'm a fucking nobody. If if if Bitcoin fails, I will live in the woods. And if Bitcoin succeeds, I will live in the woods. But if Bitcoin fails, I will be living on someone else's woods. Like, I will just be squatting in your woods.
[01:48:12] Unknown:
It it's important to
[01:48:14] Unknown:
I I think we're we're falling into the trap that too many people fall into, which is we're we're misdefining software.
[01:48:22] Unknown:
A fork in Bitcoin is a change that is enforced by the vast majority of economic terms that applies to soft and hard forks. Right? So if if you're not if you don't have the vast majority of nodes enforcing the rules, this is not a change to Bitcoin's rules. This is just a censorship attack. Right? So what you're describing is not a software. It's a censorship attack. And the wonderful thing about censorship attacks is they only last as long as the same miners are still doing it. So if you actually saw Hash Power just, oh, I'm gonna go we're gonna go enforce OPCAT tomorrow.
The main the main mafia decides, like, oh, we're just gonna enforce OPCAT. It's It's the rules of the network now. Everybody's gotta learn to deal with it. This is gonna last as long as the miners don't wake up and realize, oh, we can make a lot of money if we go just take all that money locked up and off cat. Like, all this there's all this money sitting on chain locked up and off cat. That is actually anyone can spend money. Right? We're not talking about this bullshit anyone can spend, SegWizz anyone can spend because, you know, not all nodes enforced it. No. Basically, all nodes enforced it. Right? But the only the reason it wasn't anyone can spend money is because all nodes enforced it, not because Hashpower enforced it, because the nodes enforced it. And so if you see that kind of malicious fork, well, yeah, sure, it might last a while. You know, the the mid name mafia might stick around. They might keep enforcing it. But then in 10 years, all of a sudden, there's gonna be new miners and they're gonna say, oh, you know, there's a lot of Bitcoin sitting there. We can just take that Bitcoin. It's our Bitcoin now.
And a lot of people are gonna be real sad. It's gonna be a total clusterfuck. Right? If people actually start using something based on a censorship attack, you've got a lot of people with a lot of Bitcoin locked up in basically custodial shitcoin with Bitmain. You know, if you're using OPCAT and on Bitmain is the only one enforcing it, you're just custodying your money with Bitmain. That's all you're doing.
[01:50:16] Unknown:
Wasn't for wasn't one of the takeaways from I wasn't around at the time, so any of the old timers can correct me on this, but wasn't the day that they did the fork wasn't it something like 75% of Hash Power moved over there and, like, by the end of the day, they were back on Bitcoin?
[01:50:33] Unknown:
I don't think that ever happened. Every time I had b cash? Yeah. B cash. No. That never happened. Dion never had the balls to actually like, he indirectly controlled the overall majority of hash power,
[01:50:45] Unknown:
but he never had the balls to kill his golden keys. Have the balls to take a 1,000,000,000 of his company's dollars and put them directly into Bcash and then ride it all the way down to 0. Yeah. He did do that. But with the hash rate, he never
[01:50:58] Unknown:
I don't think the hash rate ever flipped, period.
[01:51:00] Unknown:
There there were some people mining back and forth, switching on whatever was most profitable. Oh, yeah. Oh, yeah. Sorry. There Oh, shit. There there were a number of miners that, were switching back and forth depending on whatever was most profitable. And that caused a lot of issues, especially on the Bitcoin Cash Corp. But, like, they they were just following, like, an just an algorithm, you know, what's most profitable. Okay. Just do that. But I I don't think they were looking to accomplish anything other than just make the most amount of money in the shortest amount of time. They were probably,
[01:51:38] Unknown:
like, hour long periods where VCAS is the most profitable, and they had 80% a half hour or something, but certainly not on a scale of, like scale where we can actually average this out. Right? Because you can't really accurately measure where Hash rate is on short time horizon. When there was a forked up mobile website. Right? Right. But, yeah, I mean, you there's a lot of noise. They have to average out over some time horizon.
[01:52:00] Unknown:
Yeah. On the time horizons, they could average out. I I don't know the hash rate. Yeah. Forged out, you never saw a significant percentage of all hash power. I mean, I think you saw, like, 10 or 20%, and I think it was enough that blocks were slow, but it was, like, annoyingly slow. Like, no one was, like, like, blocks weren't happening or it was nothing like that. Right? It was just, like, a little bit annoying. And some people and I think the fee rate increased in this time, and some people were arguing that it was because the blocks were 10 or 20% slower. And I don't know if that's, you know, justified for the actual one. It was a pretty minor thing. Shadowgram, just in case with Yeah. Okay. Chat Chat
[01:52:37] Unknown:
but they don't have a choice yet. I don't Yeah. And, also, they're not zapping with their comments. You can So ignore it. I live on mobile phone
[01:52:45] Unknown:
24 7. I'm pretty sure it never flipped. I I I mean, I think Matt that I'll be wishing that is Matt Matt explained my concerns much more eloquent than me. He and he used the technical term clusterfuck. Like, I really wanted to avoid. I'd prefer to avoid a a mass rug pull, kind of event or, like, a massive reorg if if you start to see miners, you know, switch back. And, like, right now, that it just feels like we're at, like, kind of a detente, and it it feels like most of the conversation is unproductive.
[01:53:20] Unknown:
I mean, that's also true if you watch Twitter. If you hang out with developers, I'm not sure, like, you know, if you just watch Twitter, you would assume that, like, myself and Polstra or myself and, Ethan Heilman or myself and and don't know. You're just fighting with everybody. You'd think that we, like, wouldn't get along and that we hate each other. It's not like you know, we have we have conversations about it and we talk about it, like, there's more research needed. And I think I think there's I I don't know that we actually really have that drastically different of a viewpoint.
Like, you know, I I take different positions in public because I I think these issues aren't talked about enough, and that's what I focus on in public, but that doesn't necessarily mean that that's the only thing I care about. That doesn't necessarily mean that I don't love El Cat too. Right?
[01:54:04] Unknown:
So then what about Andrew? Like, what is your, and I love this is, like, such a great detour before final thoughts, like, half an hour detour before the 5 minutes. We're not in a rush here.
[01:54:16] Unknown:
The Final thoughts before I went and finished my line. I know.
[01:54:19] Unknown:
And then you came back, and we're just continuing No. I'll finish my line. Well, I mean, I I we got this group here. We have to have, like so what are your thoughts on, like, more restrictive changes, like, something like an out fault or something? Like, you just don't need to think like that.
[01:54:35] Unknown:
So they I'm skeptical that they're actually more restrictive. Right? So op vault is a is a good example of an opcode where, you know, 2 weeks ago, I would have cited that as an example of something more restrictive. It just enabled vault, and it doesn't do anything else. And then, I think it was Brandon. Whoever it was on my panel beside me said, oh, like, just a few days ago, I figured out how to do, how to do, like, generic covenants just using off walls. Right? I figured out how to abuse them. So I think that it's possible to come up with new opcodes that don't enable you to do everything that does, But I'm not convinced that, like, I'd really have to study any specific proposal before I, come in. Is
[01:55:22] Unknown:
probably pretty clearly nonrecursive.
[01:55:24] Unknown:
I believe that CTV is okay. Yeah. So you could use that as an as an example. Yeah. So CTV, yeah, is is a good example. And it's also been around for a few years, and nobody's, like, figured out how to do it. So that's also pretty good evidence that CTV actually only does what it sets on the 10th. So if your question is, like, do I support it? I guess. I mean, it it enables a bunch of stuff, and and maybe if that's something we could all agree on. Well, that's my answer. If it's something we can all agree on, then I support it. But it it's it's not. Right? CTV was, kinda got mired in a lot of of arguing about whether it needed to be more general or or whether it was too narrowly focused for the complexity that it brought and so on. But, yeah, whether it added any real value directly or whether we should just add something like cat and then add.
Yeah. Yeah. Exactly. Right? I mean, there are a few Jeremy had, of course, his website with a bigillion use case and so on. But but many of those use cases were pretty, kinda, like, made pretty bad trade offs, I'd say. There were a few that that were really good, but the the ones that were good, I would say, is a small set and probably not enough to justify the complexity. So kind of what got me excited about cat, right, is that the complexity, technically speaking, was so low. Right? And you'd do very little room for bike shedding. You'd do very little room for for for code that could be buggy, if we deploy it. And then later, we move on and say, you know what? That was fucking useless. That's just you know, we should have had some better off code. Well, you know, it's only 5 lines of code that we have to maintain forever because of it. Right?
So cat has those benefits going for it. And in general, I think any opcode does narrow enough not to do what opcat does would have to fall into the CTV kind of range. It would be pretty technically expressive. Right? And, personally, I would like to have vaults. Right? If we got covenants and they can do vaults but nothing else, I'd be happy. Well, we had an opcode. It turns out it doesn't just do vaults. Alright. Fine. CTV doesn't do vaults. It does sort of a boring form of nonrecursive vaults, but you can do that today with pretying transactions. So that's not so exciting.
Like, to do proper vaults, you kinda need recursive covenants, and then they come with I don't know. It's I I I know. It's not like there's there's kind of a range of trade offs that we can make. Right? And I don't think of any good points in that area. At the Bitcoin plus plus in Austin, that was basically all of the smaller opcodes where we're like, hey. We're trying to narrowly focus this down, and so it only does one thing. So the opcode you in? Yeah. Well, all of them showed up, and all of their presentations were consisted of, I tried my best to make this as tight as possible, and 8 months later, when I had the 9th or 10th guy look at it, he found a way to basically turn it into a generalized company.
And that was for all of them. That was, like, thoughtful, APO. Right? Like, just down the line. Right? And so and with CTV, right, it's like, hey. Say we activate CTV. Well, now you can use CTV with basically any other sort of tiny change, and then you end up getting the covenants there. And so discussion that Andrew's having about we have to decide whether or not we want this is, like, very important because there's basically to to date, there's basically no way for when you try to add one of these things without accidentally introducing this down the line potentially. Right? You can't prove that you won't be able to before that. And then another important point that came up there for it was that currently there's no way for someone to express on chain whether or not they want this thing. Right? So for example, if we had Cat activated, for example, and there were 100 of people or, like like, millions and millions of Bitcoin worth of activity for people using OPCAT for vaults, then that's, like, a very clear direction where Bitcoin Core and, like, the developers for it can say, hey. People definitely want Vaults. And so we can take the inefficient use of this with opcat and turn that into a tighter opcode, for example, for it, where it's doing the same thing that people are already doing with opcat. But for example, today, for whenever anybody talks about vault, so there's no way you can click. Like, there's a bunch of huge entities that are currently using pre signed transactions to get around the vaulting thing, but that's not something that people can point at. They're not very public about it. So when you try to point to, oh, hey. This huge company or this huge entity is demonstrating that they do want vaults.
That's not something that you can, like, point to and say that's, like, actual economic activity that we should try to align around for.
[01:59:55] Unknown:
I'm gonna push back on that. I don't believe that anyone will ever use phones. I think that the conversation so I will So aside from both sides. Aside from both sides. And his weird, manually created everything.
[02:00:11] Unknown:
He's gonna write all of his own software. They were they were great with 1, put 1 up, which is not accurate. Yeah. So
[02:00:20] Unknown:
so the problem so the problem involves management problem and replace it with 2 key management problems.
[02:00:28] Unknown:
And at least I have a project called codec city too, which was 69.
[02:00:34] Unknown:
Just pieces of paper. We replaced our 2 key management problems with 10 key management problems. Now this is only strictly better. No. But you only have to call 7 of the time. Right. Right. Right then. Alright. So, you know, there's a lot of large entities with lots of Bitcoin that care very deeply about their key management, and have spent a lot of time, a lot of money investing in key management. And vaults give you replace your key management problem with 2 slightly different key management problems. So it is true that your hot keys is ever so slightly different in its security model than your cold key, but it's not that different. Like, you still want your hot or, I guess, maybe it's your warning key because you have a separate hot wallet, so now you have 3 key management problems. But, but your warning key, you know, you still want it to be super secure and not have to deal with it. Then your cold key, you still have to access regularly to make sure it's still there. You know, one one problem with the vault cold key construction is, you know, no one's ever gonna have a, call you know, no no enterprise should ever Yeah. That's exactly right. Have a super cold key or set of keys where they never access it or you still have to you wanna access it once a year to check that it's still there, it's still working, you can still you know how to access it, whatever.
And so this is something that basically so I so I think in practice for a large enterprise, the cold key, vault cold key, and the existing warm ish, cool ish key, design would look basically identical. And so I think for most of them, when they actually sit down and start designing the vault system, they're gonna say, why are we duplicating all these keys? Can we just not do this? And not and so I I think there will definitely be both some maybe I was a little harsh. There will be people who use it, but I think the, like, excitement over how, like, every large enterprise wants this, that's gonna be great. I don't think that's really accurate, and at least the large enterprises that I've spoken with had to sit and, like when you kinda sit down, you're like, alright. So How are you gonna design your cold key? And they're gonna kinda stare at you blankly and then they say, oh,
[02:02:46] Unknown:
you know, maybe we won't. But isn't it it's more helpful for, like, individuals in inheritance. Is that not true?
[02:02:52] Unknown:
Maybe.
[02:02:54] Unknown:
I mean, that Maybe we can still use, like, multisig to do our own thing if you want. I mean But we could try to drag Robin to this conversation. And it's like, right now, Anchor Watch. Wait. He's active in the live chat. Yeah. Oh, that's what it is. Alright. So I I think that Anchor Watch I don't know what your term bill is limited to a year at a time or something. You do have layers of keys that people have to manage, and I wonder Yeah. So conceptually, I would call this kind of like our MVB product to start. Right?
[02:03:22] Unknown:
Making it very compressed on the technical side. The idea ultimately is that they couldn't addresses to distribute risk and make them safer and more resilient. We basically make a pseudo vault within a single UTXO by leveraging manuscripts. Right? And this enables with the combination of time locks and threshold to thresholds. We're basic and, you know, using, like, op if, like, nested opt if statements, we're able to do many different ways that you can spend a Bitcoin UTX. So the idea, ultimately, is that we wanna be able to provide assurances that there's many ways that this Bitcoin address can be encumbered. And, basically, in general, just how the industry work and kind of how the practices have developed, everyone's using, for long term cold storage, either some sort of MPC architecture where they're sharding an individual key, or they are doing some sort of n of n multisig, which has beta multisig has been around since 2011. We've paid a Scrip Hash since 2014.
And it was just a general observation we had about over a year ago that there was a more rich design space built on, you know, to make this full circle, Rust Bitcoin, Bitcoin DevKit, Rust Minionscript. And for us, I think I view this as, like, the starting place of being able to make Vault like functionality with the understanding that, you know, I'm a company building in the space, so I don't have the luxury of hoping that there will be some sort of fork activation that's gonna add new functionality. This is kind of like an idealized state of how far can we take this concept of vaulting today. And it is a key management problem, but you can distribute those keys and you can have more robust scripting. So you can rely on organizations, lawyers, estates, trusts. And with that distribution of keys, you're able to distribute the risk and internally make the money more safe by not making it there's this one way you can spend the money in the transaction.
[02:05:04] Unknown:
Would you would you imagine that your users so right now, there are keys that are, like, time locked with with the highest time lock in in your elaborate script. Would you imagine that some of those keys would move from being, like, very long time lock keys to being actual vault keys that just aren't used except in
[02:05:20] Unknown:
bad cases? So I guess, like, to to Matt's point about, you know, you're just changing one key management problem to another. There needs to be a contingency of if this default happy path is broken and those keys are compromised, you do need to have some sort of emergency cold storage keys that you're able to reclaim to in the event that those hot keys are compromised. A very simple example is I could have a with an op vault construction on my phone, maybe I have a single sig, that it sits in an intermediary address for, say, a week before it can actually get flooded, which maybe 90% of the time is fine. But if someone compromises my phone key, someone's just maliciously trying to drain my money all the time, and I'm constantly spending money on chain transactions trying to sweep it out, you need to be able to have some sense of kind of distribution of keys. But I think what you can do is you can make a bunch of keys phone keys. You can make them really hot and accessible, and then you can have your hardware wallet, cold storage, in a bunker wrapped around in aluminum foil to kinda keep your super safe keys as, like, disaster recovery or some sort of federation or distribution of those. I think that's totally an option. Yeah. I think we're gonna build that, and then we're gonna see people are gonna say, oh, my phone got hacked. Let me go find my key that I wrote down when I created this wallet. It's I put it in a safety deposit box. They're gonna go to the bank, and then they're gonna realize the bank took their safety deposit box and sold it because they haven't visited the bank,
[02:06:37] Unknown:
in the last year, which, by the way, is a thing that happens. Sure. Yeah. It did. And then they're gonna get sued. So I I think, you know, I I think when we really sit down and we model out all of these issues, I think we're gonna find that that and in in general, when I do talk to people who do model out these issues, and maybe you guys have, but I think at least on the enterprise case, we we generally find that people say, oh, well, actually, the key ends up looking similar, and we end up building something very similar.
[02:07:07] Unknown:
You know, we All of my keys are codecs32 checksums, and every 3 to 6 months on a schedule, right, I make sure I can access them, and I verify the checksum using my worksheets, which I then burn. So I do have a process to refresh my key that don't require the interrupt. Again, we've already established you're gonna use all this stuff. These conversations whether other people were mentally stable, they're gonna use all these things. Again.
[02:07:29] Unknown:
I can't do it. If it's mental stability, it's the threshold of the conversation.
[02:07:36] Unknown:
Andrew's actually gonna retire on the profits from selling the book that allows you to do this stuff.
[02:07:42] Unknown:
Yeah. It's it's the rich dad, poor dad model. I'll watch I'll watch your Netflix movie. I have a quick story for, like, what made me decide that, like, bolts are important. So, I was helping out a guy who had all of his funds stolen out of his cold storage. And the time that the guy had actually gotten compromised was, like, 3 years previously when his Google was compromised. Right? And at the time, this was just, like, you know, a total newbie or whatever. He'd taken a picture of his seat. Right? And so this he had it there. And instead of immediately sweeping all the funds, what the hacker had done was he'd set up a worker for just watching the wallet Mhmm. And allowed the guy to continue stacking to his cold storage.
And the guy continued to do it for, like, 2, 3 years, and then the first time that he actually tried to move the funds was basically a replace by fee transaction that swept the entire wallet. Right? And so based off that, right, like, the the thing that I'm most, bullish on for Vaults, right, is that when a key gets compromised currently, right, they don't have to do the attack immediately. It's like once compromised, there's no indication that the key has been compromised, and there's no way that you can have any sort of reactive security to your key was compromised. They started moving the funds. I can do something about it. Right? And so just, like, think about how many, like, how many freaks are out there and, like, you know, they did their cold storage setup with their multisig or whatever, and they've just been continuously stacking to it without checking all these things and also not having any sort of indication that the key was compromised in the event that it was, and then 5, 10 years later or something. Right? Like, because once you have the key, you already own the wallet, and you don't have to do anything that shows that you do it. But with a vaulting structure, that's something where in the event that it is compromised, you do have that window for being able to go after it. And that was the specific instance where after that one, I was like, oh my god. Look. We need Proactive to react. 2 things. Right? Like, the there's
[02:09:34] Unknown:
yeah. I mean, there there are definitely cases we can point to where we can solve it. There's no question about that. And you're right that, like, being able to have reactive security isn't it'd be primitive that that may be useful. But I think it's important to ask what percentage of attacks are like that. You know, how many does the attacker really leak the key, get the key, and then sit on it for a long time? And I think that may probably growing, but it I assume it's still fairly rare. And then there's the question of what percentage of people are gonna build this vaulting thing and then assume that their vault key is safe and then forget about it and not actually have it be safe, and I think that's probably very high, especially, you know, when we're talking about enterprises. I know when Volts first were being talked about, it was mostly about enterprises. I don't know that enterprises are really gonna use Volts very much, but at least them, they are we know, okay. They're gonna they're gonna do all stuff. They're gonna check that the keys are still there once every 6 months. They're gonna send people out to all the vaults, physical vaults in this case.
Check the keys, reroute the keys, try to sign something, make sure it's all valid. But with a normal person, we assume they just never will. I think 99% of people just never will. It's never gonna rise to the the threshold of, like, they're gonna actually check it. And so I I I don't know. Like, you know, we have to we have to consider those proportions, and some people are gonna build wallets like that. I don't know that they're gonna have the most users. You know, I think they're, like, 2 or 3 model where a server applies velocity. You know, one thing, if we had volts where you can apply velocity, like, maybe just velocity controls generally would solve this too. Like, maybe that's actually what people want to velocity controls, not volts.
Maybe we want both. So, you know, maybe Vault's the wrong thing to focus on. Maybe we should be focusing on 64 bit math, and then we get the curse of covenants again, and then we have this whole thing starting from the top. But
[02:11:29] Unknown:
nice. Yeah. Another super cool thing other than vaults that you can do, that I think you'll win immediately is, clawback transactions. Like, you know, undo button that expires after 20 minutes. You can't do that now, But, you pay somebody and then you can pull back the money in, like, an hour or something.
[02:11:43] Unknown:
So you think, like, the lack of chargeback chargebacks
[02:11:46] Unknown:
is a bug not future? Well, like, if this guy wants to bring the government in, if you take all chargebacks, I think, I'm fine. Yeah. Yeah. He's gonna be sig with the CRM. He doesn't love with
[02:11:57] Unknown:
that. No. But Sorry. I respect. Yeah. But he did, he did some Mike for fun.
[02:12:03] Unknown:
Oh, no. I I don't know. Like, could you do that with the multi sig and some sort of time lock? You like, the clawback stuff? Yeah. I don't know. I mean, there's no way to to remove this much additional.
[02:12:14] Unknown:
Yeah. That's a so in the layered example, like, what we're doing, once a time lock is satisfied and you can't you can still spend the older condition. So if I have money I can spend today and there's a new spend condition at 6 months and there's a new spend condition at 1 year, you can spend the no time lock and the 6 month time lock condition even if you hit the 1 year. It's not like you can expire a spend condition by the nature of how it's funny because you call it, like, a time lock. It's more like an unlocking of some sort of condition. Right? You basically pass a you open up a logic gate with the either check lock time verifier or the check sequence verify. Right? So you turn a verify function in Bitcoin script, which is pass fail into pass, and you can't make it go to fail again once you flip it to pass. Yeah. You can't make it invalid after a certain time. Jersey. To to bring Brad the the conversation to us, this is like a cargo feature. It's just additive by nature.
[02:13:05] Unknown:
No. I got it.
[02:13:07] Unknown:
You can first do this by No, Mike. You can do this by just spending the UTXL,
[02:13:13] Unknown:
Putting another transaction. RBF.
[02:13:15] Unknown:
Yeah. Or yeah. Yeah. Mehul's never clear again. You'll always have the opportunity to RBF. You can just give someone an end lock time transaction to the future, and then you have time to be able to spend it, bump it out, and claw yourself back without hitting the men publicly. I mean, of course, you could just get into, like, a back and forth where it just goes to 0. Totally.
[02:13:33] Unknown:
Scorched earth policy. I mean, I just wanted to shout out weirdo robot, in the comments. Matt, he called you mister Blue, which I feel like more of us should do.
[02:13:47] Unknown:
Room because that's ambiguous.
[02:13:49] Unknown:
Yeah. Mister Blue's good. It bangs. Yeah. Should we should we do what what Cody suggested, an hour ago?
[02:13:59] Unknown:
Yeah. Sure. So let's go around for the projects of, like, what the road map looks like for them and then, like, contribute. We talked a little bit about contributor status, but, like, anything where you're kind of, like, lacking somebody and you'd want them to, like, come in. I work at a couple of, I'm sure everyone else has maybe a couple of, like, this is part this is part of our roadmap where we don't have dev resources that we could throw at this right now. K.
[02:14:21] Unknown:
Sure. I'll speak to my rusty coin. It feels like the project's healthy. We've got people coming in. I go to sleep sometimes, and I wake up stuff's done. So it feels really good, but it's like sometimes it doesn't. Yeah. So it feels good. We've got developers. We need more of yours. It's felt good to hear everyone, or it's been good to hear everyone saying that they're using the project. That's great. My ultimate dream is that no one ever talks about rustic coin. It does exactly what you want. No one rinses about it, and you never hear about us again.
[02:14:50] Unknown:
Yep. They agreed on all counts then. Yeah. The biggest thing we need are are users who, will tell us what they're doing. So we we aren't, accidentally breaking up stuff. Yeah. Double on the on the user feedback, I think. So BDK, we do want you to hear about us. We want people building products, you know, new self custodial, high privacy on chain stuff, high security best practice. We're stabilized specifically so people can do those products and get that kind of guarantee and give us the chance to write the documentation. So we need your help and feedback, documentation, build stuff with us. Just build it. And if you're, you know, an existing user of BDK, let us know. We will help you migrate, to a pre one point o to the one point o API. So, you know, reach out. We're on Discord or, you know, email. We we're building the software that is built by people that are better than anybody else you'd be able to hire. Like, these are rock star Rust devs that are building amazing software and you get it for free. Of course, we would like your support financially also, but, it's a complete game changer for building a company. So please take advantage of that.
And, yeah. Check us out. Bitcoindebkit.org.
[02:16:07] Unknown:
Before I get into that I'm sorry. I have to bring the conversation back once more. 6 hour podcast. Someone did DM me, and they sent me a chart. I'm not actually sure where it's from, so I don't know if it's legit. But it does show the BCH hash power getting a tick over 50%, very briefly sometime between midnight August 20th August 24th. So we were on, thanks to Eric Wall for pointing out.
[02:16:35] Unknown:
Eric Wall.
[02:16:39] Unknown:
I I will point out that, Rob in in the room pointed it out to me. And I told I basically I shushed him.
[02:16:46] Unknown:
I got to shoot. Yeah.
[02:16:49] Unknown:
I mean, I I mean, that's like that that was the kind of show you. I don't think that was, like, a real flip. But you're just trying to keep the frequency No. I'm not I'm not person. Gaslighting. I admitted it. I admit it. Fighting the freak. Gaslighting the chat that was telling us we were wrong. But how did they measure that? Like, how is that even measurable?
[02:17:06] Unknown:
It was a 3 hour rolling average.
[02:17:08] Unknown:
Okay.
[02:17:10] Unknown:
I got the same image from Maribel. But, like
[02:17:13] Unknown:
oh, you got it from Maribel? So he hit you first, didn't get didn't did get spoke about, and then he hit he and mister Blurb. Can explain yourself. I like Eric. Eric's one of my favorite shit corners. I, yeah. I mean, at that point, if I recall correctly, like, in August was
[02:17:32] Unknown:
they had, like, a ridiculous difficulty adjustment algorithm. Remember, it's like teams and their algorithm trying to It was like an insane trying to steal hash power Yeah. Worked very briefly and then it created And it was really bad. Their market collapsed and then they got their hash power.
[02:17:46] Unknown:
Okay. Continue.
[02:17:47] Unknown:
Alright. Alright. Yeah. So, LDK, our road map sadly, you know, a lot of people in this room talked about all kinds of great API things and trying to get the API perfect and focusing on stuff like that. We just we're just trying to ship features. We've gotta ship, splicing and bill funding and taproot channels and multisync channels and, async payments and trampoline payments and BLASA. Nice. So, we have a huge road map. We like our API. We think we're our API is pretty good, but that is not our focus. But we are hiring, so the great thing about LEK is Spiral has headcount full time to work on this. You know, we funded a lot of developers on other stuff, but Spiral you can come work directly for Spiral, and we are hiring right now for at least 1 LDK engineer, maybe 2.
You don't need to know Rust. We don't require you to know Rust. I think everyone on Spiral learned Rust while working on LDK. I don't think anyone actually knew Rust coming in. Some people didn't know lightning that helps, but it's certainly not a requirement. Somebody in the chat's asking if splicing is an in all the key today. No. It's not. We're getting there. We've got we've made good progress on it. We're not right there. We'll find things a little closer. But we've got the state machine. We gotta finish writing it.
But also more broadly, and I think this was discussed earlier when I also wasn't in the room, but, you know, if you wanna contribute to an open source project like LDK, it doesn't have to be writing code. In many cases, it can just be providing feedback. LDK, a little harder because it's actually a library, but, you know, write take LDK Node. Try to make a high level app. You know? It's act it's designed to be super easy. You should only barely need to be a developer to know how to do that. So do it and let us know how it goes. And I think one thing that open source projects universally don't get enough of is just user feedback.
People assume that open source projects, you can just take it and run it. And if it doesn't work, then you have to work around it because it's open source, so you have to do the work to make it run. No. Let us know. Let us know how it went. We wanna get better. We wanna actually get feedback, and we just don't get that in a way that a lot of for profit things where people pay for it and then they assume they get support. And in many cases, open source projects do actually give you the same level of support. You just have to actually ask for it. You have to know you wanna you can ask for it.
[02:20:10] Unknown:
Yeah. Just to briefly add for that, for, for release, we're really, really looking forward to upgrading, to BDK 1 dot o, which will be, really great, on many levels. It will also allow us to get add a bit more server features syncing with Bitcoin, stuff like that. That will be great. Also, we'll be looking to add some more support for the LSP spec. But apart from that, what I wanted to mention is one takeaway from this week was that a bunch of this project or I think all of the project most of the projects in the room were actually, building out, language bindings that kind of reexported some of the rust Bitcoin types.
And one takeaway from this week was that we will now create a new project that basically instead of everybody doing the same work of exposing these types of rust Bitcoin, we'll do that once and all the other projects can reimport that project so that these rust Bitcoin types are available. This will be writing a bit of boilerplate code, and it it will probably not be super complicated. But if you, out there, basically, are, a Rust developer and have, maybe even with experience, with with language bindings and maybe Unify in particular, the Mozilla language binding generator, that would be a really great project to start contributing to that would benefit all of the or most of the projects here in the room.
[02:21:42] Unknown:
Yeah. And then, I'll cover Fedi Vin, and then let's go for everybody else because we've got a bunch of projects here. So for FettiMint specifically, we're cutting a 0.4 release this week and then after that, there's a couple of different, Rust elements that we're working on. And so but to work on payment, you kinda need to be a pretty significant lead experienced Rust developer because there's consensus code involved. But, one thing we're really excited about is we're gonna have a TypeScript client very, very soon. And so that's just gonna be a drop in WASM compatible so you can just put it run it in a PWA or you can run it server side, but like a full TypeScript client. So more people integrating Fediment into their existing applications. Right? So if you want something where you already have an on chain component it or you already have a Lightning component but you wanna add, eCash, it's gonna be the the goal of it is to just have a super simple drop in. So anybody working on any other Bitcoin projects wants to add Feddy Mint, like, we're gonna have very good TypeScript bindings for that. So you can just drop it in, just npm install or uninstall Feddy Mints, and then, you can get started with it. Yeah. I want me to rephrase a bit. The goal of, the Fendament Web SDK is going to be to completely eat everybody's lunch in terms of developer experience for Bitcoin Lightning.
Everybody, but, Yeah. NPM installed, and we have a fully working Lightning wallets, eCash wallets, unlock your wallet. Yes. It's one sec. So deal. So yeah. Yeah. And so doing a DevX. That'll be pretty great. And then, specifically within Fedimint, we have UIs for the running the guardians and running the gateways that we don't have developers for just because the guys who normally work on it, they've, kind of moved on for other projects. And so anybody with any sort of React experience, like, we can help you out with all the Rust side of things, but it's mostly just working on a normal front end project. So any front end web developers like Faiman's definitely, wanting some of you guys right now. Also, yeah, we're we're also serving for, like, front end help, in the open source side. So, like, for, like, the Guardian UI. You know, right now, Cody is, taking that all on himself, and the the Fedi front end people are, strung out. So so, yeah, if you are a front end dev and wanna contribute to some of this hardcore Bitcoin open source stuff, yeah, we need you to.
Yep. And maybe go around the room for anything. Hey, Tony.
[02:23:54] Unknown:
Hey, Tony. I wanted to say a couple things on Russ Bitcoin, though, that we missed. We missed, some some Cindy cryptographic function optimization. There is some room in Rust Bitcoin to optimize these functions. Maybe We talked about that as a problem and we also talked generally, all of our projects are looking for a better HTTP client, to make requests. Yep. Turning an HTTP client that already exists, async, one that's async. Yeah. Yeah. On the page one side specifically, we're working on getting our dependencies up to speed with everyone, of course, finishing the async pay join protocol spec, which is very, very close that will be merged in the bps repo this year for sure, hopefully fall during the fall, and getting a pseudo stable, maybe the better word is complete API for page 1 so you can do some of the more interesting batching stuff if you're an exchange or someone like that.
So there's there's cryptographic stuff to do for public key encryption that's a cross between what PayJoint is doing, what Rust Bitcoin has, and some general Tor alternative oblivious HTTP stuff that we can work on, and that's that's about it. Yeah. When do you expect people to use PayJoin? I mean, I use PayJoin.
[02:25:29] Unknown:
I mean, like, more than like, more than a dozen of us.
[02:25:33] Unknown:
I don't understand your question. I'm not even using PayJoint. I don't know. I,
[02:25:38] Unknown:
I'm not gonna what? It's out there. You can't I know it's out there. I'm not gonna we'll we'll we'll have a proper conversation, just the 2 of us. But, I think Pedro and I I mean, I love I love what you're working on. I think it's incredibly important. But it probably unless we see, like, a mainstream client that just completely ignores coin selection and just does pay joints by default, like, we probably will not see significant adoption, and we have not seen significant adoption. I completely agree. I think the reason you haven't seen it in mainstream clients is because the original
[02:26:10] Unknown:
two protocols relied on synchronous communication Yeah. Which is incompatible with someone like an exchange using it, but the new protocol allows that to happen. And there are 2 exchanges who have commitments to integrating it with both their exchange product and their client applications
[02:26:27] Unknown:
as soon as they can. That's awesome. I just wanna jump in. So Dan showed a demo today with BK and the new page point protocol, the CLI. I think making examples of how to do this for, you know, your basic or maybe wallet developers will help just adoption. Are there Make it available. Ready for mutiny. They just have to hit the merge button. Are the 2 exchanges public?
[02:26:49] Unknown:
Yeah. Galois has a bounty out for it, and Francis has been tweeting all over the So Bill Bitcoin is 1? Yes. I think Galois is not an exchange. Galois has a custodial exchange product, I think, in blank. No? I don't know. Yeah.
[02:27:03] Unknown:
Okay. Dope. Well, maybe jump to the chat. It's asking just a couple of small questions. The one is is Requests not cutting it? And no. I mean, Requests has a massive dependency tree for one thing that, like, exceeds the size of any of our existing dependent. So we don't wanna open more than double that. It also, how it's like it changes kind of frequently, so it's difficult to have it as a dependency because then you can't stake what's the single compiler version. Then are those the repos being discussed? That is definitely Rust Bitcoin. Is that the repo? Yes. Yep. Cool. And then is this a point of PDK? I guess you mean BDK.
[02:27:40] Unknown:
No. Page on that. PDPDK.
[02:27:43] Unknown:
And Oh, okay. Cool. We're adding just every everything's a dev kit. They needed a new protocol too, though. It wasn't just a dev kit. The dev kit started getting built last year, and then there were the protocol was terrible. It required synchronous communication so we needed a whole new protocol and now that's just maturing, like that is that is almost merge worthy.
[02:28:02] Unknown:
Also, a request isn't blocking quite well. It does like a Yeah. It's weird. Small blocking. Async is small blocking that is not, like, blocking. So yeah. One more critical thing.
[02:28:14] Unknown:
The new version of PayJoint, we're looking for someone to help implement it in Bitcoin Core. It seems possible now that you can just take the Rust implementation and copy it over into c plus plus
[02:28:29] Unknown:
and there are some avenues where funding may be available. To be clear, he means the wallet. Like, it's not a core protocol change. It's just the wallet. Get a feature. One core wallet. Exactly.
[02:28:38] Unknown:
Dan, can I ask you, like, if you're making a private well, a public shield to exchanges to add, this support, like, what is what is the, what is the sell? Like, do they have fee savings out of it? What is it? Yeah. The biggest thing is fee savings. So
[02:28:57] Unknown:
the example is cut if you go to payjoin.org and click learn more, this is the first article that talks exactly about this. We show an example where you save, I think it's like 16% in fees and this is not a totally optimized example where this is an absolute best case. This is like a pretty generic example that's a small transaction. So if you take batching Right. Which has been around forever, that only allows you to batch outputs actually. Yep. PayJoin lets you also batch inputs. It totally opens up that space. So it's like someone's depositing to the exchange and they participate in the batch withdrawal. Is that what's happening?
[02:29:33] Unknown:
Exactly. And Oh, that's cool. As a consequence,
[02:29:36] Unknown:
you blur the edge of the cluster of each of the depositors and people withdrawing and the exchange because unless you are the exchange yourself or one of the participants, you don't know all of the coins involved. So for a 3rd from a the perspective of dragnet surveillance, they join As long as the exchange isn't providing that information. Publishing things, it's still it's still worse. But if your exchange does this and you deposit, then at least It's strictly yeah. Interacting with you. Like, if I'm giving you some money and you, for whatever reason, are selling Bitcoin to an exchange, which you would never do Right. Then it would be more difficult Not on chain. That you're going to that exchange or your,
[02:30:18] Unknown:
like, how much you're depositing? It's strictly net net better. And, from an external external viewpoint, it's it's strictly better and the exchange saves
[02:30:28] Unknown:
money. That's right. And everyone everyone wins. It's a good sell. And it fall it falls back. So if it if the page one doesn't work, you fall back to a naive transaction. Okay. I'm gonna I'm gonna help you with this. We'll get more we'll get more onboard.
[02:30:41] Unknown:
I'm sold. Matt does naming, and he does project descriptions.
[02:30:47] Unknown:
You're good.
[02:30:48] Unknown:
Who's next? Oh, maybe I'll jump in here. I get to have some closing thoughts without actually saying much conversation, which is nice. Can we introduce Nick? Yeah. So, Nick, our thanks for joining us. Thanks for having me. It's good to see you again. Nickar, we were back.
[02:31:03] Unknown:
So working for us now. On all of the things we just discussed. Yeah.
[02:31:07] Unknown:
We can go back to the start. Just just keep it on your. Working for a snap, next generation multisig. It's gonna make Bitcoin self custody much much easier, much much better, much more more private. We could do a lot of fun stuff with it. Also, separate to Frost Nap, we have a very spicy thing coming out in maybe today, maybe tomorrow. I can't talk about it publicly yet. Oh. Looked forward to that. It's coming out tomorrow.
[02:31:38] Unknown:
You teasing us? What is it? Oh, yeah. I can't tell you. Everyone's already No. We'll we'll edit this part out of the Yeah. This live
[02:31:51] Unknown:
Yeah. They're gonna have catch that. Right?
[02:31:53] Unknown:
So I don't even know what it is, but sure.
[02:31:56] Unknown:
But, yeah, check out frostnap.com. Next generation. This one's on custody. Twitter for the update. Oh, yeah. Yeah. Probably, if you wanna see the the thing we're gonna post soon, UTXO UTXO club on Twitter.
[02:32:11] Unknown:
Do do you have an aster or no? Website. Read out your hand pub.
[02:32:15] Unknown:
Yeah. Yeah. What is your name, bud? Nick at utxo.club
[02:32:20] Unknown:
is my,
[02:32:21] Unknown:
zip zero file. She'll blind sign her too on Duster.
[02:32:25] Unknown:
Oh, yeah.
[02:32:26] Unknown:
Yeah. That's good.
[02:32:27] Unknown:
That's that's gonna take too long. We gotta go away over 2 minutes.
[02:32:31] Unknown:
Thank you. Is your hardware wallet public yet or no? Well, there's there's no video here. I can It's like the human centipede of hardware wallet. It's like the mouse plugs and tabs. Supposed to be posted on that or you just Well, I asked him. I asked him. Something else. Yeah. It's a cool design. I like it. We we can post
[02:32:51] Unknown:
this the new devices publicly as well soon. They'll be for sale soon as well. Soon, GM.
[02:33:00] Unknown:
Yeah. You just, like, you plug the mouth to the ass over and over again for multi sig. It's amazing. Actually, I have some for you. Oh, thank you. I've seen some out points with all those ones. Not not the ones I have in my hand. We'll edit this part out. I'm glad you called me on that. Thank you for joining us, Nick. It was a pleasure. Service. Yes.
[02:33:21] Unknown:
Yeah. I can go. So I'm the single kid. I'm working on Kashi Dev Kit. Similar to other parts and agreements that the development kit built built in, Rust.
[02:33:34] Unknown:
Kinda was at the top of the click containers.
[02:33:36] Unknown:
We're looking for people to build stuff on Cashew and in general. It's it's really wide open design space. There's a lot of stuff left to do, and then you can use CDK to do it. It does both knit and and wallet. So whatever you're looking to do, you can use CDK for it and let me know what's what's broken in it. It's it's a little less mature than the. But yeah. So let me know. Report issues, and I'll fix them, or even better open a PR and, can join the.
[02:34:06] Unknown:
Okay.
[02:34:08] Unknown:
Hey, wait. You got you got PayPoint 10 runs working in half an hour. Right?
[02:34:13] Unknown:
It's a little more than half an hour because I have the whole,
[02:34:16] Unknown:
PayPal wallet. But the PayPoint card was was about a half hour. Yes. The cash you guys have actually have on chain support, but,
[02:34:24] Unknown:
I hacked it into it some day. Oh, yeah. I was wondering about that when I was watching the presentation.
[02:34:29] Unknown:
Yeah. So there's a a draft a draft knot, to implement it. So, we're working on on getting on chain support implemented,
[02:34:39] Unknown:
in the in the spec. Because you know Cali fundament I mean, he's not the ruler of Cashew, but he fundamentally disagrees with on chain support. Well, we'll see. Because of the because of the permission thing. Because of, you know, Mintz not being able to control what goes in and what goes out. Yeah. That is that is one of the issues. I mean, we have Cody here. Like, Fedimint had a DNS issue where, like, some of the Fedimint's, they got banned on the dotxyz domain, and, they couldn't stop people from continuing to deposit. And Cali kinda took a victory lap on me on that one. And he was like, well, that can't happen with Cashew.
[02:35:19] Unknown:
Well, so Cashew is a little bit different in that it does you I mean, of course, it does it's a quote. You get a quote before you deposit. Of course, if you do get a quote at a time, you can still use that that address later. But in theory, if a wallet is functioning correctly, it's getting a quote and using it kind of immediately or within the expiry time. On chain, of course, you can't, like, actually expire the address that you can with lightning so that that it doesn't use that issue.
[02:35:47] Unknown:
But, yeah, it's kind of an unavoidable issue on on chain, I think, that that leads it up to implementation to protect users. I mean, I will say from, like, a user point of view, like, leaving a mint. I prefer having on chain support like, native on chain support so you don't have to deal with liquidity or anything. Otherwise, it just becomes, kind of what we're talking about with, like, time out channels. Like, in a real user situation, it's just them going from, like, custodial they're, like, hopping from custodial wallets trying to not get rugged Yeah. When on chain is beautiful. Right? It's like you just give them an address and you just get your money. Yeah. So both in for both on chain and lightning, the mint operator does have the option to disable,
[02:36:26] Unknown:
like minting. So an operator could decide to do, you can't you cannot mint into on on chain, but you can melt on chain. So that would be the spec would probably support groups or both. Like I said, it's a draft, so let's let's see what actually happens. But, the operator could decide to do exactly that where you have to peg in lightning and you peg out. So you go withdraw via on chain but not deposit? Yes. You could do it that way via the implementation.
[02:36:56] Unknown:
Cody, you wanna defend Fedimint until you grab the white? So specifically, I'll be in this issue that is solved in 0.4 getting cut this week. So Nice. I appreciate your your work. Yeah. For the and the for the on chain wallet, that's currently, well, there's an element of it where if you give out a previous wallet, a previous address, you can't stop somebody from doing another deposit for that other one. But, currently, that's just an implementation detail impediment is that the way that you do a peg in is that you tweak the Federation's descriptor and you deposit to the tweak.
And so for that one, because the descriptor, the Federation is public for it or they reveal it to whoever in their community has, like, joined the federation, you I mean, you could stop it of just, like, you stop revealing what the descriptors. Right? Or the other thing is, for example, for, like, if we move to, like, a BDK wallet, where instead of the client creating the address, the federation creates the address and gives it out, and the federation, just the same way with Casio, could just stop giving out the address if they wanted to be Right. Documenting. Fair enough.
[02:38:03] Unknown:
Hey. I'm Rusteshin Rob, and I'm working on some compact block filters, node implementation in Rust. Right now, it's just me. I make an issue and talk to myself. Stop some eyes on it. Yeah. It's called Kyoto, because one of the main dependencies is Tokyo. So,
[02:38:28] Unknown:
for a station,
[02:38:29] Unknown:
Rob. Kyoto, please come check it out and, save me for myself.
[02:38:35] Unknown:
He has it well integrated with BDK and a great demo also on, with language bindings recently. I think we got that running with, Swift. So it's Yeah. A lot of fun stuff to play with. It's,
[02:38:49] Unknown:
it's a standalone project, I guess, technically, but I had BDK in mind, like and LDK Node as well. So all the design choices and stuff, if I've been, yeah, mashing it at a BDK, and we have a wallet balance that updates properly and everything. So, yeah, it's pretty good.
[02:39:09] Unknown:
Awesome. Anchor watch. Anchor watch.
[02:39:13] Unknown:
I'll just briefly plug that we use a lot of work on top of BDK. So for things that are on the BDK roadmap, we're obviously interested in our things like the mini scripts planning module. I know that maybe more of a BDK 2 point o thing, but any eyes or anyone who's interested in being able to streamline. I can have a bag of keys that are part of my larger vault, and I can kinda put in a date and a time, and I can get, you know, pre trap stuff sent over me, which is we kind of code around that right now with, like, hard coded, understanding what layer you're trying to execute upon. Just as a really quick thing with all the logic before talking about time locks, that's what BBK must be quite greatly abstract because it's constructing all of the witness data that is on top of that also the end lock times required. So it's just a massive force multiplier for us. And I'll hand it over to Matthias because he's also upstreaming some code around databases to BDK. Yeah. I mean, yeah, just being able to host multiple wallets,
[02:40:06] Unknown:
in Postgres using BDK. I gotta get that going, hopefully, the next week. And then I think there's still a bug in cargo that doesn't let me add it to the BDK repo. So, hopefully, when that gets fixed, I'll add it to the BDK repo, but otherwise, it might just live on the Internet as its own crate. But, yeah, thanks thankful for everyone in here working on risk Bitcoin, BDK on Fediments. I mean, rising tide lifts all ships. So, yeah, just, super grateful to be a part of all this. So thank you, everyone.
[02:40:44] Unknown:
Stay humble, StackSats, and support open source.
[02:40:47] Unknown:
Love it. Love you all. Peace.
[02:41:08] Unknown:
Fast on a rough road riding high. Through the mountains climbing, twisting, turning further from my home. Out into this great unknown. And I don't want no one to cry. But tell them if I don't survive, unknown stranger. Grateful for my time with no regrets. Close to my destination, tired. Frilled and aching, waiting
[02:45:24] Unknown:
Love your freaks. That was born for you by Kid Rock. Stay on the stack set support, open source contributors. It's a it's a good idea. You should do it. It it helps all of us. One of the easiest ways is by going to opensas.org. There'll be more dispatches. I have no idea when they're gonna be, and thank you guys for all being a part of making this happen.
Pounding the table because eventually the Fed is gonna start easing here. That's great for gold and that's for Bitcoin. What I said is Bitcoin is growing up and will be eventually half the total market cap of gold. So that's about 350,000. So quite a ways to go from here. The Super Bowls, if central banks adopted and, you know, it's part of the monetary system, then, you know, in the millions, but I don't like to talk about that too much. What more than 2,000,000? More than 3? Yeah. Like 2.9. We've got some model, which is you you have to look at the assumptions. Right. Well, yeah, there are always big ifs there.
[00:00:40] Unknown:
Where are you as an ETF guy
[00:00:43] Unknown:
with all kinds of different ETFs? Everything from fixed income to, you know, who knows? Staples, consumer cyclicals, etcetera. Yeah. Where do you put your personal money right now? I like longer term trends because I feel like, okay, it'll be a bumpy ride, but I like to have conviction about something that's gonna happen in 5 or 10 years. To me, there's no doubt that Bitcoin is becoming adopted the way gold is. I just think it's it's it's it's obvious. Now, I think you have to have your own diversified portfolio and kind of having a huge overweight to Bitcoin is a personal decision, but I I just see that rising. I'll give you another example, India.
The Indian economy is the best macro story. Everyone says the stocks are overvalued. I get it, but it's doubtless. The Indian equities have done as well as US equities over the last 10 years and will continue to do well. Correct. He but he was a gold bug. So Of course, the founder.
[00:02:09] Unknown:
Yeah.
[00:02:12] Unknown:
Happy Bitcoin Friday, freaks. It's your host, Odell, here for another Citadel Dispatch, the interactive live show focused on actual Bitcoin and Freedom Tech discussion. That intro clip was Fox Business with the Vanex CEO, humbly calling for a $2,900,000 Bitcoin per his model, says that Bitcoin will be worth half the market cap of gold. I'd like to remind the VanEck CEO that Trump said that Bitcoin is gonna be worth more than gold, so they can argue about that. And Michael Saylor called for a $49,000,000 Bitcoin, which if you're wondering what the environment was when I started doing 200 k by conference day in all caps, it was kind of like this. And it kinda makes me wanna just go $200,000,000 by conference day, but I'm gonna stay humble and not do that this cycle. Just stay on the stacks and and and focus on improving your skills. Guys, we have a crazy rip today.
Bunch of legends in the house. This is the tail end of the Rust Bitcoin Summit at Bitcoin Park. Obviously, last week, there was, quite the circus in Nashville with the Bitcoin conference, and, we also had a bunch of really great content and people here at the park. But we're a little bit masochist here at the park. So, of course, a Rust Bitcoin Summit was planned for the week following that, and And these gentlemen just wrapped on that. So without further ado, let's get to the show. I mean, I think we're gonna probably have, in total, maybe 15 to 18 guests, on this rip, and they're gonna cycle in and out. Right now, I'm looking at 7 people.
The rest are eating lunch, and they're gonna come in and out. Tobin, why don't you pick up the mic? We have Tobin Harding here. How's it going, Tobin? What's what's what what was the Rust Bitcoin Summit?
[00:04:14] Unknown:
How you doing? Good to be here. Rust Bitcoin Summit was a get together of programmers who write in the Rust program language, who worked on Bitcoin all day, and who wanted to come to Nashville.
[00:04:27] Unknown:
Let's go. And and who the hell are you?
[00:04:29] Unknown:
Me. I'm Tobin. I live in Australia, and I work in Rust on Bitcoin all day.
[00:04:35] Unknown:
And, I mean, you're also a rider like freak. Right? You you
[00:04:38] Unknown:
you listen about dispatch and rabbit hole recaps. So Dispatch tends to go for 3 hours, so sometimes I get bored. But, yeah, I listen to the actor.
[00:04:47] Unknown:
Well That's so interesting. You know? To the show. If if you're listening right now, hopefully, we won't make you bored. We have Andrew Polster here. How's it going, Andrew?
[00:04:59] Unknown:
Hey. Good to be here. I'm Andrew Polster. I'm the founder and, comaintainer of West along with Tobin, couple other people. So I'll try to share the mic. Yeah. Why don't you why don't we pass it down and everyone introduce themselves,
[00:05:13] Unknown:
because we have a lot of people here.
[00:05:16] Unknown:
So hi, folks. I'm Jose. I contribute to Buzz Bitcoin and BDK. We are welcoming contributors, so go hang out on GitHub. We have, like, very nice, contributor friendly, new, issues. So, yeah,
[00:05:32] Unknown:
come and join us. Awesome. Yeah. I'm Cody. I work at Feddy and, on Feddy Mint.
[00:05:40] Unknown:
I'm Dan Gould. I work on PayJoin DevKit and Rust Pay Joins to better Bitcoin matching.
[00:05:47] Unknown:
Rob Hamilton. I am a Rust Bitcoin and Bitcoin devkit prospector,
[00:05:51] Unknown:
and will be build our tech on the bank watch.
[00:05:54] Unknown:
Yeah. Hey. I'm Matthias de Bernardini. I'm, building on top of BDK and Rust Bitcoin, working at Anchor Watch with Rob. So yeah.
[00:06:05] Unknown:
So how the hell are we gonna structure this conversation, gentlemen? Why do we have Rust Bitcoin? Where did it come from? How do all the Do do you have a mic? I got my there's mics for me.
[00:06:15] Unknown:
I I wanna know how
[00:06:17] Unknown:
Russ Bitcoin, this project from 2014, turned into the basis for all of the applications built on Bitcoin. Now, you know, Cash App's using it. Well It's, like, uses it. It's everything. Well, first of all, I mean, dispatch has mostly a technical audience, but it's also a lot of technical curious people. And I think one of the things in the space that we want to see more of is, just more new open source contributors. I like to say, like, our our birth replacement rate is not great right now. Like, the devs die before enough new ones are born. So what the fuck is Rust?
Let's start with that.
[00:06:51] Unknown:
I'll I'll take that one. So Rust is a new programming language, you know, in terms of, you know, the history of computing and all of that. You know, you have Python, c. Those are, much older languages. But Rust is relatively new. And the purpose of Rust was to allow people to make programs that are both performance and secure. So for the longest time, you pretty much had to choose between 1 or the other, whether your program was very secure or it was very fast. And it was hard to sort of have your cake and eat it too. And this fellow at Mozilla, working on the Firefox, browser, I think his name is Sheldon Graden? Graden Hore. Graden Hore. Yeah. Andrew, the mics exist. Yeah. Yeah. Yeah. Talking to mic people. Those people. And he was trying to was working on this, on on the browser, and there was a very difficult problem that, they were trying to solve.
It was I believe it was the, the CSS render in Firefox. And this, part of the browser is very important because, you want it to be really, really fast so that your page loads. And the issue was that they had a number of implementations in c plus plus which is what Firefox is written in, and they pretty much all of them had one issue one way or another. Either they could get hacked, you know, just loaded with vulnerabilities, or it just wasn't performing enough. So, this this fellow went back to the drawing board and took all of the, you know, learnings of past 20 years at at the time and just combine them into one programming language and just start to work on it. And that was the sort of the beginning of Rust. Would you would you say that Rust is
[00:08:57] Unknown:
the hottest programming language out there right now? Like, I feel like it's it's hyped a lot. Like, people get really excited about it.
[00:09:04] Unknown:
It it does get hyped a lot because people are very excited about it for for a lot of reasons. The the biggest one is that you can if you learn it, you can start making applications that are both, memory safe and performant. And you can kind of have your cake and eat it too. I mean, there's there's caveats to that, but, people are definitely excited about it, which is which is positive. You know, in any new language, you desperately need, incomers to just come in and and adopt the language.
[00:09:41] Unknown:
But it it it does get hyped a lot. I don't know if,
[00:09:44] Unknown:
it's the most hyped up language.
[00:09:49] Unknown:
I mean What is the most hyped up language? CSS.
[00:09:52] Unknown:
CSS.
[00:09:55] Unknown:
I mean, Dan, look, if we don't take the what Mike away from this guy, he's just gonna talk the whole time. Yeah. Yeah. I'd say one of the really valuable things for it is that you
[00:10:05] Unknown:
by programming in Rust, you can eliminate entire classes of errors that you would get from programming in other programming languages, and some of those are, like, the most common production errors. Something on the order of, like, 70% of production errors end up being a, like, a memory error of some kind. And simply by the fact of programming in Rust, you can very reliably remove those classes of errors. So for really, production important materials like stuff around Bitcoin, if you can just eliminate those before you even deploy the application, it's very valuable, especially, like, when we're dealing with people's money.
[00:10:38] Unknown:
There's is there is trade offs. There's no silver bullet. So everyone starts off as a massive fanboy, but eventually, you hit an edge case in the language and it's annoying. But it is generally a fun language to write. But, yeah, we shouldn't be present it too much like it's all hollow because the air is so hot right now. But, yeah, there is downside. We don't need to go into all the negatives for their own negatives.
[00:10:58] Unknown:
Okay. So Rust Bitcoin. What is Rust Bitcoin?
[00:11:02] Unknown:
Well, Rust Bitcoin is a project I started in 2014 or so. So the the Rust language itself had its 1.0 in 2015. But prior to that, it was, I mean, it was originally created in 2008, and there were various iterations of the language prior to 1 point o. Really big things are happening. It's not like the Gmail beta where, like, everything changed for 10 years of beta. Right? Yeah. Rust language was dramatically changing pretty much right up to the week of the void. And I heard of this. I heard that Mozilla was using this for Firefox and their CSS renderer and and whatever and thought it was a pretty cool thing and wanted to stay with it. And at the time, I was already into Bitcoin. That was kind of the thing that I knew that I didn't have to go googling around to get stocks for. So that's why I started writing. And I was just kinda keeping up with the language evolution. If you look at the Git history of of Rust Gitcoin, you'll find also for syntax that no longer exists and didn't exist in in Rust 1.0 because it was basically a way for me to play with language features and, on on something that I was familiar with in in a problem domain that I had experience tackling with c and c plus plus and these other languages.
And in those early days, it was really just my personal hobby product. I was using it to scan the blockchain to like answer random problems that popped into my head. You know, like what's the average transaction size or, you know, stuff like that. And, and you can even find I was making PRs and and filing issues with the Rust compiler. That's an early RFC in the Rust programming language, which if you search for my name, you'll find it. So probably the worst RFC they gave a number to. But I fixed, like, 20 bugs in one shot by basically proposing that we remove a bunch of stuff from the language that didn't really work. Unfortunately, I wasn't the only one who did that, and there there are a bunch of missing things in Rust.
But, Yeah. Rust picked one of really just a toy for for the longest time. And, and I don't know exactly when it became a a big thing that we would have a a summit for. But there are definitely over the years, a couple of people showed up who knew Rust, who weren't writing c and translating into Rust the way that I was And weren't just like playing with obscure features and copying bad ideas from standard lib like I was. And they helped clean it up. And then later we had things like the BDK project, that started using Rust Bitcoin seriously for real. And, and then I realized that I should stop screwing around.
And at some point, I will actually stop screwing around, but I definitely definitely realized that I should stop.
[00:13:31] Unknown:
Awesome. Alakos, you gotta hand the mic. By the way, now we have we have 13 Bitcoin developers in the studio right now. We
[00:13:41] Unknown:
have I was gonna say, Alakos, if you wanna take on the question, you've joined in a little late. Like Yeah. That is question of why, like, why Rust Bitcoin? Why you wrote it in Rust? You could maybe take the the the the baton on that and say why,
[00:13:55] Unknown:
you know, make another wallet library in Rust on Rust Bitcoin. Would that genesis happen maybe? I think that's a great idea. The person who was just speaking was Steve Myers, a maintainer of of BDK, a Bitcoin park member who runs our our bit devs. And, now he's handing the torch to to Alexos Fellini, do do pronounce your last name correct? Yep. He makes that cool, NFC hardware wallet now. Yep. What do we call that again? What's his what? Oh, portal. Portal. Yes. Portal. So, Alex, go to Yes. I miss
[00:14:29] Unknown:
more than actual conversations. I'm not gonna repeat much stuff, but, yeah. So Rust is cool. Rust gives you a lot of security guarantee. I guess you already talked about that. Correct. And so was made in Rust because when you start a new project, you, just look for the best tool to get the job done, and I guess Rust was the best tool to get job done. It started as kind of an internal project I was working on with a bunch of consumer release and it also uses Rust quite a lot. So, yeah, it was just, I don't know, natural to to start using Rust for it. And there were there were, thankfully, great tools, Rust speak, Rust speak, or any. So it kinda made sense. I guess the language was good.
The people I was working with were familiar with it, and I was starting to learn it more and more. And yeah. And then the the ecosystem of us is developing was developing, still developing very well. So it makes sense to to be positive and and make BDK with that level.
[00:15:33] Unknown:
Awesome. I mean and I guess to go to where Dan originally started, so now, like so so BDK was was built with Rust Bitcoin underpinnings, essentially, and now there's a ton of projects that are being built on top of BDK, basically. Right? So there's, like, this whole ecosystem that's developing around this, and it's part of the reason why the summit exists.
[00:15:56] Unknown:
Yeah. There's a lot of dev kits now. We've also got Matt Corallo in the studio for, doing lightning dev kits. So maybe you wanna get a little bit of that because sort of the order of this was Rust Bitcoin, BDK, LDK.
[00:16:08] Unknown:
Yeah. So that it's Bitcoin devkit and Lightning devkit. Alright. Yeah. And then there's also
[00:16:14] Unknown:
Casu dev. Yeah. Casu dev kits in the room. Hey, join dev kits in the room. We're cornering the market on the dev kit. Fedi Min is Fedi Min is not dev kit. No We've been discussing mean Fedi Mint dev kit. We need to corner the market on the dev kit. Yeah. We have to log in and we kind of organize our repos the same way that you guys do. So I guess, technically, this kind of sister project, all these other things, kind of your sister project to BDK. BDK is on chain. LDK does lightning. And similarly, it's kind of a library designed to let people build, whatever they want based on using the Lightning protocol to build awesome wallets or awesome whatevers.
But he met now or several, I guess, Catu 2 has some options to use LDK to power the lightning, gateways.
[00:17:11] Unknown:
That has a bunch of mobile ones. Now
[00:17:14] Unknown:
I'll be getting node, which is a much easier, lighter weight API that you can get started with really quick, few lines of code, and you can have a lightning wallet in your app with LSP spec support. So we've got a lot of stuff cooking there too, but, yeah, there's there's just a lot of great stuff in the Rust ecosystem.
[00:17:34] Unknown:
Yeah. And the cool thing about Rust too is that we can kinda use this as sort of a baseline for all of the other languages as well because Rust is really good, support for exporting bindings in all the other languages. So it becomes a really powerful tool for have this be the base, like, have the reference implementations in Rust, and then they export bindings to TypeScript, Python, Java, Swift, all those other things that everybody else wants to do. So that's sort of what this whole summit was about for, like, how do we make the really strong core that everybody else, when they're building applications, can kinda build on top of.
[00:18:09] Unknown:
Love it. Phreaks, if you're listening and you're not in the Nostril Live Chat, the Nostril Live Chat is sidildispatch.com/stream. You do not need to have a Nostra account to use it. Feel free to throw questions, comments in there, or zaps. The show does not have ads, so please send me sats for my family. Cody, I mean, I you're the host here. I'm just the producer.
[00:18:35] Unknown:
Yeah. Maybe we could kinda cover what went on for the Rust Summit and sort of the big takeaways at the end of it. So what's the current state of Rust Bitcoin? What's of the one point o? Because a lot of our projects are versioning like BDK's cutting the 1 point o. But, for Rust Bitcoin, what does it look like for cutting 1 point o? Once they track for that and then we can kinda go back to the projects for the current state of them? Sure. I'll take that. So for Rust Bitcoin, as people who use the project are, grimly aware of, the the library has been changing very rapidly. The API has been changing very rapidly over the last year or 2 with the goal of getting towards 1.0. And for 1.0, we really want a API where we're using the features of the Rust language to create an API that's quite hard to misuse.
And better than that, an API where when you try to use it, it guides you by the shape of the API and and what functions are available and what conditions are on those functions into doing the right things. So that kind of complicated protocols, like, for example, building an address from a a series of scripts and then building a tap tree, for example. There's sort of only one way as a developer. Right? You've got a pile of scripts, and there's really only one way that you can put those together with the API to get an address out. Right? And that one way should be something that I mean, ideally, you just type stuff and then you get close enough that the pilot will tell you. And if not, you leave the docs sort of thing. And the library is not there yet. This is improving, with with every iteration for sure, but there's still lots of weird crafty things where you can do wrong things. So for example, in our our bit 32 module, bit 32 is a a way of deriving secret keys and public keys for wallets.
And the way it works, you have kind of the series of 31 bit numbers, numbers that are between 0 and above 2,000,000,000. And you can construct these in Rust Bitcoin with numbers that are out of range right now. And the API will let you do that. It's not going to tell you that you've done anything wrong. It will just do unexpected and nonstandard things when you do this. So there's stuff like that that we want to clean up. But as a consequence of this and a consequence of Rust itself having a gazillion crazy features for API designers, all of which have sharp edges and surprising limitations. You don't notice till months into trying to use them.
There there have been big changes to the library and and lots of simultaneously very fast changes and that we're changing a lot of stuff, but also very slow and that we wind up having kind of long arguments about individual piece of the API. So every 6 to 12 months, we we do a release with all of the crazy breaking overhaul changes that we've done. This pisses off all of our users who immediately have to rewrite their code. They'll find that there's some functionality they were depending on that we forgot to maintain when we were tightening up the API. And, and then they come to complain at us, and we're like, oh, well, we're in the middle of doing another round of that. But, yeah, we'll double back and, like, fix your things when we get around to it. We promise.
So the first day of the summit was Tobin and I going up there and and kinda talking about what we're planning to do to make everyone's lives smoother for the next few months. And we prepared maybe 0 minutes of material on this, and, nonetheless, we have 4 hours of of people yelling at us saying, like, it's not this, like, please, like, surely there's some way that we can do the the minimum thing. And, and where we landed, well, we we there's maybe 2 takeaways. So one is much of the ecosystem said, you know what? We're gonna freeze on Rust Bitcoin 0.32, and we're not gonna follow your updates for a little while until it stabilizes a bit. But the other thing is that kind of our first order of business in Rust Bitcoin is that we're going to pull the core components of the library, the structures that represent transactions and blocks and then the basic building blocks. We're gonna pull those into its own library called Bitcoin Primitives because that work, we pretty much nailed down what those look like. Maybe not every single feature, but definitely the core functionality.
We'll pull that out. We'll stabilize that. That will be a thing that never changes. And that will reduce a lot of the breakage because at least you've got that core library at the center and your dependence on Rust Bitcoin and its crazy changes are limited to maybe the edges of your library or or things that are easier for you to update.
[00:22:50] Unknown:
Yeah. I don't know much about that. Oh, more about what we did. Yeah. I don't know much about that. I mean, Angie just, like, hand handed Tobin the mic, and Tobin felt compelled to say something.
[00:23:00] Unknown:
Yeah. This is So, Cody, where next? Yeah. So then, the next day, we had BDK, and, so building off of the discussions of where we're gonna go with Rust Bitcoin, BDK is cutting the one point out. So maybe Steve, do you wanna get an update so I could I could pick up from there? So, yeah, we we kinda split the 4 days as from the bottom up. So Rust Bitcoin, BDK, LDK, the, Fedimint, and then what I missed. Yeah. And then all of the anything. Anything else. Like, all the projects. We have a lot of people. So in in addition to these space projects, we have a lot of projects built on top of these projects. But back to BDK, so we spent our day kind of like our our big milestone was hitting a 1.0. And for us, 1.0 actually, I should say 1.0 beta. We are probably a year late on this, to be totally honest, but, you know, designing you know, as Cassandra mentioned, designing good hard to abuse APIs is very hard.
And I think one of our contributions to the Rust Bitcoin team is that we just brought in a bunch of users that wanted to not learn the intricacies and just get sort of a nice simple wallet API. So doing on chain, you know, getting your balance, getting your, you know, making a transaction, doing RBFs, supporting, of course, descriptors with the full manuscript support, Taproot, all that good stuff. Just basically pulling all those components and bringing them together and making a nice easy to use API, but making a nice easy to use API is easier said than done. We also as part of this, like the, so Lloyd and Evan were sort of the 2 chief architect guys who had this great idea that, hey, What BDK started as was a simple single purpose make up single user library.
Hey. Maybe we could, like, break out some of these pieces and and, like, separate out a core chain tracking crate that did all of the the logic of managing when there's reorgs and things like that. And then just kinda the wallet piece is just sort of a layer on top of that. So, so the scope of what we originally intended for 1.0 sort of grew a bit with that entire rearchitecting. The initial actually, the initial, I think, impetus was just we wanted to be able to do asynchronous stuff. Like, we wanted to be able to sync the blockchain data to the wallet while the sync without blocking access to the wallet, like, say, getting a balance or making a transaction. That was kind of the initial, the initial threat we started pulling on that that ended up becoming, like, a year and a half long design and implementation project. Talk about it in February.
[00:25:30] Unknown:
Use the mic, Alexas.
[00:25:33] Unknown:
I think we thought about vk 1.0 in February of last year. Yeah.
[00:25:37] Unknown:
Yeah. Yes. I think we did.
[00:25:39] Unknown:
I think and I think I so much value. Yeah. I even had a t shirt made that said vdk one point o world tour, and it says 2023 on it.
[00:25:47] Unknown:
Here we are in, what is this? In August
[00:25:49] Unknown:
2024,
[00:25:50] Unknown:
but, hey. Yeah. I'm sorry for the reason. No. No. That's a good point. Yeah. The yeah. So, you know, we we one of the you know, our goals for this one point o, we know it's not perfect. Like, you're never gonna get a perfect API, but it it it meets the initial goals. It sets us up with a design that I think will take us forward into making future improvements. And it it gives, hopefully, it gives our users a stable thing to build their applications on for at least, you know, maybe the same of next year. And then whenever, you know, when when Rust Bitcoin is ready with something, you know, whatever their next big upgrade is. We already, like, have a big backlog of things we wanna get into, say, a 2 point o. So be prepared. But we will, you know, we're our focus right now with this beta is, testing much more tutorial style documentation as we do get a lot of new folks that are just building their first wallet potentially.
Yeah. So, you know, documentation, testing, and, yeah, just getting it ready to
[00:26:51] Unknown:
you know, for people to build and support products on that will be living out in the wild. I mean, I think a big mainstream success that we had announced this week was Proton. Yes. Thank you. ProtonMail created Proton Wallet on top of BTK. We call ProtonMail
[00:27:05] Unknown:
and are actually really, you know, true Bitcoiners, and they wanted to do an on chain self custodial. Of course, there's always trade offs, but they're trying to do sort of a mass market wallet. And they they have a great team to work with and they're very, you know they basically want all the privacy stuff. So whatever we can give them privacy oriented, they want it. They want us to put it in there. So that's, you know, part of this one point, it was also to help give them a stable API to break up, you know, to to build on and not break things while they're, you know, trying to, you know, they're they're gonna be supporting a huge audience of ProtonMail users that will soon have access. It's currently in beta, so you need an invite code in ProtonMail. But, you know, once they get out of beta, everyone's gonna have access to a Bitcoin wallet through our ProtonMail accounts, and they're gonna have a mobile app.
[00:27:51] Unknown:
It seems like the biggest thing they're missing, maybe I'm jumping the gun a little bit, though, is coin selection, and that is something that I think is missing in this ecosystem. I thought it was gonna say page 1. So b d k so b d k is so b d k completely supports coin selection. It's just,
[00:28:04] Unknown:
so much has gotta, like, implement it. It's more of a I mean, the problem is is Coin control. Coin control. So Coin control, just as a quick anecdote, we spun that up internally at AnchorWatch, and it was like, what? I'm I'm sitting next to Matthias here who could. It was like a day. Just really quick, like, one quick endpoint, and we have full coin control in our wallet natively. It was a very quick stab of a finger. The problem is, though, and I think they're gonna add it relatively soon,
[00:28:27] Unknown:
like, in advanced options. The problem is is fundamentally, coin control has a UX problem, which is, like, how do you conceptualize to I mean, this is like they're they're positioning it as my first Bitcoin wallet. Right? It's it's your first touch point into Bitcoin. They have I don't know how many users. They have a lot of a lot of users, and they've never used Bitcoin before. And how do you explain to them how to use coin selection? And so, like, why do you you automatically say join. You have a you have a queue in the background. Automatically.
[00:29:00] Unknown:
Up in coin control when you receive a pay join or when you set 1. Yeah. They I think they're more interested at this point in things like RBF because obviously, you know, fee rates might be low now, but in the future, they won't. Well, mempool dot space solve that. You just use the mempool transaction. Or maybe maybe, ShopBase Repair, and I think that might be higher on the purchase moment, but Andrew needs some Yeah. Well, the way I personally do point control. Right? So I have my my points are all controlled by a series of handwritten wallets. And I learned that I just don't ever need to spend more than 1 UTXO at once. And I don't ever need change. Right? So whenever I wanna move coins to a hot wallet, to my phone, or to an exchange or whatever, I just pick a UTXO, and I round down. I just, like, drop the last few digits, and that will be my fee. And I kinda wanna
[00:29:46] Unknown:
people solutions where you just throw away the clients. The question is why are you spending the clients? Yeah.
[00:29:53] Unknown:
I don't spend it. I I write fully collateralized options.
[00:29:58] Unknown:
I'm gonna go on a limb and say that you're not the average proton male user.
[00:30:03] Unknown:
Okay. But I would hope they support me. I I should mention we also have Big Key, which actually you know, Big came out earlier this year was it late last year as a mass market. Sure, BDK based, you know, meant for first users with, multi sig and hardware support for, you know, protecting the keys. So another example again of something Also, it doesn't have coin selection. Also, it does not have coin selection. Exactly. Has tight integration with exchange, but, you know, there's that's another, like, ecosystem thing built on Rust Bitcoin, EDK, Rust Mini Script, the libraries.
Yes. One of the one of the big ones I think that came out with EDK Day is it's very, very hard to make these primitives that work for a wide array of users. And so there's a lot of work that's being done at making it simpler, But there's, like, for example, like, we had a long discussion with BDK about how we could use BDK within the Fedimint wallet. Right? But it's like the primitive is a little bit different that we need versus what they need, and while we could probably roll something, the thing that they're designing for is something that's kind of most widely used, and they already got a good set of users for it. So and, I think another interesting thing that came out from the BDK day was that there's a lot of new users, and the first thing that they do is maybe it's because it's, like, SEO optimized or something, but the first place they land when they start working on Bitcoin development is in Bitcoin DevKit. Right? So either they'll land in your Discord or any of your other stuff. And then so a lot of the documentation that, BDK said that they would be working on is stuff where integrating it in with other projects. Right? And for our team, like, we we have folks that are focused on on language bindings who are also helping with the documentation.
That's the other reason, like, just for our sanity to have a stable API. When you're writing tutorial documentation, you it's very easy to keep the API documentation in sync, but if you're writing, like, a nice, easy beginner tutorial, you don't want the and we've had this problem, like, we're guilty of this where our tutorial no longer matches our API or any of our code because it's, you know, 6 months out of date. So keeping, you know, keeping the API stable for a year or so will help us have documentation that's valid for a year or so and that we can gracefully upgrade.
[00:32:13] Unknown:
So we have this problem for when we're discussing users using the software, but we have it all the way down. So we often well, first, when I came into Bitcoin, I thought, oh, this is not really that complicated. You know, we'll get on top of this in a few months. And then it turns out there's a few edge cases that you don't get until you've read the specific bit by the 3rd time. And so one thing we try to do in Rust Bitcoin is make it so that, a developer can come in and not spend 2 weeks reading the bit, pouring over the bit, getting frustrated and angry, but I can just come to the API and go, alright. I just wanna do more or less the basic thing. That'll do it correctly. But then we have someone else who has spent 3 days reading the BIP who's like, you idiots. That's not exactly correct. Mhmm. They're like, here it is. There's another function called underscore dangerous or something like that that you can get the exact behavior that we all think is wrong, but you can still do it. So we try to support people to do anything they want but make it obvious that you probably don't wanna do this unless you're really, really not doing. And that bubbles all the way up to the users. Right? Some of these things are hard. I just wanted to jump on that too that, you know, part of this breaking up our our crate our our Rust crates a bit is this, you know, we have sort of an opinionated wallet crate and then a chain crate which has all the little knobs and all the all the the lower level detail stuff. Now like for instance, for Fetti,
[00:33:31] Unknown:
we'll we'll most likely not use the wallet API because what they're doing is is not a standard kinda wallet, but we would use the chain crate. They just wanna, like, you know, use all the primitive stuff. So we now have that as an option that we didn't have before where it was no single purpose before. Jose, do you have something? Another takeaway, from the Rust Summit is that, we do have good API docs, but we need to have kind of like a cookbook.
[00:33:55] Unknown:
So something that newcomers can can see and and check how to do, like, common basic stuff on top of, Rust Bitcoin and BTK. And this is something that we are pouring some efforts on. We do have our West Bitcoin cookbook, and we have also the book of b k. And we were thinking of integrating this kind of, like, top level user friendly, docs and tutorials into a single one so that we can also link stuff and share, like, efforts between risk Bitcoin, BDK, Fedimint,
[00:34:25] Unknown:
LDK, and so on. So this is this is something that we are working on as well. I wanted to plug again also the language findings which falls into this, which is, you know, if you're a new person, you may not wanna learn Rust and you don't have to. We this is something that came up also in the Rust Bitcoin section was we know I think we have sort of a general agreement that, you know, if somebody wants to make you know, we'll we'll create a project, to support the Rust Bitcoin and then we also have for the you know, for people who don't wanna use the Vk wallet stuff, we'll have some just, like, primitive stuff from Rust Bitcoin available in other languages. That's like Swift, Kotlin, the biggie Swift Kotlin and Python are that kind of a lot of people use those, especially on mobile. And for BDK, we, you know, have extensive support for those languages as well as, like, examples how to actually build it for these mobile apps because, you know, we want more mobile wallets. Yeah. Well, maybe a a success story in Rust Bitcoin regarding trying to figure out how to support everything that's written in a bit, worth making things accessible and and understandable and also documenting it is what we did with the lock times in Rust Bitcoin.
The lock time story in Bitcoin is is pretty complicated. Right? There there are relative lock times that are absolute lock a lock time. They're lock times specified in terms of number of blocks, ones that are specified in terms of of seconds. They're kinda obvious edge cases there. They're non obvious edge cases. What does it mean to have a lock in seconds? But what it means is if you look at the blockchain and you look at the most recent 7 blocks and you take the median of those 7 blocks 11. It's 11. Sorry. Rob's telling me it's 11, not 7. And then there are multiple ways that these lock times are encoded. Right? So for every input, an absolute lock time is the code of personnel's action, but a relative lock time is encoded per input, like, about the age of the individual inputs.
And then another question about what happens. You have multiple inputs that have different kinds of lock times or or, you know, how do they mix? If multiple participants are trying to build this stuff, the lock handler encoded in a field of the transaction relative lock times called the sequence number. Well, there's a limited range of sequence numbers that actually represent lock times, conceptually. And then there's kind of a separate range of valid values that represent lock times when they're used in the check sequence verify or check lock time verify opcodes. And so for a long time in Rust Bitcoin, we were basically just using 32 bit integers for representing lock time, telling users that you gotta make sure that you're within the rules if you wanna use this. And some people, maybe it was kicked. I don't remember who exactly showed up and said we gotta make the proper API with proper types, and you can't construct the types unless you're you're putting the semantics of the bit. And I basically argued nobody can possibly know the rules for lockdowns. Like, it's it's not possible for you guys to do what you're doing. So you don't have your fun draft PRs and so on, but I'm not even gonna repeat what you're writing because it can't be done. And users don't want to use lock time. It should just stay within, like, really safe boundary, of of, you know, when you know, don't mix a lot of times and don't Mhmm. Use high.
Don't go close to the limits and so on. And amazingly, the the people who thought they could do it actually did succeed. And today, we have, a series of lock time types in Rust Bitcoin. And when I want to use lock times in Bitcoin, I go to the Rust Bitcoin docs and make sure that I can construct what I'm doing. I mean, I check that, the other the values that I want to use. I can actually use the Rust Bitcoin API to do what I'm trying to do. If I'm unsure what some of the rules are, typically, I'll check the Rust Bitcoin source code rather than trying to check the BIP and trying to check the reference code in Bitcoin Core. And if I even if I need to dig into the the BIP stuff, the API documentation for Rust Bitcoin have citations to the BIP for every rule that we have and everything that we do.
And that I think was actually a tremendous amount of work even if you don't care about Rust in making the bits themselves more accessible. So that, I mean, we went from from me saying that, like, no human could possibly understand this to now there's, you know, docs.rs slash Bitcoin, and you can you can look up the answer to whatever your question is. I'd say Rust Bitcoin also has very good examples. Like, they're extensively examples as well as documented. That's that's a goal we have for BDK is to have as many good concise examples for a lot of these things. Because myself, the first thing I'll look for is an example before I read the docs. And so a lot of people do that.
[00:38:52] Unknown:
I'm getting a warm fuzzy feeling right now because while this is a shared effort, I've put a lot of effort into that lockdown. So the downside is I put a comment at the top, and it literally says, if you haven't spent 3 days reading a bit, you probably don't wanna use all these functions. The downside that I didn't notice is I should have written, if you haven't spent, like, 3 weeks reading the docs, don't patch this module. Because every time I have to review it, it's so hard that I have to go back and read the PIP again. So just don't touch it anymore unless you wanna spend a long time going in. I'm glad I'm not the only one.
[00:39:24] Unknown:
I, I just wanna say, like, just to, like, Andrew's note, I think one of the success stories of Rust is being able to model a the problem space really well and sort of codify it into the Rust type system and just make it really concrete, you know, what's actually going on, you know, in in inside of our nodes, inside of our wallets. And, yeah, actually make it in a way, that that you can sort of write software with it really productively and actually get up and running, and put something out there for people to use and feel relatively good about it. You know? I think that's one of the big big success stories.
[00:40:07] Unknown:
Yeah. So something else that came up I noticed between a lot of the projects is that we've kind of used distinctions between, like, specification driven ones and then, like, the reference implementations. Right? And so I know, like, for LDK, LDK generally is, like, aligns with the lightning spec, and then there's LDK node, which is a reference implementation for it. And for the reference implement like, for Fedimint, like, there is no specification for it. There is the Rust implementation, and that's it. And for a lot of the Rust Rust reference implementations that we do, because we can export them with language bindings to other, to other languages as well. Right? Suddenly, you, like you know that when you get it, this is a correct implementation of what should be happening, right, either in the lightning spec or within the big one spec.
We've got Matt and Tino for from LDK guys. You guys wanna talk about the differences between, like, LDK node and LDK, maybe? Sure.
[00:41:00] Unknown:
So LDK is great. LDK tries to implement the specs all correctly and gives a lot of customizability to users. And, Yeah. Doing that is pretty powerful. It is, though, pretty big, and it's pretty it has different modules that need to be integrated to build a full lightning node. Which is great because they can be switched out. You can integrate lightning in your already existing wallet environment and stuff like that. But it's, not entirely trivial to get started. So the idea of the LDK Node project is to make it much, much easier to get started with a simple note library, essentially, with a smaller opinionated API surface that is much more controllable and gives more sane defaults that LDK already does.
Yeah. That's the core idea basically of LDK node to be a bit more, let's say, opinionated, a bit more conservative, but also a bit more fail safe for, users, essentially. And, LDK node comes with an integrated BDK wallet, so we are basically, not only Rust Bitcoin users, but also BDK users ourselves.
[00:42:18] Unknown:
Yeah. And, I mean, just Ilya said most of the work. He's not gonna brag about it, but I think the feedback we've had from people has been really great. It really is just one library you take as a dependency. It's in Rust, but supports many other languages through their great language findings, that exist in the Rust ecosystem. You know, you add this dependency to your app or your program or whatever it is and you call, like, 3 you call one function with a few configuration options, and you have a lightning wallet, bitcoin on chain wallet.
[00:42:51] Unknown:
You get the whole thing there ready to go.
[00:42:54] Unknown:
So it it really the the feedback we've gotten from people is that it it really just works super easy. You don't have to think about it. You get a you get a whole wallet. You get lightning support.
[00:43:03] Unknown:
Yep. And it's awesome. For, Feddy Mint, so, for a follow on to 0 dot 4 so 0 dot 4 dot 1, we have LDK gateway integration for that, and that was, like, extremely straightforward for just adding the LDK node initially. But then we have, like, this Fedimint specific stuff. And so, one of the another thing that came out of this was trying to figure out where do we have to fork it, where do we need to what can we use that we're not using yet. But just generally speaking, it's like a very effective note in a box that you just kinda drop there, and then you can add what you need on top of it. Matt, I don't think, so we covered, like, the origins for Rust Bitcoin and, BK. You wanna cover the origins for,
[00:43:41] Unknown:
LDK and Rust Lightning? Yeah. I mean, it was basically the same as as Rust Bitcoin. Right? I wanted to learn Rust. I wanted to learn Lightning, and so I started writing a lightning note in Rust, and it was just a toy. And then, then I kind of looked back and I spent a few months on it and was like, alright. Well, there's like a lightning note thing here that I wrote. What is this just a toy that I should throw away now now that I've learned a little bit about these things? Or, you know, should I find a niche in the market of lighting nodes that actually where this can add real value? And we obviously kept working on it. We decided this was great when we founded Spiral. We decided that actually this is something that the whole team should work on and dedicate a lot of resources to. And I think it's now probably by far the lightning node with the most engineering resources on it, at least working on the lightning part.
But so yeah. I mean, we, you know, we looked at it. We said, what exists in the lightning implementation market and what doesn't exist? And what exists and existed at the time and still exists today is lightning nodes, full binaries that you take and run on your server, that route payments, that do all this stuff and, like, you're an IP and RPC interface, but not something you can take and embed. So there's, Phoenix has their library that they use to build their app, and you can theoretically take that and embed it, but that's not really something they they primarily support. That's not their goal with the project. LND is one big honk and go binary.
In theory, you can run it in the mobile app, but it's pretty honking. It's takes a lot of resources. It it's a little it's not designed for it. Core Lightning is a multi daemon architecture, and that's not even you you can't get that thrown on the mobile. Good luck. But LDK, not only is it an embedded library, it's designed to run on any environment, whether it's mobile or server, but also Wasm. So, you know, we do all kinds of crazy stuff. Like, we stub out the TCP library so that it's actually an interface, And this lets people like Mutiny go and take lek, embed it in their WASM binary embed a WASM binary of it in the browser.
And when they wanna make a raw TCP connection out to a Lightning node, they can do that. They just have to stub it out and use a proxy that that proxies out your WebSockets. So we we stub out everything. Like Elias mentioned, this does make our API pretty big. We everything, every system call, every anything is configurable by the user, and that's just a lot of work to have to figure all that stuff. So that's why lpk node exists. But for those who want it, wanna do something super custom, wanna embed lightning in some really weird environment, that's why it exists and it works great for them. And it's the only game in town still.
[00:46:30] Unknown:
Very cool. Yeah. I think for now, one of the talk about? Why Cody's not wearing shoes. I took them off. Get it go. Make yourself a note. Is there Yeah. Is there more does Scott do more to this? No. They're right here. Yeah. Maybe let's go shoes. Yeah. Maybe let's go around again and for, what the contributor set looks like right now for each of the different projects. Right? Like, sort of, I think for people getting started within Rust Bitcoin and, like like we said, like, they kinda land at BDK, but, like, more on the dev side for contributors, right, of, like, what does it look like right now, like, for maintainers versus kind of, infrequent contributors and then, like, places where maybe you're missing, like, dev talent that you'd, like, wanna have? And honestly, on on Rust Bitcoin, because as I mentioned, we're changing the API so quickly and and doing so many crazy things. It's a little bit possible to new contributors. I don't mean that, like, we're mean. I try try not to be, you know, sometimes we're not You're not in you're not intentionally hostile? Yeah. Yeah. We're not we're not intentionally personally hostile with the environment is, like, when you show up and you're trying to do stuff and you're like, oh, well, for one thing, there's a lot of issues that look like they're straightforward, like, newbie issues where one of us just kinda, like, threw up an issue to remember something like, oh, you know, we should restrict the range of bit 32 numbers, right, kinda thing. And a new contributor shows up. They're like, oh, you know, create a a type wrapping a number, restrict the range kinda thing. Here we go. And then they do this and they get 200 plus comments on their pull request Mhmm. Saying that the way that they're modeling, derivation paths doesn't allow, like, infallible runs when you're trying to do a public derivation of a a path that only has public keys. And how we want to have the underlying representations being compatible so that we can use unsafe code to cast between our different wrappers of u 32 and how we have this mental model of how people should use the thing, which matches the bit to be clear and then match an actual usage. But, you know, we didn't write it down because, I mean, it should be obvious in the API. And so it will be obvious as soon as we get to it. And, anyway, instead of I mean, maybe we should be hostile. Maybe we should see, like, shoe instead of, like, offering individual critiques of these kind of things.
But what do we need on Rust Bitcoin? Right? But, I mean, what we need I would say we're actually not hurting for developer talent right now. And and that's a dangerous thing to say because we will be. Right? Tobin and I will get old, as we'll we'll kick, and then we're going to regret, you know, hoarding our stash of of Rust Bitcoin APIs. But what we can use obviously is more review. We can always use more review. We can use documentation and examples. Probably the the biggest thing is people who are using our code if they can show up and and discuss what they're doing.
And if they a lot of people try to use our code base and they they find that something's difficult and they'll kinda find a way to work around it. And at best, this represents a gap in our documentation, right, where they they really struggle because we didn't explain something. But at worst, there is actually gaps in our API. We didn't know that people were using it in a certain way. So what would be awesome is if the people using our crate could show up and say, like, this was a pain point for me, and I had to do this crazy hack. And, like, I did this, but it doesn't feel right. Or, like, I did this. And, like, I think you deliberately made this hard because you guys are assholes. And, like, we would appreciate that kind of feedback because most of the time, I think we're just oblivious.
[00:50:03] Unknown:
Yeah. One thing I would say is all open source projects, all free software projects always say this. We need more reviewers. And then when you come to a new project, you're like, how do I review this? I don't know all this stuff you're talking about. But you can ask well placed questions, and you can ask them by just looking at the diff. And then you bring up the code yourself and you look around it, and you're like, I can't see any reason why you'll do that. And so you can just ask the question, why did you use that type? Why didn't you use the type? Why have you put that function name sort of thing? And if the person doing the patch can't say, oh, it's because of x y z, then maybe they overlooked it. So, like, when we're totally infallible, we have to make mistakes all the time, some of us more than others.
And that that's okay. You know? And so a well placed question is really useful. So, yeah, anyone can come and review, look at the code, learn more yourself, and ask good questions, and, it's really useful.
[00:50:57] Unknown:
I I would just sort of second this for BDK. This is probably true for any open source project, especially, you know, Bitcoin, but probably any open source project. Like, start as a reviewer, ideally. We have a new full time contributor who came in, valued MAML, and he just started reviewing. And he just did really great reviews. Like, he just really looked at the code, thought about it hard, and, you know, just by doing that, became, you know, a full time maintainer on the project. The other thing is, of course, documentation since we like, if you wanna come and change your API, that's great. Love to have your contributions, but don't expect it to get merged for another 6 months or a year. So just have expectations with that. The stuff you wanna get stuff involved right away, it's gonna be documentation, examples, potentially side protocols.
You know, we're, you know, we provide a basic core wallet, but we need things like, you know, protocols for chain syncing. We have a a contributor here in the room, Rustation Rob, who, you know, built a compact block filter implementation for BDK and is integrating that, those kind of contributions. The nice thing about those is you can go You don't really need our review. You can go ahead and just write it and then help integrate it. We'll help you integrate it and, you know, get it into our docs. But yeah. Like, so immediate contributions, docs, side, you know, side add ons, you know, PayJoint's another example that, you know, and the Casu stuff. We have Casu, Rust contributor here. You know, those kind of projects are great because you don't really need our permission or or review. It you know, we'd we'd certainly love to help you, but, you know, for the core library, it's mainly gonna be documentations and testing at this point.
But yeah. So I think that's, you know, that's where we're at right now with BDK.
[00:52:32] Unknown:
Yeah. I mean, in LDK, we also all also really welcome any new contributors, generally. I would second, like, starting with review and just starting basically asking questions is is often the right way because, of course, new contributors also costs basically review time, especially in the beginning. And, so but most fresh contributors, I'm pretty aware of that. So it it's just great if a new contributor start off by reviewing and just, yeah, basically helping out with review. But in general, it's really great to to see that in LDK, we see a constant stream of new contributors, to be honest. And over time, a few really stick around and and make valuable contributions over the years, which is just amazing to see. So
[00:53:31] Unknown:
Is it worth mentioning at a high level, this thing we're doing, it's a meritocracy. So anyone can show up. And if you work hard, you try hard, you think about shit, you're not a total retard, then you can get there. And then we have things like this impression. Probably, you can say stuff like that, and people are gonna go, I'm like, god. That guy is like like, when they're looking at your face, they know you're just joking. It's a it's a proof of work thing. Yeah. Yep. Proof of work. But yeah. And also this is like when you're looking at someone, you get more information. Yeah. So we do these things so that when we're online, we can write messages that don't mean stuff. So if you see someone call someone spastic, then you don't have to be upset because you're like, oh, those guys actually ate together, and they drank together, and they know each other. And so that's that's the one we're doing this thing. I,
[00:54:10] Unknown:
we're, like, nearing the point where COVID and humidity stops listening to this little dispatch. So I just wanted to to be clear to the freaks, before some of you drop off, maybe. I mean, you should stick with us. I we have literally a room full of some of the most prolific Bitcoin developers in the world. It's kind of ridiculous and amazing. Rod, me, Harry, Josh from Bitcoin Park, we made the space available, but Russ Bitcoin Summit was possible because of of Tobin and Steve, Steve Myers. They they made all this happen. So you shout out to them, and then I'll just pass it back to Cody who's the host of today's conversation.
I think also, you know, should we go around the horn and and do Bitcoin price predictions? Like, I think that would be more. I get their free schedule. Predictions for a technical
[00:55:01] Unknown:
So much? I think we already said 100,000,000.
[00:55:04] Unknown:
Yeah. 200,000,000
[00:55:05] Unknown:
might count predictions. Anybody think that 2.9 just bearish?
[00:55:09] Unknown:
Yes. That's too easy. I go all the hands around. Without an absolute numbers. Yeah.
[00:55:14] Unknown:
We could do Oh, like, what's speak to you around. You're on.
[00:55:17] Unknown:
Yeah. Oh, that got spicy. Yeah.
[00:55:21] Unknown:
If I if I have one more thing just from the sentiment side, and this is also something You're the host. Summit that, I saw a lot is that I think where everyone here got a lot of good feedback from knowledgeable people who hadn't used their project before, like, documenting their experience with first coming to it. Right? So it's like when you first like, a lot of people we see this a lot with Fannie Mae. It's it's hard to get the feedback for it, but one of the most valuable things you can do as a new contributor is documenting your experience of first coming to the project and trying to set it up, trying to do it yourself. Because normally people, if they get stuck, then they just let go away. Right? But if that doesn't end up in a GitHub issue, if that doesn't end up in something being told to the Rust Bitcoin guys, the BDK guys, the Fedmek guys, then it's not something we can fix. And so I think everybody here at the Rust Summit had a lot of good experiences with people trying out their project from the other projects because they have they they don't know how specifically how to use LDK, for example, but they're relatively knowledgeable. So relatively knowledgeable Rust programmer runs into an issue, that's something that needs to get documented. And so anybody coming to the project who can open an issue like that, that's extremely valuable.
But, yeah, maybe oh, yeah. Jose?
[00:56:29] Unknown:
Before we lose folks, I just want to say how important it is to support open source. All of this is possible because we have, like, very big, and bright ideas. We have open sets. We have Grain. We could have a spiral who will kind of, like, help us organize the summit and also have a Right. Yeah. We also have Casa Michonne at Brazil who also supports open open source debts to also work on Buzz Bitcoin and related stuff. Right platform? Yes. Right platform as well. HRF. HRF. I might be missing someone. I'm here from Chaincode. Chaincode. Yes. Chaincode Labs as well.
K.
[00:57:09] Unknown:
Yes. Very important. Fund your open source distributors, and everybody should donate to Open Sans. Yeah. Give us There we go. Open sans.org. Is Riot Platform Riot Mining?
[00:57:18] Unknown:
Yeah. It was Riot Blockchain then. I thought they became Riot Platform. Okay. Are they Riot Mining now? I don't know. They're awesome. I just I don't know what the name is. Them Riot. Yeah. Know what else I'm talking about. Okay. Well, then you said right platform. I know I do what you're talking about, so I had to double check there. You wanna find out? I would just I would just add, yeah, we can go to Spicy. Foundry, because you mentioned Riot and Riot's Mount Mining, and Foundry is, you know, the KYC suit American based pool, who's who's been doing great work. This is supposed to be a compliment of them.
They recently launched their own open source, funding mechanism within their GUI. So any miner that uses Foundry can have a drop down, and I know OpenSats is supported. I believe HRF and Brinker supported. I think they're gonna add a few others. But that's just really cool. I think, you know, as a non dev myself, lowering the friction point to supporting open source contributors is incredibly important. I think a lot of people wanna support, but but it it's too difficult for them or they get overwhelmed, and then they get, like, decision paralysis, and then they go on and live their life and and don't make it happen. So the more ways we can make it, we can reduce that friction, and I think Foundry did a really good job with it. We worked with them pretty heavily in terms of it's literally just a drop down, and they they you can pick how much of your hash just like it's donated, which is awesome.
Cool. So, Opcat.
[00:58:44] Unknown:
Andrew, you wanna kick it off? Sure. Alright. So for those who don't know, of course, Opcat the concatenation off code for Bitcoin script allows you to combine 2 elements on the stack. That's all that it does. So if it's a pretty low level thing, I don't think it would really affect anybody. There would be any controversy about it. But, you know, it's a missing functionality. I think you should put it back in the Bitcoin. And, yeah, it's a pretty mechanical thing, I'd say. Right? It's just like routine maintenance of the Bitcoin protocol to add a little bit more functionality. But I expect we should be done that in the next couple of weeks. Yeah.
[00:59:21] Unknown:
Does anyone have a different opinion?
[00:59:24] Unknown:
Well, I think a big takeaway from the, Bitcoin plus plus that was in Austin about script and op heads was that the order of these things is, currently a sufficient argument against basically anything that you wanna add to Bitcoin is that it has potentially unforeseen consequences. Right. Right? And so one of the big announcements that Rusty Russell did at Bitcoin Pixel Plus was announcing his great script restoration project, which is a mechanism of basically writing the script interpreter in a way where you can define the effect of adding a new opcode into it. And so, for example, for OPCAT, if on the engineering side, you can prove before you activate it that this is not going to increase the worst case validation time for a block, right, then that gets rid of a whole class of arguments, which I think is sufficient for anybody now that Bitcoin is so big to halt any new opcode activation or any sort of functionality upgrade up, upgrade, just generally speaking. Right? So, like, on the in the Twitter sphere, is the fact that there are unanswered questions about this opcode, I think that's sufficient for them to say, no. I don't wanna support it. Right? Yeah. I mean, the concern is, like, edge cases that people
[01:00:45] Unknown:
that, like, Andrew can't foresee.
[01:00:47] Unknown:
Exactly. And the, the goal of Rusty's Great Script Restoration Project is what if we can define beforehand what this is going to look like and prove that there's not gonna be this edge case when it comes to increasing specifically, when it comes to increasing validation time of a block. Right. From a technical perspective, Cody's totally right. Right. There are some ways that we could extend Bitcoin that actually would break the validation model and or would make it harder to reason about the validation model. You can imagine adding opcodes that did, like, random disk access or opcodes that added extra metadata to your TXOs and meant that when you were checking whether coins have been spent or not, there's also a weird thing that you're doing.
One of the the biggest ironies of off cap, right, is that it very easy to reason about in terms of node cost. Right? It doesn't introduce any new ways to introspect transactions. It doesn't introduce any new ways to do transactions. All it does is take 2 elements in a stack while you're running a script and put them together. But if you go to a higher layer, it turns out that this allows you to get access to transaction data on the stack. And you do this by using the checksig opcode, which is an opcode that reads the whole transaction and and checks that you've signed all of it. Using offcat, you can kinda like in conjunction with checks that you can kinda pull the transaction data out of that. And as a result, now you can do things like covenants, and now you can do things like colored coins directly on chain. And you maybe could do like DEXs or some sort of multi asset thing. And you've gotta think about NUV, and you've gotta think about mining incentives. And the whole thing quickly becomes kind of intractable in in much of the ways Cody was was worried about from a techno perspective, but but here we're on a much higher layer trying to reason about economic incentives in a world where people are doing arbitrary stress. Yeah. Like, you know, because it's a line that
[01:02:44] Unknown:
whatever. Actually, you talk. Yeah. I was about to say the same thing. So I think the problem with engineers. And and my personal PMD on the pop cut is I don't care. Like, I personally don't have any use for it. My the thing I'm working on right now, I'm gonna use for it. So I personally don't care whether it's or not. So I'm not speaking against it because I I I don't like it or something. I mean, feel free to speak against it if you like. Well, I mean, yeah, what I wanna say is pretty much what Andrew said. So engineers kinda get stuck into this. I can prove there's no additional cost to that. That's okay. That's fine. But then there's, potentially unintended nuances that happen because of,
[01:03:23] Unknown:
new use case we should be able to. So Yeah. Yeah. Okay. So I've heard, very, very smart people in this room at other times, you know, not to quote people out of context, but, say things along the lines of, opcat may introduce non trivial NVMe v vectors. But, I've never I never understand what people mean by that. It seems like nobody's able to specifically talk about the MVP vectors. So I get it.
[01:03:46] Unknown:
I was having lunch, but we were listening to the the live stream in the other room. So
[01:03:52] Unknown:
You're gonna be back.
[01:03:54] Unknown:
So I didn't finish my lunch. I'm a little annoyed
[01:03:56] Unknown:
Thank you for your sacrifice. Yeah.
[01:04:00] Unknown:
I I think so unlike every other self work we've ever done, covenants might materially change the kind of high level things you can do with Bitcoin, like, Segwit enable some things with the, no malleable transaction IDs, you know, make lightning more practical, and a lot of things more practical, same with CSV. But the amount of new things you can do with those pales in comparison to covenants. I think we've seen this with a lot of discussion around, all kinds of ideas that people have for covenants both with CTV, so non recursive covenants. And now, there's more discussion about recursive covenants again. So, cat does enable fairly inefficient, but in theory, are arbitrary recursive covenants.
So, if you imagine and and I think it's important to recognize this because, you know, we can't screw Bitcoin up. We we really have introduced
[01:05:04] Unknown:
Meevil in a big way. We're we're kind of focused. Like, we really are at that point focused. Yeah. But, like, what are the I I we'll get there. Right? I just wanna set the stage a little bit. Yeah. Yeah. Well, I just just real quick, Matt. Like, MEV is minor extracted value. It's like adding different variables that miners can play with the chain to try and extract more profit, so it it fucks with everybody.
[01:05:27] Unknown:
Yeah. So, I mean, we've seen this on Ethereum. Right? So in Ethereum, creating a block template, so selecting the transactions that you wanna block is sufficiently complicated that there's 2, 3, maybe only one company that can really competitively build a block template. Right? And so there's really only 2 or 3 companies that can mine that would be able to mine Ethereum profitably, if it were proven to work still. Proof of stake, you actually have some other benefits that help here. You can stake non profitably or stake with less revenue, it's not really a big deal. If you're a miner, you're mining with less revenue than all your competition, you're gonna go out of business. You're fucked.
So, we'd end up with, you know, the same world that Ethereum has which, again, this is unrelated to their centralization, do you have proof of stake and stake centralization, Just the centralization of, just the centralization that is created through Mev and for Beeville results in there only being a few milliseconds in mine in mine. What does Maval stand for? Is it Just just Maval. Maval. Okay. Got it. That's what I thought. The actual definition of Mav is is much broader. It's super it, like, includes fucking everything. So it's kind of a useless term in practice. If you start talking to, like, a billion people, it it it's not what we're talking about. We're talking about something much more specific, and it's the centralization Got it. From Mev and those kinds of systems. So And Meville. It's a different term. Call it Meville. Sticking with it.
But, anyway, so to answer the original question, there are a number of different MEV vectors in Ethereum that create a lot of the MEV, but I think by far and away the biggest or maybe 30 or 40 percent of Mav is DEX volume. So people trading their random coins, some NFTs for, USDC usually, but often Ethereum itself. So the most immediate concern for Bitcoiners should be can and will someone build a DEX with this, and especially also AMMs, but just a gen general DEX might be problematic. And it's not clear with CAT. I think it's very unclear. Right? So there's, a lot of people who've argued, no, you can't build a DEX because the existing Colored coin protocols don't allow you to build a DEX with cat, but that's not an interesting threshold. Right? Because if you can build a DEX and especially if you can build an AMM, people will And so someone will come up with a different coin protocol.
And there are some I think I've seen at least 1 or 2 proposals for ones that are pretty bad, but in theory, you can kinda get a deck. You can get a dex, but AMM maybe. So so it's unclear. There's definitely been very little research into this. There's been, like, a few people talk about it on Twitter, and they seem to have different opinions, and it hasn't gotten very far. So that's the immediate concern. There's other forms of Mab that could pop up. Right? So there's base roll ups or things that people are clearly working to build, and if we see those become large, they will be a platform for for DEXs and AMMs, and we won't that it doesn't matter whether the script supports it directly. If you have a a base troll up, you can build that.
So there were various things that could happen with or without CAT. I think it's clear that CAT makes them much easier. So bit VM, it's not, you know, it's still very early research, bit VM, efficiency numbers, but currently the efficiency numbers look like it might end up being the case that with cat, you can practically build bit VM, without cat, you can't. So the current efficiency numbers for bit VM are, like, you know, if you wanna actually get a proof that hits the chain, you're talking about a week's worth of blocks or maybe more. So, like, maybe that isn't practical, but certainly with CAT it is. We've seen numbers that are, like, you know, a few blocks or maybe one block, and that becomes more practical. So, you know, maybe with CAT, we would see based roll ups, but without we wouldn't. It's kind of unclear right now.
And so I think there's there's a lot of ongoing research on several directions that will give us a little more clarity on what you can build with CAT, but also, I think it's, again, just really important to recognize that we, like, we screwed this specific thing up, we're screwed.
[01:09:57] Unknown:
Yeah. Yeah.
[01:10:00] Unknown:
There are 2 two points to add. One quick one. Right? Because as Matt said, there's not a lot of research into this, and I should show for the, start where a research grant related to OPCAT. If you have any ideas for how OPCAT can benefit or more importantly, confirm Bitcoin, you can look up this stuff where OPCAT research grant. They have a $1,000,000 that they're ready to give out for, for small kinda like 3 to 6 months research grants. I'm not affiliated with StarkWare, but I am sharing this research grant. So I should just kinda throw that out there. And then the other kinda more philosophical thing, right, is that the the threshold amount is describing where if we cross this line in Bitcoin and then we have all of a sudden, we can create DAX and we can create MEV.
This isn't, like, unique to op cap. We're kind of, like, beside this cliff in Bitcoin development.
[01:10:55] Unknown:
And It's also fuzzy. Like, it it is clear you can build base roll ups today. They just can't be bridged, so maybe people won't. There's cases of people doing, some of these existing centralized exchanges with, with, token, with ordinals, which could, in some cases, create Mev. You know, you also look at some of these other side chain protocols that that exist in merge mining. Like, merge mining could create substantial Meebel. There there are a lot of ways that we could create it, and it's not clear, you know, it's very fuzzy. It's not a clear line. It's not clear which things we add to Bitcoin would shift that line or not, but it is something we need to do a lot of research on before we make changes. Right. Yeah. And it is
[01:11:44] Unknown:
yeah. It is definitely a fuzzy line, and there are some ways like, there are external external incentives that you can create for Bitcoin. So for example, on the Ethereum chain, I I conveniently have the block counter in front of me. Right? I could write an Ethereum contract that will pay you out, 1 eighth for every instance of block 855-119 that you give me. And then miners, so maybe it has to be more than 1 ETH. I don't know what ETHs are worth, but, you know, maybe a 1,000,000. Alright. Well sorry. I'll give you infinity, so it's worth, you know, a Bitcoin.
And I'm gonna give you this for every instance of block 855-119. Then in theory, miner to be incentivized to stop and masking the chain and just create 855-119 over and over and over and keep extracting until all of my infinity ether are gone. Right? So without even changes to Bitcoin, I can construct things that that sure look like Meebo. But having them on Bitcoin
[01:12:43] Unknown:
no. I I don't think whether it's on Bitcoin is relevant and and totally. I mean, there's you can absolutely construct Meebel today. There are absolutely cases of Meebel that had existed where miners have been able to extract a little more value. You know, we see slipstream from Mara. You know, they accept nonstandard transactions. This is something where they had to hire a full time engineer, pay them substantial money, you know, find someone competent, and as a result, they get some very small additional revenue from doing so.
But that's a lot of work, you know. So that that is Meeval, but they invested way more money than they actually got. Right? So, like, there's the Meeval we see today is very very small. If you're a small miner, you know, you're talking about fractions of a percent. It's not gonna make or break your business. You know, your your margins are only a few percent. Right? So large fractions of a percent would make or break your business, but but, you know, fractions of a fraction of a fraction of a percent are not. And so the question is really, are we going to add things which create enough meevil where suddenly it's, like, really material, you know, where we're talking about half a percent, a percent of mining revenue change, that's gonna break Bitcoin incentives.
Right? But if we're talking about fraction of a fraction of fraction, that's okay, and we do see that today already. It's just a question of what new things are people gonna build in, and to some extent it's a question of like predicting, you know, what are people gonna build? I've seen people argue, no. No. No. Based roll people don't build based roll ups. They're not built on Ethereum because, there's financial incentives for people to build non based roll. If you can have a centralized sequencer, and then you can make money as the sequencer because you're extracting all the revenue, you're extracting all the Mav. And it's great. Like, okay. Yeah. I mean, if if people really won't build based roll ups, then maybe we're okay. Maybe we don't need to worry about that. But people can build them, and should we bet Bitcoin on the fact that people won't.
And then also, you know, we see a different community in Ethereum versus Bitcoin. Right? We see Ethereum people don't wanna build these things, but they also don't really have a lot of the same reaction to centralized parties who are extracting fees can't steal your money but are extracting fees as you often see in the Bitcoin space. And so instead, we've seen people actually building base products in Bitcoin. Yeah. We've seen, people building libraries to enable people to do that. So, you know, it's unclear. I mean, this is this is not things we've grappled with for Softworks in the past.
It's new, it's novel, and, like, it's something that the community broadly needs to discuss. It's not something that a bunch of developers in a room can decide. Like, the the Bitcoin community needs to decide, is this something we're okay with? Are these trade offs worth it? Are these risks worth it? Because we do get a lot of value. I'm excited about opcat. More so other script restoration things, other other covenants. I wanna use really awesome covenants. I wanna build all kinds of weird lightning derivative things and, like, a more awesome, more scalable lightning. I want people to have payment verticals that are somewhere between custodial and noncustodial that scale super well and let everyone have Bitcoin. But, also, I know we can't we can't take that risk if it goes the wrong way. So it's something the broad community needs to discuss.
[01:16:09] Unknown:
Yeah. These these are all great points. Right? So I guess we see on Ethereum that very bad thing that happened. There are a lot of very big differences between Ethereum and Bitcoin. Right? And I guess the one technical difference that off cat affects is whether within a Bitcoin transaction, can you introspect and constrain the transaction being spent. Right? So can you do covenants? Can you say these coins can only move to these destinations under these circumstances and so on? And, yeah, the the comment that, the Rob one h there. I'm not sure if he's related to the house and Rob h he's talking to. Yeah.
[01:16:46] Unknown:
Yeah. He's in he's in the room right now.
[01:16:50] Unknown:
I I was being strategically ambiguous. The so with with with how to calculate Well, there's this technical change. Right? Whether or not you can directly do covenants. Right? Upcap gets you that. Maybe in such an inefficient way that these covenants turn out like, the the, evil that you could create with these covenants is, is just too inefficient for you to actually make money. Maybe it turns out that transaction introspection and covenants aren't enough. Maybe we'd also need an account model or or something like that for these bad things to come to account. Maybe it's not hinted at, like, there's just,
[01:17:30] Unknown:
cultural differences. Right? We would need to have some sort of the kind of community in Bitcoin that would move the entire chain of proof of stake in order for these problems to occur. And we don't have a clear idea about when when No. I think it's the other way around. I think with the coins community, you're more likely to see these kinds of decentralized systems that create meable, whereas in Ethereum, you see centralized systems that avoid it. Because often, when when you add a centralized sequence or when you add a centralized party, you avoid the MEWL because that centralized entity just takes the MEWF and pockets it. But I think the account model thing, I've I've seen that come up a number of times, so I wanted to address that.
That's a really a red herring. Like, we've seen on Liquid, people have built AMMs. They're like, people can't build this thing because they want an account model. That's nonsense. Right? Instead, you're actually gonna create more Gmail. What you'll do so if you imagine, like, a a completely flexible script, Bitcoin scripts, you can do anything you want. You will build an AMM that just has one UTXO. Right? So, like, all of the AMM funds and logic are in that one UTXO, and then when someone interacts with the AMM, they spend it and they create a new UTXO, and now all the funds and logic are in that UTXO. And it's fine. That works great. This in fact creates a lot more evil because now miners need to write more Bitcoin Core, but I don't know if Bitcoin Core is gonna it. Write a bunch of additional custom software to handle this concept of, like, that much state and stuff in 1, UTXO where they now have to, you know, be able to rebase transactions. Right? So you'd be able to say, like, I saw this transaction in the mempool. I wanna include it, but there's this other transaction that first spent this AMM money, and now I need to, like, take that other transaction and change the input to the other one, and do do, like, transaction rebases, all kinds of complexity there.
So it I I I don't think that's relevant. In fact, I think it might very well make works. It might mean just more complexity on the side of miners, more private relay networks where small miners aren't able to get all the transaction data that big miners are.
[01:19:37] Unknown:
I'm I'm skeptical that it's more complex than the UTXO model because in the account model, you have, you know, maybe, you know, a 100 transactions and any 80 of them depending on the way that you order them. Any 80 of them you can include. Whereas in the UTXO model, you just have, like, one path. Right? You have one UTXO. So you have to have 100 transactions. No. You still have to, like, rebase them. You do have to rebase them, but rebase them is It wouldn't you're right. It's not, like, a huge difference. I think it's clearly the UTXO model is not
[01:20:05] Unknown:
less Beeville creating. There's a little more complexity. Mine is set to write a little more software. Hopefully, that software is not too complicated. And so it's gonna be okay, but they do have to do more work because they have to do this kind of rebasing logic. They have to I don't think that's more work. I don't think that's software. Well, I mean, it's just work that you didn't have to do otherwise.
[01:20:24] Unknown:
Maybe less a solution space, but I think I think it's less of a of a solution space because you do have those dependencies in the UTXO model,
[01:20:33] Unknown:
but it's probably the same amount of work. Yeah. It's just that you you remove the dependencies. Right? Like, you you create no dependencies because you have these covenants rather than actual dependencies. Just the miners have to do the work to rewrite the Well, that's the actual inputs. There's never no dependencies. Right? In a rich statefulness model where every transaction is manipulating a global Same kind of dependencies, I would say. In
[01:20:57] Unknown:
no. In in Ethereum, every transaction depends on every other transaction in principle because they're all manipulating the same global store. That's that's a point. Yeah. I I mean, specifically for just if you're just interacting with the AMM contract,
[01:21:10] Unknown:
the total dependencies and the total complexity there is is the same. It's just you have to actually rewrite Bitcoin transactions to make it make it work that way. Yeah. A a couple clarifying questions maybe. So,
[01:21:21] Unknown:
like, rough consensus, generally speaking, is that no legitimate technical question goes unanswered before the activation of it. So, like, a legitimate technical concern there. Based on the way Bitcoin like, pre script restoration project, is there anything that we could do for activating opcodes, anything like that, where we could answer the technical I mean, I gotta I've just focused on the engineering side, but, like, that's the thing that we can directly control. Is that are there any of those where we could feel confident with Bitcoin as it exists today, activating something new where we could answer every technical question for it, defining the behavior for it. Seems like a strong man. I I don't think
[01:22:04] Unknown:
so first of all, I think that answering the technical questions around OPCAT and other things are super easy. We're probably basically there. Like, the the actual, like, is this implementation fine? I mean, like, we could get there a month. Right? Like, we're probably already there. Whatever. The Meavil stuff and the higher level, like, is this gonna break Bitcoin stuff need I think we can still answer it. We can still address that point, but we need to do the research. Right? We need to sit down. We need to say, let's create, not just, like, talk about how it's hard to create, but actually go create the best token protocols we can that use off cat and then build the best, AMM or the best DEX we can using these token protocols. What's that gonna look like? Let's go, you know, have a conversation in the community about, like, are people actually gonna use based roll ups? My intuition is certainly more so than Ethereum, but I don't know. You know? I'm I'm just one guy. I know that the roll kit people told me to eat shit. They're gonna build it anyway. Right? So, like, where is the Bitcoin community here? Where is like, why aren't people saying this is bad, this is something we shouldn't do? Like, these are things that that the Bitcoin community can do broadly and also especially research. You know? Andrew mentioned the the grant from startware, I'm sorry, which I think is great. I think that's the exact kind of thing we need to be doing. We need to be funding people and and certainly finding people. Money is one thing. It's really about finding the dev talent, the research talent. But we need to be finding those people who are talented who can do this kind of research and analyze the problem and say, here's what we can build. Here's why it sucks. Here's what we can build in ways that don't suck. And then the Bitcoin community can sit down and say, okay.
I think the things that suck, that create evil, suck so hard that no one's gonna use it, and are they gonna use the decentralized options instead? Because that's really what we're talking about. We're talking about we want people to not use a decentralized option and use a centralized option instead because the decentralized option breaks Bitcoin, which flies in the face of everything the Bitcoin community loves to do, but that's that's really what we're talking about. It's really what we need people to want to do. Yeah. And then another question for this is,
[01:24:11] Unknown:
I think we've got, like, 12 or so different projects represented here right now. Is that have we come up to the limits of Bitcoin as it exists today in terms of development work and, like, stuff that we can do going in the future? And maybe, like, we could kinda go around for people to describe, like, how much they're doing, but, like, I know with Infangement, we have, like, a multiyear road map for Bitcoin as it exists today requiring no changes, where it's just more resources
[01:24:35] Unknown:
can get better results for users without any changes for Bitcoin. Certainly, as simple as Lightning, we have at least 5 years worth of features to show.
[01:24:43] Unknown:
Yeah. Same for us, but
[01:24:46] Unknown:
But I I think I I think it's a point to push back on that a little bit. Like, I know all of us have a 5 year roadmap, you know, if we ship opcat tomorrow, we're not gonna look at it for another 5 years. Right? But it is it does again because we're talking about we're we're really talking about a fundamental shift to the nature of what we can do with Bitcoin. And again, I think, you know, there are limits to the kinds of systems we can build today in Bitcoin that potentially get removed. And, again, there's more research needed, maybe it's not efficient enough to be practical, but potentially get removed. And we can start to talk about a lot more systems in the gray area between custodial and noncustodial, and that's really where Bitcoin needs to get to, you know. There's this, I guess Peter McCormack always loves to talk about this, kinda like what what do we do when not everyone can own a UTXO? Like, how do we get people on Bitcoin?
And you're not allowed to say custodial. Maybe you're allowed to say custodial, but I'm gonna add that restriction right now. You're not allowed to say custodial and and we don't have a good answer right now. Generated custody.
[01:25:47] Unknown:
Well, I mean I think that you used the word custody. I think you might have broken the one rule. There was just one. But I mean, the night the nice thing about Federman is you don't. It doesn't require a software. I mean, I I'll I'll be the monkey brain in the room, like, the left curve of IQ. I will say, like, the opcat discussion, to me, opcat feels like an attack on Bitcoin, and I'm a little bit conflicted because You just think that because it's Udi. No. No. No. Yes. And and and Andrew, who's incredibly high integrity, like, breaks the template a little bit. It's like it's like Udi and the degens. Like, I know And then Andrew.
Is Ethan. I love it. Yeah. Ethan's awesome. Integrity. And, but besides all of that, I mean, this is just leaving out the activation question. And, I mean, I would personally propose that the way we decide if we activate it or not is is which side zaps more. I think it's a good way now. Yeah. During the show. By the end of the pandemic. It's the best activation method for Bitcoin.
[01:26:52] Unknown:
Also, yeah, I'm still very curious what people's, over under would be, in terms of, like, a date, for activation. Is it 2 years out that there would be a 50% chance before or after a date?
[01:27:02] Unknown:
I mean, it seems like there's some movement towards doing great consensus thing up first. Negotiation notes. That's getting revived a little bit, and that's still probably a ways away. And so if we have that first, I mean, they're talking about a ways away before we start thinking more seriously about opcat activation being something other than a weak one.
[01:27:21] Unknown:
What's what's the number? 3 years? 3 and a half years? I'm gonna throw out 3. I'm gonna make a darker prediction though, which is that all this horrible cat stuff is within the next 3 years, people will figure out how to do it without cat, and then cat's not going to be the thing that pushes us over the edge because we bought, like, movie in the world that we're not sure how to navigate.
[01:27:44] Unknown:
Well, I mean so, to bring it back, like, if if you're an average user if you're an average user from a use case perspective, well, like, why would you want CAT?
[01:27:54] Unknown:
Again, I I think it really comes down to this, like, you can't own a UTXO question. There's obviously a lot of, like you know, there's a lot of people super excited about, oh, we're gonna do, you know, these these roll up things with BitVM or CatVM, I guess, now. And it's gonna be great because, we can have all the, like, Ethereum complexity and all of the CVM garbage, and it'll all be on the Bitcoin chain and it'll use Bitcoin as the native asset and people are excited about this and I don't really understand why. But if you are a Bitcoiner Surprise. Well, okay. So I'm surprised maybe. Number go up at least until people realize there's nothing there and then they get that. But, but, but I think if you're a Bitcoiner, you're like, I just want good money. You know? There's there's a lot of cool there's a lot of cool stuff on Ethereum. I don't know if it'll actually come to Bitcoin because, it never came to Rootstock, and Rootstock exists and has been around for whatever decade now.
But if you're just like, I want good money, I wanna I wanna transact with good money. I wanna do it with lower fees so that I can own a UTXO even though I only have $10. You know, how do we build something? There's there's a lot of proposals that are super early for using covenants, and I think, you know, like, with things like time out trees, things like ARC, they all have big drawbacks that I would say are in some for many of the use case for the the kind of naive use case of just, like, I wanna, you know, have everyone use this thing that they're kinda showstopper kinda drawbacks, but there's a lot of interesting research still to be done there. There's a lot of yeah. I mean, we need to dump a lot more technical and and brainpower into that problem.
And I think it's fairly clear that we've mined the, ideas out of current Bitcoin, and covenants gives us a whole new space to think about where we can potentially build some really, really cool semi custodial kind of thing, you know, like, Time Out Trees as the for those of you who don't know Time Out Trees, it's it's a proposal basically what you do. You you take lightning channel, take an LSB. The LSB opens a channel to everybody all at once in one UTXO using CTV, And then at the end of, let's call it 6 months, all of that money in that UTXO reverts back to the LSP.
So everyone, they got a channel from this LSP, but it's a time limited channel, so they can only use it for the next 6 months, and then they gotta make sure their money's out before the end of 6 months. And then they gotta open a new channel, put the money in the new channel. That's great. You just need one UTXO. You can have as many landing channels as you want. It kind of falls apart if you actually have to go on chain. It you can't really go on chain because you don't have enough money to go on chain because that's why you didn't have a UTXO. So, like, the average user is just, like, sending between them. Right? Like, just quickly it's like the rug pull stopwatch. Yeah. It's like yeah. Exactly. It's it's a it's a, you know, there's a time timer on the bomb, and it's gonna work for you at the end of the timer, and you gotta make sure you get out. It sounds very much like an MLM when you describe it that way. But I promise you it's not designed to be a policy scheme.
So but, you know, it it has a big show stopping issue, but also, it would let you actually use order custodial Bitcoin on chain in a lightning channel that in a way you can't do today. And so ideas like that, I think, are gonna be I should say, I I wanna end that sentence with the future of Bitcoin, but that's definitely not how I wanna end that sentence. But, you know, ideas like that are are are really cool and things that we need to be thinking about, things we need to be building. I think it's clear that we need covenants for that. So personally, I'm really excited about it. I spend a lot of time shitting on covenants because I think there's not enough of that. It's not enough people shitting on covenants, so I end up doing it. That doesn't mean I don't also love covenants and, like, want covenants for my own things I wanna build.
[01:31:48] Unknown:
You you made kind of like a a throwaway comment there about how, like, all the ideas are gonna mine out of Bitcoin, but then you'd be have covenants in a whole new world. But would you say that having bit the m show up in the last 6 or 8 months or whatever, that was a bit of a, like, was it new ground? Like, I was not expecting new ground of that magnitude. Do you? Yeah. No. Absolutely. Yeah. And, again, I mean, it it might be the case that the ATM is too inefficient to to be practical. I mean, I think that
[01:32:14] Unknown:
some people have pointed out to me that the Ethereum, the Ethereum roll up the Ethereum, optimistic roll ups have never had a challenge proof on chains, so they've never actually validated it. Okay? Oh my god. This is in large part because they have have a limited set of people who are allowed to challenge, so it's not not anyone can come by and challenge. And then in bit the m p 2, anyone can come by and challenge. It's optimistic.
[01:32:39] Unknown:
Very
[01:32:40] Unknown:
odd. That's what it works. Who knows?
[01:32:45] Unknown:
So, like, maybe maybe inefficient is fine. Like, I don't know if people went to fly it anyway and just have a limited set of people who can challenge. But, yeah, I mean, I think I think you're right. The BIVVIA was a very transformative idea in terms of what you can do with Bitcoin, but I think it is, to some extent the first new idea of what you can do directly on Bitcoin since Lightning. And Lightning was the first new idea of what you can do with Bitcoin in, like,
[01:33:15] Unknown:
4 years prior to that. So Since 2013 when every good idea was a Bitcoin Taco Yeah. Basically. People.
[01:33:23] Unknown:
I mean, Jeremy came up with payment channels first. Right? But, yeah, I mean, like, we had a ton of great new ideas in 2011, 2012, a few great new ideas 2013, One great new idea, and I don't remember when lightning was. Somebody yell it out. Nobody? Alright. 2014. And then 14/10. Then we had the PM. Right? So it seems like we're not getting a lot of new ideas. You may be right that, like, you know, maybe we just haven't figured it out yet. Maybe there's something there. It's gonna be perfect. We're all gonna use it. We're all gonna love it. But it wouldn't surprise me to some extent. But but VM surprised me. So
[01:33:58] Unknown:
Yeah. I mean, like, half of the booths at the at the conference were just a good yeah. Deripatives or at least, like, super, like, attacks, affinity scams for VPN, at least. Buy your token, BitPM, or something something BitPM. Buy your token. There's these money contracts, BitPM. Yeah. Yeah. Maybe let's start moving toward our wrap up for it and kinda go around the horn for what the current state is for the projects that are here within
[01:34:25] Unknown:
the Rust sort of Bitcoin ecosystem. And Let me finish my lunch now. Yep. You're good. My Elliot's too late to pay for.
[01:34:34] Unknown:
Yeah. Okay. So he looks like you're on the horn. And, one final thought is final thoughts on this, especially for, like, after the Rustic Point Summit, like, what your project looks like and where you want it to go. If you have, like, specific contributor requests,
[01:34:47] Unknown:
then, let's make those. But before we go to final thoughts, like, Andrew, like, how does this how would this get activated if you want opcat? Like, how do you expect this to get activated?
[01:35:00] Unknown:
So I think that we need like, we we do need to kind of address this question as a community of this. What does Bitcoin look like in a world where we have transaction introspection and therefore covenants? Right? So one way this gets resolved is just we just kind of figure out how to do covenants without any changes, and then we're across the we're across the threshold. I have, like, kind of a a weird conversation with somebody recently where they were talking about simplicity, which is a total rewrite of bit my script. And they said, like, how could you possibly propose simplicity when it brings all these new things to Bitcoin and will let you do all these know you the things and how you reason about it. And I said, well, if we have cap first, cap actually by itself lets you do everything. Right? In simplicity, it's just kind of an optimization, which is a weird thing to to to hear myself saying. That's a weird thing to be true, but I think it is true. So one way is that we just wind up stumbling over that cliff, right, without any further upgrades to Bitcoin. And at that point, right, there's no further harm caused by op cap.
Although as Matt hinted before he left, there is a kind of a fuzziness related to the efficiency of these things. Right? So maybe we find it tremendously inefficient way to emulate off cap by, like, using shot 1 collisions or something. And then off cap lets us do it, you know, unless than 2 to the 80 work. Alright. That's an improvement. And then a real covenant opcode would obviously let us do it without, you know, using 30 opcodes and and a whole bunch of other crap. So the correct way to get opcat, and I guess the the kind of optimistic path that I see, right, is that we do figure out that Bitcoin should move forward. Right? We shouldn't just, like, stay ossified where we are. Right? That's essentially what we have to do. Right? If if we want to avoid all the new functionality that cap gives us, it's not just cap you avoid. You have to avoid all faults apparently, according to Brandon Black, I think, on my panel and, at the big conference.
You also have to avoid, like, an opcode that can do a comparison of 2 arbitrarily length strings. You have to avoid arbitrary size arithmetic. You might have to avoid opmall. Yeah. There's various crypto opcodes you'd have to avoid. You'd have to avoid certain kinds of variable length encodings for for signature and public keys. There's there's a lot of ways to to to get what AutoCAD gives you. And the reason is that fundamentally, all of the scary stuff, all the scary transaction in respect to them already in OpCheksig. It's just that you can't get it out of Cheksig and make it do more than checking the signature, because of just like these these kinda accidents of of what computations you can do on your signatures.
So okay. May like, maybe we don't ever want to cross this line. And in that case, we can't do any of the things that I described, any additional upgrades. You need to be really carefully, super specific things that avoid providing a new general functionality. And we better hope that there's no further research that that lets you, you know, be able to do that off cap. Ultimately, we decide that we just need to bite the bullet and move forward, but that is something that the community does need to decide. And until we do so, off Cat is in,
[01:38:22] Unknown:
in stasis. So I mean, I feel like you very gracefully didn't answer my question. So one thing that I like, the way I look at it is, in in Bitcoin, we have this idea of soft forks and hard forks. Right? And the key difference between soft forks versus hard forks is soft forks are effectively backwards compatible. You don't have to go and update your node. They are sold as opt in changes to Bitcoin. And with a hard fork as we have with Bcash, a hard fork is the history of the chain is the same up until the point of the fork. And then at that point, you're basically split into 2 forward histories or or or the the transaction letters are just split going forward. And if you want to be on the fork, you have to then up update your your your Bitcoin software. You have to update your note.
I think there's, like, a little bit of a misunderstanding on the risks of a soft fork because we've never had a contentious soft fork. And with something like OPCAT, I mean, right now, I mean, I I think if if you look at what what the community is looking at right now with OPCAT, there is clearly not broad consensus on it. It would probably be our first contentious soft fork. So if if you did go through activation, what does activation look like? Well, you know, you have the Bitmain Mafia at 50%, nearly, like, Anpool's basically creating block templates for 50% of the hash, and you have Foundry at 35%.
So let's say you convince those 2 people, right? You can convince the CEO of Foundry and you convince Jiyeon, and they go ahead and activate it, but there's not actually a broad consensus for it. Basically, what happens at that point is is effectively a hard fork, but much messier than a hard fork. So I feel like that is the concern that's not really being addressed. And you would have no relay protection. Like it would be it would be an absolute fucking mess. Most users would be really, really confused. So, I mean, I think that's the core of the question. The core of the question is like, how much here are we just, you know, playing mental gymnastics over something that really in practice cannot be responsibly implemented on a protocol level?
And then, I mean, the second question would be, would it be cleaner to just do a hard fork? Like, why why isn't there just, like, a replay protection, OPCAT hard fork and then let the market dictate? Like, I would be I would be happy to have 2 Bitcoins again.
[01:41:04] Unknown:
I I too made a bunch of money off of eCash. So, well, to answer your first question about why are we not addressing it. Right? In some sense, we're addressing it by not proposing an activation. Right? Like because you're right. Like, right now, if you or I were to go on the mailing list and just, like, say, here's an activation parameters. Even if they were super responsible, and it was like, nothing's gonna happen for 16 months, and then we're gonna have 4 months of signaling, and then it will activate, you know, 6 months later or whatever. We can get people all the time in the world, but that's not going to address the question of is a community entirely on board, and is there a large faction of the community that is explicitly not on board and would try to go do their own fork? And in that case, you know, I wouldn't say this is a first contentious way. I mean, some of these aspects appear in the SegWit as well. Right. And that there was a lot of and there we kinda stumbled into it because on the technical side, none of us were really expecting SegWit to be contentious. It was a very boring technical change at its core to change the way that the commitment structure works within blocks.
And it's a change that made various things like chaining unchanged transactions together, much easier, which you think, like, a lot of the b cash crowd is like, you know, 0 comp should work kind of thing. Well, 0 comp works much better with SegWilly. We weren't expecting any of the the opposition that we had. And the reasons for that the reasons for the opposition are are still not entirely clear. Right? It may have been basic boost. It may have been some cynical b cash, that does make money by having a fork. It may have been some weird power play or or ego thing where, like, Roger or somebody wanted to be king of Bitcoin. I don't know, but we certainly weren't expecting it going into it. Right? And then we were in the middle of it. And and somehow or other, we got to the other side. Right? But here with CAT, we're in a more fortunate position. Right? Where we know there's nothing like ASIC booth related to op cat because it's such a tiny narrow technical change. So that's that's the relief. Right?
And if there was really opposition of the form, like, I just want to have my own b cash fork that that I pre mine a bunch. Well, that's I mean, those ideas are pretty much dead. There have been a 1,000,000 of Fort Coins, and they're they're no longer big. But what we do have is is this real opposition of the form like this changes philosophically what Bitcoin can do. And that's quite a serious form of opposition. Right? And if a lot of people feel that way, then we can't move forward. But what I will say, and you'll notice I continue not to answer your question. A couple years ago, right, we could have been having this conversation, and the idea of having covenants in Bitcoin was just like, Right? Yeah. Covenants is a bad word. Nobody wanted them.
And those attitudes changed a little bit around certainly over the years that Jeremy was was shilling CPV, but also just think vaults became more popular as a concept as as the Bitcoin value went up and and more people became long term holders. And there's also kind of this this idea that Matt was hinting at that maybe these Meeval things are not actually efficient enough to make people money. And, like, there are a lot of challenges of the form, like, show me the mebel. Right? Like, actually give me a construction for some terrible thing that you can do with covenants that would make any sort of sense that you usually go along with and that could make money. And, I mean, attitudes have changed a lot in the last couple of years. Right? We're now, like, we're seeing this as a contentious thing. Well, a few years ago, it wasn't contentious.
The majority like, everybody was kind of on the opposite, like, on the anti cat side. And now we're contentious, and maybe maybe, the over to the window continues to shift. And then it becomes less contentious, and people are pro cap. And maybe we can we can move forward then.
[01:44:49] Unknown:
But do you think I mean, I guess, like, my question is, like, do you think it's particularly dangerous to activate a contentious self work? Like, to actually activate it, to have a majority of hash rate, basically force it through. I mean, we had an interesting question. We do Chatham House rules, at Bitcoin Park. We had an interesting question last week, which was, until we at least partially mitigate mining centralization concerns, Shouldn't all these activation questions just be off the table? Because right now, like, I think you can obviously, it's a little bit hyperbolic, but you you can you can basically say this, like, Jeehan plus Foundry, things activated.
Like, as a Bitcoiner, as I mean, I know you've been a Bitcoiner longer than most people and have the majority of your savings in Bitcoin, like, you're heavily invested in this. I mean, you lost it all in a voting accident. I apologize. No. But, I mean, you have I mean, your whole career is in Bitcoin. Right? Like, if Bitcoin dies, like, it's like Andrew Polstra is a nobody. Like, you and and as Bitcoin succeeds, you're an absolute legend. Do you not do you not, like There's a lot of member whittles. Do you not agree with that as, like, I to me, it's just
[01:46:02] Unknown:
Okay.
[01:46:03] Unknown:
Count them both rules here. I feel like all of this is I I I just feel like all of this is, like, you're putting the cart before the horse a little bit. Like, it to me, it's just, like, every like, cool minds. Like, everyone just chill the fuck out a little bit.
[01:46:17] Unknown:
So regarding the the kind of like personal identity parts of what you're what you're asking me. Right? We know that it's well, many people believe that at some point in the future, we'll have quantum computers. Right? Right. And those will focus Bitcoin to change pretty dramatically. Right? So the mining incentive will get kinda wonky where our our random work will become quantum random work. So All of our Schnorr and ECDSA signatures get, like, immediately broken. And all of my expertise as a cryptographer goes up the window. Right. Everything I've done cryptographically is, like, appealing elliptic curves to do cool stuff. An elliptic curve, they're basically useless Yeah. In a post quantum world.
So that's what I lay awake at night thinking, like, at what point do I need to just ride off into the sunset and disappear? And then when I think about doing that, it's quantum computers. Right? Cat didn't even cross my mind that's, something cat related or or covenant related or scripting or whatever would, would be the trigger. I forget what the second half of your question was.
[01:47:15] Unknown:
I don't know. I just I just think mining centralization, we got we have a unique situation where 2 parties can can basically force through this change if if, like, Udi pays them enough. Right. And, like, that to me is incredibly dangerous. Like, I I I don't I actually I think the lesson from b cash the lesson from b cash wasn't that hard forks so dangerous. I actually I would much prefer a hard fork here. Like, I think a hard fork would replay protection, would be incredibly clean, and it it wouldn't you know, I I apologize for saying what I said about your potential saving strategy, but my family is all in on Bitcoin.
Like, I I mean, we can stop talking about you. Like, I'm a fucking nobody. If if if Bitcoin fails, I will live in the woods. And if Bitcoin succeeds, I will live in the woods. But if Bitcoin fails, I will be living on someone else's woods. Like, I will just be squatting in your woods.
[01:48:12] Unknown:
It it's important to
[01:48:14] Unknown:
I I think we're we're falling into the trap that too many people fall into, which is we're we're misdefining software.
[01:48:22] Unknown:
A fork in Bitcoin is a change that is enforced by the vast majority of economic terms that applies to soft and hard forks. Right? So if if you're not if you don't have the vast majority of nodes enforcing the rules, this is not a change to Bitcoin's rules. This is just a censorship attack. Right? So what you're describing is not a software. It's a censorship attack. And the wonderful thing about censorship attacks is they only last as long as the same miners are still doing it. So if you actually saw Hash Power just, oh, I'm gonna go we're gonna go enforce OPCAT tomorrow.
The main the main mafia decides, like, oh, we're just gonna enforce OPCAT. It's It's the rules of the network now. Everybody's gotta learn to deal with it. This is gonna last as long as the miners don't wake up and realize, oh, we can make a lot of money if we go just take all that money locked up and off cat. Like, all this there's all this money sitting on chain locked up and off cat. That is actually anyone can spend money. Right? We're not talking about this bullshit anyone can spend, SegWizz anyone can spend because, you know, not all nodes enforced it. No. Basically, all nodes enforced it. Right? But the only the reason it wasn't anyone can spend money is because all nodes enforced it, not because Hashpower enforced it, because the nodes enforced it. And so if you see that kind of malicious fork, well, yeah, sure, it might last a while. You know, the the mid name mafia might stick around. They might keep enforcing it. But then in 10 years, all of a sudden, there's gonna be new miners and they're gonna say, oh, you know, there's a lot of Bitcoin sitting there. We can just take that Bitcoin. It's our Bitcoin now.
And a lot of people are gonna be real sad. It's gonna be a total clusterfuck. Right? If people actually start using something based on a censorship attack, you've got a lot of people with a lot of Bitcoin locked up in basically custodial shitcoin with Bitmain. You know, if you're using OPCAT and on Bitmain is the only one enforcing it, you're just custodying your money with Bitmain. That's all you're doing.
[01:50:16] Unknown:
Wasn't for wasn't one of the takeaways from I wasn't around at the time, so any of the old timers can correct me on this, but wasn't the day that they did the fork wasn't it something like 75% of Hash Power moved over there and, like, by the end of the day, they were back on Bitcoin?
[01:50:33] Unknown:
I don't think that ever happened. Every time I had b cash? Yeah. B cash. No. That never happened. Dion never had the balls to actually like, he indirectly controlled the overall majority of hash power,
[01:50:45] Unknown:
but he never had the balls to kill his golden keys. Have the balls to take a 1,000,000,000 of his company's dollars and put them directly into Bcash and then ride it all the way down to 0. Yeah. He did do that. But with the hash rate, he never
[01:50:58] Unknown:
I don't think the hash rate ever flipped, period.
[01:51:00] Unknown:
There there were some people mining back and forth, switching on whatever was most profitable. Oh, yeah. Oh, yeah. Sorry. There Oh, shit. There there were a number of miners that, were switching back and forth depending on whatever was most profitable. And that caused a lot of issues, especially on the Bitcoin Cash Corp. But, like, they they were just following, like, an just an algorithm, you know, what's most profitable. Okay. Just do that. But I I don't think they were looking to accomplish anything other than just make the most amount of money in the shortest amount of time. They were probably,
[01:51:38] Unknown:
like, hour long periods where VCAS is the most profitable, and they had 80% a half hour or something, but certainly not on a scale of, like scale where we can actually average this out. Right? Because you can't really accurately measure where Hash rate is on short time horizon. When there was a forked up mobile website. Right? Right. But, yeah, I mean, you there's a lot of noise. They have to average out over some time horizon.
[01:52:00] Unknown:
Yeah. On the time horizons, they could average out. I I don't know the hash rate. Yeah. Forged out, you never saw a significant percentage of all hash power. I mean, I think you saw, like, 10 or 20%, and I think it was enough that blocks were slow, but it was, like, annoyingly slow. Like, no one was, like, like, blocks weren't happening or it was nothing like that. Right? It was just, like, a little bit annoying. And some people and I think the fee rate increased in this time, and some people were arguing that it was because the blocks were 10 or 20% slower. And I don't know if that's, you know, justified for the actual one. It was a pretty minor thing. Shadowgram, just in case with Yeah. Okay. Chat Chat
[01:52:37] Unknown:
but they don't have a choice yet. I don't Yeah. And, also, they're not zapping with their comments. You can So ignore it. I live on mobile phone
[01:52:45] Unknown:
24 7. I'm pretty sure it never flipped. I I I mean, I think Matt that I'll be wishing that is Matt Matt explained my concerns much more eloquent than me. He and he used the technical term clusterfuck. Like, I really wanted to avoid. I'd prefer to avoid a a mass rug pull, kind of event or, like, a massive reorg if if you start to see miners, you know, switch back. And, like, right now, that it just feels like we're at, like, kind of a detente, and it it feels like most of the conversation is unproductive.
[01:53:20] Unknown:
I mean, that's also true if you watch Twitter. If you hang out with developers, I'm not sure, like, you know, if you just watch Twitter, you would assume that, like, myself and Polstra or myself and, Ethan Heilman or myself and and don't know. You're just fighting with everybody. You'd think that we, like, wouldn't get along and that we hate each other. It's not like you know, we have we have conversations about it and we talk about it, like, there's more research needed. And I think I think there's I I don't know that we actually really have that drastically different of a viewpoint.
Like, you know, I I take different positions in public because I I think these issues aren't talked about enough, and that's what I focus on in public, but that doesn't necessarily mean that that's the only thing I care about. That doesn't necessarily mean that I don't love El Cat too. Right?
[01:54:04] Unknown:
So then what about Andrew? Like, what is your, and I love this is, like, such a great detour before final thoughts, like, half an hour detour before the 5 minutes. We're not in a rush here.
[01:54:16] Unknown:
The Final thoughts before I went and finished my line. I know.
[01:54:19] Unknown:
And then you came back, and we're just continuing No. I'll finish my line. Well, I mean, I I we got this group here. We have to have, like so what are your thoughts on, like, more restrictive changes, like, something like an out fault or something? Like, you just don't need to think like that.
[01:54:35] Unknown:
So they I'm skeptical that they're actually more restrictive. Right? So op vault is a is a good example of an opcode where, you know, 2 weeks ago, I would have cited that as an example of something more restrictive. It just enabled vault, and it doesn't do anything else. And then, I think it was Brandon. Whoever it was on my panel beside me said, oh, like, just a few days ago, I figured out how to do, how to do, like, generic covenants just using off walls. Right? I figured out how to abuse them. So I think that it's possible to come up with new opcodes that don't enable you to do everything that does, But I'm not convinced that, like, I'd really have to study any specific proposal before I, come in. Is
[01:55:22] Unknown:
probably pretty clearly nonrecursive.
[01:55:24] Unknown:
I believe that CTV is okay. Yeah. So you could use that as an as an example. Yeah. So CTV, yeah, is is a good example. And it's also been around for a few years, and nobody's, like, figured out how to do it. So that's also pretty good evidence that CTV actually only does what it sets on the 10th. So if your question is, like, do I support it? I guess. I mean, it it enables a bunch of stuff, and and maybe if that's something we could all agree on. Well, that's my answer. If it's something we can all agree on, then I support it. But it it's it's not. Right? CTV was, kinda got mired in a lot of of arguing about whether it needed to be more general or or whether it was too narrowly focused for the complexity that it brought and so on. But, yeah, whether it added any real value directly or whether we should just add something like cat and then add.
Yeah. Yeah. Exactly. Right? I mean, there are a few Jeremy had, of course, his website with a bigillion use case and so on. But but many of those use cases were pretty, kinda, like, made pretty bad trade offs, I'd say. There were a few that that were really good, but the the ones that were good, I would say, is a small set and probably not enough to justify the complexity. So kind of what got me excited about cat, right, is that the complexity, technically speaking, was so low. Right? And you'd do very little room for bike shedding. You'd do very little room for for for code that could be buggy, if we deploy it. And then later, we move on and say, you know what? That was fucking useless. That's just you know, we should have had some better off code. Well, you know, it's only 5 lines of code that we have to maintain forever because of it. Right?
So cat has those benefits going for it. And in general, I think any opcode does narrow enough not to do what opcat does would have to fall into the CTV kind of range. It would be pretty technically expressive. Right? And, personally, I would like to have vaults. Right? If we got covenants and they can do vaults but nothing else, I'd be happy. Well, we had an opcode. It turns out it doesn't just do vaults. Alright. Fine. CTV doesn't do vaults. It does sort of a boring form of nonrecursive vaults, but you can do that today with pretying transactions. So that's not so exciting.
Like, to do proper vaults, you kinda need recursive covenants, and then they come with I don't know. It's I I I know. It's not like there's there's kind of a range of trade offs that we can make. Right? And I don't think of any good points in that area. At the Bitcoin plus plus in Austin, that was basically all of the smaller opcodes where we're like, hey. We're trying to narrowly focus this down, and so it only does one thing. So the opcode you in? Yeah. Well, all of them showed up, and all of their presentations were consisted of, I tried my best to make this as tight as possible, and 8 months later, when I had the 9th or 10th guy look at it, he found a way to basically turn it into a generalized company.
And that was for all of them. That was, like, thoughtful, APO. Right? Like, just down the line. Right? And so and with CTV, right, it's like, hey. Say we activate CTV. Well, now you can use CTV with basically any other sort of tiny change, and then you end up getting the covenants there. And so discussion that Andrew's having about we have to decide whether or not we want this is, like, very important because there's basically to to date, there's basically no way for when you try to add one of these things without accidentally introducing this down the line potentially. Right? You can't prove that you won't be able to before that. And then another important point that came up there for it was that currently there's no way for someone to express on chain whether or not they want this thing. Right? So for example, if we had Cat activated, for example, and there were 100 of people or, like like, millions and millions of Bitcoin worth of activity for people using OPCAT for vaults, then that's, like, a very clear direction where Bitcoin Core and, like, the developers for it can say, hey. People definitely want Vaults. And so we can take the inefficient use of this with opcat and turn that into a tighter opcode, for example, for it, where it's doing the same thing that people are already doing with opcat. But for example, today, for whenever anybody talks about vault, so there's no way you can click. Like, there's a bunch of huge entities that are currently using pre signed transactions to get around the vaulting thing, but that's not something that people can point at. They're not very public about it. So when you try to point to, oh, hey. This huge company or this huge entity is demonstrating that they do want vaults.
That's not something that you can, like, point to and say that's, like, actual economic activity that we should try to align around for.
[01:59:55] Unknown:
I'm gonna push back on that. I don't believe that anyone will ever use phones. I think that the conversation so I will So aside from both sides. Aside from both sides. And his weird, manually created everything.
[02:00:11] Unknown:
He's gonna write all of his own software. They were they were great with 1, put 1 up, which is not accurate. Yeah. So
[02:00:20] Unknown:
so the problem so the problem involves management problem and replace it with 2 key management problems.
[02:00:28] Unknown:
And at least I have a project called codec city too, which was 69.
[02:00:34] Unknown:
Just pieces of paper. We replaced our 2 key management problems with 10 key management problems. Now this is only strictly better. No. But you only have to call 7 of the time. Right. Right. Right then. Alright. So, you know, there's a lot of large entities with lots of Bitcoin that care very deeply about their key management, and have spent a lot of time, a lot of money investing in key management. And vaults give you replace your key management problem with 2 slightly different key management problems. So it is true that your hot keys is ever so slightly different in its security model than your cold key, but it's not that different. Like, you still want your hot or, I guess, maybe it's your warning key because you have a separate hot wallet, so now you have 3 key management problems. But, but your warning key, you know, you still want it to be super secure and not have to deal with it. Then your cold key, you still have to access regularly to make sure it's still there. You know, one one problem with the vault cold key construction is, you know, no one's ever gonna have a, call you know, no no enterprise should ever Yeah. That's exactly right. Have a super cold key or set of keys where they never access it or you still have to you wanna access it once a year to check that it's still there, it's still working, you can still you know how to access it, whatever.
And so this is something that basically so I so I think in practice for a large enterprise, the cold key, vault cold key, and the existing warm ish, cool ish key, design would look basically identical. And so I think for most of them, when they actually sit down and start designing the vault system, they're gonna say, why are we duplicating all these keys? Can we just not do this? And not and so I I think there will definitely be both some maybe I was a little harsh. There will be people who use it, but I think the, like, excitement over how, like, every large enterprise wants this, that's gonna be great. I don't think that's really accurate, and at least the large enterprises that I've spoken with had to sit and, like when you kinda sit down, you're like, alright. So How are you gonna design your cold key? And they're gonna kinda stare at you blankly and then they say, oh,
[02:02:46] Unknown:
you know, maybe we won't. But isn't it it's more helpful for, like, individuals in inheritance. Is that not true?
[02:02:52] Unknown:
Maybe.
[02:02:54] Unknown:
I mean, that Maybe we can still use, like, multisig to do our own thing if you want. I mean But we could try to drag Robin to this conversation. And it's like, right now, Anchor Watch. Wait. He's active in the live chat. Yeah. Oh, that's what it is. Alright. So I I think that Anchor Watch I don't know what your term bill is limited to a year at a time or something. You do have layers of keys that people have to manage, and I wonder Yeah. So conceptually, I would call this kind of like our MVB product to start. Right?
[02:03:22] Unknown:
Making it very compressed on the technical side. The idea ultimately is that they couldn't addresses to distribute risk and make them safer and more resilient. We basically make a pseudo vault within a single UTXO by leveraging manuscripts. Right? And this enables with the combination of time locks and threshold to thresholds. We're basic and, you know, using, like, op if, like, nested opt if statements, we're able to do many different ways that you can spend a Bitcoin UTX. So the idea, ultimately, is that we wanna be able to provide assurances that there's many ways that this Bitcoin address can be encumbered. And, basically, in general, just how the industry work and kind of how the practices have developed, everyone's using, for long term cold storage, either some sort of MPC architecture where they're sharding an individual key, or they are doing some sort of n of n multisig, which has beta multisig has been around since 2011. We've paid a Scrip Hash since 2014.
And it was just a general observation we had about over a year ago that there was a more rich design space built on, you know, to make this full circle, Rust Bitcoin, Bitcoin DevKit, Rust Minionscript. And for us, I think I view this as, like, the starting place of being able to make Vault like functionality with the understanding that, you know, I'm a company building in the space, so I don't have the luxury of hoping that there will be some sort of fork activation that's gonna add new functionality. This is kind of like an idealized state of how far can we take this concept of vaulting today. And it is a key management problem, but you can distribute those keys and you can have more robust scripting. So you can rely on organizations, lawyers, estates, trusts. And with that distribution of keys, you're able to distribute the risk and internally make the money more safe by not making it there's this one way you can spend the money in the transaction.
[02:05:04] Unknown:
Would you would you imagine that your users so right now, there are keys that are, like, time locked with with the highest time lock in in your elaborate script. Would you imagine that some of those keys would move from being, like, very long time lock keys to being actual vault keys that just aren't used except in
[02:05:20] Unknown:
bad cases? So I guess, like, to to Matt's point about, you know, you're just changing one key management problem to another. There needs to be a contingency of if this default happy path is broken and those keys are compromised, you do need to have some sort of emergency cold storage keys that you're able to reclaim to in the event that those hot keys are compromised. A very simple example is I could have a with an op vault construction on my phone, maybe I have a single sig, that it sits in an intermediary address for, say, a week before it can actually get flooded, which maybe 90% of the time is fine. But if someone compromises my phone key, someone's just maliciously trying to drain my money all the time, and I'm constantly spending money on chain transactions trying to sweep it out, you need to be able to have some sense of kind of distribution of keys. But I think what you can do is you can make a bunch of keys phone keys. You can make them really hot and accessible, and then you can have your hardware wallet, cold storage, in a bunker wrapped around in aluminum foil to kinda keep your super safe keys as, like, disaster recovery or some sort of federation or distribution of those. I think that's totally an option. Yeah. I think we're gonna build that, and then we're gonna see people are gonna say, oh, my phone got hacked. Let me go find my key that I wrote down when I created this wallet. It's I put it in a safety deposit box. They're gonna go to the bank, and then they're gonna realize the bank took their safety deposit box and sold it because they haven't visited the bank,
[02:06:37] Unknown:
in the last year, which, by the way, is a thing that happens. Sure. Yeah. It did. And then they're gonna get sued. So I I think, you know, I I think when we really sit down and we model out all of these issues, I think we're gonna find that that and in in general, when I do talk to people who do model out these issues, and maybe you guys have, but I think at least on the enterprise case, we we generally find that people say, oh, well, actually, the key ends up looking similar, and we end up building something very similar.
[02:07:07] Unknown:
You know, we All of my keys are codecs32 checksums, and every 3 to 6 months on a schedule, right, I make sure I can access them, and I verify the checksum using my worksheets, which I then burn. So I do have a process to refresh my key that don't require the interrupt. Again, we've already established you're gonna use all this stuff. These conversations whether other people were mentally stable, they're gonna use all these things. Again.
[02:07:29] Unknown:
I can't do it. If it's mental stability, it's the threshold of the conversation.
[02:07:36] Unknown:
Andrew's actually gonna retire on the profits from selling the book that allows you to do this stuff.
[02:07:42] Unknown:
Yeah. It's it's the rich dad, poor dad model. I'll watch I'll watch your Netflix movie. I have a quick story for, like, what made me decide that, like, bolts are important. So, I was helping out a guy who had all of his funds stolen out of his cold storage. And the time that the guy had actually gotten compromised was, like, 3 years previously when his Google was compromised. Right? And at the time, this was just, like, you know, a total newbie or whatever. He'd taken a picture of his seat. Right? And so this he had it there. And instead of immediately sweeping all the funds, what the hacker had done was he'd set up a worker for just watching the wallet Mhmm. And allowed the guy to continue stacking to his cold storage.
And the guy continued to do it for, like, 2, 3 years, and then the first time that he actually tried to move the funds was basically a replace by fee transaction that swept the entire wallet. Right? And so based off that, right, like, the the thing that I'm most, bullish on for Vaults, right, is that when a key gets compromised currently, right, they don't have to do the attack immediately. It's like once compromised, there's no indication that the key has been compromised, and there's no way that you can have any sort of reactive security to your key was compromised. They started moving the funds. I can do something about it. Right? And so just, like, think about how many, like, how many freaks are out there and, like, you know, they did their cold storage setup with their multisig or whatever, and they've just been continuously stacking to it without checking all these things and also not having any sort of indication that the key was compromised in the event that it was, and then 5, 10 years later or something. Right? Like, because once you have the key, you already own the wallet, and you don't have to do anything that shows that you do it. But with a vaulting structure, that's something where in the event that it is compromised, you do have that window for being able to go after it. And that was the specific instance where after that one, I was like, oh my god. Look. We need Proactive to react. 2 things. Right? Like, the there's
[02:09:34] Unknown:
yeah. I mean, there there are definitely cases we can point to where we can solve it. There's no question about that. And you're right that, like, being able to have reactive security isn't it'd be primitive that that may be useful. But I think it's important to ask what percentage of attacks are like that. You know, how many does the attacker really leak the key, get the key, and then sit on it for a long time? And I think that may probably growing, but it I assume it's still fairly rare. And then there's the question of what percentage of people are gonna build this vaulting thing and then assume that their vault key is safe and then forget about it and not actually have it be safe, and I think that's probably very high, especially, you know, when we're talking about enterprises. I know when Volts first were being talked about, it was mostly about enterprises. I don't know that enterprises are really gonna use Volts very much, but at least them, they are we know, okay. They're gonna they're gonna do all stuff. They're gonna check that the keys are still there once every 6 months. They're gonna send people out to all the vaults, physical vaults in this case.
Check the keys, reroute the keys, try to sign something, make sure it's all valid. But with a normal person, we assume they just never will. I think 99% of people just never will. It's never gonna rise to the the threshold of, like, they're gonna actually check it. And so I I I don't know. Like, you know, we have to we have to consider those proportions, and some people are gonna build wallets like that. I don't know that they're gonna have the most users. You know, I think they're, like, 2 or 3 model where a server applies velocity. You know, one thing, if we had volts where you can apply velocity, like, maybe just velocity controls generally would solve this too. Like, maybe that's actually what people want to velocity controls, not volts.
Maybe we want both. So, you know, maybe Vault's the wrong thing to focus on. Maybe we should be focusing on 64 bit math, and then we get the curse of covenants again, and then we have this whole thing starting from the top. But
[02:11:29] Unknown:
nice. Yeah. Another super cool thing other than vaults that you can do, that I think you'll win immediately is, clawback transactions. Like, you know, undo button that expires after 20 minutes. You can't do that now, But, you pay somebody and then you can pull back the money in, like, an hour or something.
[02:11:43] Unknown:
So you think, like, the lack of chargeback chargebacks
[02:11:46] Unknown:
is a bug not future? Well, like, if this guy wants to bring the government in, if you take all chargebacks, I think, I'm fine. Yeah. Yeah. He's gonna be sig with the CRM. He doesn't love with
[02:11:57] Unknown:
that. No. But Sorry. I respect. Yeah. But he did, he did some Mike for fun.
[02:12:03] Unknown:
Oh, no. I I don't know. Like, could you do that with the multi sig and some sort of time lock? You like, the clawback stuff? Yeah. I don't know. I mean, there's no way to to remove this much additional.
[02:12:14] Unknown:
Yeah. That's a so in the layered example, like, what we're doing, once a time lock is satisfied and you can't you can still spend the older condition. So if I have money I can spend today and there's a new spend condition at 6 months and there's a new spend condition at 1 year, you can spend the no time lock and the 6 month time lock condition even if you hit the 1 year. It's not like you can expire a spend condition by the nature of how it's funny because you call it, like, a time lock. It's more like an unlocking of some sort of condition. Right? You basically pass a you open up a logic gate with the either check lock time verifier or the check sequence verify. Right? So you turn a verify function in Bitcoin script, which is pass fail into pass, and you can't make it go to fail again once you flip it to pass. Yeah. You can't make it invalid after a certain time. Jersey. To to bring Brad the the conversation to us, this is like a cargo feature. It's just additive by nature.
[02:13:05] Unknown:
No. I got it.
[02:13:07] Unknown:
You can first do this by No, Mike. You can do this by just spending the UTXL,
[02:13:13] Unknown:
Putting another transaction. RBF.
[02:13:15] Unknown:
Yeah. Or yeah. Yeah. Mehul's never clear again. You'll always have the opportunity to RBF. You can just give someone an end lock time transaction to the future, and then you have time to be able to spend it, bump it out, and claw yourself back without hitting the men publicly. I mean, of course, you could just get into, like, a back and forth where it just goes to 0. Totally.
[02:13:33] Unknown:
Scorched earth policy. I mean, I just wanted to shout out weirdo robot, in the comments. Matt, he called you mister Blue, which I feel like more of us should do.
[02:13:47] Unknown:
Room because that's ambiguous.
[02:13:49] Unknown:
Yeah. Mister Blue's good. It bangs. Yeah. Should we should we do what what Cody suggested, an hour ago?
[02:13:59] Unknown:
Yeah. Sure. So let's go around for the projects of, like, what the road map looks like for them and then, like, contribute. We talked a little bit about contributor status, but, like, anything where you're kind of, like, lacking somebody and you'd want them to, like, come in. I work at a couple of, I'm sure everyone else has maybe a couple of, like, this is part this is part of our roadmap where we don't have dev resources that we could throw at this right now. K.
[02:14:21] Unknown:
Sure. I'll speak to my rusty coin. It feels like the project's healthy. We've got people coming in. I go to sleep sometimes, and I wake up stuff's done. So it feels really good, but it's like sometimes it doesn't. Yeah. So it feels good. We've got developers. We need more of yours. It's felt good to hear everyone, or it's been good to hear everyone saying that they're using the project. That's great. My ultimate dream is that no one ever talks about rustic coin. It does exactly what you want. No one rinses about it, and you never hear about us again.
[02:14:50] Unknown:
Yep. They agreed on all counts then. Yeah. The biggest thing we need are are users who, will tell us what they're doing. So we we aren't, accidentally breaking up stuff. Yeah. Double on the on the user feedback, I think. So BDK, we do want you to hear about us. We want people building products, you know, new self custodial, high privacy on chain stuff, high security best practice. We're stabilized specifically so people can do those products and get that kind of guarantee and give us the chance to write the documentation. So we need your help and feedback, documentation, build stuff with us. Just build it. And if you're, you know, an existing user of BDK, let us know. We will help you migrate, to a pre one point o to the one point o API. So, you know, reach out. We're on Discord or, you know, email. We we're building the software that is built by people that are better than anybody else you'd be able to hire. Like, these are rock star Rust devs that are building amazing software and you get it for free. Of course, we would like your support financially also, but, it's a complete game changer for building a company. So please take advantage of that.
And, yeah. Check us out. Bitcoindebkit.org.
[02:16:07] Unknown:
Before I get into that I'm sorry. I have to bring the conversation back once more. 6 hour podcast. Someone did DM me, and they sent me a chart. I'm not actually sure where it's from, so I don't know if it's legit. But it does show the BCH hash power getting a tick over 50%, very briefly sometime between midnight August 20th August 24th. So we were on, thanks to Eric Wall for pointing out.
[02:16:35] Unknown:
Eric Wall.
[02:16:39] Unknown:
I I will point out that, Rob in in the room pointed it out to me. And I told I basically I shushed him.
[02:16:46] Unknown:
I got to shoot. Yeah.
[02:16:49] Unknown:
I mean, I I mean, that's like that that was the kind of show you. I don't think that was, like, a real flip. But you're just trying to keep the frequency No. I'm not I'm not person. Gaslighting. I admitted it. I admit it. Fighting the freak. Gaslighting the chat that was telling us we were wrong. But how did they measure that? Like, how is that even measurable?
[02:17:06] Unknown:
It was a 3 hour rolling average.
[02:17:08] Unknown:
Okay.
[02:17:10] Unknown:
I got the same image from Maribel. But, like
[02:17:13] Unknown:
oh, you got it from Maribel? So he hit you first, didn't get didn't did get spoke about, and then he hit he and mister Blurb. Can explain yourself. I like Eric. Eric's one of my favorite shit corners. I, yeah. I mean, at that point, if I recall correctly, like, in August was
[02:17:32] Unknown:
they had, like, a ridiculous difficulty adjustment algorithm. Remember, it's like teams and their algorithm trying to It was like an insane trying to steal hash power Yeah. Worked very briefly and then it created And it was really bad. Their market collapsed and then they got their hash power.
[02:17:46] Unknown:
Okay. Continue.
[02:17:47] Unknown:
Alright. Alright. Yeah. So, LDK, our road map sadly, you know, a lot of people in this room talked about all kinds of great API things and trying to get the API perfect and focusing on stuff like that. We just we're just trying to ship features. We've gotta ship, splicing and bill funding and taproot channels and multisync channels and, async payments and trampoline payments and BLASA. Nice. So, we have a huge road map. We like our API. We think we're our API is pretty good, but that is not our focus. But we are hiring, so the great thing about LEK is Spiral has headcount full time to work on this. You know, we funded a lot of developers on other stuff, but Spiral you can come work directly for Spiral, and we are hiring right now for at least 1 LDK engineer, maybe 2.
You don't need to know Rust. We don't require you to know Rust. I think everyone on Spiral learned Rust while working on LDK. I don't think anyone actually knew Rust coming in. Some people didn't know lightning that helps, but it's certainly not a requirement. Somebody in the chat's asking if splicing is an in all the key today. No. It's not. We're getting there. We've got we've made good progress on it. We're not right there. We'll find things a little closer. But we've got the state machine. We gotta finish writing it.
But also more broadly, and I think this was discussed earlier when I also wasn't in the room, but, you know, if you wanna contribute to an open source project like LDK, it doesn't have to be writing code. In many cases, it can just be providing feedback. LDK, a little harder because it's actually a library, but, you know, write take LDK Node. Try to make a high level app. You know? It's act it's designed to be super easy. You should only barely need to be a developer to know how to do that. So do it and let us know how it goes. And I think one thing that open source projects universally don't get enough of is just user feedback.
People assume that open source projects, you can just take it and run it. And if it doesn't work, then you have to work around it because it's open source, so you have to do the work to make it run. No. Let us know. Let us know how it went. We wanna get better. We wanna actually get feedback, and we just don't get that in a way that a lot of for profit things where people pay for it and then they assume they get support. And in many cases, open source projects do actually give you the same level of support. You just have to actually ask for it. You have to know you wanna you can ask for it.
[02:20:10] Unknown:
Yeah. Just to briefly add for that, for, for release, we're really, really looking forward to upgrading, to BDK 1 dot o, which will be, really great, on many levels. It will also allow us to get add a bit more server features syncing with Bitcoin, stuff like that. That will be great. Also, we'll be looking to add some more support for the LSP spec. But apart from that, what I wanted to mention is one takeaway from this week was that a bunch of this project or I think all of the project most of the projects in the room were actually, building out, language bindings that kind of reexported some of the rust Bitcoin types.
And one takeaway from this week was that we will now create a new project that basically instead of everybody doing the same work of exposing these types of rust Bitcoin, we'll do that once and all the other projects can reimport that project so that these rust Bitcoin types are available. This will be writing a bit of boilerplate code, and it it will probably not be super complicated. But if you, out there, basically, are, a Rust developer and have, maybe even with experience, with with language bindings and maybe Unify in particular, the Mozilla language binding generator, that would be a really great project to start contributing to that would benefit all of the or most of the projects here in the room.
[02:21:42] Unknown:
Yeah. And then, I'll cover Fedi Vin, and then let's go for everybody else because we've got a bunch of projects here. So for FettiMint specifically, we're cutting a 0.4 release this week and then after that, there's a couple of different, Rust elements that we're working on. And so but to work on payment, you kinda need to be a pretty significant lead experienced Rust developer because there's consensus code involved. But, one thing we're really excited about is we're gonna have a TypeScript client very, very soon. And so that's just gonna be a drop in WASM compatible so you can just put it run it in a PWA or you can run it server side, but like a full TypeScript client. So more people integrating Fediment into their existing applications. Right? So if you want something where you already have an on chain component it or you already have a Lightning component but you wanna add, eCash, it's gonna be the the goal of it is to just have a super simple drop in. So anybody working on any other Bitcoin projects wants to add Feddy Mint, like, we're gonna have very good TypeScript bindings for that. So you can just drop it in, just npm install or uninstall Feddy Mints, and then, you can get started with it. Yeah. I want me to rephrase a bit. The goal of, the Fendament Web SDK is going to be to completely eat everybody's lunch in terms of developer experience for Bitcoin Lightning.
Everybody, but, Yeah. NPM installed, and we have a fully working Lightning wallets, eCash wallets, unlock your wallet. Yes. It's one sec. So deal. So yeah. Yeah. And so doing a DevX. That'll be pretty great. And then, specifically within Fedimint, we have UIs for the running the guardians and running the gateways that we don't have developers for just because the guys who normally work on it, they've, kind of moved on for other projects. And so anybody with any sort of React experience, like, we can help you out with all the Rust side of things, but it's mostly just working on a normal front end project. So any front end web developers like Faiman's definitely, wanting some of you guys right now. Also, yeah, we're we're also serving for, like, front end help, in the open source side. So, like, for, like, the Guardian UI. You know, right now, Cody is, taking that all on himself, and the the Fedi front end people are, strung out. So so, yeah, if you are a front end dev and wanna contribute to some of this hardcore Bitcoin open source stuff, yeah, we need you to.
Yep. And maybe go around the room for anything. Hey, Tony.
[02:23:54] Unknown:
Hey, Tony. I wanted to say a couple things on Russ Bitcoin, though, that we missed. We missed, some some Cindy cryptographic function optimization. There is some room in Rust Bitcoin to optimize these functions. Maybe We talked about that as a problem and we also talked generally, all of our projects are looking for a better HTTP client, to make requests. Yep. Turning an HTTP client that already exists, async, one that's async. Yeah. Yeah. On the page one side specifically, we're working on getting our dependencies up to speed with everyone, of course, finishing the async pay join protocol spec, which is very, very close that will be merged in the bps repo this year for sure, hopefully fall during the fall, and getting a pseudo stable, maybe the better word is complete API for page 1 so you can do some of the more interesting batching stuff if you're an exchange or someone like that.
So there's there's cryptographic stuff to do for public key encryption that's a cross between what PayJoint is doing, what Rust Bitcoin has, and some general Tor alternative oblivious HTTP stuff that we can work on, and that's that's about it. Yeah. When do you expect people to use PayJoin? I mean, I use PayJoin.
[02:25:29] Unknown:
I mean, like, more than like, more than a dozen of us.
[02:25:33] Unknown:
I don't understand your question. I'm not even using PayJoint. I don't know. I,
[02:25:38] Unknown:
I'm not gonna what? It's out there. You can't I know it's out there. I'm not gonna we'll we'll we'll have a proper conversation, just the 2 of us. But, I think Pedro and I I mean, I love I love what you're working on. I think it's incredibly important. But it probably unless we see, like, a mainstream client that just completely ignores coin selection and just does pay joints by default, like, we probably will not see significant adoption, and we have not seen significant adoption. I completely agree. I think the reason you haven't seen it in mainstream clients is because the original
[02:26:10] Unknown:
two protocols relied on synchronous communication Yeah. Which is incompatible with someone like an exchange using it, but the new protocol allows that to happen. And there are 2 exchanges who have commitments to integrating it with both their exchange product and their client applications
[02:26:27] Unknown:
as soon as they can. That's awesome. I just wanna jump in. So Dan showed a demo today with BK and the new page point protocol, the CLI. I think making examples of how to do this for, you know, your basic or maybe wallet developers will help just adoption. Are there Make it available. Ready for mutiny. They just have to hit the merge button. Are the 2 exchanges public?
[02:26:49] Unknown:
Yeah. Galois has a bounty out for it, and Francis has been tweeting all over the So Bill Bitcoin is 1? Yes. I think Galois is not an exchange. Galois has a custodial exchange product, I think, in blank. No? I don't know. Yeah.
[02:27:03] Unknown:
Okay. Dope. Well, maybe jump to the chat. It's asking just a couple of small questions. The one is is Requests not cutting it? And no. I mean, Requests has a massive dependency tree for one thing that, like, exceeds the size of any of our existing dependent. So we don't wanna open more than double that. It also, how it's like it changes kind of frequently, so it's difficult to have it as a dependency because then you can't stake what's the single compiler version. Then are those the repos being discussed? That is definitely Rust Bitcoin. Is that the repo? Yes. Yep. Cool. And then is this a point of PDK? I guess you mean BDK.
[02:27:40] Unknown:
No. Page on that. PDPDK.
[02:27:43] Unknown:
And Oh, okay. Cool. We're adding just every everything's a dev kit. They needed a new protocol too, though. It wasn't just a dev kit. The dev kit started getting built last year, and then there were the protocol was terrible. It required synchronous communication so we needed a whole new protocol and now that's just maturing, like that is that is almost merge worthy.
[02:28:02] Unknown:
Also, a request isn't blocking quite well. It does like a Yeah. It's weird. Small blocking. Async is small blocking that is not, like, blocking. So yeah. One more critical thing.
[02:28:14] Unknown:
The new version of PayJoint, we're looking for someone to help implement it in Bitcoin Core. It seems possible now that you can just take the Rust implementation and copy it over into c plus plus
[02:28:29] Unknown:
and there are some avenues where funding may be available. To be clear, he means the wallet. Like, it's not a core protocol change. It's just the wallet. Get a feature. One core wallet. Exactly.
[02:28:38] Unknown:
Dan, can I ask you, like, if you're making a private well, a public shield to exchanges to add, this support, like, what is what is the, what is the sell? Like, do they have fee savings out of it? What is it? Yeah. The biggest thing is fee savings. So
[02:28:57] Unknown:
the example is cut if you go to payjoin.org and click learn more, this is the first article that talks exactly about this. We show an example where you save, I think it's like 16% in fees and this is not a totally optimized example where this is an absolute best case. This is like a pretty generic example that's a small transaction. So if you take batching Right. Which has been around forever, that only allows you to batch outputs actually. Yep. PayJoin lets you also batch inputs. It totally opens up that space. So it's like someone's depositing to the exchange and they participate in the batch withdrawal. Is that what's happening?
[02:29:33] Unknown:
Exactly. And Oh, that's cool. As a consequence,
[02:29:36] Unknown:
you blur the edge of the cluster of each of the depositors and people withdrawing and the exchange because unless you are the exchange yourself or one of the participants, you don't know all of the coins involved. So for a 3rd from a the perspective of dragnet surveillance, they join As long as the exchange isn't providing that information. Publishing things, it's still it's still worse. But if your exchange does this and you deposit, then at least It's strictly yeah. Interacting with you. Like, if I'm giving you some money and you, for whatever reason, are selling Bitcoin to an exchange, which you would never do Right. Then it would be more difficult Not on chain. That you're going to that exchange or your,
[02:30:18] Unknown:
like, how much you're depositing? It's strictly net net better. And, from an external external viewpoint, it's it's strictly better and the exchange saves
[02:30:28] Unknown:
money. That's right. And everyone everyone wins. It's a good sell. And it fall it falls back. So if it if the page one doesn't work, you fall back to a naive transaction. Okay. I'm gonna I'm gonna help you with this. We'll get more we'll get more onboard.
[02:30:41] Unknown:
I'm sold. Matt does naming, and he does project descriptions.
[02:30:47] Unknown:
You're good.
[02:30:48] Unknown:
Who's next? Oh, maybe I'll jump in here. I get to have some closing thoughts without actually saying much conversation, which is nice. Can we introduce Nick? Yeah. So, Nick, our thanks for joining us. Thanks for having me. It's good to see you again. Nickar, we were back.
[02:31:03] Unknown:
So working for us now. On all of the things we just discussed. Yeah.
[02:31:07] Unknown:
We can go back to the start. Just just keep it on your. Working for a snap, next generation multisig. It's gonna make Bitcoin self custody much much easier, much much better, much more more private. We could do a lot of fun stuff with it. Also, separate to Frost Nap, we have a very spicy thing coming out in maybe today, maybe tomorrow. I can't talk about it publicly yet. Oh. Looked forward to that. It's coming out tomorrow.
[02:31:38] Unknown:
You teasing us? What is it? Oh, yeah. I can't tell you. Everyone's already No. We'll we'll edit this part out of the Yeah. This live
[02:31:51] Unknown:
Yeah. They're gonna have catch that. Right?
[02:31:53] Unknown:
So I don't even know what it is, but sure.
[02:31:56] Unknown:
But, yeah, check out frostnap.com. Next generation. This one's on custody. Twitter for the update. Oh, yeah. Yeah. Probably, if you wanna see the the thing we're gonna post soon, UTXO UTXO club on Twitter.
[02:32:11] Unknown:
Do do you have an aster or no? Website. Read out your hand pub.
[02:32:15] Unknown:
Yeah. Yeah. What is your name, bud? Nick at utxo.club
[02:32:20] Unknown:
is my,
[02:32:21] Unknown:
zip zero file. She'll blind sign her too on Duster.
[02:32:25] Unknown:
Oh, yeah.
[02:32:26] Unknown:
Yeah. That's good.
[02:32:27] Unknown:
That's that's gonna take too long. We gotta go away over 2 minutes.
[02:32:31] Unknown:
Thank you. Is your hardware wallet public yet or no? Well, there's there's no video here. I can It's like the human centipede of hardware wallet. It's like the mouse plugs and tabs. Supposed to be posted on that or you just Well, I asked him. I asked him. Something else. Yeah. It's a cool design. I like it. We we can post
[02:32:51] Unknown:
this the new devices publicly as well soon. They'll be for sale soon as well. Soon, GM.
[02:33:00] Unknown:
Yeah. You just, like, you plug the mouth to the ass over and over again for multi sig. It's amazing. Actually, I have some for you. Oh, thank you. I've seen some out points with all those ones. Not not the ones I have in my hand. We'll edit this part out. I'm glad you called me on that. Thank you for joining us, Nick. It was a pleasure. Service. Yes.
[02:33:21] Unknown:
Yeah. I can go. So I'm the single kid. I'm working on Kashi Dev Kit. Similar to other parts and agreements that the development kit built built in, Rust.
[02:33:34] Unknown:
Kinda was at the top of the click containers.
[02:33:36] Unknown:
We're looking for people to build stuff on Cashew and in general. It's it's really wide open design space. There's a lot of stuff left to do, and then you can use CDK to do it. It does both knit and and wallet. So whatever you're looking to do, you can use CDK for it and let me know what's what's broken in it. It's it's a little less mature than the. But yeah. So let me know. Report issues, and I'll fix them, or even better open a PR and, can join the.
[02:34:06] Unknown:
Okay.
[02:34:08] Unknown:
Hey, wait. You got you got PayPoint 10 runs working in half an hour. Right?
[02:34:13] Unknown:
It's a little more than half an hour because I have the whole,
[02:34:16] Unknown:
PayPal wallet. But the PayPoint card was was about a half hour. Yes. The cash you guys have actually have on chain support, but,
[02:34:24] Unknown:
I hacked it into it some day. Oh, yeah. I was wondering about that when I was watching the presentation.
[02:34:29] Unknown:
Yeah. So there's a a draft a draft knot, to implement it. So, we're working on on getting on chain support implemented,
[02:34:39] Unknown:
in the in the spec. Because you know Cali fundament I mean, he's not the ruler of Cashew, but he fundamentally disagrees with on chain support. Well, we'll see. Because of the because of the permission thing. Because of, you know, Mintz not being able to control what goes in and what goes out. Yeah. That is that is one of the issues. I mean, we have Cody here. Like, Fedimint had a DNS issue where, like, some of the Fedimint's, they got banned on the dotxyz domain, and, they couldn't stop people from continuing to deposit. And Cali kinda took a victory lap on me on that one. And he was like, well, that can't happen with Cashew.
[02:35:19] Unknown:
Well, so Cashew is a little bit different in that it does you I mean, of course, it does it's a quote. You get a quote before you deposit. Of course, if you do get a quote at a time, you can still use that that address later. But in theory, if a wallet is functioning correctly, it's getting a quote and using it kind of immediately or within the expiry time. On chain, of course, you can't, like, actually expire the address that you can with lightning so that that it doesn't use that issue.
[02:35:47] Unknown:
But, yeah, it's kind of an unavoidable issue on on chain, I think, that that leads it up to implementation to protect users. I mean, I will say from, like, a user point of view, like, leaving a mint. I prefer having on chain support like, native on chain support so you don't have to deal with liquidity or anything. Otherwise, it just becomes, kind of what we're talking about with, like, time out channels. Like, in a real user situation, it's just them going from, like, custodial they're, like, hopping from custodial wallets trying to not get rugged Yeah. When on chain is beautiful. Right? It's like you just give them an address and you just get your money. Yeah. So both in for both on chain and lightning, the mint operator does have the option to disable,
[02:36:26] Unknown:
like minting. So an operator could decide to do, you can't you cannot mint into on on chain, but you can melt on chain. So that would be the spec would probably support groups or both. Like I said, it's a draft, so let's let's see what actually happens. But, the operator could decide to do exactly that where you have to peg in lightning and you peg out. So you go withdraw via on chain but not deposit? Yes. You could do it that way via the implementation.
[02:36:56] Unknown:
Cody, you wanna defend Fedimint until you grab the white? So specifically, I'll be in this issue that is solved in 0.4 getting cut this week. So Nice. I appreciate your your work. Yeah. For the and the for the on chain wallet, that's currently, well, there's an element of it where if you give out a previous wallet, a previous address, you can't stop somebody from doing another deposit for that other one. But, currently, that's just an implementation detail impediment is that the way that you do a peg in is that you tweak the Federation's descriptor and you deposit to the tweak.
And so for that one, because the descriptor, the Federation is public for it or they reveal it to whoever in their community has, like, joined the federation, you I mean, you could stop it of just, like, you stop revealing what the descriptors. Right? Or the other thing is, for example, for, like, if we move to, like, a BDK wallet, where instead of the client creating the address, the federation creates the address and gives it out, and the federation, just the same way with Casio, could just stop giving out the address if they wanted to be Right. Documenting. Fair enough.
[02:38:03] Unknown:
Hey. I'm Rusteshin Rob, and I'm working on some compact block filters, node implementation in Rust. Right now, it's just me. I make an issue and talk to myself. Stop some eyes on it. Yeah. It's called Kyoto, because one of the main dependencies is Tokyo. So,
[02:38:28] Unknown:
for a station,
[02:38:29] Unknown:
Rob. Kyoto, please come check it out and, save me for myself.
[02:38:35] Unknown:
He has it well integrated with BDK and a great demo also on, with language bindings recently. I think we got that running with, Swift. So it's Yeah. A lot of fun stuff to play with. It's,
[02:38:49] Unknown:
it's a standalone project, I guess, technically, but I had BDK in mind, like and LDK Node as well. So all the design choices and stuff, if I've been, yeah, mashing it at a BDK, and we have a wallet balance that updates properly and everything. So, yeah, it's pretty good.
[02:39:09] Unknown:
Awesome. Anchor watch. Anchor watch.
[02:39:13] Unknown:
I'll just briefly plug that we use a lot of work on top of BDK. So for things that are on the BDK roadmap, we're obviously interested in our things like the mini scripts planning module. I know that maybe more of a BDK 2 point o thing, but any eyes or anyone who's interested in being able to streamline. I can have a bag of keys that are part of my larger vault, and I can kinda put in a date and a time, and I can get, you know, pre trap stuff sent over me, which is we kind of code around that right now with, like, hard coded, understanding what layer you're trying to execute upon. Just as a really quick thing with all the logic before talking about time locks, that's what BBK must be quite greatly abstract because it's constructing all of the witness data that is on top of that also the end lock times required. So it's just a massive force multiplier for us. And I'll hand it over to Matthias because he's also upstreaming some code around databases to BDK. Yeah. I mean, yeah, just being able to host multiple wallets,
[02:40:06] Unknown:
in Postgres using BDK. I gotta get that going, hopefully, the next week. And then I think there's still a bug in cargo that doesn't let me add it to the BDK repo. So, hopefully, when that gets fixed, I'll add it to the BDK repo, but otherwise, it might just live on the Internet as its own crate. But, yeah, thanks thankful for everyone in here working on risk Bitcoin, BDK on Fediments. I mean, rising tide lifts all ships. So, yeah, just, super grateful to be a part of all this. So thank you, everyone.
[02:40:44] Unknown:
Stay humble, StackSats, and support open source.
[02:40:47] Unknown:
Love it. Love you all. Peace.
[02:41:08] Unknown:
Fast on a rough road riding high. Through the mountains climbing, twisting, turning further from my home. Out into this great unknown. And I don't want no one to cry. But tell them if I don't survive, unknown stranger. Grateful for my time with no regrets. Close to my destination, tired. Frilled and aching, waiting
[02:45:24] Unknown:
Love your freaks. That was born for you by Kid Rock. Stay on the stack set support, open source contributors. It's a it's a good idea. You should do it. It it helps all of us. One of the easiest ways is by going to opensas.org. There'll be more dispatches. I have no idea when they're gonna be, and thank you guys for all being a part of making this happen.
VanEck CEO on Fox Business Intro
Rust Bitcoin Summit Overview
Guest Introductions
Rust Bitcoin Project Origins
Rust Bitcoin API and Development
Bitcoin Dev Kit (BDK) Overview
BDK 1.0 Release and Features
Lightning Dev Kit (LDK) Overview
LDK Node and Integration
Contributing to Rust Bitcoin Projects
Funding and Supporting Open Source
OP_CAT and Bitcoin Script Discussion
Potential Risks and Benefits of OP_CAT
Activation and Consensus Challenges
Mining Centralization Concerns
Alternative Opcodes and Vaults
BitVM and Future Bitcoin Ideas
Project Roadmaps and Contributor Needs
Closing Remarks and Final Thoughts
