Video: https://youtu.be/L0Yh6VP6vxU
0:00:00 Matt Odell Introduction
0:06:54 The Bitcoin Core Development Process
0:49:09 Decentralized Bitcoin Exchanges - With Mike Brock, Wiz, Josef Tetek, Chris Stewart & D++
1:15:07 10x-ing Bitcoin Development
1:56:50 Softforks Benefits & Tradeoffs - With Jeremy Rubin, Jimmy Song, Paul Stzorc & Ben Perrin (BTC Sessions)
2:37:33 DLCs - Programmable Real World Events
3:17:45 Bitcoin & Lightning Node Roundtable - With S2L1, /Rootzoll, Jonas Nick, Keagan McClelland & Matt Odell
3:59:00 Rabbit Hole Recap - With Marty Bent & Matt Odell
twitch: https://twitch.tv/citadeldispatch
bitcointv: https://bitcointv.com/video-channels/citadeldispatch/videos
podcast: https://www.podpage.com/citadeldispatch
telegram: https://t.me/citadeldispatch
support the show: https://citadeldispatch.com/contribute
stream sats to the show: https://www.fountain.fm/
join the chat: https://matrix.to/#/#citadel:bitcoin.kyoto
Good morning, Miami. Good morning. We got a great house here today. Let's fucking go. So, I mean, I know a lot of you think I'm a natural at this, but I've never actually been on stage by myself in person in front of a great crowd until yesterday. So this is my second attempt. I took some notes because I missed a bunch of things yesterday. First off, I wanna thank the production crew. They did a fantastic job yesterday. They're filming with very high quality cameras. They're uploading everything after the fact, and we have a great crew backstage that nobody sees that makes this all happen, so huge shout out to them. Woo.
You might notice I'm wearing sunglasses just because these lights are very bright. Can I get a show of hands who was here last year? Okay. Awesome. A lot of new faces. As you can see, we did it a lot bigger this year. We got a nice dedicated space, larger than most conferences, dedicated to open source, contributors and projects. Extremely excited for it. We've been you know, it's been 6 months in the making, and I'm glad you're all here. Part of that program was we gave away a 120 free tickets to open source contributors of 32 Bitcoin projects. A lot of them are here today. It's great to see those faces. We do appreciate you. You guys are are what makes this movement possible and what makes Bitcoin robust.
We have So let's let's go through what what's going on here. We have First of all, we have workshop tables in the back. If you are over there, try and keep your voices to a minimum while the talks are going on. The talks will end at 3, with the live rabbit hole recap is gonna end the day. And then at 3, everyone can use the workshop tables to their full effect. We can network. We can talk about open source. You can see all the great projects that are that are being displayed out there. We have teams from around the world who are participating in that. We structured the panels to be longer.
They're 40 minutes each so we can have proper discussion, rather than just intros and outros and then get off the stage which I'm pretty excited about. We had fantastic panels yesterday so if you weren't here for it, make sure you go check out the video after the fact. They were really really great. Today, we are gonna have a absolutely awesome lineup. We're gonna have a Bitcoin core panel that I'm really excited about, Bitcoin Development Panel, decentralized exchanges, DLCs, nodes. It should be a very, very great day and I'm really excited to share with all of you.
What else do we have here on my notes? So open source. I'm sure most I hope that most of you, I mean, you're here today know what open source is. You know, the the power of open source is that the code can be verified and so you don't have to trust any corporation, with what is running, and that you can build off that code, you can improve it, you can distribute it, and that that code is viral in nature. It lives forever. It'll live way past all of us just like Bitcoin will, And, that is extremely powerful and that is why it is imperative for all of us to support these projects, support these contributors, use the tools, build the tools, test the tools.
You don't have to be a developer to contribute to the open source ecosystem. They love getting feedback through testing. They love design help. Design help is huge, And of course donations. So most of our open source contributors have chosen not to work at very lucrative paying jobs and instead have dedicated their time to working on these open source projects that are often, you know, their their compensation isn't great. So if you want to support them it is really great to send them some stats. I have 2 projects that I've been working on and to make that easier, you have bitcoindev list.com where you can donate sats directly to open source contributors who choose to get listed on the site.
That's powered by VTC Payserver, so no middleman, goes straight to them, it's basically directory. And then we also started OpenSats, which is a 501c3 tax deductible foundation. You can donate to that with credit card or through Bitcoin. Very excited that after a year and a half, we publicly launched 2 days ago. So if you go to opensats.org, you can donate today. Let's fucking go. OpenSads, part of the reason it took us so long is we take 0 cut. So most five zero one c threes will take 5% or 10% or 2%. We take 0%. We also we have a great board.
So the way the Open Stats works is, you know, you you donate to this general fund and our board basically there's 2 things. There's a general fund where we choose which projects go, where where where the donations go for you, and then there's also the ability to donate directly to projects that have applied and on the website. I don't think we have that part built out yet, but you can donate directly, to the projects. If you donate with credit card, by the way, we automatically convert that into Bitcoin and hold Bitcoin only. And the credit card fees the credit card fees, we don't even that doesn't even come out of your donation because, we got Ledger to sponsor the credit card fees, so just no credit card fees either. So it's just a 100% to devs, and you can get a tax deductible donation on it.
Yeah. And just a just a huge thanks to there's there was a massive team that worked with me to make this happen at Bitcoin Magazine. I really could not have done it without them. I couldn't have done it without a lot of people in this room today. It just inspires me, gives me a lot of hope for the future. You all you all are my people, and I'm proud to be here today. I'm excited to be here today, and, you know, we're gonna win together. We're gonna fucking do it. So let's fucking go. Have a great time. Enjoy yourself.
[00:06:55] Unknown:
Oh, this is so Good to see you. Oh. I see you.
[00:07:00] Unknown:
I didn't realize the Jackson 5 was the official music of core development, but, okay with that, I guess. Thanks for, getting up early and coming out. We're gonna be talking about the core development process. My name is James O'Byrne, and we've got what is probably the biggest panel of the, open source stage, at least so far. Maybe that bodes well for, increased developer participation. We'll see. But, yeah, I'm really excited about the panelists that we have here. So maybe we can get going. We've got a lot to cover. And, Yeah. Let's start off with some intros.
[00:07:38] Unknown:
Is that Andrew?
[00:07:40] Unknown:
So I'm Andrew Chow. I work on the Bitcoin Core Wallet. I'm the wallet maintainer, and I'm at Blockstream.
[00:07:46] Unknown:
Hey. I'm, Jeremy Rubin. I am a Bitcoin contributor. I work on, Sapio smart contract framework for Bitcoin.
[00:07:55] Unknown:
Hi. I'm Gloria Zhao or Glozao. I work mostly on mempool and p2p, at Brink.
[00:08:02] Unknown:
I'm, I'm mainly trying to focus on, making phone notes easier for people to use.
[00:08:12] Unknown:
K. I'm Carl Dong. I work for Chaincode Labs, and I used work on reproducible builds, but now modularizing the consensus engine.
[00:08:22] Unknown:
Very cool. So, let's start off by talking about, some repository mechanics. So as you all know, right now, Bitcoin Core is hosted on GitHub.com. It's a Git repository, and, there are a number of contributors, obviously, who work on Bitcoin Core in this venue. But there's a kind of special class of contributor, or maybe not so special as we'll find out, called maintainers. And Andrew is actually one of these maintainers, and we hear a lot about them. There's kind of a mystique surrounding them. So, Andrew, maybe you can talk a little bit about who the maintainers are, what they do,
[00:08:59] Unknown:
and their roles. So so the maintainers are the the people who have the ability to merge code into the Bitcoin Core code base, and it's actually largely a janitorial role. Maintainers look for other contributors to review code and and agree with the changes before they merge them. They're not, like, unilaterally adding things. It's it's mostly just, like, you know, seeing seeing that things that got reviewed make it in.
[00:09:31] Unknown:
Yeah. Yep. That makes sense. So, Jeremy, what has your interaction been like with, maintainers? How do you, you know
[00:09:41] Unknown:
I think that what's difficult, with maintainers is there's a lot of good, but I think what's difficult is that, what the community sometimes expects from the maintainers is different from, like, what contributors expect. Mhmm. And then you have to tell maintainers sometimes, like, hey. The community is, you know, wanting you to do this. What do you think? And they're like, oh, I don't wanna be doing that. That's not what a maintainer does. And you're like, you should probably, like, you know, like, there's some sort of miscommunication
[00:10:15] Unknown:
Can you give us an example of when those expectations differ?
[00:10:20] Unknown:
So in particular, like, I work on some consensus changes and, people wanna know, like, oh, like, what are what are the maintainers going to merge it? And I can communicate to maintainers. Like, people would like to know, like, you know, like this. Like, you should communicate that, you know, formally that this is not something that you're doing.
[00:10:37] Unknown:
But I think it's hard to sometimes get these, you know, like, people don't really want to communicate some of those things sometimes. And and I I think there's, like, a difference between how Bitcoin Core treats maintainers versus other projects. Like, in a lot of other projects, you have kind of like the the benevolent dictator for life, and they get to decide everything that's going on, what gets merged, and where the road map is going, whatever. But Bitcoin Core doesn't have that and we don't really want to. So it does lead to sometimes maintainers are are just doing the the work of clicking the button versus deciding, the direction of the project, which which we really wanna leave up to the contributors and community for for where Bitcoin is going to go.
[00:11:22] Unknown:
Yep. Yeah. So, I think maybe when a lot of people hear Bitcoin core, they're thinking about the rules of Bitcoin, how it functions, the consensus mechanism. Gloria, we know that there's a lot that happens in Bitcoin Core that isn't necessarily related to consensus, and a lot of the the job of the repository is to manage details that aren't related to that. So how are the 2 different?
[00:11:46] Unknown:
Yeah. I think when people think about protocol, they often think about consensus rules, so, like, scripting rules, for example. And then the next and most obvious thing would be the p to p protocol, like what messages are sent and understood by the all Bitcoin nodes. But there's so much that's only, like, a small fraction of what Bitcoin d is, which is also a small portion of or a major, but not the full portion of what Bitcoin Core is. And people often say, like, oh, Bitcoin development is so slow, But there's, like, dozens of PRs merged every day. There's bugs fixed every day. And I don't I just don't think it's true. I find it very hard to keep up with all the pull requests and issues that are open to the Bitcoin Core repo.
So, yeah, there's there's a lot a lot more than consensus. And a lot of the biggest impacts that we can have at a protocol development level are not actually in consensus. Right? Peter Wille is known for many consensus changes, but I would even say that his biggest contribution is Ultra Prune, aka turning the state from let's look at what outputs are available in the blockchain and instead just keep a small UTXO set. And that, I think, did more for scalability than almost any or more than any consensus change that we've had. Likewise, I guess I'm going to show my own bags, package relay is not consensus change. It does require a lot of community, like, consensus.
Not consensus consensus, but, like, you know, agreement. But it is it is it would also be a very impactful change. So hopefully, my message is consensus is overrated, and there's a lot we can do without requiring a soft work.
[00:13:51] Unknown:
There's also a lot of things within Bitcoin Core that, like, so since I work mostly in the wallet, these are gonna be some wallet examples. But, like, we do things in the wallet, some new innovation, and then other wallet software will, you know, pick them up, see that they're good ideas, and use them. And that's not that's also not a consensus change. And in fact, it doesn't even really require agreements between different software. But, you know, there are there are there's a large component of Bitcoin Core where we make changes that are basically local and then other people also pick them up because they seem like good ideas and, you know, vice versa. We've taken some ideas from other people as well.
[00:14:33] Unknown:
So, Jeremy, I know you've spent a lot of time on OPCTV among many other things, but specifically OP CTV in terms of consensus development. Can you just walk us through the process of, how changes to consensus are are proposed?
[00:14:50] Unknown:
Yeah. I I would if I, like, knew what it was. I think that there it's kinda funny because we have, like, this whole, like, you know, BIP process, and that's something that, you know, Luke knows a lot about because he's the BIP editor. But there's really no, fixed set of things that you have to do, say, or talk about. It's sort of this, you know, maybe rough process where you just decide you you're kinda like you're the, the who's the gopher who comes out and looks at his shadow and is like, you know, is winter gonna keep on going? You just poke your head out and see if people shout at you and what they shout at you about. And then you're like, okay. Like, it's gonna be in another 6 weeks or you're like, actually, maybe it's gonna be another 6 years or something like that. That make you Bill Murray? I definitely sometimes identify with the notion of doing the same thing every day and the same thing happens. So I would say maybe. Yeah. I'll take it.
[00:15:43] Unknown:
That's funny. So, you know, as Gloria was talking about earlier, Bitcoin d is composed of a lot of different components. It does a lot of different things. It's the one piece of software that people participating in in Bitcoin have to run. So I think it might be useful to go through and enumerate the different parts of Bitcoin d. So, just in quick succession here, let's start with Carl and kinda go down the list and and have each of you talk briefly about one component of Bitcoin.
[00:16:13] Unknown:
Well, yeah. So like, yeah, I can I can talk about the consensus engine, I guess, or or what people would call validation? So you guys know how like Bitcoin has a blockchain. And so, the blockchain has to be kept somewhere, and basically, it's kept in what we call validation code or what I like to call sort of the consensus engine. It keeps track of, all of the blocks. It keeps track of all the, you know, UTXOs, which are basically, you know, the coins. And what it also does is it defines what it means to be Bitcoin, basically. It define it's the arbiter of truth of whether, you know, a transaction or a block or or something is valid, which makes it a critical part of Bitcoin.
And all of the consensus engines across all of the nodes on the network basically have to agree for, you know, consensus to be formed. And if they disagree, then, you know, that's what we call it. Sort of an unintentional fork and that's bad. So yeah. That that's what the consensus engine or validation is.
[00:17:30] Unknown:
Random, the mining module essentially decides which transactions the miners don't put into a box they might potentially buy. So when a miner finds a box, they had a certain
[00:17:53] Unknown:
Cool. I'll talk about p2p, I guess, which is where I think a lot of the ideological values of Bitcoin kind of come to life in code form, which makes it very interesting. So this idea of, like, oh, it should be permissionless, but not just that. It should be censorship resistant. Anyone should be able to join the p to p network and broadcast their transactions, but that also makes p to p security model, like, extra hard mode because we want anyone to be able to join, and we don't want to be able to tell who's who. But, also, there are going to be bad guys. We have to, expect that, and that allows for very interesting, very anxiety driven development sometimes.
It makes review kind of spicier. And, yeah, we're always thinking about privacy and security andDoS attacks. So that's that's my pitch for p2p.
[00:18:54] Unknown:
I guess I'll I'll go into the mempool, which is the, you know, list of transactions there to be confirmed into a block. It sort of serves as the glue between the last three modules you heard about of consensus, the thing that gets finalized, mining, how we pick the things to finalize from the mempool, and then also p to p, like, how we get things into the mempool to give to those other 2 modules and then use the mempool to also figure out what to put into the p2p network ourselves. And so the mempool is, at least I view it as sort of like this central plane for all of Bitcoin where it sort of touches all the different parts and, it, you know, stores all the transactions that you might ever do in Bitcoin. And each node has their own mempool. There's no one global mempool, but there's also a, you know, philosophical mempool of all the transactions that somebody in the world somewhere knows about.
[00:19:47] Unknown:
And, of course, I'll talk about my favorite thing, the wallet. Of course, everything else we've just talked about wouldn't matter if you didn't have a wallet to make transactions.
[00:19:56] Unknown:
So Store value.
[00:19:58] Unknown:
Well, you still need a wallet. So, the Bitcoin Core Wallet, you know, it does things like manage your UTXOs, manage keys, figure out what addresses, what scripts to be watching for. And I find it to be actually very senior to be working on the wallet because, it's like the the one thing that users interact with a lot and then if you do it wrong, you might actually end up losing people's money. And, of course, you never wanna lose someone's money, which is so so the wall is is, a pretty big component and and there's a lot of work going into making sure that things are secure, that funds are still available, and that we don't, like, do anything weird with it.
[00:20:39] Unknown:
And there are many other components that are are, fairly crucial to running Bitcoin, like the RPC interface, the the graphic user interface that maybe are sort of nonessential, but, but niceties that, that help everything run. So, let's turn now to, the development process itself. Working on Bitcoin is, you know, notoriously, I don't wanna say difficult, but it it definitely has, unique attributes that make it time consumptive to work on. So, Carl, how how have you found doing large projects on Bitcoin Core, and why do you think the review process is is so, intense?
[00:21:30] Unknown:
Yeah. I mean, I think, you know, this is logic that I've heard from other people, and I I I think I agree with sort of on the surface. It's it's sort of, you know, if we just sort of walk away from Bitcoin, you know, it still kind of works. You know, maybe default compilers would change and and all that, but it still kind of works and which is why I think that, you know, Bitcoin has such a conservative, you know, model of reviewing PRs and and getting getting them through. Not not to say that I've I've I've fully agree with that or agree with the lien or anything. So I think that's what it is. I think personally when I'm trying to get across large changes, what has been really important is just, like, getting the rationale up, you know, you know, writing a big document about the rationales, the FAQs, sort of socialize the change, breaking up into little reviewable pieces, which has been sort of like, a culture that has developed over the years as review has become more and more, stringent.
And, well, one thing that I found to be really helpful is sort of dealing with and talking with people about, you know, potential flaws or or or potential downsides or potential alternative strategies sort of upfront. I find that that that really helps get people across the line after they've had a lot of context.
[00:23:06] Unknown:
Yeah. That's great. Gloria, a lot of your projects require coordination, deep thinking, you know, trying to sort of emulate how, mempool policy changes and peer to peer policy changes will kind of, ripple out through the network. You know, how do you feel that developing for that part of the system differs from, you know, other other tasks in Bitcoin.
[00:23:32] Unknown:
Right. Yeah. I think a lot of people underestimate the amount of advocacy work that you have to do, even just to change something that doesn't require anyone to to coordinate. Right? Like, I I think it's kind of understated how bad it would be if we, you know, merge to change that had an assertion that is not supposed to be hit, but could potentially be hit if, you know, a peer sends us something in particular. Because then you have a crash bug where someone can attack the network and just shut down all of the nodes running that version with that bug in it. You know? And sometimes we change something here and something breaks over there. Right? Like, it's pretty it's I think we should we should be careful about changing things.
So I'm on the I guess I'm more on the conservative side of development. But, yeah, like, with policy and p to p, with, yeah, with policy changes, the I guess policy exists in this gray area, and we can we can both speak to this, where, like, there are no
[00:24:37] Unknown:
there are no What what is policy?
[00:24:39] Unknown:
Okay. Sure. So policy is the set of validation rules that we apply to unconfirmed transactions. So not transactions and blocks, but ones that we receive on p to p or through the wallet, for example. And they're local to a node. Usually, the user is able to configure them and we do hope that people stick to the defaults because it's more safe. But, you know, if you're a miner, for example, and you have more resources, you can afford to, like, make your mempool, have a higher maximum dynamic memory, like, limit. Right? Yeah. The that's why there's this kind of gray area you cannot really expect people to adhere to a certain policy. And for example, in Lightning, they might take some liberties in, like, using, you know, a few bits of the in sequence field to, to communicate the ordering of transactions in their channel, for example. Right?
Or I I think, you know, we've we've tried to say, like, oh, maybe we should make this nonstandard, but, actually, you know, colored coins is using this to, like, flag certain transactions in a certain way. So that this is kind of this, like, no man's land where people can use it for their purposes. And that's why it requires so much coordination when we try to change policy because if we accidentally make something nonstandard and, like, 99% of nodes on the network are Bitcoin Core, and then 99% of those nodes are running default policy, Well, you cannot really expect your transactions to propagate if you're relying on something that, you know, the Bitcoin Core developers unilaterally decided to to make nonstandard.
Right? Which is why we don't unilaterally decide that. But it, you know, it I think it's it's good to to have this, you know, usable space for people to develop applications, of course. And that's why it's so important to have a nice communication between, you know, protocol or l one and l two because this is an interface that we rely on to to make the ecosystem work. Like, obviously, we cannot scale to millions of transactions per block, So we rely on these applications, such as Lightning, to scale. But, also, you know, if if the the first layer is broken or if transaction propagation doesn't work the way it's supposed to, then maybe Lightning is vulnerable to paying a tax, for example.
[00:27:22] Unknown:
Yeah. So as time has gone on, I've seen for myself that it feels sometimes as though, development in Bitcoin Core has become more arduous, and and that sort of makes sense that the process would get a little bit more heavyweight as the value of the network grows, say. But I know there are a lot of early developers who, feel that it's very difficult to work on the code now, and it and it continues to grow in difficulty. Jeremy, can you talk a little bit about, you know, whether that's whether there's good reason for that and how we might be able to keep the development process safe, but also kind of nimble and approachable.
[00:28:04] Unknown:
Yeah. I I think that I have a pretty specific take. Currently, a a lot of Bitcoin core development, happens more as an artisan process than an engineering process. And I would delineate the 2 if you wanna think about building a bridge, where an artisan process, you might be more concerned with, like, the, aesthetic detail of, like, what is the color of the bridge? What's the molding on the bridge look like? Are we using, you know, peak wood or something like that? And the engineering concerns would be asking questions of, like, how many cars need to be going? What's the load? What's the peak load? How many lanes do we need? And and those would be things that would be more concrete engineering constraints. And I think the reason why there there's a difference why Bitcoin ends up being a little bit more artisan and we could benefit by being more engineering driven. Is it an engineering driven process? You can define some sort of, objective acceptance criteria for is this bridge a satisfying bridge for our our need.
And, you know, if it is, you can proceed. I think Bitcoin as a community, we've been very resistant to having, standard processes required, because people view a standard bar for something as something that an adversary might be able to say. I've met the bar, and the bar that I met was for introducing a bug. And everybody can see that it's a bug, but now there's a standard thing that was satisfied by it. And now we're screwed because we said we would accept anything that met that bar. I don't think we have to commit ourselves so strongly to that, but I do think that by having, better standards, that means that you have things like a preflight checklist of, like, one one example of something I think is is maybe a new idea would be, like, any peer to peer or, like, policy change that we implement, we should back test against every previous block that we would be able to relay all the transactions that come in the next block into the mempool.
And they're obviously non standard blocks that get mined, but what that would give us would be to say, okay. If we're introducing a new thing, anytime we introduce any policy we should always have a backtest that tells us if there are new transactions that previously would have been okay. Right? And that's the sort of thing where in your if you're in an engineering process, you can define more of these criteria. And the more criteria that you have, it's actually, even though it's more arduous because you're saying, well, you better do this, you better do that. It's actually easier because you know exactly what you have to demonstrate, and you can work towards a concrete goal. And I think as long as developers aren't trying to adversarially be like, I'm going to come up with a rule that's not going to trigger this test, and then I'm going, I think you can actually get more confidence in the review process. And so I think that's something where the solution to make it less arduous is to get more strenuous, if that makes sense. I don't think it's very safe to just have, like, a checklist. I I know that's not exactly what you're saying, but, like,
[00:30:49] Unknown:
security is not a, oh, if we meet all these checkboxes, it's secure. There's always, like I I think it's more about developing this kind of, like, adversarial thinking
[00:31:01] Unknown:
when reviewing code, and that's not something you can really just I teach. Yeah. I I absolutely agree with you that you can't just purely rely on your checklist. I think that, we just have, kind of, like, empirical evidence that, like, things like checklists and actually, like, you know, redundant checklists for, like, mission critical things in, like, aerospace do reduce critical failures. And they make sure that when you're doing something, you never let yourself rest on an assumption of, like, oh, this is a small change. We don't need to audit it in this way. You always are saying, well, it might be a small change, but we still have to go through all of these steps no matter how big or small we think it is. And so it doesn't let you skip any of the things in between. And and in terms of code review, one thing that I've heard recently is that, like, apparently, a large number of developers maybe, like, mostly review the tests when they're looking at a code change rather than, like, reviewing line by line every piece of the code. And that was, like, really surprising to me because I usually almost never look at the tests, and I always go line by line through the code. I think that that's something where at least understanding, like, well, if you're acting, you actually should have gone through line by line of the code and at least read every single line before you act. It's something that, like, maybe is like a a checklist type thing that would be, you know, an improvement. That that seems pretty obvious. Yeah. But I guess people don't do it. So I don't know. So, like, necessary but not sufficient checklist is? Yeah. I think I think that's something where, like, yeah, it's more annoying if anytime you wanna approve a pull request and you're saying it's an act Yeah. That you that you have, like, you know, like, 10 tick boxes that you have to do and it's, like, did you review every line of the code?
You know, and if you didn't, it's fine. You you know, but, you know, it's like it would just mean it would get more information of, like, have we actually satisfied,
[00:32:44] Unknown:
you know, the the preflight checklist. Yeah. Because there there's a there's a big space between, what we can do with static analysis. So for example, like, you know, for the CI system, that's basically a checklist. Right? It's an automated checklist, versus sort of there's a big spectrum between that and what you have to, you know, think about on, like, a design level when it comes to p p to p and stuff. Right? So, you know, you you could have, you know, things in the middle which are not yet automatable, but is somewhat, you know, just, you know, you can describe it, let's say, fully, and you can have a checklist without god, I I would love to have that for bash scripts and things that shell tech can't, can't can't catch and
[00:33:29] Unknown:
and modular dependencies and stuff, which are not, you know, enforceable. Yeah. For example, you know, when Jeremy was talking about the idea of backtesting, transaction broadcast based on historical blocks, I think that's a great check, and and you could probably write a functional test. Well, that's difficult because the, you know It's it's gonna take a few hours. Gonna take a few hours. So it's almost this this zone between, you know, functional test and, something that someone would do manually where, you know, you might have a simulation framework or something to to to check some of those things. So I think that's that could be a really valuable project for somebody looking to get involved with Bitcoin is to kind of focus on the testing regime between those 2. Sorry.
So talking about the development process and maybe some of the the difficulties associated with it, it, one of the ways that, you know, this this could be resolved, and, Luke, you know, I think the route that you've taken is that you have your own implementation of Bitcoin, a fork of Bitcoin called Bitcoin knots. And, you know, obviously, you can make the argument against that that, having, an implementation that's unilaterally controlled by a single person is risky, that, you know, having multiple implementations in the first place comes with some non obvious risks. But how would you make the case that that's actually sort of a good thing to be doing?
[00:34:45] Unknown:
So basically, get all the everything that would be a good idea to merge, probably safe as merging the Bitcoin nuts, whereas Bitcoin core believes it takes the more careful and extra careful review approach. And so the users have the option between do they want to have something that takes this extra careful approach, or do they just wanna have something that has all the latest and greatest and, hopefully, safe enough? Right. So it could function, I guess, as a good test bed maybe. Right. It can be used in a lot of ways. Potentially, it's testing and other.
[00:35:23] Unknown:
Great.
[00:35:26] Unknown:
Yeah. I would I would like to add on to that. So, the the project that I've been working on is called Lit Bitcoin Kernel, and it's, it's it's a project to extract sort of the consensus engine out of, Bitcoin Core. And one of the rationales or one of the problems that we're sort of trying to solve is that people have different and and as they as Gloria has mentioned, like, people have different expectations for how they want, you know, their mempool or their validation or or or or or or or or sorry. Mempool and sort of the the the rest of the code, like wallet or GUI, RPC and all of that to act.
And as Luke has said, perhaps they want to be more you know, experimental or have, you know, features that perhaps, can't get into Bitcoin Core. Right? So the options right now for experimenters like that are, you know, you either go through as I hope we painted a picture of, PR review being very stringent, let's say. You either go through with PR review and try to get it into Bitcoin Core, which is hard, but also is a, you know, a burden on maintainers. Right? This is not a piece of code that you write, and then that's that's it. We have to maintain it throughout time. So you either do that, you either fork Bitcoin Core, which is what LUKE does, and and and every release, you have to rebase. And perhaps, you know, Bitcoin Core structures it in a way that now makes it really hard for this critical feature that that you have. And I think Luke has run into that problem before.
And and and then the third way is just to sort of reimplement Bitcoin Core. Right? And and if you reimplement Bitcoin, then you are sure to get almost certain to get sort of, consensus incompatibilities, which, you know, as I just described before, consensus incompatibilities is what leads to, you know, unforeseen or unexpected bugs, which is, you know, sort of what keeps all of us up at night, I would I would say. And so having this sort of, extracting out sort of the part that defines consensus allows experimenters. And, you know, I I I think it speaks to the strength of our community that we have people who want to experiment, have people who want to implement features, have people who want to tweak parameters.
It sort of allows people to experiment with that and not have to worry about the, you know, consensus compatibility part, not have to sort of try to cram it into Bitcoin Core and make it a burden on everybody else, not have to, you know, do do do the forklift. So I I, you know, I I on a personal note, I'm I'm very, very happy that, you know, there are experimenters out there, and I think we should encourage them. So I think your project, the Bitcoin Kernel, is one of the most exciting,
[00:38:25] Unknown:
initiatives ongoing in Bitcoin Core now because you could really see the inner workings of consensus packaged up very nicely in a format that allows people to build a lot of the policy components or optional components of Bitcoin kind of in in the way that they like to without risking some some kind of major consensus fault. So with with that, under consideration, Carl, how do you see Bitcoin Core's scope kind of expanding or contracting over, say, the next 5 years? What do you think will ultimately be a part of the Bitcoin Core process?
[00:39:00] Unknown:
I and and this is just me speaking personally is is I I would hope that sort of the there is a the project is to basically delineate a clear boundary between what is consensus and what what is not. Right? And, you know, the the the big problem right now is that when we make a change, because everything is all tangled up into this, like, spaghetti monster mess, when we make a change, we don't know if it'll, you know, affect consensus. And and and sometimes, you know, to Jeremy's point, we probably need a checklist for this. Sometimes we introduce, like, a a block filter, and then it pick up as part of consensus. And you're like, okay. What? So I think be you know, delineating that boundary means that, it's a technical change, I think, to sort of a social problem where now we can have more eyes on the consensus critical part and, you know, and and the sort of outside realm can be swapped out, and and, you know, we we won't have to have, like I I mean, we we just have too many flags right now. I mean, we don't have to have, like, you know, a 100 flags just for, you know, all the all the all the use cases that people have. And that, I think, will be able to that will make the review process easier because people now know what is consensus critical and what is not. Right? And and it'll make,
[00:40:25] Unknown:
things a lot smoother in a social sense, I think. So, Andrew, you work a lot on the wallet. You're the wallet maintainer. You know, the wallet is one of those parts of Bitcoin that, is not consensus critical, but is still very crucial to using Bitcoin. And it's something where the design space is very open. So you obviously have a number of different wallet implementations. How do you see the repo evolving over, say, the next 5 years? What components do you think will be in there? What what won't be, maybe? So I think,
[00:40:55] Unknown:
eventually, what we want to have is to have the wallet be a separate repository, and it uses the interface exposed by lib Bitcoin kernel or whatever the the node part stuff remains. And we've we've actually observed this with the GUI kind of, where the where all the work on the GUI is actually occurring in a different repository where, you know, it has its own issues, has its own pull requests. And that just that also makes it easier to keep track of, what's going on and, makes it easier for people who care about the GUI to, work on it.
Same thing I expect to happen to the wallet and maybe some other components of Bitcoin Core as well. So as we we break it up a little bit so that, you know, people can focus on the things that they care about without, you know, having things get lost in a 100 PRs of of something completely different. And yeah. So I I expect that there will be, a a wallet repo in the future once we get, you know, a lib Bitcoin kernel or multiprocess, implemented.
[00:41:57] Unknown:
Do you mind if I try something? Absolutely. Yeah. How many people here run a Bitcoin node? Great. How many people here, use the Bitcoin GUI? K. How many people here use the Bitcoin Wallet? Bitcoin Core Wallet? K. Good number. How many people here run a transaction index? K. How what's another good optional thing? Block filter index? Yeah. Who runs a block filter index?
[00:42:23] Unknown:
Okay. Few people. Right? So all these Sorry. Does anyone configure their mempool differently from defaults?
[00:42:29] Unknown:
One one thing. You you you you all have to come talk to Gloria afterwards. We do not know anybody who does this, and it'd be really good to know what you're putting in. And we'll talk about, like, maybe why you really have introduced a vulnerability for yourself by doing so. So yeah. I'd like to repurpose the remainder of this panel to just call the audience about what features they actually Yeah. No. Well, so to bring it back to what what these guys are talking about and I think this too, is that we are shipping a lot of code onto your computers that you're not running, and we would like to give you the minimal possible thing that's going to do what you're actually using. Like, probably most of you said you're running a node which is, like, tremendous, but then all the other things were really a little bit more specialized and what would be really good is if we could have this thing that's just a node that you can run and then these other things you actually can get maybe a, more competition among service providers for that functionality which if we're all capitalists who here's a capitalist?
Okay. That that's good. Most of us. So if we're you know, we think maybe that will get us a better end result, you know, eventually. So I think that that's sort of maybe the motivation for some of this. Yeah. And I also think then you can ship more versions of the GUI and wallet,
[00:43:35] Unknown:
and not have to rely on Bitcoin core releases. Who here likes dark mode? Yeah. Maybe Yeah. Dark mode faster.
[00:43:43] Unknown:
Luke, you look like you wanted to jump in there and say something. Yeah. I just want to point out that I disagree with, Gloria and Jeremy in that that I think it would be ideal if every user decided their own policies for themselves. We have defaults, but they really shouldn't be used as some kind of consensus rules. Relying on them to be identical across the network is insecure and really should be considered a security risk in general.
[00:44:12] Unknown:
So I I think that there is, like, you know, the the difference, of what we're saying would be, like, imagine you have your, your wallet dot dot file and the setting that you choose is to make it readable by anybody on the network, you know, and and, like, like, that would be if you're, like, putting if you're selecting the folder for your wallet that that is like a shared open public file, like, that would be an insecure setting. Right? And then and then for consensus, there are things that are similar where if you, like, pick the really bad parameter, like, you know, or even for policy that our implementations just can't handle those parameters.
[00:44:43] Unknown:
To a large extent, do you avoid policy settings like that?
[00:44:47] Unknown:
Oh, I that's why it's configurable. Right? We have, like, startup options for you to change it. But, like, you know yeah. You're right. Feel free to use your config options, but we try to make the default as safe as possible.
[00:45:00] Unknown:
Like, right now, though, it's it's kinda hard to change your own options. You have to, you know, make the bitcoin.com file and know what, how to format the lines and put all the right options there. At least, you know, if you're using the GUI, there's almost no way to change any of, like, your relay options from within the GUI itself. So it's
[00:45:25] Unknown:
Like, why not? It does have several GUI options for that. Hopefully, it'll eventually get in the core. There's a few people
[00:45:31] Unknown:
There's some work there that
[00:45:33] Unknown:
no one has reviewed. None of them are using the GUI now.
[00:45:38] Unknown:
True. So with the remaining 3 minutes, I thought that maybe we could turn to ways that you guys think we might be able to grow the developer ecosystem at Bitcoin Core and just increase the health of of the project. So I'll just open it up to the group if there's anything in particular you think we could do.
[00:45:58] Unknown:
Yeah. I have a few ideas. If there's anyone in the audience that's interested in contributing to Bitcoin Core and maybe doing it full time in the future. There's this great thing called PR Review Club. It's bitcoincore.reviews. We do a weekly meeting where we pick a Bitcoin Core PR, and there's a host. It's not always me. There's a host that will come up with a list of notes as well as questions. So you kind of get an opinionated tour through this area of the code base and hopefully walk through some questions that start to build up your mental model of what adversarial thinking looks like when you're reviewing a PR in Bitcoin Core. And, you know, hopefully, as you've done you know, maybe you could do, like, 5 to 10 of these review clubs, you've gotten a good breadth of different areas of the code base, and you find one that you want to dig into very deep, and maybe you write a functional test that tests something that, very specific that we we don't have coverage for yet or a unit test or whatever it is.
And then you and then you look through the issues and you find there are many features and bugs in that particular area of the code base that we don't have enough people to to work on. Anyway, all I wanted to do was show prreviewclub, Bitcoin Core dot reviews.
[00:47:24] Unknown:
I guess I'll be annoying again and just say, who here, if there were not an obstacle to it, would like to be a Bitcoin core developer? Okay. You know, come find us and, like, tell us what the obstacle is that might be stopping you from doing that, and, like, we'll try and find a pathway to, like, making you, you know, do that thing.
[00:47:41] Unknown:
And for what it's worth, I think there's a lot of funding out there at this point. There's probably more funding out there than you think, and and it's it's just been so fantastic to see companies in Bitcoin step up and and provide those resources. So if you're kind of on the margin, if you wanna get involved, really do consider it getting into touch with any of us, and we can try and point you in the right directions. But, it's a really great time to be a Bitcoin developer. So, so so please consider it. And, I would just say you don't have to be smart. You just have to keep on trying. Absolutely. Persistence is totally underrated.
[00:48:15] Unknown:
We can always use more reviewers. Always use more You don't necessarily need to be able to code, but if you can read code reading code is very different from writing code. So
[00:48:24] Unknown:
more reviewers is great. I think, you know, it's worth mentioning. People don't often acknowledge that the the main bottleneck in Bitcoin Core is is getting suitable review because nobody wants to merge code that, hasn't been scrutinized, hasn't hasn't, you know, been analyzed by a lot of people working on the project. So get involved, and and there are a number of ways you can review. You can just download the code and run it and build it. You don't, you know, even necessarily have to, to try and understand the code if you're doing something to add to the process. So great. We're out of time. Well, we've got oh, yeah. We're okay. Now we're going up on the time. We're out of time. Number go up. Time go up. I wanna thank all of our wonderful panelists. I wanna thank you guys for for coming to this. I hope it was, enjoyable.
Thank
[00:49:13] Unknown:
you. Right. The glider? Yep.
[00:49:35] Unknown:
Alright. Let's go ahead and get started. So my name's d plus plus and the topic for today's panel is decentralized exchanges or DEX for short. Now I'm thrilled to be here on stage at Bitcoin Miami 2022. Specifically, I'm thrilled to be on the best stage, the open source stage.
[00:50:06] Unknown:
Yeah.
[00:50:09] Unknown:
This is the real Bitcoin stage. Just very quickly about me, I'm a Bitcoin educator. My aim is to bring simple education to the next 1,000,000,000 folks. I have I have a background in computer engineering. I've worked as an entrepreneur and a coding professor before I devoted my life to Bitcoin maximalism and Bitcoin education. Now before we dive into the questions on today's topic, I'd love it if our lovely panelists could quickly introduce themselves.
[00:50:43] Unknown:
Hi. I'm Chris Stewart. I'm the founder of a company called Shirdbits, and I'm here for spicy takes.
[00:50:47] Unknown:
Hey. I'm Joseph Tietex, zerozef on Twitter, and I'm a analyst and economist at Trezor.
[00:50:54] Unknown:
Hey. I'm Liz. I work on mempoolspace, Bisq, Bitcoin TV, and a bunch of other projects. It's great to be here. Hey there. Daniel Buckner. I work at TBD at Block, on decentralized identity protocols.
[00:51:07] Unknown:
Awesome. So speaking of block and TV decks, Daniel, this question is for you. I've gone through the white paper. I I really think Satoshi was onto something with this whole 6 page white paper thing. Can we make that a standard, just generally? That'd be great. But that said, can you explain like I'm 5? Distill it into something that, maybe explain like I'm 4. What is tbdex? Can you walk me through it? Yeah. Absolutely. So it's a decentralized value exchange protocol, a generalized protocol,
[00:51:40] Unknown:
where you can really exchange any things of value between participants who can locate each other using, a protocol based on distributed systems and decentralized identity. The first type of value exchange we're focused on is fiat on and off ramps and being able to get, you know, people to exchange Bitcoin, you know, for dollars or whatever the local currency is. The interesting thing about the exchange itself is that it it gives the ability to transfer reputation and trust. So in in a way that's standards based. So we use centralized identifiers, verifiable credentials. Doesn't mean that participants have to require reputation and trust if they don't want to. It's completely optional. But if they do require something, they they can totally do so. So, you know, if it's a bank, they probably will require some sort of credential.
If it's not, if it's like a peers, they they might not. They might just require peer reputation. An interesting thing about the protocol is that it's actually useful even beyond the stage of fiat. So imagine we're in a hyper Bitcoinized world, and you wanna buy a car with Bitcoin. Well, it turns out that this value exchange protocol, can cover that use case in the sense that you might be able to locate and find, know, all the cars available out there. And then you wanna know that the car, you know, that you're buying is backed by you know, it's it's via pink slip. Right? It's valid, and the person has money in their account. Right? So these are things that you can exchange as reputational proofs, in the process. And the last thing I'll note is that the protocol is built on a generalized decentralized app platform. So this is kind of the first app we're building on top of it, and we'll have more news about that platform, in the coming
[00:53:15] Unknown:
months. Okay. Let me say it back to you. Yeah. So TV decks is a messaging protocol Mhmm. That I can use to discover people, or financial institutions. So if I'm using it to discover other people, could it be used in a peer to peer sort of local Bitcoin
[00:53:35] Unknown:
type of way? Absolutely. Yeah. So the the protocol the use of decentralized identifiers in the protocol enables you to find any participants in whatever type of value exchange you wanna do, whether it's currency or just any other type of good, and then be able to communicate with them privately, securely, and encrypted, exchange reputational proofs, and sort of come to agreement about, you know, selling and buying of of any type of goods.
[00:53:59] Unknown:
Okay. So I can discover other people. So let's say, Alice and Bob Mhmm. Our friends, Alice and Bob meet by way of the TB DEX protocol, so they can transact Bitcoin, of course. What other types of things can Alice and Bob do now that they've found each other? It's so romantic. This question is for Chris. What else could they do now?
[00:54:27] Unknown:
Yeah. And once they've they've found each other, they they can build things like discrete log contracts. But what I what I'd have to say to the audience is, what I think Bitcoiners get right is, they're really focused on censorship resistant money. And I think we all in this room agree that that's kind of one of the core principles of Bitcoin. You can spend your Bitcoin how you want to. What I think Bitcoiners get wrong is, they stop at censorship resistant money and don't advocate for censorship resistant financial markets. What my understanding of TBD is and Bisc, which Wiz works on, is that's what they're providing is censorship resistant financial markets where people can trade different things.
Bitcoiners sometimes get up in arms about what's being traded on these censorship resistant financial markets because it's a token they don't like or it's economic activity that they aren't fans of. But, you know, if something's censorship resistant, you can't pick and choose, what you like and what you don't like. It's a platform either everybody can use for everything or nobody can use because it's gonna get coerced and co opted by a government or a large corporation.
[00:55:33] Unknown:
Okay. So then on that topic of censorship resistance, I feel like we're all gonna have something to say on this and it's important to everyone here. But, Wiz, how does censorship resistance play into BISC?
[00:55:46] Unknown:
Yeah. That's a good question. Bisc is basically a decentralized exchange platform, which means that it's a peer to peer network running over Tor where everyone running the disk node software on their computer connects to each other and exchanges the order books. And this allows users to make offers or take offers and, connect to each other. And because there is no, centralized servers anywhere, it just, you know, achieves censorship resistance by being decentralized in nature. There's no, Bisc Office or Bisc Company to shut down. It's more of a trade protocol.
[00:56:25] Unknown:
Okay. So can it be stopped? Can it be shut down?
[00:56:30] Unknown:
I guess if Tor had some issues, which has happened in the past, sure. I mean, Bisc is, also governed by a a DAO to manage the parameters of the network like, what the trading fees are and like this and, other, limits or payment methods. These are all controlled by the DAO, which has a, kind of like a, unique governance structure. Basically, they have their own, shitcoin token where they do the voting. And, they DAO stakeholders can vote to change certain parameters, but the DAO stakeholders are not known. And so because of their, relative anonymity and the decentralized nature, it's not easily
[00:57:16] Unknown:
censorable. Okay. Do you think the shitcoin token is really necessary?
[00:57:22] Unknown:
No. Personally, I don't. I don't I don't use it. I I'm a Bitcoiner, you know, and and you don't need to use their shit coin to use this. You could just pay the trade fees in in good old sats and works great. It's only if you really wanna participate in the governance of the network, which is mostly just the contributors anyway at the end of the day.
[00:57:42] Unknown:
So I'm curious for the audience. How many of you are customers of Bisk? How many of you are passionate about peer to peer Bitcoin exchange generally? How many of you find local Bitcoiners in your area and exchange cash for Bitcoin? And how many of you earn Bitcoin, get paid in Bitcoin, which is one of the best ways of getting KYC free Bitcoin? So p speaking of KYC, Wiz, I'm sure you're gonna have a hot take on this as well. You know, there is illicit activity happening on bitcoin and the illicit activity is KYC. Know your customer.
Is KYC gonna be necessary on decentralized exchanges?
[00:58:27] Unknown:
No. If it's, peer to peer exchange, then, the only two people who need to know about each other are the the two counterparties of the transaction, because it's it's purely decentralized in nature and there is no regulator, enforcing any rules. It's purely peer to peer. So, it's kinda like Craigslist if you post an ad to sell your sofa and someone buys it. The only 2 people who know about the details of that transaction are the buyer and the seller, and that's exactly how it works on DISC. The only person you send your, bank details, for example, would be to the other guy, and it's not in either of those parties' interest to snitch on each other.
So, it achieves a very nice level of privacy and, also censorship resistance this way.
[00:59:10] Unknown:
Can Yeah. I just wanna chime in here because I think it's, like, a really important point, what Wiz is bringing up here is, like, you can start with something that's, censorship resistant and doesn't have AML KYC at the base layer, and you can always add it on top if that's a feature that is required. And I think that's an acceptable trade off. But if you bake in, like, all these, like, regulations at the base layer, you can never have something that's no AML KYC on top of that. So getting these, like, levels of the stack engineered correctly are really important, and that's, like, kind of one of the core innovations of Bitcoin, in my opinion, is we have this censorship resistant money, this strictly a proto computer protocol, and we can build, you know, financial institutions on top of it. You know, many financial institutions have been super successful built on top of Bitcoin, but we can't go, the opposite way. So when thinking about designing these things, it's super important to get the base level right without, you know, these these things baked in. And if you wanna add them on top, go for it. That's my 2 stats on that.
[01:00:11] Unknown:
Alright. Why don't we back up? We've talked about tbdex, but why don't we start with why? Why decentralized exchanges? Why does this matter? And why should we care? Yosef, I'd love to hear from you.
[01:00:25] Unknown:
Yeah. So, decentralized exchanges for me are important for three reasons. First is, you are actually forced to self custody our Bitcoin from the start because, these exchanges never hold your keys for you. And unfortunately, the default setting for centralized exchanges is they are the custodians, and people tend to not withdraw their points. So that's the first one, self custody. The second one is you actually get to use Bitcoin as a protocol because on centralized exchanges, you usually just buy some kind of weird financial derivative that's maybe, settable in, like, physical Bitcoin if you withdraw, but most people don't withdraw from these exchanges.
So they don't actually get to use Bitcoin, whereas at this, you use, multisig. You are confronted with, like handling your private keys and with minor fees and stuff. And the third one is the privacy aspect. There is no KYC. Only the party knows some of your details, but there is no reason to snitch us with that. And, yeah, KYC is this whole, like like we said, that's the early security. That's the thing because it stays with you. And once you KIC yourself, it's hard to get rid of because these exchanges employ, like the chain analytic companies and privacy in Bitcoin is hard. And if you, like, dox yourself at the start, it's very hard to, correct that.
[01:02:01] Unknown:
Yeah. That's a great topic actually of privacy in general. I'm I'm curious for Wiz. What kind of privacy information would I be concerned about, say, leaking to my counterparty if I'm exchanging peer to peer on this?
[01:02:14] Unknown:
Yeah. That's a good question. Really depends on the payment method. The most private might be, meeting in person at the Starbucks and just handing cash to someone. There's also, US Postal money order. You can like physically mail a money order to someone for like $1,000, and, the post office website allows you to verify that the money order serial number and the amount everything was cashed or not cashed. So you can, you know, verify without going through the banking system, but also be able to send the money. Of course, if you use a payment method like a bank transfer, then you'll need to send your bank account details to the counterparty, but it's not really in the other guys interest to save those or docs you for any reason. So, there's different trade offs with different payment methods.
Some of them are faster or slower, some of them are more expensive or cheaper, some of them are more private or less private. And it also depends on the country. If you're, you know, in Japan, for example, you can actually do anonymous bank transfers. If you're in the US, the postal money order is excellent, but every country has their own localized payment method, so it really depends on your threat model, I guess.
[01:03:32] Unknown:
So cash in the mail, cash in person.
[01:03:35] Unknown:
I mean, I don't own any Bitcoin, but if I did, a lot of people in the crowd do, though. It's, you know, if I did, I would use the, the US postal money order system on disk. It's, it's pretty cool because it's basically how people sent money to each other before banks were, what they are today And, because the post office has this really cool website where you can verify everything, you know, no one can claim that you didn't send them the money or everything. Like, it just shows what post office it was cashed at and everything. So it's really, well built for, Bisc users in the United States.
[01:04:10] Unknown:
I noticed that strike is one option. What kind of privacy would I be expected to leak, say, if I were to use strike to pay on Bisk?
[01:04:20] Unknown:
I guess strike is is a newer payment option. I haven't I don't have a strike account, so I've never used it. But if, if that's true then I would assume it works like any other, payment method. I mean, obviously, Stripe, you need to connect your bank account, but the counterparty counterparty wouldn't be able to see that.
[01:04:41] Unknown:
Right. I I believe they receive fiat on the other side of that trade. So that's a great, I think, payment method that now exists on bisque. I've got, like, a 1000 questions for Daniel, and I think we're probably not gonna have enough time. We'll probably have to talk later. But I'm curious to hear more about TB decks. My understanding is that TB DEX cannot exist without some kind of verifiable credential, some kind of system of trust. Right? And the reason for that is because Bitcoin, of course, is trustless, but the fiat system is not.
And, when you're exchanging with another person, there is some level of trust that's going to be required. Now, my understanding is that tbdex is predicated upon decentralized identity or DID for short. And again, if you could explain like I'm 5 or preferably explain like I'm 4, what is DID, and how is it used by DEX?
[01:05:40] Unknown:
Yeah. So DID is, the standard that has, you know, gone through international standardization at W3C. We're using it. A lot of other companies are. It allows you to create identifiers that are wholly yours that you can rotate keys under and you can prove. So unlike an email address, you actually own your identifier, and can have the full route ability to, like, be to send messages to someone. You can have multiple identifiers so and we encourage that. It's not like one identifier and you keep using it everywhere to correlate yourself. Like, you wanna retain privacy.
And then the other big component is verifiable credentials, which is sort of like a data signing standard, basically, for proofs. And it could be proofs of anything. Right? You can prove a diploma or whatever. In this case, you might prove KYC details or reputational proofs if it's like peer to peer and you don't need like a KYC component. It's just modeling it with a standard. So whatever your form of reputation or proof is, we're trying to use these these standardized forms for it. That's really interesting because in Bisc there is no identity system. There is no reputation system.
[01:06:41] Unknown:
The Bisc DAO basically guarantees the trades if you were to get scammed or something, which, because the security deposit system is financially disincentivized. So, in Bisc, there is no identity system because we want privacy, we want anonymity. You know, you could create, you know, create a new Bisc account for every trade and or you you could use the same one. There is no, identity.
[01:07:06] Unknown:
Yeah. I think there's a misnomer, right, with identity. People you you hear the word identity people get really scared. Right? Identity just means an identifier you use. It could be a single use identifier, like a burner. Right? You can make a DID in a second. Has no reputation, you're just using it to do the messaging exchange, and that's kinda how how we work it. And so identity, you have an identity, but you may have many facets of your identity. You may have millions of identifiers, right? Every website you use a new one. So so we believe in exactly the same thing. It's just a standardized means of doing of locating, people if you needed to in a recurring fashion. The other thing is we wanna make on and off ramping to existing financial institutions easier only because it's the world we live in today. Like, I'm I'm a big you know, I've been in Bitcoin for 10 years. Like, I, you know, want that as much as anyone. But the reality on the ground is that we need to get more people into Bitcoins. We have to bring the world with us and that's part of the reason why we added these features that are totally optional so that those institutions can start helping by participating in the system, and increasing the number of people who have Bitcoin.
[01:08:12] Unknown:
Yeah. So so my question is, would, DBD, be compatible with stuff like FIDO2? Like, there's this open standard for online identification. It's very fast identification online. Yeah. And Tresor is, like, supports that. So I could prove my identity, like, like, credentials, not my real identity, but I'm the same person like the last time they've signed in some kind of cryptographic message.
[01:08:42] Unknown:
Yeah. So I actually I worked on some FIDO stuff while I was at Microsoft. You know, I was on the identity security team. FIDO is is great standard. We're we were looking at towards the end of my tenure there doing extensions so that your DIDs are backed by keys you own, can go through that same existing standard. FIDO, right now, the way it's designed, it sort of assumes that you're using a single key, just a non robable key, and the PKI source is like a centralized entity. So you have, like, a key with a website and you have to go register it with them. So it's kind of not designed to be decentralized. You can extend it though. I also we did extend OpenID Connect so that it uses DIDs instead of centralized accounts. So there's there's ways that we can uplift these things into more decentralized forms. Yeah. Yeah. And I wanted to ask if I may, like,
[01:09:30] Unknown:
BISK sort of uses reputation because there's the account age. Is that right? And number of trades, I believe, and do you tend to choose, like, these accounts first? It depends on the payment method. Right? So,
[01:09:40] Unknown:
I think in the US, there's a payment method called Zelle, which is, I guess the common way to quickly send money between banks in the US. And because there is a very, small amount of chargeback risk, it's not 0, they implemented a small limit for new accounts and once you trade a few times, that with other counterparties who were signed, then they'll sign your account to build this, kind of like decentralized level of trust. They're not signing your identity so much as they are your the hash of your payment accounts. So, I guess, yeah, you could consider that payment accounts and identity.
[01:10:19] Unknown:
Mhmm. But, yeah, I would call that a pseudo anonymous identity. Right? Sure. Yeah. You're gonna have any identifier you have in the world. It's if it's a point of reference, really. When we talk about identifiers like email or even, you know, your at name on Twitter, it's a point of reference. So someone is able to accrue reputation or or use it in any way, it forms an identity. Now, let's not confuse, like, personal identity, like, you as a person with that identity. Identity just means, like, I could be a dog on the Internet, but I'm this hash of this dog. Right? So, yeah, I I think it's a scary word, but it's kind of it's a little overblown. And Yeah. Like, piggybacking off that, like, I think maybe,
[01:10:53] Unknown:
one of the ways you can think about identity is simply a public key. Right? A public key is an identity. And on a Lightning Network, for instance, you know, our identity is our public key with an IP address, and that's how how you connect. And the question I have for you is, how, you know, to make this a little bit more concrete, would you say that, you know, if DIDs should be included in the lightning spec to be that form of identity? Or how would, DIDs compare and contrast to the current form of identity on the Lightning Network which is the public key and IP address?
[01:11:26] Unknown:
Yeah. So I I do I think it would be great if if Lightning did embrace the DID spec. This spec is not actually prescriptive in terms of how you would implement a decentralized identity network. Like, when I was at Microsoft in Outblock working with Ion, which is like a layer 2 on Bitcoin to do DIDs, it's mostly a data model. So it's like Okay. Every type of DID method, right, you could create one for Ion, spits out the same PKI document so that everyone can like, you know, in a standard way can find the keys and routing endpoints. Like how much data?
[01:11:54] Unknown:
Not much. It's not personal identity. Like, the DIDs themselves don't have any It's like a pervy 3 byte public key is what we have on Lightning today. I'm guessing it's more than that. We're talking kilobytes, megabytes.
[01:12:04] Unknown:
Oh, oh, less, you know, maybe 2 kilobytes at max. It's just public keys and routing references. It could be decentralized your eyes to, like, how I message you. Right? You look up an ID or just, like, need that. It's like, the equivalent would be like DNS. Right? You look up a zone file? Sure. Right? It's that. You don't put your website in zone file. Right? So, it's really important because I think it gives efficient lookups and and locational finding that could be even better potentially than some of the construction lightning that are required because they're doing path finding Yeah. Like, liquidity and stuff. Okay. It kinda feels like, the more modern way to do, decentralized web of trust. Like, back in the day, we would have,
[01:12:40] Unknown:
key signing parties where we would meet in person and sign each other's PGP key. But now, it seems like maybe there's also gonna be the entry of corporations that will basically KYC people and sign their key for them. So, you'll have at wiz at Twitter for example or maybe some block or square. You could be wizsquare and that's kyseed. But if you're at wiz at bisque or something you know maybe it's not kyc,
[01:13:11] Unknown:
and depending on who signed what keys you might wanna trade with this person based on those things. Right? Yeah. That's exactly what verifiable credentials are. So, like, let's say in one context of your life use a given identifier and you accrue reputational trust. Like, I get a degree from an institution or something like that. Those are all verifiable credentials. Right? Like LinkedIn may soon accept these and say, oh, I can verify that this institution that has a DID signed this proof, and it is you who's in with zero knowledge proving that you actually are the the holder of the keys that back it. So absolutely. Yeah. So my understanding is that we're doing
[01:13:46] Unknown:
a 0 knowledge proof without the need for ZKP cryptography.
[01:13:50] Unknown:
Oh, no. I mean, so some of the controls definitely will use ZKP stuff like, I worked on a smart construction with, MSR colleagues, when I was at Microsoft that we are looking to implement in the community that's, yes, it's, you know, it's motor snark. Right? And it is a zero knowledge credential that you could say, like, let's say a credential of, like, 10 things you can prove in it. You could do selective disclosure where you only want to disclose a few of them. You could do predicates where you say, I'm just over this age, like, you know, range proof stuff like that. And those can be more advanced constructions of credentials.
[01:14:21] Unknown:
Well, like I said, Daniel, I'm gonna have a thousand more questions for you after. So I hope you have some time later this week. And I wanna say thank you so much to all of the panelists. Unfortunately, that's all the time we have for today. I'm very excited for the future of the redecentralization of the web, which will hopefully be using some of these exciting technologies that we discussed today and which definitely will not be some kind of web 3, VC backed, shitcoin, dino, decentralized in name only block chain. It's going to be the real decentralized web and it's going to use Bitcoin and Bitcoin only. Yeah. Absolutely.
[01:15:10] Unknown:
They weren't joking. They really are.
[01:15:15] Unknown:
Should've brought this on. Okay. How's it going, guys? So just a quick shout out to the guys doing the, workshops at the back. It it is a little bit noisy. So if you wanna, have conversations, please, go on the outside because, you are you you really are gonna wanna you you really are gonna wanna hear what these these incredible people have to say today. I think you can come back in at 3 o'clock and use the tables to to do your your workshops and your and your hacky stuff after. So, just a just a note on that. So, yeah, welcome, everyone. Thank you for for joining us today. So we're gonna be talking about improving and 10xing the the Bitcoin development experience. I've got some amazing panelists with me today.
So my name's Connor. I work at Spiral. We're focused on improving, the Bitcoin open source ecosystem, via a number of different initiatives, some of which we'll kinda go into detail today. So we'll start by just, getting to know our our panelists a little bit today. So, Steve, if you wanna start. Sure. Yeah. So I'm Steve Myers, and I'm a contributor
[01:16:21] Unknown:
contributor on the Bitcoin DevKit project. And my work is sponsored by Spiral, as are a bunch of other developers on our project. So, and, yeah, we'll talk about what BDK is in a bit.
[01:16:32] Unknown:
Hey. I'm, Steven Delorme. I hang out in the Bitcoin design community. I've I guess, I spend a lot of my time contributing to the Bitcoin design guide, and other open source design related projects in Bitcoin.
[01:16:47] Unknown:
Hey. I'm Matt Corallo. I work on the lightning dev kit project, sponsored by Spiral as well, or I guess work for Spiral. So our goal being to, allow people to build custom lightning nodes and lightning integrations, super easy, and we take all the hard work out of that.
[01:17:07] Unknown:
Okay. Okay. Awesome. Just an just another note. Again, if you if you wanna have a conversation, please please leave the room, and, you can come back in around 3 o'clock to to use to do the workshop and stuff. But so we're, again so we're gonna talk about, like, improving the the Bitcoin development experience. But before we talk about some of the projects that are aimed at doing that, let's talk about, what the experience has been like over the past couple of years in trying to build
[01:17:32] Unknown:
Bitcoin wallets and other types of applications. Maybe, Steve, if you wanna if you wanna start. Sure. So the the way I came to the BDK project was that I wanted I had a solo project I was working on. I wanted to do something on mobile with a Bitcoin on chain, multisig, and there's just not a lot of great options. You know, like, there were some stuff in Java, but it doesn't work on iOS. And then, of course, a lot of them didn't have the latest modern features that you would want in a in a Bitcoin wallet. Teamed up with Avakos Fellini, and he's got you know, there's this great library that uses another library set of projects called Rust Bitcoin, which provide, you know, all the primitives you need, and then, you know, put put together with another Rust Bitcoin project for mini scripts so you get descriptor support and, you know, of course SegWid and all, you know, talking to different, Bitcoin back ends.
It just, you know, basically gives you all the features. So then one of the things I focus on is making that available on mobile. So, you know, with Kotlin and Swift, so you can just, you know, as a developer, you just can pick up this library now and, and build a Bitcoin wallet for desktop
[01:18:37] Unknown:
or mobile. Okay. Awesome. And so some of some of these libraries that existed over the last cup couple of years, I'm assuming they haven't been as well maintained,
[01:18:47] Unknown:
and it Yes. Requires, like, developers to operate at a very, like, low level when they're trying to, integrate Bitcoin and Lightning. Is that is that true? Yeah. I mean, it's kind of a the other thing about having a library like BDK and LDK is that it it it's got sort of the best the best practices built in, implemented in a way that a lot of people have looked at. And, you know, you can you know, you don't have to necessarily be a a bits and bytes Bitcoin developer. Okay. You can understand the API and, you know, and just use it with a whole community kind of supporting you behind it. Okay. Awesome. And, Matt, you've been around in Bitcoin development for some time. Like, how how do you kind of see,
[01:19:24] Unknown:
how Bitcoin development has kind of
[01:19:27] Unknown:
us Yeah. Historically. Yeah. So, I mean, I I came at this from from I worked on Bitcoin Core for many, many years, and and have now kind of moved over to the lightning space. You know, historically, when I when I started working on Bitcoin many 11 years ago or something, there weren't any funding for Bitcoin Core developers. There weren't even any full time Bitcoin Core developers. Now that, you know, obviously, can always use more resources probably. But that's kind of a solved problem. There's a ton of people working on Bitcoin Core. Bitcoin Core has a lot of really smart people working on it. There's room to grow. But everything further up the stack doesn't. Right? And so BDK has been really awesome.
Steve talked about all these, like, libraries that have been kind of one offs that people have thrown out in various languages, and they're not well maintained, and they're not really all that usable. And so having a common base for on chain stuff is awesome. But we looked at it as the spiral team, and we also concluded there needs to be something like this for lightning, too, right? Is that lightning is even more complicated than the on chain stuff. There's even more to get right. There's even more to do. And we've seen several kind of mobile lightning wallets. We've seen several lightning wallets come around. And it's a full time job for a team of 3 or 4 people to not only build a lightning implementation, but actually keep up with all of the changes happening in lightning and everything going on in lightning.
And so our goal is to abstract that out, right? And make it so that you don't need a team of 4 full time engineers to build a great Bitcoin wallet, where there's frankly some work to be done. There's some good wallets out there that need to grow, need to add lightning support, need a little better UX here or there, need a little better design help for the design community folks. And we want to see a lot more, especially things like Bitcoin Beach Wallet, things like where there's a localized community that has some local features they might need, or or where, you know, integration with some local services makes more sense, and really enable people to build good user experiences around bitcoin that, you know, it's just currently you have to be a great low level engineer to do that. And finding a great low level engineer who is also good at building UX and good design is not I mean, basically it doesn't exist, right?
And so trying to abstract away that low level stuff so that we can do all that work for you, and then you can focus on how do you build a great user experience.
[01:22:04] Unknown:
Okay. Okay. Amazing. Amazing. And so it's yeah. Random floor. It's like, it's this idea of, like, allowing people who operate at different levels in a in a stack to really specialize in specific areas. So, like, you say, if you're a protocol engineer, you can operate and build the tools that make it easy for application developers to build front ends and and who work with more UI and UX focused people, it can really hone in in those areas. So, we've kind of identified that the developer experience is something that is is pivotal to 10x in the the Bitcoin development, experience.
Steve Myers and and Matt Crowder, you're working on some projects to to do that one being the BDK and the LDK. So do you wanna explain to the people what what the BDK actually is? Right. So, BDK stands for Bitcoin DevKit, the name inspired by LDK, which had,
[01:22:57] Unknown:
the similar name. And the idea that we're focused is on building descriptor based wallets. So these are on chain wallets and you basically get all the modern features. You know you have, like I said, so descriptors are a way of defining the, the spending conditions for wallet, but it's, you know, it it provides you a way to create those scripts in a way that's portable between different wallet implementations, as well as well reviewed and audited. Like, you can easily look at a descriptor and figure out what it does for some more complicated spending conditions. As Matt was saying, you know, people might wanna build applications for specific, you know, specific communities, but it could also be like you're a company and you wanna build something in house that uses Bitcoin. You can now you know, you don't need to have a bunch of bitcoin protocol engineers in house. You can take this library. It's gonna be reviewed by, you know, the Bitcoin community. You can contribute back to it if you have no features.
We had one one person that was contributing back to our project, and, he had a use where he wanted to do proof of reserves. So he could easily, within his company, create a proof of reserve library using BDK and then, you know, release it both open source. And now any company that has that need can can use these 2 libraries together. This is, like, an example of somebody that, you know, didn't have to start from scratch. And, it's it's a really important thing too that a lot of things are changing on LDK, but things are still changing on BDK too. You know, Taproot is coming out. You know, it's gonna be it's gonna be difficult for somebody to, you know, implement a Taproot wallet from scratch. But you start with BDK, and BDK is gonna be supporting Taproot. Now you can just immediately get that feature in whatever application you're building. So that's part of the power. Fantastic. And on on the LDK side?
[01:24:35] Unknown:
Yeah. I mean, so basically the same thing. Right? But but on the lightning side, right? So the lightning protocol, like I mentioned, is it's complicated. And it's really hard to get right. And it's really important to get right. You get it wrong, you're you or your customers lose money, and that's not a great user experience. So so we try to, you know, do something similar where we we do all of the lightning state machine. We do all of the the logic around how you how you route payments and how you, how you even forward payments if you're running a non kind of mobile node, and and do all of that stuff.
And then we expose it as kind of the individual building blocks, and they all work well together, and it's easy to hook them up together. Or you can separate them out, and you can say I'm gonna run the routing part on a server, and I'm gonna, query that from the client, and then I'm gonna do my backups by doing live updates against, you know, Icloud or or whatever you wanna do. You know, we give just neat little interfaces for all of the different pieces that aren't kind of corded lightning, but, like, how do you store your data? How do you, where do you get your private keys from? How do you sync the chain?
All these kinds of things that you could have many different ways you wanna do it. We provide just interfaces for that, and you have to go kinda hook it up to the right places, but you don't have to do all of the kind of hard work of building a lightning state machine. And so we we do that in Rust as well, and then have, like BDK language bindings in a number of different languages and more continuing to come so the developers can focus on how they wanna build a Bitcoin application and how they wanna have the UX work. And we can just kind of make it easy to to hook it up and then have lightning suddenly running.
[01:26:19] Unknown:
Okay. Amazing. And you have developers working across various different stacks whether it be on desktop or mobile on embedded devices whatever it might be also working in different programming languages as well. So how do you approach trying to accommodate for all of those different types of users?
[01:26:40] Unknown:
Yeah. I mean, that's a good point that it's one thing to have a nice, well reviewed, you know, feature rich Bitcoin and lightning stack, but then it's a whole another thing to support that ecosystem around it for mobile. So you have to have, you know, you have to support Android. You have to support iOS. And in those environments, you wanna support those languages. So you need to support Kotlin or Java on Android and you wanna support Swift. You know that's sort of like just you know the you know that's sort of the, you know the price of admission is you just need to support that. And to do that as well as supporting the core library gives you that just kind of, you know, easy pick it up off the shelf and you can start building your app, whatever environment you want.
Which is hard for, you know, hard
[01:27:22] Unknown:
it's it's it's it's a just sort of building that ecosystem just opens it up for everybody. Cool. And I think like the technical term it kind of uses like language bindings and like Matt what would be some of the challenges around
[01:27:35] Unknown:
language environments and supporting, like, these various environments? Yeah. I would say, you know, supporting different environments and thinking hard about different deployment scenarios is, like, 60% of the work we do. The other 40 is actually doing lightning stuff. Yeah. I mean, we built a language bindings framework from scratch. We sat down and said, like, all of these existing lang you know, we have a rich object oriented interface with different classes and different interfaces that you have to plug into and and use and we want to support that in different languages. Turns out there are no language bindings frameworks to support this. It just doesn't exist. You know, all the all the existing language bindings frameworks are are for people who are saying, like, well, I've got my my app and it's written in in Java or Swift or whatever, and then this this one function is too slow, and I have an implementation in c I wanna call, and it's like one function and it's a pure function and it doesn't doesn't have all of these interdependencies or whatever.
And there's a ton of frameworks for that and they're really great. And then you want to have, well, I have these classes. And I want it to feel like a native interface where you're instantiating these classes that are secretly written in Rust, but they're actually, you know, exposed to you in Java or Swift. And then you have interfaces that you want to write an implementation of in Java that the Rust code is actually calling all the way into. Yeah, it turns out that didn't exist. So we had to we spent about 2 years of engineering time a little more, actually building that from scratch.
And, yeah. It was an insane amount of work, but it ended up working really well. And so, you know, Cash App shipped with with LDK powering their lightning node, And they didn't write a single line of Rust. They didn't look at a single line of Rust. They wrote it all in Java, or I guess they wrote it all in Kotlin. But so that turned out to be a good investment. It worked incredibly well at the end of the day. But but that ends up being almost all of our work is is a combination of that And also just thinking about how do we design an interface that is hard to misuse? How do we design an interface that's either gonna, like, immediately spontaneously combust and the application won't even run, or it works right and you can't lose money, and the payments go through reliably, and it all works. Right? So trying to design interfaces is hard, hard form, right?
And so that ends up being the other half of our work is just how do we make sure that this interface is gonna be robust and users are gonna know how to use this correctly just by looking at it,
[01:30:10] Unknown:
and and it they they can't screw it up. Right? Yeah. Actually, LDK also provides great documentation, you know, API documentation as well as examples. That's the other thing BDK also tries to provide is examples, documentation, which is another big piece of work. It's not you know, you can't take it for granted that every library would have that. Yeah. Awesome. Okay. So Steven, we've not heard from you just yet, but you come from a slightly different perspective,
[01:30:36] Unknown:
being a designer. So do you wanna talk to us a little bit about, the Bitcoin design community? What that is, what that f is, what type of things are involved on on that side of things, and then we'll we'll dive into a bit of how we tie the fact that we have these awesome SDKs and with the the UI expertise that come from that community as well. Yeah. So the Bitcoin design community is, just kind of a
[01:31:03] Unknown:
decentralized community of designers and creatives, who are interested in, working on open source, Bitcoin. You know, I guess the the kind of central thesis of would be thesis of it would be that, you know, Bitcoin is the best money, so it should have the best user experience. And, you know, I think a lot of people would agree that it's, you know, it's currently lacking. A lot of people find Bitcoin difficult to use. There's a lot of uncertainty for people about how to self cut to do their own Bitcoin. So, kind of the flagship product of the design community is this project called the Bitcoin design guide. And the Bitcoin design guide is you can think of it kind of as, like, human interface guidelines for bitcoin products. If you're building a non custodial bitcoin product, You can turn to this guy to look for principles and techniques that you can employ to build a better experience for your users. And it might be good to differentiate a little bit. Like, you you said the word UI. Like, you know, it's also, I think, important to differentiate between, like, UI, like, just the the thing that the user sees on screen, like, the the the specific color of the button or the font choice. Right? That that I consider to be more UI. But, like, UX, I consider to be a little bit broader than that. Like, we're we're trying to think about, like, the whole experience the user has to go through.
You know, is the application you're building, let's just say it's a wallet, for example. Do when they turn it on for the first time, do they know what they're supposed to do when they receive their first Bitcoin? Is there a backup facilitated? How is the user still using it a year down the road? Are they still using it a 5 years down the road? And is the way that they're using it changing? So these are kind of, like, all, you know, things that I would consider kind of under the umbrella of user experience. And I guess kind of, like, similar to LDK or, like, BDK and LDK is that, if you think about, like, why should every single developer have to repeat the same work over and over again? Like, let's find what works. Like, let's, you know, build our our good, you know, lightning state machine and just put that into a toolkit, and everybody can use that.
You know, similar with design, like, we don't need, everybody to come up with a new design solution every time. Like, if some other wallet or Bitcoin service has come up with a good design solution that makes it really easy to use for people, why don't we document that in an open source way? And then other projects can take, you know, take advantage of that.
[01:33:38] Unknown:
Amazing. And, just to to touch on a few things around, like, the design guide and, kind of documenting patterns that work regardless of, you know, what what wallet you're trying to build or what Bitcoin application you're trying to build. Do you wanna talk maybe about a concrete example and one that was, you know, announced earlier by by Myles and the Cash App team that the BIP 21 URIs and, like, how that's an example of developers and designers who, you know, developers who have created the standard and getting some some some aid, I guess, from from the UX side to kind of tie it together as, like, a concrete example? Yeah. Yeah. That that's a good one. So for if, if anyone didn't see the Cash App talk this morning, you know, Miles announced
[01:34:25] Unknown:
a lot of cool features. But, yeah, one one of them in particular was this plan to kind of move to a new type of QR code or using an existing type of QR code, but differently. And this, you know, there's been this, you know, big conversation about it in the Bitcoin design community and, other open source Bitcoin communities, about this. You know? Like, just as a real world example, I think, you know, many of us witnessed this last year in El Salvador, just the difference in payment formats. You know? For example, you go into, you know, like, a little bodega or pupuseria, and you wanna order something, and, you know, you ask to pay in Bitcoin, and, you know, there's usually some kind of toggle that they have to switch between an on chain, address QR code or a bolt 11 invoice QR code or proprietary Chivo QR code. So you know? And there's just not a lot of education. People aren't sure what what what to do in in these situations. And you think about QR code. It's kind of like an ugly human unreadable thing. Like, you can't look at a QR code and just, like, know what's inside of it unless it tells you. So that was a big problem, and, you know, there's been many people have tried to come up with solutions for that, like, Galois, Bitcoin Beach. They had kind of a solution that they were experimenting, But, I'm not sure exactly where the idea originated from. I first, I think, heard it from, you know, Pavlinx and, you know, John Zohari and Steve Lee, some combination of those 3. But basically, this idea of, you know, just taking a a BIP 21, which is this, it's this payment URI format. It's been around for about 10 years. I think you weren't you involved in I think I might have written the original spec. Yeah. I think I saw your name on the paper.
But, you know, it's basically this idea we can use as an existing spec. We can put, an optional parameter in there, put a lightning invoice in there. And I think the spec was very forward looking. Like, it it you know, you were kinda predicting that people would wanna use it in different ways, and we don't know how we're gonna wanna use it in 10 years. Well, this is an example of that. So we're now able to use this existing, open source standard. And, you know, in the Bitcoin design community, we started experimenting with it. We built a website. We started documenting, which wallets could support the standard and which, don't.
And we started reaching out to projects. And this is just an example of, like, you know, designers can get involved in open source, and you can go on GitHub, and you can open an issue with a project and make a bug report or a feature request or suggestions for UI improvements. And so we've gotten pretty positive feedback. It's an ongoing discussion, but we've gotten very positive feedback. And even Cash App was able to get involved and have discussions with the Bitcoin Design Community about about this project. So, it's really cool thing if you think about, like, if you have the best UI, the slickest UI, the best UX in the world for your wallet, if every other Bitcoin wallet out there has has is hard to use, it hurts you too. Like, we're kind of all in this together when it comes to Bitcoin UX.
So, you know, Cash App, I thought it was really great that they, they got involved with the design community, got involved in these discussions. And, now we've basically seen in a very short period of time, designers and developers, collaborating together to, you know, improve improve the UX.
[01:37:53] Unknown:
Yeah. And I don't want to zone in on that last little thing you said there around, developers and designers coming together. Like, sometimes we term like bridging bridging the gap between designers and developers now that we have these development tools and and a design guide Why why why is it important to to kind of bridge that gap? Is it the fact that now we can get more experimentation happening quicker? Is it the fact that, like, those tools just naturally, bring bring those 2 users together? Like, what would you say about about that side of things?
[01:38:28] Unknown:
Yeah. I mean, in terms of, you know, bridging the gap, I'd say, you know, I think this is, like, a running problem in in, you know, software engineering and product development. This idea that, like, if you're if you're trying to build something and, you you spend, you know, 6 months planning it out and then, 3 months building it and then, you know, 2 months testing it. And then eventually, by the time it it gets to market, it's like you, you know, the the competitors beat you or users, you know, customers' demands have changed. So I think, like, what we've witnessed over, you know, the the past several decades is just that, you know, development cycles for products are are getting a lot. You know? I hate to use this word, but I guess you'd say it's becoming more agile. Like, we're figuring out how to, we're figuring out how to, like, ship features quicker. And so an important part of that is, like, you don't want a situation where, like, the designer is, you know, building this perfect, you know, layout, and then I pass it over to the developer. And then, you know, the the developer, you know, kinda has their own interpretation of it. And then, you know, by the time it hits the market, it's you know, something's been lost in translation.
I think, like, on the open source side, what's what I've witnessed, just in the design community is that, like, some of the most successful Bitcoin open source projects are one where the designers and the developers work very closely together, and they have, like, kind of a constant feedback loop. So, like, if you come in and you say, you ask the designer, like, can you solve this problem for me? What's the answer to my question? And then take it and run with it. You know, here's the thing. This isn't like a perfect science. Like, you know, like, there's not, like, one just answer to UI because it's gonna depend on, like, where you are in the world, what kind of customer you're trying to serve, you know, what your the needs of your community are. And so there's not just like, you know, this isn't like, you know, physics or something where we can like, you know, absolutely define something down to a molecule. So the ongoing, collaboration between the designer and developer, I think is so that, you know, you can test stuff, see what works, and just very quickly find what works for the product or for the customer that you're trying to serve.
[01:40:33] Unknown:
Okay. Fantastic. And, so just to recap a little bit, we have the BDK, which is helping with on chain Bitcoin functionality, exposing all these high level APIs. Similarly, on the LDK side, if you wanna integrate instant lightning payments into into any wallet or application. What what types of what types of applications and and are we seeing being built with, like, BDK, and then we'll go into LDK in a second. So yeah. Yeah.
[01:41:05] Unknown:
Yeah. So I, so right now, you know, we primarily have sort of example applications. We we did I mentioned there was a a bank looking to use you know, looking at BDK for some proof of reserve stuff. Kind of our big focus now is just getting more, you know, more of the mobile stuff built out to support more mobile applications. And, you know, that's part of, you know, what I'm doing here and the rest of the BDK team is doing is just finding open source developers or finding closed source developers. Anybody who wants to build something using on chain Bitcoin and, you know, getting to know them and getting to solve their problems with BDK.
You know, I don't think we have any big, like, commercial programs yet using BDK, but the goal is we we hope to soon yeah. We're certainly that's our that's our goal is to make that happen. Yeah.
[01:41:52] Unknown:
Yeah. Okay. Yeah. And on the ldk side, we've been around for a little longer than the bdk side. And so we have so Cash App was our first user to go live in a big way. It was actually the the second user to start integrating overtorments back here somewhere, from blue wallet, suffered through a lot of the pain of of some of our very early alpha language bindings, projects. And so they have they're they're more in flight as well. Obviously, you know, building for mobile is is just a little harder in almost every way, not only on the language bindings end, but but also especially on the lightning end. There's just so many more things you wanna get right to have a really great user experience, especially as a as a non custodial end user application. And so cache app beat them to the punch. It's a little easier to build a custom Lightning node that is just custodial than the non custodial.
But but it highlights the the very different uses for LDK and projects like this, where Cash App is a large corporate. They have a ton of back end infrastructure that existed already for all of their existing. Obviously, Cash App does a whole lot more than Bitcoin. And they really wanted a lightning node that tightly integrated with all of that infrastructure. Right? So using their own logging infrastructure, their own database infrastructure, their own node failover and hosting infrastructure, all of the stuff that they already had, that they wanted their lightning node to really integrate well with that. And just taking something like CLightning or LND, which which are great, but in running it off the shelf, it doesn't provide them that. Right? And so they wanted to build something super custom. And they were able to, in in a number of months, put together a a full lightning node from scratch that, used LDK to do all of the kind of lightning parts, but then integrated and worked in exactly the way they wanted lightning node to work for them.
On the on the other side, you know, blue wallet, just completely different scenario. But again, where it's they already had an on chain, non custodial wallet. They already synced the blockchain. They already had key derivation. They already have had a backup system. You know, they already had all of these pieces and they didn't wanna, you know, take something like lnd and try to make it run on mobile, and then, sync the chain twice, and have 2 separate key derivation systems, and have so, you know, they wanted a lightning node that worked with their existing infrastructure and actually integrated into the app, and not something that just was completely fresh from scratch, or was from scratch kind of for them. And so there again, you know, this LDK where it's really just building blocks. You know, we provide a bunch of different building blocks and some sample implementations, and you can take the pieces you want and hook them up in the way you want and end up with a lightning node that works in exactly the way you want. So being able to build super tailored systems for exactly what you need
[01:44:48] Unknown:
is really kind of the, I would say, the value of everyone standing on this stage is is helping people build exactly what they need. Yes. It's it's interesting because although, like, sometimes we talk about, like, LDK having the sweet spot of like non custodial mobile where there are like constraints on memory storage, background tasking, all of these kind of things. We are seeing something like Sensei which is a, I guess, a lightning of implementation based off of LDK as well, which we hope might be in the in the Umbral app store soon and, you know, might be instances where, although, out of the box, it's not really designed to be like an out of the box node experience. Like you have the tools to to make a custom node yourself right? So that's really cool. And on on the on the Bitcoin design side, although you talk about the the user experience and and getting developers to work with designers to to build, you know, customer facing stuff like wallets and other types of applications, What other things do we see from the Bitcoin design community around art and narrative and and all of these kind of things?
[01:45:55] Unknown:
Yeah. So, I mean, there's there's a lot a lot of different projects, you know, in the design community other than just the design guide. You know, around art, I'd say, yeah, I mean, there's a whole channel in our, our Slack workspace where people post, like, art they're working on and stuff, which is really cool. You know, we've gotten involved with other you know, there's a lot of, just kind of, I guess, like, collaborations, you'd say, you know, we're which is basically somebody's doing a project on Bitcoin. They come to us, and, you know, they might need some help with something. And, you know, we'll put together a call and people in the community who might wanna help this project, can jump in and help out. And so, you know, like, on the the narrative side, you know, there was this Hello Bitcoin project that you were involved with, and, you know, it's kind of a video series that kinda teaches people the fundamentals of Bitcoin and why it's valuable. And several people in the community got involved with that and started working on the animation for that. And, also, just, like, with, like, wallet projects and stuff, I mean, there's currently a collaboration with JoinMarket.
I think, there's some people there's a team working on trying to redesign the UI for Bitcoin core, like the wallet, portion of it. There is, there's the Zeus a while, which has been a incredible, incredibly good collaboration. There's, you know, also just some some, kind of other flagship products. Next to the design guy would be, like, the UI kit and, the Bitcoin icons kit, like, Kristoff, Ono, and Bosch. Like, those are basically kind of toolkits you can use. So, you can, take the icons kit and install it as a viewer react module and just instantly have icons for your your Bitcoin product.
You can use the the UI kit. It's a Figma prototype. You know, so you can basically rip screens from that and incorporate them into your project. It's kind of like why why reinvent the wheel? Not to limit your creativity in any way, but it's a good starting point so you don't have to rebuild, everything from scratch. So there's really just a ton of of projects going on in the community. Sometimes new initiatives just kind of spring up out of nowhere without any central authority with school.
[01:48:01] Unknown:
Yeah. Awesome. And then just trying trying to tie things back to, know, 10x in the development experience. What what advice would you give people who want to get involved in a space, whether it be contributing directly to BDK, LDK, and the design community or taking these tools and and building applications themselves. Like, any any advice
[01:48:23] Unknown:
for for these people? I'd say one thing that I know that from the design side, I used to work in enterprise software, and Okay. We basically never built anything until we had UX and UI, primarily UX, actually. Because, you know, that's like you wanna developers sometimes aren't great talking to users. In UX, that's part of what they do to bridge the gap is they're basically collecting that user feedback about, you know, what does user wanna do? How do they wanna use it? You know, maybe they don't know what they want. And maybe what they want isn't actually what they want, what they think they want. So that, like, that's obviously part of it part of it. But on the BDK side or on the on chain side, just being able to take a library that's well reviewed, has examples, allows you to kind of bootstrap whatever project you have.
And then I think it's also you know, from the co in the closed source world, you might have all these companies replicating the exact same software. Mhmm. And that's pretty inefficient. You know, with open source and, you know, projects like LDK and BDK, you have all these people that wanna do the same thing, all these smart people that can just get together, combine forces, trade ideas back and forth, people all over the world. You're gonna get a a cross section of developers that you could never, as a company, afford to buy. Like, they're not for sale, most of them. So, you you get that for free, and it's it's quite amazing. You know? It's it's, you know, it's a resource that you can only get in an open source project. You're not gonna get that on a closed source project.
[01:49:41] Unknown:
So How about on the design side if you wanna if you wanna get involved? Yeah. So on the design side, I mean, just from a, you know, a purely tactical perspective, you go on to Bitcoin dot design, our website, go to the contribute page, and follow what it says there. You can join our Slack channel. You can add our calendar, to, like, your Google or Apple calendar and all of that. But just to dig into that a little bit more, I mean, you know, we we do calls, you know, talking about specific projects or issues, and it's all pretty open. So, I mean, I would really encourage you to just lurk. You know, once you get on a call and you, you know, you can just hang out, you don't have to ask questions or be involved if you don't want to. And you can just kinda see how an open source community functions, and then jump in and contribute, when you feel comfortable. And I'll just say that, like, I really encourage you to do it, especially, like, especially if you're, like, starting out your career and you're thinking of doing an unpaid internship.
I'd say don't do that. And I would say contribute to an open source project instead, because, you know, like Steve said, you're gonna meet, like, people all around the world with different ideas. You're gonna you're just, you you know, kinda connected to this hive mind of ideas. And and, also, like, the open source contributions you make, people are gonna see them. So it's not gonna be, like, some proprietary thing that's hidden, and you have to kinda, like, hype yourself up. Like, people can see when you're doing your work in the open, exactly what you're contributing. And those open source contributions, I think, will follow you from one job to the next.
[01:51:09] Unknown:
Cool. Yeah. Definitely. And and to maybe to to summarize a little bit, like, you know, there's a lot, a lot, a lot of focus in this space of, like, oh, I wanna contribute to, like, the lowest levels of the protocol. And and that's awesome. You know? Those those spaces need as much contribute contribution as they can get, as many eyes on it as they can get. But they also have, over the last few years, started getting a lot of eyes on it, a lot of contributors, a lot of a lot of great people working on those projects. And further up the stack, you see a lot of these awesome wallets that people have started building and that people use every day. And the real touch points for users on Bitcoin non custodial have teams of 2, or 3, or 4 people.
Right? And these projects, they often don't even have a UX or a designer. Or they have some contribution from the design community and work or are turning to that increasingly. And they don't have the resources to build out a lot of really awesome UX that they might want to build because they're too focused on some of these lower level things. And so there's there's a lot more room to contribute to some of these projects further up the stack, and and make a much bigger impact on how people actually use and experience Bitcoin, because these are the real touch points. You know, people actually are using an app to to receive their Bitcoin, and they're not they're not using Bitcoin Core on a regular basis.
And so I think there's a lot of room to contribute to these communities, certainly, especially the design community and going out and actually working with some of these wallets. And then there's also just a lot of room to to build great user experiences using Bitcoin. You know, there's only probably a handful of wallets that that people strongly recommend that have great UX. And, you know, go build another one. You know? Go go build something that's that's unique and and has some other user experience that that you think might win yet more people over to Bitcoin and give them really the the experience that they want. And there's there's a lot of room in the space for that kind of contribution.
[01:53:17] Unknown:
Awesome. And then just a kind of final closing thoughts from the from the 3 of you. What are you kind of most exact excited to see in in Bitcoin development this year? And, then just tell people where they can, like, find your projects again, the projects that you're working on again. So maybe, Steve, do you wanna start? Sure. Well, I mean, as a an on chain library, I think Taproot's probably the most exciting thing right now just
[01:53:41] Unknown:
from what you're gonna be able to do with it and being able to support that in an open source, you know, easy to accept sort of way. Yeah. If you wanna go to bitcoin devkit.org, that's our website. You can get links there to the the GitHub repository and also our Discord community. If you have questions or have ideas for an app or you wanna contribute to the project, you know, you can chat with us there. We're we're around the we're we're around the globe, so there's always somebody around online there. Awesome. And, Steven? Yeah. I'm,
[01:54:07] Unknown:
you know, one kind of thing. I mean, obviously, I'm excited about the unified QR code. Another thing I'm kind of excited is just, like, stabilized lightning channels. I mean, obviously, Bitcoin's the best money and it's what you want your savings in. But one thing I've just kinda seen, you know, like, with adoption in developing nations is that, like, you know, there's obviously this need for, like, having a little bit that's stabilized, you know, for your weekly expenses. And I think the Overton window has kind of shifted around that conversation, and we've seen this, like, kind of explosion of ideas over the past, like, 2 months here of just different ways of accomplishing that. So I'm really curious to see how, you know, what what the engineers decide is the right approach, but, you know, after the the whole kind of rough consensus process. But I'm also curious to see what the design around that, how how we solve those design problems.
But, yeah, you can, like I said, you can follow what we're working on in Bitcoin design just by going to Bitcoin.design on the web.
[01:55:01] Unknown:
Perfect. I'm about to finish this off. Yeah. Oh, man. There's so many things going on in lightning. All of the things. So, yeah, on on the l e k side, let's see. We're we're working on bolt 12 integration. So so improving, the the way people pay in lightning to add, to to address a number of shortcomings in the user experience and a number of different ways people expect to pay, especially things like static invoices. So that's huge. Shipping, 0Conf, and other features that are kind of needed for a first class good mobile user experience and what people expect from existing lightning wallets, That's gonna be huge.
And and just helping people start building a lot more lightning walls and a lot better UX and helping people not have to spend 4 developers, 3 developers full time just to maintain stuff and actually enabling people to really start experimenting more with lightning, start building more stuff, start, extending more stuff, and and, you know, getting stuff getting to the point where we can start, you know, having people build good, dollar denominated lightning channels, on on a mobile app. You know, that's that's gonna be awesome, but, man, we've got a lot of work to do to get there. And and, yeah, you see, you can go to the lightning devkit.org, if you wanna check it out. And we have a Slack and a Discord community because, I don't know, we like we like making sure we're available to anyone who has questions.
So you can you can join one of those. There's always someone around to answer questions. And and, you know, like like all these great folks, we try to be pretty hands on and pretty available to to answer any questions and to help you figure out what's going on and how best to to build what you wanna build. Hey, Yousef. We got a lot of work to do. Back to work? Yeah. Back to work. Thank you for listening.
[01:56:53] Unknown:
Oh my god. Why is it so bright?
[01:56:56] Unknown:
I feel kind of far away from you guys, but,
[01:56:58] Unknown:
yeah. We can all move in on this. You you you wanna go on the couch? It's sure. Yeah. It's gonna be a little awkward. Actually, it's better if we stay in order for them, I think. Alright. Alright. Yeah. Sure. We're all good. I I hope we're we don't Yeah. Cut the camera people. Sorry. I think they framed the shot with that. That last chair on mine. So
[01:57:15] Unknown:
welcome everybody. My name is Ben. I'm host of the BTC Sessions on YouTube. I guess I'll I'll just let you guys introduce yourselves. We'll start with Paul. Sure. My name is Paul Storitz.
[01:57:27] Unknown:
We're gonna be talking about soft forks today, so I have a soft fork proposal, BIP 300. I've also written a lot about soft forks in the past, so I guess that's my intro. Awesome, Jimmy. I'm a bitcoin
[01:57:40] Unknown:
expert I guess or educator or something. I I do a lot of stuff in bitcoin. I write lots books and, yeah, I'm up here mostly to look pretty, I think.
[01:57:50] Unknown:
Hey. I'm Jeremy Rubin. I'm a Bitcoin core rabble rouser, and, I also have a software proposal that I've been doing called BIP 119, and happy to be here to talk about it with Zelle. Awesome.
[01:58:03] Unknown:
Welcome, guys. Let's give him a round of applause for being here. And, so I I wanna start this talk out, by making it accessible to to, you know, some people that may not be super familiar. So we'll just set a few baseline things, then we'll get into the weeds after that. So, I'll open it up to anybody here, but let's just break down really, really quickly, briefly,
[01:58:28] Unknown:
the difference between a hard and soft fork for whoever wants to take what I just teed up. I will do it because a fork is a very serious thing. It is really how the protocol changes from one protocol to a different protocol which can cause people a little bit of consternation because they worry about oh am I gonna lose the old things I really like about the old protocol and And that is the difference between the hard and soft fork, which is that the hard fork is an absolute permanent split where the you've formed 2 networks and it's you you break up and you are never getting back together and then with the soft fork there's this theoretical compatibility where all all the these different sub these different protocols, are nonetheless interoperable with each other. So you can stay this idea of it being compatible and opt in, which is a nuanced point, but the idea of the the old node, you can stay there. You can stay with the old protocol, and that is why that's what makes it soft. And I could talk more about that if you want, but I'm sure you can. I would say that it's
[01:59:28] Unknown:
soft forks are backwards compatible. Yeah. Hard forks are not backwards compatible. And you, and the idea of a fork is that you have 2 blockchains or 2 ledgers that have some difference. And that is terrible for any sort of consensus mechanism because they're not in consensus. And that that's what we wanna avoid generally and soft work or hard work. That's, unless you are permanently
[01:59:56] Unknown:
wanting to split like Bigchain cache. And and what precedent does that set for, the, rather, for the user, like, in terms of a soft fork versus a hard fork? If you're a user, you're perhaps running a a Bitcoin node, for instance. What responsibilities
[02:00:11] Unknown:
do you or don't you have in a soft fork versus a hard fork? What do you have to do? So so I'll jump in there and just kind of with a more contrarian take right off of this and tell people what their responsibilities actually are. But, ultimately, like, they're not really so different. Like, both of them can result to a bad thing happening to your Bitcoin. And so from that perspective, they're the same. And I think, ultimately, what it comes down to is how do you participate. And the choice of the soft work is really something that allows people who are just kinda disinterested in what's happening with development to, and and disinterested in upgrading or whatever to just, like, continue to be a part of the network.
The downside of that is is that, like, changes can happen to the Bitcoin network even if you're not participating. So in some senses, soft forks are maybe bad because how do you oppose something that can happen if you're just not even aware that it's happening? And then hard forks, on the other hand, it's like, well, if you don't want it to happen and the rest of the network does it, now you're off the network permanently and that's, like, not really great. But on the other hand, for a hard fork, you have to have, like, much more overwhelming consensus to make it happen. So each of them have trade offs and ultimately, like, the end negative outcome is the same which is that, like, a bad thing could happen to you, but we get to choose the trade offs. And right now in the community, the dominant choice is that people prefer seemingly Softworks, but that is a preference. It's not like a mathematical proof that one is superior to the other. Let's let's go a bit deeper into this. So one point. Yeah. So what what precedent does it set,
[02:01:40] Unknown:
given that that Bitcoin leans heavily? The the community has leaned heavily towards keeping things backwards compatible versus protocols that have gone off and basically have regular hard forks. What do we lose by normalizing regular hard forks versus what has been preserved with Bitcoin? Well, the main main
[02:02:01] Unknown:
problem with hard forks is that you're forcing essentially everybody to upgrade. And if you if they don't upgrade, then they're no longer part of the consensus. And that who's doing the forcing? If if if you're being forced by some central entity then you're clearly centralized because whoever made that hard fork is demanding it of you. This is how Ethereum works. They demand you to upgrade. If you're if you don't the software that they tell you to run, then then you're part of that consensus. In which case, it's not really consensus as much as it is somebody from authority telling you what you have to run-in order to be compatible with the rest of the network. So hard forks for me are centralized. And it's an indication of centralization, at least the way they've been used. So for for coins to go do that it reveals their centralized single point of failure. Whereas, you know, with a software, what you what you have is this ability to be backwards compatible. You're not forcing anybody anything on anybody.
Hard works, like, almost all rules are up for grabs, including, you know, the supply limit and stuff like that, which I find an anathema. Like, part part of what you have that's very valuable about Bitcoin is that you know certain things aren't going to change because of the way,
[02:03:30] Unknown:
because it's, backwards compatible, and it enforces the rules that you all know, including 21,000,000. Right? Like, that's Yeah. Sacred. But, of course, he just said that, but but Jeremy just said that soft and hard forks really aren't that different. So I'd like to maybe and you're saying they're very, very different, of course. And, I agree with a lot of what you're saying, but we have to now maybe unpack this for the audience because this is where the rubber meets the road so to speak because this as I said the fork is a very serious matter of changing the protocol and it was thought that first of all the soft fork is clearly it's not only backwards but forwards compatible all the nodes share the same network And it used to be thought that because they were all compatible you can just stay where you were and therefore the opt in property came from the the compatibility property.
But it was later, the couple there were a couple sort of chinks in the armor of that, argument where Peter Todd proposed the evil fork idea where you can change lots of things with the soft fork, and then Segwit actually increased the block size with a soft fork which was sort of a very it was something that everyone had to experience. There's the there's another case actually that I think is a very good example which is the s value signature case where that is something that's very very soft and the very old definition of the soft fork was that if you got miners on your side anytime there the 2 different blocks were mine following incompatible rules since the miners always went with 1 everyone would end up going along That was the old old definition of the software. So this s value situation is where so an example of something where it was 100% soft, but it was 0% opt in. You a a normal layperson had no choice but to upgrade the software. They could not send money. Yeah. I need to, like, break that down. Like Yes. A similar thing to this would be, like, if we decided PUSH was bad and then just said no more spending PUSH addresses.
[02:05:33] Unknown:
Like, that would be a soft fork, possibly, and that would be confiscatory, and that would steal people's money, and that would be bad. And I think overall, it's one of these things where for, hard forks, I think it's like there there is a propensity to to shove it down people's throat, but it's more of a cultural value for what type of activity we want to do. And softworks generally align more with things we want to be more often, But you could do either on either, an example of this would be we could use all the same BIP 9 version bits. We can talk about what those are and, speedy trial and, you know, we'd have a delayed activation that would be, like, 2 years in the future for a hard fork. And that would probably be pretty good, in terms of not being something where we just, like, the devs decided there's a hard fork happening. And but it still would be that old nodes at that 2 year mark would fall off.
There have been proposals previously. Like, somebody said, you know, Bitcoin Core should I think Luke junior made this point. Bitcoin Core should just, like, have a fixed number of block headers that can consume by default, and so it shuts off in 10 years. So all nodes just have a shelf life, and now every hard fork is a soft fork based on if you're running Bitcoin Core because we could deploy it, and then the node automatically shuts off after some fixed deadline. It's like, well, I don't love that, but, like, yeah, you can kinda map I don't love that. I one on the other. But I know my love. Ultimately, the I think the thing that, you know, to to wrap it up in the coherent point is, hard or soft, like, you know, feature or whatever, what what matters is that we do these things in a way that involves, mass participation and
[02:07:07] Unknown:
consent of the I I don't wanna say the word governed, but that's the phrase, you know, consent of the ungoverned. Oh, it's a good answer. I I would say that you can do evil things with a soft fork. I think that's the point that you're making. Of course, you can do that. You can eliminate segwit. You can eliminate all all kinds of things by saying these are no longer allowed on the network. I I don't think we're denying that. The the real question, I think, in in your sort of equivalence of hard fork and soft fork is that, okay, is it possible to have sort of like a benevolent hard fork? I suppose in some metaphysical way, it can be somewhat benevolent.
But I I I think what we're saying is, with soft works, at least the ones that Bitcoin has done, it it's generally benevolent soft works, not the evil soft within the space of softworks that I think, you know, benevolent or good things for the network are. Because it once you change sort of, like, permanent rules or anything like that, that that opens up a whole, like, can of worms that I don't think we wanna go down. So for for me, like, softworks are very important to, like, stay within that area of softworks and not and, you know, obviously avoid the evil softworks. But, you know, go go with this, sort of subset that's actually benevolent.
[02:08:29] Unknown:
Let's let's go back historically, in terms of Paul, when I was speaking to you over email prior to this, you you you made reference to it's a question of of is it worth it in the instance of of a hard fork. And and then we saw historically, like, for 2017 when when, there's this push to go from 1 megabyte to 2 megabytes. I mean, the the resounding answer from a a lot of individuals was no. We don't we don't wanna set the precedent of changing for for small incremental, increases in in block size like that. But we Bitcoin has hard fork before, so I'm wondering if somebody wants to maybe touch on It has. When it was.
[02:09:12] Unknown:
I'm not sure that it ever intentionally has because the only 2 that I'm it's like kinda like 1 and a half. Mhmm. One was when Satoshi added the OpNops in 2010 or something, and he's the creator. So he sort of you know, it's like creators right or whatever. It, like, doesn't really make it's not really a very relevant consideration, right, since he created in the first place. And then there was the other one was after the, the summer 2015 database lock situation. I'm not exactly sure what to call that, but there was something where a database configuration rule had become a consensus rule without anyone knowing, and then it had been changed. And so it is possible to sync old nodes, but you have to do this extra step, and so that sort of makes it a hard fork. And I don't know, like, no one has ever, like, intentionally done a hard fork, like, through the whole peer review slow Yeah. Process.
[02:10:07] Unknown:
Yeah. Well, debate depending on how you interpret the whole Maybe I just drank too much last night, but, I don't think either of those are hard forks. I actually can't think of any that that because a soft fork is, like, sort of, you know, increasing the rules and, like, making it stricter.
[02:10:25] Unknown:
And I don't think either Oh, Soft Fork is shrinking the rules.
[02:10:29] Unknown:
Yeah. Soft fork is shrink you know, what it's it's increasing the number of rules shrinking the set of things that are valid. Yes. But I I actually can't think of it maybe, you know, again, the drinking thing. Okay. No. The opt addition of the opt I can't think of any that were actually a hard fork even, like, remove because then you're talking about removing, like, opcat and stuff like that? No. I'm sorry. Those he added the op nops, 0 through That's it. 20. They didn't exist. And he added them for the specific purpose of later using them as soft forks.
[02:10:56] Unknown:
Who that is. Yeah. So he added, like so, like, what lay what later became up, check template verify or whatever. Oh, not excuse me. Now now you've got to get confused. I'm talking about check check lock time verify. That was added by Satoshi as a blank thing that was like a blank check. So when he added all the blank checks, it was hard. But then when we repurposed them individually,
[02:11:18] Unknown:
that was soft. But it doesn't make any difference because it was so long ago. Yeah. And I think also just in terms of, like, this this notion of, like, time ago, I think there's something, you know, to be said for, like, if you were considering a change and we knew 2 ways of accomplishing the identical goal in terms of the effect on the system, except one had a lot more technical debt in how you might do it. One of the things that bothers me sometimes about a software process is if you go through too much extra work to do the thing, you're actually signing up the rest of the future of humanity to, like, maintain technical debt forever. I'm like, it actually might not be the like, we might be able to swallow a small amount of governance now for saving, like, a bunch of complexity and potential risk in the future. Well, let's go down that road. In in what instances would you see a hard fork as as not an absolute no, like, for each of you? What what what I agree with Jimmy that the the you don't want to do see, the the way it kind of
[02:12:12] Unknown:
played out was, for a while, I thought or I guess people agreed with me also thought that the soft fork sort of protects us from arbitrary tyranny by the development process or something else because you can stay on your old node and then move to the new node if you want or stay. But then now these things have been just these ways of discover that equivocate the hard and soft work is sort of modern things that are make it so that they're they're very similar in terms of what you can do. And so, yeah, the way I see it, we lose some of the protection. And then what I my BIP, BIP 300, is really about ending all soft and hard forks and putting them into to some extent, so that the protocol can do an unlimited number of hard and soft forks without actually without actually changing at all. So the protocol can have a fixed amount of code. You don't need to do any pull requests or write anything else. And I kind of feel that we should move towards the direction of not,
[02:13:12] Unknown:
changing layer 1 Bitcoin code at all. I'll give you a really concrete one where I think it's okay, which is if we did a soft fork that turned out to be constabulary for a user who can demonstrate that, you know, that what they were doing, their funds got stuck, I would advocate for a hard fork to remove that rule and allow the user to get their funds out because it was the the software community stole money from this person. Like, to me, that's a bad thing, and they probably should have been more vocal in that process. But if we have to patch in a hard fork to say, we will allow this transaction to proceed to restore this person's funds, I I think that that would, at least from my perspective, like, I don't love the governance around it. That would be in the shape of the right thing to do. Well, that that would be interesting because you're kind of assuming that an evil software could go through and that you have to reverse Not not evil. So for example, if I wrote a smart contract that was, like, in early as a Bitcoin using opt cat to do something and then cat got soft worked out Mhmm. Which it did. And then I demonstrated, hey. Look. Like, imagine, like, you know, I don't know, how Finney comes back and he's like, hey, you know, by the way, like when and he was still, you know, around at this point, but he's like, by the way, when you did this, I couldn't advocate for myself, but I got unfrozen. And, like, and now I can't get to my coins because you thought and and we talk about doing these things all the time.
There's this thing called and I don't wanna pick on anyone in particular, but, like, the great consensus cleanup to clean up some of these really, like, edge condition things that we don't think anybody actually uses. But if somebody relied on that, I would wanna honor the Reliance interest. So but to to push back against that,
[02:14:39] Unknown:
isn't that setting the same kind of precedent that was set with the Dow?
[02:14:43] Unknown:
Yeah. I I I I kind of agree with what you're saying here because I I I don't think you wanna hard fork for any of that stuff. If if, The time to speak up is at the soft fork, hey, you're gonna confiscate some of my money.
[02:14:57] Unknown:
If you don't do that at that point, now it's like, oh, you know what? By the way, I have this thing So I gotcha. Didn't we just say the whole point of the soft work was that if you don't wanna be a part of whatever these people are doing, you can ignore what's going on?
[02:15:10] Unknown:
Yes. But you were saying that before, but that's also the the the feature of it that's now, like,
[02:15:16] Unknown:
that, sort of fading away. It doesn't it's not present. Well, I I didn't I didn't point that. I said it's backwards compatible. Well, I get the I think part of the point of the soft fork is that, like, a user who and these aren't things that aren't, like, necessarily, like, evil. It's just like things that we do that have an unanticipated consequence. But, like, if you are a, you know, relying on this thing and you're not paying attention to what's happening, like, this is a big deal for us developers is that we don't want to make it feel like the community has to pay attention to what we're doing. We actually would prefer, not for, like, reasons of, like, hiding stuff, but we'd prefer if we operated in a way that most of Bitcoin doesn't have to care if we're doing something to tinker with it. But if that does happen, like, I I just don't, you know, like like, I I would see if I were involved in such a thing, I feel a personal responsibility to work on restoring funds. Maybe if it's a small amount of money, you just pay it out as, like, a, okay. Sure. We'll make you whole. But I I do think that it's that it's, like, sort of a like, it it ruins part of the promise of softwares if somebody can come forward later and be like, you did something that's incompatible with what I was doing, and now my funds are frozen.
[02:16:14] Unknown:
You know, I think I can reply to that by answering your question about what kind of hard fork actually would work in practice, maybe, because it doesn't make any difference what I think might I might like or whatever. But, I think you'd really have to get buy in from the most important group in Bitcoin, which is the Bitcoin investor. And they are probably not technical, which is means that they the status quo will have an enormous amount of leverage, for lack of a better word. And, they you also need to make it seem as though this is in their best interest, which probably would it would be almost impossible if you were saying, like, well, some people lost their money somehow, and we need to get it back. I would imagine it would make a lot of people nervous. And so I'm not I share your suspicion that that would that type of a hard fork to reassign funds to people would be very would be viewed with a It would be very
[02:17:05] Unknown:
skeptical. And also, like, we're we're presume we're doing, like, a presumption on top of a presumption that there's a soft fork that somehow confiscates someone's funds because it was used in this very weird way. An example would be like before SegWit, somebody used the, you know, particular form and, it's okay. Now now you can't redeem it because, you know, Segway rules make it so that you can't you you can't redeem that. Like, that's a very specific like, you you almost have to be pathological to have done that. And it's and we try to sort of, like, make sure that doesn't happen. And it's it's like such a corner case to me that I I I don't see this as, like, a thing that would realistically happen. There there is something,
[02:17:52] Unknown:
where, like, in Bitcoin, we have something called, like, the, like, sequence field. Mhmm. And usually well, let me jump up for a sec. Usually, when we have one of these things like a SegWit version, we try to reserve it and make it so it's really hard to send to the network. So we're kind of communicating very clearly like, hey. You shouldn't rely on using this thing because it's for an upgrade. If you use it, like, we can't guarantee what will happen. So it's kind of undefined behavior. In programmers, we all love undefined behavior. Right? So that that's kind of okay. Use undefined behavior, get screwed. Like, that that's that's a clear contract. But what happened is we had for end sequence, which is how you do, a relative time lock in Bitcoin. We had something that was intended for future upgrades, but we forgot to do this thing where we don't let you send it to the network. And so people actually started using it. And recently, I I found this, and I was like, hey. We actually kinda screwed up on this. We don't prevent you from broadcasting this. Is anybody using this? Because you probably, like, undocumented, unspecified behavior.
And then we're like, okay. No one's using it. Good. Maybe we can do a just not even a software, just a policy change to make them un broadcastable. And then people from the Lightning Network were like, no. Actually, we decided to put some extra metadata in there because we need a memo field. We're like, why? And they're like, oh, it's the cheapest place to put it. And we're like, okay. So now we've, like, kind of and this is kind of still being debated and discussed, but, like, now we've maybe, like, permanently burned end sequence for future upgrades. And other people have been like, no. We haven't burned it. We just need to do this trick and that trick and this other trick. I'm like yeah. I I personally, like, I'm not sure. Is it can a can, like, a behavioral norm or a tradition
[02:19:26] Unknown:
become a mandatory soft fork or something? Yeah. Yeah. Possibly. And we have a we have 4 bytes, and every transaction has a version field that it's like, what if people started using that or something? Does that just We kinda do. Right? I've I've checked
[02:19:40] Unknown:
But But we use, like, 3 of the of the 4,000,000,000. We use, like Yeah. Well well, I guess that that that's what I was just saying. You know, in this example, this is entirely something where I could imagine that if I had like, and if I weren't, you know, maybe just like a very selfish developer, I could have been like, I noticed this thing, but I wanna propose something for end sequence. And so I'm just not gonna tell people about this issue. And we might have gotten pretty far down the software path before anybody actually noticed that, like, hey. Actually, we have a hard dependency on on using this. And And that's an example where I just think that these things are at the limits of our capabilities as, like, a software community. Well, I I mean, in a sense, like, the
[02:20:16] Unknown:
you you don't want to disenfranchise the people that are currently, like, kinda using it, and you know, like there's no permission required. That's that's kind of the whole point. So if some people are using it, then, you know, I yeah. It sucks as a developer because you don't have as much freedom to use certain fields or whatever. But that's kind of the burden that you have as somebody that's trying to add features that you want to add. I think that's entirely fair. It's it's it's okay that, you know, sequence field is used in a way that maybe you don't like, but, you know, it is what it is. It's you can't force anybody on the network. That's the 5 minutes. So I wanna we've we've been discussing a lot about things that can go wrong with soft forks, implications for people,
[02:21:02] Unknown:
despite it being a backwards compatible mechanism. I'd like to talk a little bit about, right now we're talking about preventing bad things being put into the code. But on the other side of things, we also want to, for the time that it's still malleable enough to introduce these types of things, things that can give us huge improvements in Bitcoin, we still want to be able to do them. And I wanna maybe dive down the road of of activation methods and what we've gleaned from things like like SegWit, because obviously, there was we we had some difficult time there.
Things that should not have been maybe as contentious as they were, became contentious. So what do you guys feel that we learned about activation methods from SegWit to start with?
[02:21:52] Unknown:
Well, I I I don't know if, like, we can assign moral value, like, saying we should it should have been easier or whatever. It was what it was. Right? And there there's no sort of moral judgment that I I think we can really cast on it. What what I will say though is that what we showed was that the corporations were not in control. And that was a major major event in Bitcoin history. And it's not a coincidence that Bitcoin went up in price afterwards. At least I don't think so because we proved that that corporations don't control it. Now, like, like, what what's what's the right way? What I mean, ultimately, I I I'm not sure that it's like a permanent thing. Right? Like, oh, 90% is the right number, and that's gonna be the case for the rest of time or whatever.
I I think each soft work has its own sort of, like, sort of, environment in which it has to activate, and it you you have to get consensus whatever way you can for that particular software with each one. And that kinda sucks for people like the like, that that are on stage with me because Yeah. We we they wanna get something on there. And it's like, well, what's the process? Well, I I hate to tell you, but there there is no process. And like you you just kinda have to go get consensus, and I don't know exactly what that looks like. But it's a it the burden is on you to prove to the rest of the community that this is something that's desirable. Yeah. I can tell you, and certainly, I think Jeremy will agree that it's very.
[02:23:25] Unknown:
You're just sort of like, I don't get consensus, and it's, like, oh, okay. Thanks. Earl earlier, I said it's, like, kinda Groundhog Day. You come out. You see if there's.
[02:23:33] Unknown:
Is there consensus today? But,
[02:23:36] Unknown:
I think just kinda adding onto that, I think people really want to, learn from anecdotes. And I only care to learn from data, is sort of my perspective on this. And I don't think that there's any generalizable lesson out of what happened with Segway other than maybe, oh, corporations, like, don't have this unilateral control. Like, if if they did, we would have seen something else in this anecdote. But even that is not, like, the most useful thing because maybe for, like, a less because Segway had controversy around it. Maybe it itself wasn't as controversial, but, hey. It kinda was a little bit conciliatory to some miners who developed some IP around it. Right? And that's, like, maybe something that we are, like, we fucked up. Like, sorry for this livestream or whatever, but, you know, we messed up and, you know, we we don't want to, we we really strive not to break anyone's mining hardware. Yeah. And that's something that, like, I think it's a big egg on the face of the, you know, development community that, like, okay. Like, if if I want to learn something, it'd be like, we should probably have much better integration testing that we have some way of making sure, that, you know, every developer is, like, intimately familiar with how mining hardware works so that maybe we can, you know, avoid things like this in the future. That said, from my perspective, we're probably not gonna have a lot of forks that are like SegWit, even soft forks. Most of them are much simpler. So that if you're trying to generalize a lesson from SegWit activation for check template verify, which is, you know, what I work on, it's like I think most of the learnings there just don't really map.
You know, there's some stuff that maps, but, like, it's a very different thing. It's a very different mining climate. And it's a change that is just like it's not coming in to solve something that's controversial. It's something that every it's in a problem space that I think most people are like, oh, we're gonna make the, I I say, make the hardest money ever even harder. Yeah. Right? And it's like, okay. If we can all agree on that, we can all agree on things self custody. Like, I think that those are things that just like the the the the type of thing the the lessons of like, oh, these things have to be really hard and we've gotta really, like, be afraid of, like, pissing people off. It's like yeah. I I'm not sure that everything goes through that same sort of gauntlet.
[02:25:37] Unknown:
So, I mean, you know, Segwit was controversial. You're saying there's not a lot of those that are are likely to we did just have a a large, upgrade soft fork that was not, especially controversial, Taproot. And so I'm wondering if if you guys just for people watching that are unfamiliar, maybe just touch on what that enabled for us and, and and where that can go and and things that are still needed beyond that that could be implemented later. But start with, what what did Taproot do for us?
[02:26:10] Unknown:
Well, for me, I I think it gave us a lot more privacy. So you you have this mass syntax tree and you you you have the single key unlock on so you have the key spend and the, and the script spend. And you you, those were 2 different types of addresses all throughout Bitcoin's history up until top road. So you had the pay to pubkey hash addresses, the addresses that start with a 1, pay to script hash addresses, which are the addresses that start with a 3. Even within SegWit, there was the Beck 32 addresses that were shorter and then the Beck 32 addresses that were longer. 1 was pay to witness pubkey hash. The other one was pay to witness script dash. You've combined those. So, essentially, you can't tell which one and and in fact, all Taproot, spends can can be one or the other, and you have the option of both. And there's no real penalty that you're paying for that.
And that that gives you additional privacy. But also you have this tap tree so you you you can make some very very complicated scripts or like have many many different conditions under which you can unlock it. And many of them can be hidden behind, you know, many, you know, very deep in the mastery and so on. So you know, depending on the probability of their execution. And this gives us a lot more flexibility in sort of how we, spend, you know, have backups to our funds and stuff stuff like that, most of which hasn't really been, you know, adopted by wallets and so on. So I look forward to sort of seeing a lot of that. But I would say that the main benefit is that we we've sort of upgraded the security for each user. So you you have this ability to go and back up your wallet to 2 of 3 of this and 4 or 5 of this and even have public companies or something that, you know, publish their public key and have it possible for them to unlock it. And they don't even know that they hold those keys. Right? Like, those are some really cool things that we can have within Taproot.
You know, so I I see it as like a beneficial software but to go back a little bit to, you know, you know, what what what Jeremy said, and I think he's absolutely right on this. You know, the the process for Segwit and Taproot, I I really don't think you can have generalized lessons. And I see that kind of as a feature, not a bug. Right? Like, it is frustrating for these guys, obviously, to, you know, have to go and try to find, okay. How do I get consensus? And, you know, Paul described it as Kafkaesque or whatever. It's like, how do how do I Well, you know, if we had, like, a strict process or something, that I I think that would imply that we have a permanent governance model or something. Right? Like and that's exactly what we don't want. This is a decentralized network. And in a decentralized network, what you need to do is convince the people that are part of that decentralized network. And there are more people coming in and out of this decentralized network all the time. So we should expect the sort of process by which we add soft forks to be different each time because we have more constituents. We have more use cases. We have different features, different thing, things that are happening.
And in a sense, like, each each software has to be different because you have different people using it, and that's a good thing. I I don't see that as a bad thing. Yeah. I I completely agree. I don't think that the controversy about Segwit, I think, was almost 0% about the actual Segwit part.
[02:29:47] Unknown:
I don't I'm even skeptical that basic boost had anything to do with it. Mhmm. So I totally agree with that. It's an extra layer of irony with BIP 300 because what I'm sort of saying is that it should I I can make it not if you just give me this one thing, it won't be cop casks anymore because it will be, there won't be any more changes to layer 1 Bitcoin. And if you wanna do any hard or softworks, the process is now sort of inside the BIP 300 activation, which occurs without any anyone changing any lines of So what's the pushback to that? Well, I think it's just a very abstract idea. I think there's a lot of, there's a lot of, like, so directed this to a storage solution. For them.
I think part of it, though, is that BIP 300 is about escaping Bitcoin Core to go to a different piece of software, and I think that's inherently that I think that baffles people, actually. People are like, don't but don't we have everything perfect in Bitcoin Core? I I really don't like that. Like, Lightning requires external software, you know, for example. It's like Yeah. So I think that, so right. It doesn't really it doesn't really apply, but I think that's part of what people sort of stumble over. It's also there's other features of it that are very different or maybe, like, it it alters who is the most important person, I think, to some extent. So that, I think, may have something to do with it. But I think it's also the the since it opens up this unlimited space of of of possibility, people are the very conservative Bitcoiner is sort of trying to wonder, will will one of those infinite things be be really, really bad? And the answer is no because it's BIP three hundred is designed very cleverly so that your full node is totally ignoring everything that is happening on those other networks, which is unlike the hard fork and unlike even the the well, we thought the soft fork had that property, but it doesn't really have that property. So this is designed to be a big improvement on the process, but it must go since it doesn't exist yet, it must go through the process. Maybe instead of, like, hard fork, you should rename drive change to over easy forks. Yeah. Over easy fork. I think people are saying, like, people have tried to change the terminology. As I wrote a whole article about this at one point about people's changing the terminology and how the existing terminology doesn't really work because and then there's a very funny thread between I mean, I don't know how far we should just throw this out out into, like, other people, but there's a Reddit thread between Adam Back and Luke Dash junior where they're, like, they're going back and forth about whether or not something is a hard fork, and it's very funny. It's, like, they really don't agree. But it's like it's because the the concepts have, they don't have the properties that people thought they had, I think, when it originally,
[02:32:20] Unknown:
defined. And that's that's something that we we really haven't defined in talk. Right? Is is the definition of a soft work. And, you know, like, we we thrown around terms like evil soft work or whatever. And the and this is a little bit of a problem because, you know, like, for some, developers, like, that's not a software. That's actually a hard fork or something like that. And it's like these are these are, you know, these things matter. Like, they're they're technical minutiae that's not transparent to most users, but they they matter.
And, you know, this is where, you know, consensus building is especially hard. Again, I feel for these guys. Right? Because
[02:33:01] Unknown:
it's not easy. It's really not. Yeah. So we got about 4 minutes left. I think the last thing I'm gonna lob at you guys is what do you see as what's next coming down the pipeline? And then, also, at what point, if ever, does Bitcoin just ossify and these conversations are moot?
[02:33:24] Unknown:
I don't know. So I guess, like, in ossification, it's a popular topic. People probably don't necessarily know what that means. It means the the thing turns to bone. It's like you can't change it anymore, and so just stop trying. And it also gets kind of a pun because it's like open source software. So the thing is if you look at, like, societies in general through history, they have some amount of, like, technologically complicated product that they can produce, and it's a curve. And then when that curve starts turning the other way, so the society is usually, like, imminently collapsed.
It's just sort of a phenomenon of, like, okay. There's some sort of, you know, the decline of the Roman Empire. It's like, okay. Well, you look at the technologies they were producing. And I think that for this ossification, like, maybe we can get Bitcoin to the point. But if we if we get to a point where we don't have the type of developers available who could produce the same type of artifact, I think we get ourselves into really hot water, just in terms of, like, Bitcoin as a society. And that's something that really, concerns me. And I think one of the thing ways that you defray that is by keeping talent fresh that can actually work on these complicated topics and understand how Bitcoin even works. And that's something that that does concern me in terms of, like, is this ossification of Bitcoin going to happen? It's like, I actually think it's sort of like the demise of Bitcoin if it does, even though I think the idea of we wouldn't have to change it is appealing. Yeah. I'm gonna disagree with that. I really don't think of this as
[02:34:49] Unknown:
technology first. I think of it as money first. And money is better when it doesn't change. And at some point, yeah, I think it'll. And I I don't think that's necessarily a bad thing because you have rules that are permanently in place, and you know how to plan for the future as a result of money being permanent. And and that ability to plan for the future is critical to entrepreneurship, to civilization building and all that stuff. And you know, yeah there are sort of like technological curves. It's usually because of bad money that you get sort of like this, technological fall off or something like that because you allow in a lot more rent seekers and so on. So for me, I don't see Bitcoin that way, that if we stop, like, soft working or something or adding features, that it suddenly, like, means that we're on the decline or something like that.
Money that stays that that's easy to predict is a very good feature of civilization. I see that as, like, a stable foundation, of, having a civilization built on the stable foundation of money as a very good thing and allowing, which allows civilization to thrive. I I would say, Jim, I know we're a little on time, but, like, I find bugs, like, relatively often. And,
[02:36:06] Unknown:
like, to fix them, like, I have to have a lot of specialized knowledge. And if we don't know how people who are understanding how these things work, adversaries will continue to find them, and then they can take out the system over time. That that's what scares me about it. I'll I'll cede it down. I'll leave it to Paul. You got one minute left. Okay. Great. I think it's a very nuanced point. I think there's some things that have ossified. Like, you could argue different parts of, like, the network,
[02:36:29] Unknown:
the, infrastructure of the Internet, have sort of they're sort of here to stay forever, warts and all. Right? I mean, again, obviously, I'm a proponent of this bit 300 thing, which and then ossifying. So I I am concerned about the exactly what you're talking about, which is that we want something reliable for the long term that that is not is tamper resistant, basically. But I also agree with Jeremy because I do think that I don't, you know, I don't agree that money is actually very stable across time. I mean, after all, it moved from shells to gold, and then it became banknote money. You can say whether or not you hate that, but then it started becoming Bitcoin. But these are those are all changes. And I'm not sure that
[02:37:09] Unknown:
in the modern world, people are very, you know, people are very I think in a sense, like, what matters for Bitcoin is the UTXO set. Yeah. And that's, like, ultimately the thing that matters a lot, and we can have any, you know, system that we devise around that, but it's really the property rights system that we have to maintain over time. Awesome. I think we'll leave it there.
[02:37:27] Unknown:
Gentlemen, thank you so much for being here. Let's give him a big round of applause. Alright.
[02:37:33] Unknown:
Cool. Thank you.
[02:37:38] Unknown:
Hello. How's everybody doing? Woo. Got that, nice belly full of food, hopefully, and ready to listen to it talk about discrete log contracts. And so let's just start off with a raise of hands. How many people have heard of DLCs before? Okay, quite a few people. How many people have tried DLC's before? Quite a few less people. So I, you know, I gotta start off the talk with a little bit of shilling. We're doing some DLC demos right after this talk by the big moon in the expo hall in the esports gaming arena. If this stuff interests you that we're talking about today, come get some hands on experience with it, bring some sats, bring an address that we can send the payout to for a DLC, and a fun bet idea. And, you know, what we're gonna talk about here today on this panel is kind of, you know, what DLCs are, what problems do they solve, and how they actually work. So, kind of like kicking us off here, I I wanna start with, you know, introductions.
[02:38:35] Unknown:
Taj, do you wanna start? Sure. Sorry. I'm Taj Dreyja. I've been working on Bitcoin for a long time. I invented the Lightning Network with Joseph Poon back in 2015. And similar from that, also wrote the paper Discrete Log Contracts a couple of years after that and introduced this way to do smart contracts on Bitcoin. And I'm actually mostly working on UTRIXO, a different new Bitcoin thing. But today, we're talking about DLCs. And so I'm definitely really excited to see that, like, people are actually starting to use it and stuff. So it's great.
[02:39:07] Unknown:
Tony, cool. Hey, everyone. I'm Tony. I'm one of the cofounders and CEO of Atomic Finance. So we're a Toronto based startup, super early stage still, but, we're building a mobile app for folks to be able to put their Bitcoin to work and earn a yield, potentially, on their Bitcoin using options based strategies that are built on top of DLCs, which, we're gonna talk more about later today. I started in the space, 2017. I actually started on the Ethereum space and then decided to pivot and focus, on the Bitcoin side of things later on and, you know, found out that, hey, there's actually all this sort of cool functionality that we can build natively, cool products, cool, applications that we can build natively on Bitcoin. So why not just do it natively on Bitcoin and focus there and, build build products for Bitcoiners. So, yeah, that's a quick intro for me. Hell, yeah.
[02:40:02] Unknown:
I'm Ben. I worked with Chris at SugarVits for about 2 years doing DLC stuff. And, I do a lot now in my free time too. And, it helps, like, build the DLC wall out there in, like, Crystal Bowl or Oracle software. Me and Justin Moon are working on, like, a SDK for mobile wall DLC stuff, but, all work in progress stuff there.
[02:40:22] Unknown:
I'm I'm gonna steal a line from, Ben on the end here and, say, Tadge is probably responsible for 2 inventions that employ a lot of people in this room, lightning network and
[02:40:45] Unknown:
job destruction. Everyone would just hang out and not have to work, but sorry about that.
[02:40:50] Unknown:
Yeah. Utrecht's a no. There's, like, 4 people Maybe in 3 or 4 years, I guess. Right? Yeah. It take takes a little while for it to to catch on. But yeah. There's more people working on that now too. So okay. Sorry. Yeah. Back to, like, kind of discrete log contracts. It's, you know, why is this an important problem to be solving in the first place? You know, we hear about, like, DeFi over in other blockchain ecosystems. And, like, Tony, I'm gonna kick this over to you, why this is, you know, a problem we should be solving in the Bitcoin world.
[02:41:16] Unknown:
Yeah. The way we look at it, you know, DLCs is a very interesting way to build some really cool products and primitives, decentralized finance, DeFi products for Bitcoin. And the reason that our team thinks about it and why we think it's necessary to kind of explore ways to build, Bitcoin DeFi is is twofold. Well, I'll break it down into, like obviously, DeFi consists of decentralized and finance. So why is why are both of those parts necessary on Bitcoin? The financial part, I think, is is a bit more obvious. You know, basically, kind of like when you look at some of the greatest assets or currencies around the world, you know, you notice that there's a very robust and, ecosystem of financial tools around them. And I think part of Bitcoin's maturation, process as a financial asset, as a currency, as a store of value is that there's gonna be more and more financial tools, that are built on top of Bitcoin. And I think that, you know, financial tools, you know, are just gonna be a large part of that maturation process. In terms of decentralized part of things, I think that's where it starts to get a bit more interesting.
Right now, the way that we look at it, there's kind of a big gap or dichotomy between, Bitcoin finance and Bitcoin, the asset today. Bitcoin, the asset, as we all know, you know, censorship resistant, verifiable, transparent, all that jazz. But the issue is, you know, when we look at a lot of Bitcoin finance tools that are available today, you know, it's kind of the opposite. Right? You kind of hand over your coins to them, then you don't know really what happens after the fact. You know, it's you can't really verify much, And it even kind of removes the provable scarcity aspect of Bitcoin to some degree because of potential, you know, of rehypothecation and all that kind of stuff. And so that's why, like, we think that it's it's very necessary to build kind of sound financial tools or decentralized financial tools, that match a bit that, you know, for the most part, match Bitcoin's aspects in terms of, you know, provable scarcity, in terms of verifiability, transparency, all that kind of stuff. And we think that that's, you know, we don't wanna replicate some of the same issues that we see in the fiat world, you know, happen on Bitcoin. And so why not build sound financial tools from the ground up that also carry most of Bitcoin's best, traits?
That's kind of why we are really kind of strong believers in the need to build bitcoin defi, the need to build sound financial tools for sound money, natively here on bitcoin.
[02:43:55] Unknown:
So, I I think that's like a good segue into why we haven't seen, like, as much development for these tools on Bitcoin. And, like, a a question I have for you, Tadh, is, like, kind of, like, you know, what's the why why is it so hard to build things on Bitcoin? Do you think it's a cultural issue that, you know, Bitcoiners don't want this? Or do you think it's a technical issue of they want it, but it's really freaking hard.
[02:44:21] Unknown:
And, you know, it's not as easy as just deploying a smart contract. Right. So, yeah, the sort of interesting thing is, like, the thing that eventually became the discreet log contracts was when someone I knew, Joey Zhu back in San Francisco was like, oh, I'm working on Ethereum. What's that? And he explained the idea of Ethereum. This is way before their whole crowdsale. And I was like, can you do that on Bitcoin? And it's like, no, you can't. I'm like, I wonder, there's probably a way. And so yes, one of the aspects is it's easier. The Ethereum ecosystem has all these tools and you can just write whatever crazy thing you want and lose $600,000,000 of other people's money. Theoretically.
Yeah, and it is it is more difficult, Bitcoin. But I do think there are some technical things that, like, are funded quite different where if you actually look in Ethereum what people are spending a lot of gas and and using it for, a lot of it's discovery. And so what we have with discrete law contracts and, like, people have worked on it a lot, it's contract execution and you have all this securities like, okay, and we always talk about Alice and Bob. It's like, okay, Alice and Bob, Alice is long Bitcoin, Bob is short Bitcoin, so Bob has sort of something like a stable coin, and Alice has this like super volatile Bitcoin because she thinks it's going to go up, And that's a good trade, like they both want to do this, and we have all these really secure ways to make that happen. But we start with Alice and Bob, And really we need to start with Alice doesn't know Bob. Like nobody knows anything.
And you need an order book, you need a marketplace. And I think that is what you sort of see being one of the use cases, one of the things that Ethereum does have that is, on the one hand, horrible because it's enormous and enormously efficient for someone to say, hey, I'm interested in going long this asset. Anyone want or, like, I have an order. I wanna buy something for this amount. I changed it. My mind, I cancel. Right? Because I know that in, like, Wall Street, it's something like a 101, like, total number of orders that go into a market versus order execution. Right? Most people put in orders and then cancel them. And and so you sort of see that recorded for all time in Ethereum where it's all these orders and cancellations and it's very inefficient, but people can find each other. And that's one of the hard parts that is sort of still unsolved in Bitcoin land where you're, you know, same with coin joins, same with a lot of these other protocols. It's like, well, yeah, if you can find your counterparty,
[02:46:44] Unknown:
we know how to do these things. But finding each other in this, like, decentralized trustless way is still something of an open question. So I think that's one of the big hurdles left. And just to I mean, I a 100% agree with that and think that's kind of one of the big unknown problems that we need to solve in the Bitcoin ecosystem is to make that work with the UTXO model. And then, you know, what I call these things is censorship resistant financial markets,
[02:47:07] Unknown:
rather than just kind of censorship resistant money that we have at at the moment. And that's something that I think other blockchain ecosystems are kicking our butt at just by the sheer fact that it's possible there. And Yeah. But it's not even possible. You can see why Bitcoin people don't want it because it's like, we don't want 100 of gigabytes of people trying to find each other recorded for all time that you have to validate. It's like no, don't. That should be offline. That doesn't need to be on the Blockchain. But it doesn't need to be somewhere that's decentralized. And so, you know, I I sort of actually, this conference started saying, we need a layer 2 mempool. Right? Like, I don't know if that's the cool catchphrase, but, like, yeah, we have the mempool Make it happen, Twitter. Yeah. We have this mempool where things are sort of floating around and miners grab stuff and make blocks and make the blockchain. And the mempool is a huge I mean, people have been talking so other people today have been talking about the open source work on the mempool. It's super important and difficult. We don't really have a layer 2 mempool. We don't You know, if you're trying to find counterparties on lightning, if you're trying to do these things it's there's all these sort of sporadic, peer to peer interactions. It's work, but there isn't what's nice is, like, there's the mempool and you sort of all put stuff together. So we don't quite have that as, like, a layer 2 thing, but that's sort of still an open question. There's lots of cool ideas about that. Do you have anything in the works to solve that? Just ask. Just kidding. It's it's a question we keep talking about, but we don't we don't like, oh, silver burrow. Not yet. Yeah. Maybe.
[02:48:29] Unknown:
I think that's a really fair characterization. It's something I'd, you know, like to say to the audience. It's a problem we're solving, and, you know, where does liquidity aggregate and where can you go find, you know, Allison where can Allison Bob go to match each other in a decentralized way so we don't have this, like, regulatory pressure of, you know, depositing your coins on a centralized exchange, and then, you know, they they, of course, are, you know, subject to the whims of whatever jurisdiction they're in. And, I I think, you know, I think Bitcoiners should take the problem more seriously. But, you know, in terms of, like, what we can do with DLCs, assuming that Alice and Bob have found each other already, can we just, like, enumerate some of the the use cases of, you know, what types of contracts we can do? Ben, do you do you do you maybe wanna take that? I'm, like, it's cool. You can do almost anything. Like, they have the options contracts where you're betting on the price of Bitcoin.
[02:49:20] Unknown:
You know, I also build a game where you just bet on Super Smash Bros games, or you could bet you know, that you guys are doing the thing. How long is Justin Moon's mullet? Like, like you can, you can do like anything. It's super cool. 2:30. Be there. How long is Justin Moon's mullet? So like, like, cause all you're doing is having Oracle sign a message of what something is. So it could be, you know, the Bitcoin price. It could be the length of a mullet. It could be a Smash Bros game. It could be like, what's the coordination of the stars or something. Like it can be almost anything. So it opens up like a 1000000 use cases and you can like, with that, you can make lots of cool stuff for like, you know, they're just signing with the Bitcoin price. So you could say, like, what's the execution of the script and then make a real, like, actual smart contract that way.
[02:50:02] Unknown:
Yeah. I mean, I think, like, one of the the most clever things about, DLCs is, like, the the scripting is very minimal, and, intentionally, a lot of information's left off chain. And, may maybe Ben or Taj, do you guys wanna speak to kinda how that's advantageous from a privacy and scalability perspective?
[02:50:20] Unknown:
Ben, do you want to Yeah. I mean, it's huge. So like, you know, today, like if you're using Ethereum, you're saying like, this is everything I'm doing. Here's the exact price I'm trying to buy at. And like, have a huge problem where there's like a minor extracted value where they just front run all the orders because they know what everyone's trying to do and just make free money. In In Bitcoin or at least in DLCs, you can't do that because all of my contract data is off chain just between me and my counterparty just like in a database that we own. And the, and the actual contract was just, like, negotiation between us, and we've all resulted in is spending from a multisig and then spending out of it. That's all anyone can see. So I don't know, like what we're betting on, if we are even betting. And, even though your Oracle doesn't know. So they might like, maybe they, you know, see your IP address, ping the server. I was like, oh, they got the Bitcoin price. They don't know if you were short or long, what the how big your bet was, anything like that. So it's extremely private that way. And then since all this is all off chain and just like 2 transactions, it's lots more
[02:51:13] Unknown:
scalable. Yeah. I mean, you mentioned, I guess, a word that we haven't actually defined yet on this talk, but, you know, what is an Oracle? Does any anybody wanna take that question?
[02:51:24] Unknown:
Chad? Sure. It's you know? And some you you need a bridge from the real world. Why why can't Bitcoin go and just know what the Bitcoin price is? Why can't Bitcoin know who won the Super Bowl? Like, why don't we just embed a HTTP client into Bitcoin and have it reach out and Consensus by figure out how long Justin Moon's mullet is. Yeah. No. None of these chains. Like, you know, everything needs an oracle because you can't you you can't assume consensus on this thing that fundamentally we don't have consensus on. Right? Like, what's the temperature outside? Where outside? You know? And and so you need some kind of entity to just post and say, here, this is the score of the Super Bowl.
And and you do have to trust that entity. And this is like a problem that I don't know. There's, like, whole entire alt coins that are entirely devoted to oracles. I don't know what they're doing. But, like, to me to me, it's always, like, well, you want to minimize. Here's this trust needed, and so you want to minimize that. Right? We we can't really get around it, but we want to reduce the power of the this Oracle as much as possible. So the goal is sort of, like, let's make the Oracle as oblivious as possible to what's going on. So they report this data, but they don't see what people are doing with it, or they don't see how many contracts are using this or anything like that. So to try this and also cryptographically, they can't equivocate. They can't, say, oh, the Rams won the Super Bowl. No. The, you know, Oilers are on the Super Bowl. They can't they can't do both at the same time without losing their private keys, which is sort of a nice extra thing. But yeah, it's it's you know some entity in the real world may be known, may be anonymous that reports on real world data.
And and that report doesn't have to go into the blockchain and ideally won't. Right? So that that report influences the blockchain, but can be on a website or something. And so that's that's sort of the you know, my goal is, like, limit the oracles. Yeah.
[02:53:14] Unknown:
And, hopefully, this real law contracts can help do that. And I I think that's such a valuable point about how the data is not going into the blockchain itself. And another, you know, property of this is that this the way the DLC specification works is the same Oracle could be used across different blockchain ecosystems. And, you know, we're at a Bitcoin conference today, but it's really nice not to have to, have the Oracle have, you know, a different reputation for, you know, the Litecoin blockchain versus the Zcash blockchain versus the Bitcoin blockchain. The same oracle can be used across the entire DLC ecosystem, and, you kind of prevent this, like, fragmentation going on. And, also, you know,
[02:53:53] Unknown:
an oracle can build a reputation that way. And we are, like, seeing that. Like, the link guys announced they're trying to do DLC stuff. So, like Mhmm. It's kinda cool that, like, the shit coins are coming and trying to, like, adopt our stuff, but rarely happens.
[02:54:08] Unknown:
Yeah. I mean, it it it is really cool. Do you have any opinions on what Oracle should report on versus not reporting on? Or, you know, what what is the limitations of an Oracle? I like, how I think about it is, you know, you should always make sure if you're gonna be an Oracle in the DLC ecosystem, the event has to be very cut and dry of what happened. And, like, Tadge was kind of hinting at this earlier of, like, you know, if what what's the temperature outside? You needed to define, like, what the thing that you're going to attest to is very, airtight as possible. Kind of almost like a legal agreement. Otherwise, you can have ambiguity and, your smart contract execution is only as good as the, Oracle's input into the, you know, the smart contract itself.
Another thing that we've worked on in in the DLC spec is
[02:55:00] Unknown:
multi oracle stuff. I know, Ben, you you you've done a lot of work on that. Do you wanna do you wanna share? Yeah. It's like what Taj was saying was, like, you know, you have to trust this one entity, but it's nice in DLCs. We can kinda actually just trust multiple entities in this, like, you know, have this, like, 2 of 3, like, multisig of oracles where you could do something like, you know, maybe, you know, I'm good friends with Chris, but maybe, you know, I don't totally trust him on reporting the weather, but I trust all 3 of these guys together. So let's say if 2 of the 3 say it's 60 degrees, I get the money. And if one lies, then I'm okay. And, so it's a really nice property and it's, scales pretty well, or like your contracts on chain is the exact same still. You just need more data off chain. But, you're able to, like, you know, abstract all these things and kinda protect yourself there if you have multiple oracles.
[02:55:45] Unknown:
Yeah. Another, thing that comes up a lot is, like, should oracles be paid? Should they not be paid? Does anyone have any thoughts on on on the panel about, you know, compensation for the services that Oracles are providing?
[02:55:58] Unknown:
I think that, like, it depends. Basically, it's it's an interesting it's it's an interesting, like, question because, like, oh, there's an oracle being paid. Open up the door for potential collusion or whatever. That, like, it's it's also interesting because maybe Oracle should be thought of as a public good or something like that. And so, yeah, it's it's an interesting kind of, like, discussion topic. I think that, you know, if if, you know, if if if, say, I'm I'm building a product and I need, you know, an oracle with, you know, a guaranteed amount of uptime or something like that or some some sort of kind of, like, you know, minimum level of service, then, you know, maybe then it makes sense for me to pay a little bit more to, like, kinda guarantee that kind of, like, uptime and stuff like that. But,
[02:56:45] Unknown:
otherwise, like, I mean, it's it's certainly an open question. I'm curious to hear what, Todd and Ben have to say. Yeah. And I think, like like, the actually, the operational cost of running an Oracle is, like, basically 0. It's like you post 64 bytes, like, you know, when an event happens, that's about it. Right. So, like, you know, all you're doing is, you know, make an HTTP request probably to, like, you know, nfl.com to get the score and then posting it. So it it they don't totally need to be paid. It is good. Like, you know, as an oracle, you want to be paid because who doesn't like getting paid? But, it is like I don't think it's a huge problem of, like, incentives. Like, most likely, like, you know, people will just set up oracles and be like, oh, it just runs on AWS now forever. And they'll sign every game. They don't need to worry about it anymore. And I think, like, doing things like open source oracles where, like, you open source, like, my NFL oracle that signs every NFL game, then anyone can run this now and we can all see, like, oh, this one's fucking up. He's signing the wrong thing. And then, you know, you just switch over to new Oracles. Like, you don't need to, like, have these all these, like, you know, super,
[02:57:44] Unknown:
like, well, you know, defined things. Like, just let's just have an NFL Oracle and, you know, everyone runs it. I think one of, like yeah. I definitely agree. It's it's not that hard. Right? You just sign a message, so it's not like, you know, you're a minor or anything. I think it's the the one use case I keep coming back to is, like, the price of Bitcoin. Right? People wanna bet on that. We see there's all these stable, you know, Tether and USDC, and it's just like I'm always very curious at, like, why people use them because it seems like a horrible idea. And one day, it's just gonna get, like, seized by some government, and then everyone loses everything. But, or not, but but yeah. But it's like, well, you can sort of get that action with the DLCs where it's like, okay, I want a constant dollar price contract. And so the bitcoin price seems very important, and it does feel like oracles possibly in that case would be incentivized from non without getting paid. So if you're an exchange, you're, you know, Gemini, Kraken, you say, well, I want if there are people making derivatives contracts based on the price of Bitcoin, I want their price to be our price. And most of the exchanges are very, you know, very close in price, but not always. You know, there there can be a little bit of a divergence here and there.
And they can say, well, if you are doing these derivatives contracts, we want you to use, you know, Kraken's price and then that'll make more people wanna trade on Kraken because you can sort of net it out. And and, you know, you're already trusting these exchanges to, like, hold gazillions of Bitcoin. So trusting them to, like, say what the last trade price is seems like a much lower ask than that. So that does seem like, you know, it's not happening now, but it could in the future where where exchanges want,
[02:59:22] Unknown:
to be oracles and wanna get that. It does happen now. They like Coinbase. I think they do, like, a oracle for, like, Ethereum and stuff, so it's not farfetched them to do it for Bitcoin.
[02:59:32] Unknown:
Yeah. And that would that would be a fun you know, so you have the sort of Bitcoin fix where everyone's, like, you know, trading on this, like, very important auction price. Like, okay. Here's the price of Bitcoin for the day or something. That'd be cool. And we're we're starting to see that. Yeah. I mean, I think another, like, interesting topic here is, like,
[02:59:48] Unknown:
whether going back to how do Alice and Bob find each other in a decentralized fashion is very, very hard in the the UTXO world, and it can be done in other blockchains, although really inefficiently and with no privacy, basically. So, another, like, idea that I guess I've been thinking about is, like, is it important that you retain custody of the Bitcoin, while the matching happens if the matching happens fast? So, like, imagine I deposit money into Kraken. They do what they're really good at, which is matching buyers and sellers, and they print a Bitcoin transaction that represents the DLC outback. Does anyone have, thoughts on that or why it's good, why it might be bad?
Any hot takes?
[03:00:33] Unknown:
And it doesn't bring you the censorship resistant financial markets still, which kind of is the goal here. But it is a, I mean, it is a, like, solution. Like, and, honestly, it should be a spectrum. Like, you know, we can have the most decentralized version where it's like, I don't know, like, some, like, actual peer to peer network that we use to negotiate these offers. And if you have the, like, you know, the centralized ones where, you know, deposit the Kraken, spit out a DLC, and you can have things in the middle. So, they're they're all our rivals. You kinda need to try them all out and see which one sticks.
[03:01:01] Unknown:
Yeah. I mean, I I I I I think my my, thinking is, like, evolving on this about minimizing the amount of time that somebody else has custody of your Bitcoin. If that's 30 seconds to match a trade, I think that's a pretty acceptable, amount of time. If, you know, the the exchange in question, is doing funky business, people will stop depositing money into their exchange almost immediately. And, you just gotta make sure you're not using that same exchange as the Oracle, and you do end up having some of the censorship resistance to, at least it's how I've been thinking about. Of course, that requires, like, a large amount of buy in from the existing exchanges, which are pretty, vehemently against adopting any sort of Bitcoin tooling, it seems.
[03:01:46] Unknown:
But, maybe maybe someday. Another model would be sort of a a broker model where, you know, there's one Bob and lots of Alice's, and so everyone's like, yeah. That's that's Bob. Like, everyone connects to this one broker, and they're sort of a party to every trade. And and Bob doesn't necessarily have to take a position. They could say, well, Alice over here wants to go short Bitcoin, and Alice over here wants to go long Bitcoin. So I sort of net that out. Well and I think that's very similar to the atomic finance model, if I'm not mistaken. Tony, do you wanna speak to that,
[03:02:15] Unknown:
a little bit more? Yeah. So, basically, like,
[03:02:19] Unknown:
how how for us, how it works is, like, basically, we do our matching, like, through an IRC channel, kinda similar to, lightning pool and stuff like that. We're joint markets. Right? And, basically, like, kind of just like, you know, users are coming on board on the app. You know, it's very seamless on on the front end for them. Just that tap button. But in the back end, what's happening is, like, you know, generating an offer message on IRC channel and then kind of, like, matching that up with a market maker, on the other side. So it's kind of, like, very simple stuff like that. I think, like, remains to be seen kind of, like, what, you know, longer term, what the matching stuff will will look like and if we standardize on one thing and stuff like that. But, you know, that's, I guess, an open question once again. Yeah. Yeah.
[03:03:04] Unknown:
Another thing that I think is, like, really interesting about DLCs is, like, you know, we've already talked about contract privacy. So somebody that's a third party can't see what you're betting on, without having Alice or Bob reveal that information to them. You know, another interesting component of DLCs, I think, that's kind of underrated is how, it's a dual funded protocol. It requires Alice and Bob to, put in some of their own Bitcoin. And, Ben, do you wanna speak to just kind of how that sometime that can have a privacy impact at the transact or blockchain level? Yeah. So, like,
[03:03:39] Unknown:
today, like, when chain analysis companies, like, try to figure out, like, what this transaction is, they generally give the assumption that all the inputs in the transaction belongs to the same person. So but with DLCs, it's you're gonna have you and your counterparties inputs in there. So you're gonna break that heuristic. And, if they don't know this is DLC, then they might accidentally, like, you know, link your 2 walls together. And now you guys, you know, screw the chain analysis. So good job. And, it's really nice and it's, great too, because it just goes in like, we just sending Bitcoin to a multisig and out. So it's the exact same off chain footprint as like a dual funded lighting channel. And, so you get this really high nice privacy where it doesn't even look like a DLC always. It could just be like and then once we have Taproot as well, it just looks like a normal payment. So it has, like, really nice, benefits there.
[03:04:22] Unknown:
Yeah. I mean and I I think, any anytime you can obscure that transaction graph, it, again, makes the analysis company's jobs harder, and that should be any sort of dual funded protocol has that property as far as I'm aware. Yeah. And so we we shall be encouraging dual funded lightning channels, things like DLCs, especially if you're a privacy advocate and, like, really deeply care about that stuff. So you, you know, make the heuristics that these companies use, a little bit harder to analyze where coins are going and why they're going there. But, Ben, you also brought up, Taproot, you know, the new, upgrade to the Bitcoin network that got shipped in November of, 2021 or something like that. Could could you, speak to how DLCs might evolve? Or maybe, Tadge? You you wanna chime in there too? How DLCs can evolve in a Taproot world? Maybe start with Tadge.
[03:05:11] Unknown:
Sure. Yeah. Taproot I mean, I I can say Taproot, but then there's also a bunch of other changes people have been talking about, especially in the last couple months on, like, mailing lists where, Taproot can help a bit with privacy and also the fact that Taproot can sort of build these trees of, potential spending paths in a single output script will let you, you know, have some more, on chain efficiency as well. But there's also other things that we've been looking at that aren't something that, you know, Bitcoin supports now. Like, hey, if you had something like sig hash, any pre route, which is something that people have been looking at for years and, like, hey, you could do different lightning network style stuff like l 2 with this. You could also make, DLCs more transferable. So you could sort of pre sign transfer, one of the issues with DLCs is once you're in a contract, if your counterparty is gone, you're stuck in that contract, right, until it expires. But if you had, some other different opcodes as well, you could have it so that you could transfer it to someone else without your counterparty being online because, basically, your counterparty presigns off on any transfer.
Also with op, CTV, there's ways to increase the efficiency as well. And then there's also Louis Fournier's post a few months ago about, like, changing the signature thing completely. And I was like, wow. That's really, really cool because I don't really know what we do with it. It it doesn't actually make it that much smaller, but it just seems like a very powerful, you know, step towards something else. So there's definitely lots of tools that aren't out yet, but we're looking at and may someday in the future become, you know, come into Bitcoin that would allow, even more powerful discrete law contracts kind of type of things.
[03:06:48] Unknown:
I mean, I think I think one of the big things is, Schnorr signatures included in the the Taproot upgrade too. And, Ben, do you wanna speak to how, you know, Schnorr changes,
[03:06:57] Unknown:
DLCs on chain and maybe off chain as well? Yeah. Like, the beauty of, like, Schnorr is it lets you do additive things. And, so today when you're doing, like, a multisig on chain, it is very obvious. So, like, 2 of 2 multisig, everyone can see it. With TapR, you can completely hide that and you just do, like, your multisig off chain with these signatures. So, today, like, when you do a DLC, you're funding this 2 of 2 multisig. So everyone sees that, like, oh, this is this is obviously the DLC output, and these are the 2 change outputs. With Taproot, they'd all look like the exact same address. And, so you couldn't tell what's going on. And when you close it as well, it's just gonna look like a normal spend, not a multistake spend. So it gives you this really nice, privacy of hiding exactly what's going on. It's not like your DLC is gonna look the exact same as just a normal, like, spend from your blue wallet or something. So you can't really tell anymore what's going on and it's gonna really hurt these, like, chain analysis companies. They're trying to figure out, like, they'll see, like, a 2 of 2 multisig. Like, okay. This is a special transaction. We can tag this. Like, you know, maybe this doesn't follow the common input here. You're sick. But now if they all look the same, they can't do that. They're like, oh, this is just a transaction. We gotta figure it out.
[03:08:01] Unknown:
Yeah. To Taj point, to Taj's point, about CTV, I think super exciting stuff potentially for DLCs just from a UI UX perspective. You know, right now, maybe it takes for a typical options contract in DLCs takes, like, how to sit around for about 60 seconds to generate all the signatures and all that kind of stuff. You know, we try to make it fun on the app, but, like, you know, it's you know, who has time to wait 60 seconds? Right? So, like, you know, if, if that comes into play, if CTV comes on board, then, you know, we can shorten that time dramatically to, say, like, a couple seconds or something like that, right, which would be amazing from a UI UX perspective and just make things simpler,
[03:08:38] Unknown:
moving forward. And that that's a really good point. And maybe, Taz, do you do you wanna speak to, like, you know, why why is there such a huge computational Right. Load that comes with DLCs? Yeah. So so the basic thing of, you know, the basic
[03:08:50] Unknown:
thing of how DLCs work, which is kinda dumb, is you precompute every single possible thing that can happen. So so for if it's, you know, who wins the Super Bowl? Well, that's just, you know, one or the other. But if it's what are what's the score of the Super Bowl? Well, there could be thousands of different possible scores, and, you know, what's the price of Bitcoin? Well, how, you know, how much do you round it to? So there there's potentially many thousands of possible outcomes. And instead of having the blockchain figure out what happens, the idea is we figure out every possible thing that can happen, store it between Alice and Bob, and then only one thing goes on the blockchain. So there's this trade off of how much the Alice and Bob are doing work, how much the sort of end users are storing and doing work versus how much the Blockchain stores? And one of the things I sort of ask and it's philosophical.
If you can save 1 byte on the Blockchain, how many bytes would you be willing to store on your local computer? Like a kilobyte, a megabyte, a gigabyte? Right? Because it's hard to there's no right answer. Right? But you know, data on the blockchain is very it it it feels heavy. It's like, man, I'm putting something on the blockchain. This thing's gonna be around for maybe longer than I am, and everyone's gonna have to validate it and download it and store it, and, like, I wanna really minimize that. And so the trade off with DLC is it's, I don't know, a 1000 to 1, whatever. You're having a constant size on chain transaction and potentially quite large amount of data between the 2 parties that never sees the chain. And so I I generally think that's good, but but there are trade offs. Right? Maybe it's too slow and like, hey, if we can just put another 20 or 30 bytes on chain, we can take this 60 seconds down to, like, one second. That that could be useful. You know? And you know, there's a market like fees fees and stuff. So so that's sort of one of the big trade offs we're looking at. And the ops CTV could give different ops to change as well there.
[03:10:35] Unknown:
Yeah. I I just realized you've made 2 protocols now that have, like, these, infinite growing well, no. No. I guess, DLCs, it's not infinite growing storage requirements. But lightning Yeah. So then you close your channel. I guess you you gotta keep adding to the
[03:10:49] Unknown:
database then. Right. But it doesn't but only one thing goes. I mean, they're they're very simp you know, it the DLC definitely came out of the the research and the work on lightning network. And they and they you know, the scripts are the same or were you know, so they're very similar in that you wanna push as much data as you can off chain. And and sometimes that means you actually have scaling issues on your single computer. But to me, like, a scaling issue on your computer is better than a scaling issue for the whole entire network. Yeah. And I think that that's such a, you know
[03:11:17] Unknown:
maybe you're the originator of this, like, kind of philosophical design point that I also hold of, like, just, like, keep as much off the blockchain as possible. It's better for scalability of the blockchain. It's better for privacy of the participants of the, you know, the the contract in question on the blockchain. And, you know, consumer hardware does keep getting better and better, although, you know, we keep doing more intricate and intricate things with that consumer hardware. Does any does anyone else have an opinion on, you know,
[03:11:45] Unknown:
on chain stuff versus off chain stuff? I mean, I think a funny thing to bring up is, like, when we were developing the DLC wallet shared bits, like, when we first started, I was like highly unoptimized and be like, we tried to do like a 3 of 5, like Oracle bet on the Bitcoin price that had like a 1,000,000 outcomes or something. And like our me and Chris, like we click like go and are both our computers crashed and we text each other. Like, did you die too? Like, yeah. So like, it is a hard problem to solve and we, you know, we added a lot of optimizations and stuff. Now we're able to do it in like a couple seconds, but we have like high end developer laptops, like Atomic Finances on your iPhone. IPhone. So it's like, this doesn't have this insane chip in memory that you can do at all. And it does blow up a lot of data. Like, I know a couple of them we did, or we didn't put in, like, rounding and then we'd have, like, 88, 80 megabyte, like, databases for one contract that we're just, like, testing with. And it'd be it wouldn't like, the networking would, like, screw up sometimes, and it's just a hard problem. So it is like a nice thing that if we do get CTV is a huge thing. Cause suddenly you negotiate all these transactions, all you do is just basically both produce the same address and that you both get the same as well. You're like, cool. And you send to it and now your DLC's set up. So it saves a lot of that, bandwidth is which is really nice, especially for, like, places that, like, if you're doing, like, over tour where it's, very slow and stuff like that, or if you're just, you know, somewhere in, like, you're from, like, Nigeria or something and don't have 5 g Internet, like, you know, it's a big benefit.
[03:13:06] Unknown:
Yeah. And just another plug in there. It's like we ship our SureDVids wallet on the Raspberry Pis on Umbrel. And that's, like, again, where, there's a lot of sensitivity to performance because on low resource devices, which I think, you know, most Bitcoin applications strive to be deployed on, the signature computation does become, sometimes prohibitive for certain types of contracts that people wanna use. My understanding of moving to Tappert and Schnorr is that computation does get quicker, which is another, benefit of moving to the to Schnorr. But we're not quite there in the DLC specification. We're waiting on us getting Taproot rolled out and deployed in the ecosystem before
[03:13:49] Unknown:
we can take advantage of that. And the the, like, Fournier, you know, changing the signature the Oracle signature to we need a term for it, but not a signature at all where it's basically I plus k x. That would probably be a 1000 times faster for the end users or some, you know, something on the order of a like, point multiplication versus addition, thousand ish times faster. So that that would be a huge improvement, and it's still not a 100% sure it's secure because it's just like a post on a mailing list. You're like, that works, I think. Okay. So there's still, like, there's still enormous amounts of things to improve and research in this space, which is really exciting.
[03:14:25] Unknown:
Another, like, I guess, like, going back to the Oracle questions, like, some something that we've been talking about a lot lately is, like, Oracle's attesting to something that's globally known, such as the Super Bowl or what the weather is outside or, you know, what the price of Bitcoin is on exchange. There is, like, you know, globally knowable answers to that, versus, like, attesting to something that maybe isn't globally known but can be used to give a better user experience. Like, maybe how much money specifically Alice and Bob receive in a very specific trade rather than, you know, attesting to what the Bitcoin price is. Does any does anybody have any thoughts there on, you know, if if that, like, warps Oracle incentives at all or,
[03:15:07] Unknown:
any ideas on that? And it kind of talks like you're thinking of like, doing like escrow with DLCs and like, I think that is like a a nice use case for, like, instead of, like, having the escrow, like, be part of your transaction, the 2 or 3 multisig. They're not just an oracle, and they don't know your transaction, so you get some privacy. It probably helps them with regulations and stuff. But, it is kinda weird because, like, if they lie, like, look, they lied. We'd be like, you can't really totally prove it because it's not a public event of, like, you know, did the package come to my house or not? So, it it kinda skews the incentives, but I still think it's a good use case. Like, DLCs have real nice benefits over, like, bringing third parties into your transaction. So I think it's, like, a great way to do it. So And another, a conversation I had in the last, like, month or 2 was with a, you know, a a guy that runs a pretty, big Bitcoin,
[03:15:52] Unknown:
company and how, DLCs could be used for reoccurring subscriptions too, where you roll the subscription over every month and, the oracle pulls the money almost like you're drawing down a Bitcoin address like a bank account. And, you can cancel the subscription at any time by double spending the transaction. The feedback that I've got from that ID on the mailing list is use and lock time. And I I think that's like a fair rebuttal. I still think there's some noninteractivity benefits maybe. But, is it you does anyone have any thoughts on just kind of out of the box, Oracle ideas that don't necessarily tie directly to betting applications necessarily? Or can can can we take this Oracle specification even further in the DLC ecosystem to enable more use cases on, Bitcoin and, have
[03:16:43] Unknown:
Bitcoin and Oracles take over everything? It's a it's a pretty general protocol, but it does seem like, yeah, you ideally, if this is like a public thing and and the oracles can't really lie that easily because that you know, and they don't know who's using the data. Because if you're sort of saying, hey. This is between Alice and Bob, you need to check whether I got my groceries delivered. The Oracle already knows who's gonna use this data, and so there you've sort of lost a lot of that privacy. So, you know, the it it doesn't help as much there, but it could be used in these things. And there is there are companies like asking, but it's sort of like sometimes you lose a little bit of the the purpose of it, but but a lot of times you you still you know, if the software is there, people will probably use it for that as well. Yeah.
[03:17:22] Unknown:
I think we're pretty much out of time, guys. Thank you for coming out. If we're doing DLC demos again, 2:30 at the expo hall, far left, back corner by the big moon. We're giving away these shirts if you manage to get through a a DLC setup. So if you want some, SureDbit swag with company on the front, the math on the back, come check us out. And, otherwise, thanks for being a great audience.
[03:17:50] Unknown:
What is up, guys? We are here to talk about Bitcoin nodes. We got some of the guys behind some of the best node projects in the space up here to discuss it with us. By a show of hands, who uses their own Bitcoin node? Awesome. The whole room. So, I mean, this is also getting recorded and broadcast out to lots and lots of people. So I think a good just a good place to start is just to interact with the to interact with the Bitcoin network, you need to use a Bitcoin node. If you don't use your own node, you're using someone else's node. If you're using someone else's node, you're trusting them with your privacy and validation of the rules of the network.
Commonly, when you're using someone else's node, it's like if you use Ledger Live, you're using Ledger's node. It's oftentimes a company. Or a mobile wallet. If you're using BlueWallet, you're using BlueWallet's node. So with all that said let's get into this discussion. We have, S2 here from Ronan Dojo. We have Keegan here from Start 9. We have Jonas here from Nick's Bitcoin, and we have Rud Sol here from Raspi Blitz. You might recognize Rud Sol because he's been running the workshop table outside. Before I forget, we will be auctioning off 3 Rasputi blitzes at the end of tomorrow at 3 PM with 50% of funds going to raspi blitz development and 50% going to greater open source development through open sats.
So, guys, where do we start? So I I guess I let let's start with Rudolf. Rudolf, when you're when you're thinking about the Raspi High Blitz project, you know, what what are, like, the priorities that you're thinking about in terms of what what to deliver users and how to go about that?
[03:19:47] Unknown:
So for for the rest people, that's the thing. The, the main focus is to be this more community driven kind of node. So because we see it on the GitHub, so we have a lot of forks. We have a lot of stars, people really participating. So, and this is a thing something for Raspberry Piplitz to be really just open platform. If people want to tinker, if people want to develop, that's that's definitely something we want to be open for. Because this whole project started from the lightning hack days we did back in the days in Berlin like they were in the recipe boat and then it did, it developed out into the recipe blitz. And so this we wanna keep this spirit going. That's kind of a thing our main focus.
[03:20:27] Unknown:
Awesome. So, I mean, Keegan, you guys have a very different approach there with start 9. How do you think about that?
[03:20:35] Unknown:
Yeah. The central thing that we're trying to accomplish is that we've kind of identified that Bitcoin as a project will not succeed and retain the properties that it was designed for in namely, you know, censorship resistance, you know, seizure resistance, inflation resistance. If the number of properly used nodes is comparatively small to the number of people who use Bitcoin. So we are trying to expand the number of users of Bitcoin in the proper way, so to speak, to the largest set that we can reasonably do. And that means that we have to do a tremendous amount of work on the user experience side. So we do a little bit less catering towards the tinkerers. Not that those people like, those people are tremendously important to the community and, you know, not one size of product fits all. But if everyone isn't really running their own node but they're still using Bitcoin, bitcoin is at risk of various forms of capture. And so it's very important that as many people are running it as possible. And so UX is kind of always at the top.
Now that does mean removing certain decisions from the point of view of the user. But we try very, very hard to make a distinction between user like choices users have to make because they have to just, you know, use a computer versus choices they have to make that materially affect the way that they actually use Bitcoin. And so if and we try to give as many of those decisions back to the user as possible because after all, if we're making decisions for how people are using Bitcoin, in some sense, we might be capturing their ability. We don't want to do that either. So it's this delicate trade off between trying to make it as streamlined as possible but still affording the user decisions, to be able to use, Bitcoin in a sovereign way.
[03:22:23] Unknown:
Makes a lot of sense. I mean, I think it's pretty cool that, you know, we do have 4 of the major node projects up here. And you guys have, com like, you all take completely different trade off balances, I feel like. So, Jonas, when you're talking about nix Bitcoin, like, how do you relate to what what these 2 guys just, Yeah. I would I would say we're yet on another end of the spectrum because,
[03:22:47] Unknown:
we mostly cater towards tinkering. Our main focus emphasis is security, privacy and customizability. The trade off for doing that is that, Nix Bitcoin has kind of a steep learning curve and doesn't have a graphical user interface, for example, for most of the things that it does. But, I call this as the most low time preference node choice because in the beginning you need to invest a lot of time. It depends on how you use it, but you need to invest some time to get up to speed with it. But then you will, reap the results, which I really think are a superior, privacy and security on the system.
[03:23:38] Unknown:
Yeah. I mean, there is a bit of a steep learning curve there, but, you guys are definitely a a a unique project in the space. It's definitely really appreciated how much focus there is on on security and reproducibility. So, I mean, s 2, you're kind of, I feel like you're kind of in the middle. So so Raspberry Pi Blitz,
[03:24:00] Unknown:
I guess, actually, Raspberry Pi Blitz is doing a similar thing. So start 9, the main the main use users of start 9 are actually buying devices directly from you, Keegan. Right? Yeah. That's that's correct. We sell, like, an integrated product. Again, it's about streamlining the entire process, and there are people who are going to have Raspberry Pis that they can repurpose and and, you know, install software too, and that's perfectly fine. But there's, like, an entire category of users that don't even wanna do that. And in my mind, like, we have a 100000000 Bitcoin users today. Like, you know, not even all of those use their or, like, have their own keys, which is, you know, itself a problem, not one that we're directly setting out to solve at the moment. But then there's another category of users that may have their own keys, but don't use their own nodes. And we're really just trying to say, like, how can we make it such that we have as few people who are using Bitcoin at an arm's length distance as possible? How can we close the gap between people who are using Bitcoin as a, like, unit of account, so to speak, all the way to using Bitcoin in its intended design with the properties that make Bitcoin special. But would you say, like, 9 like, 90% or something of of Embassy users are using the prebuilt? Or Yeah. I'd say most of them. We we don't really have a way to track those metrics Right. Because anybody who builds from like, we don't build any sort of analytics data for privacy and Yeah. I'm just saying my gut. Right? Like, the
[03:25:21] Unknown:
Yeah. I mean, like, my gut instinct is, yeah, like, the the vast majority of them are are purchasing it. Because the the reason I'm going into that is, so, like, with s 2, with Ronin Dojo, Ronin Dojo was primarily a build your own project, open source project Yeah. The no layer monetization, and recently, you started selling
[03:25:38] Unknown:
prebuilts. Right. Right. We kinda saw both ends that people want to maybe customize and build their own node or they want the convenience.
[03:25:47] Unknown:
So we we wanna kinda offer all of it. But you wanna talk a little bit about, like so, like, Ronin Jojo is a free open source project. Yep. But but you want to be sustainable. You don't wanna be, dependent on donations.
[03:26:01] Unknown:
Yeah. Yeah. I mean, how do you give software away for free and keep a roof over your head. Right? Right. So we build, products and services around it. You know, essentially, we have a focus on transactional Raspberry Pi and build 1, whether they wanna use the either buy a Raspberry Pi and build 1, whether they wanna use the command line interface or if they wanna buy a pre built node and just have it be plug and play. You know, we know that there's people who are hungry across this spectrum of nodes and node offerings.
[03:26:35] Unknown:
Yep. I think the support feature is pretty cool. Do you wanna go into that a little bit? Or Yeah. We have a premium support model. So we'll, like, walk people through,
[03:26:44] Unknown:
people need to know how to manage their UTXOs or use Bitcoin privately, and they don't wanna be tracked or surveilled. We're happy to provide premium support, and that's just another service we can build around the product so that we can, you know, monetize and, continue to give the software away for free.
[03:27:02] Unknown:
Rousseau, how do you feel about monetization? I mean, because you guys sell prebuilts too. Does that go to directly fund development? Is that is that is it a similar strategy, or is it
[03:27:13] Unknown:
Yeah. Basically, that's, that's the one way how we can refinance a little bit like the, the cost for development. And it's it's and it's an it's also a nice way for people to support the the project like, okay. I buy a prebuilt node at the shop. It's a good way to kind of support, the the whole kind of development.
[03:27:33] Unknown:
Awesome. So, I mean, I don't this question is not necessarily directed at anyone, specifically. I guess, I mean, since I have all 4 of you on stage, like, do any of you have any concerns about, you know, maybe one node project becoming the predominant node project and how do you how do you think about that? I mean, whoever wants to jump in here.
[03:27:56] Unknown:
I think the I think the the more easy it is to migrate between them, the less important that it is that one that it's like that there isn't a dominant one at any given time. Right? Like, what you don't want is a situation where there's a dominant node product and they they lock you in super hard to their ecosystem because that is a means of exerting control that very similar to the way that we see in, like, web 2 so to speak or, like, the the big walled gardens of the giant Internet companies. But in the absence of that heavy lock in, which Bitcoin itself is pretty good at doing, the entire BIP and lightning standards process makes it significantly easier to migrate between things. Which means that at any given time, if there is a dominant implementation, it's not like they have this sort of, like, stronghold that can't be breached. So they're kinda they're kept honest by the fact that users can migrate. I mean, there's so many different,
[03:28:49] Unknown:
applications to, you know, what people want. There's, you know, there's a big spectrum of nodes. Some people might want certain services. It's hard to encompass everything in one project. There's always gonna be people who are interested in, like, very hardcore security or they want, you know, transactional privacy or, you know, it's there's a lot of different applications you can host, and, it's hard to pack it all onto one device and to cover the entire spectrum. And then but so so with On Chain Bitcoin, with the regular
[03:29:18] Unknown:
Bitcoin node that you're using with On Chain, it's pretty easy to move around and change what software you're running and which which nodes you wanna run. There is but a lot of people now, like, one of the main reasons they use a who who here runs a lightning node? Use a lightning node? Okay. So all of these people, there's a degree of lock in with lightning channels. Right? Like, how do do you think do do you guys think there should be, like, some kind of standardization in terms of, like, porting those light like, that lightning database without, like, corrupting your state and and getting the penalized transaction and losing funds. Is that should that be a priority in this space, like, for easy migration in that regard? Because I I would say that's probably the number one lock in, especially if we, like, enter, like, a sustained fee and high fee environment.
And next thing you know, like, fees are a 120 sats per byte or something, it it would be very expensive to close channels and then reopen somewhere else. So I feel like it it makes it, like, kind of resistant. Jonas, do you have an opinion on this? I think this is a good point.
[03:30:30] Unknown:
In the Nix Bitcoin case, it is definitely possible to do all this migration, but it's a very manual process that can also go wrong in horrible ways because it's lightning and lightning is very stateful. And, yeah, you you know the problems with with this. So, I think this is one of the the things that, are part of the migration, but there are, of course, also other things, I would think, like all the interfaces, how how have you how have you set up your nodes in node in terms of options. Right? Every node project has a different interface and all of this, I don't really think this is portable really, like something you could easily do in 5 minutes because this would just having a standard on this would just hold back innovation
[03:31:21] Unknown:
in this space because I think it's a lost cause. It's like that I think this part seems to be a lost cause to me at least. I think there's there's 2 questions here that you're asking. There's the your there's the the migrate ability between the node projects, and then there's actually the migrate ability between different lightning implementations. Yeah. That's even If you wanna move from LND on the embassy to LND on Ronan Dojo or on to LND on, you know, RASPipelets or NEX Bitcoin. The you're not really having to do any serious lightning channel migrations because the data format is ultimately the same. It's really can we shuffle data from point a to point b. And, like, you probably don't need a standards process for that. You just need to have relatively stable locations that these things need to be in. And never turn on the old node again. Right. And and so, so, yeah. Like, Lightning itself has its own problems with respect to how stable it is in the presence of multiple nodes. But even, like, just cloning your hard drive and trying to set up a second one, it's gonna run you into that problem as well. And then this there's the second question that you're asking, which is migrations between different lighting implementations. So LND, seat lighting, eclair, anything else that pops up. Okay, yeah. And that one I'd like to see a lot more standardization, but the various teams that are working on that may or may not have the incentive to do so. And similarly to the various node projects it's not necessarily the case that any of us will have the direct incentive other than maybe, you know, sort of any goodwill that we have towards, supporting the the ethos of the of the movement.
But it's also can it's very tricky with lightning because so many things can go wrong, because of the very delicate game theory and punishment schemes that keep the Lightning, incentives honest, and and and the the sort of very few tools that we used to make that happen, which is why we have Lightning at all right now, because of that delicacy, it is difficult to make it such that people can't screw it up. Right. And as a result, I think a lot of the the node implementations And when I say node, I mean, like, LNDC lightning, etcetera. Haven't really given it a lot of, effort because, you know, there's a lot of ways to screw it up. People shouldn't be doing it anyway, so why commit effort to it? But I think the longer that we see it, like, in a 120 SOUNDS per byte environment sustain for years, which we can expect I think if we're gonna be trying to onboard millions of users over the next few years, in that sort of a situation, we may not have another choice. And so whether that's people who step up from the community to figure out how to do this, whether it's, you know, the implementations themselves that, you know, put effort into it. Like, we have a certain amount of incentive to write migrations from others from other node implementations to us. And so correspondingly, you know, other implementations might have an incentive to write migrations from our stuff to theirs. And so, like, I think I think we'll see it materialize on a need basis, but, you know, it's one of those things that
[03:34:23] Unknown:
necessity is the mother of invention here. Right. Rudolf, I mean, I think you guys actually had
[03:34:29] Unknown:
there was a migration tool or a migration setup with Umbrel. Was that Yeah. We have migration. So if you run-in Umbrel, a Citadel, or a MyNode, you can basically migrate to Respiblitz. It will only take your kind of blockchain and the, and the l and d funds and channels. If you use any other apps on on on on those, node projects, this data will not get And that's l and d to l and d. Right? You're not Yeah. It's LND to LND. Cross name before lightning. The the the the recipe blitz itself has also c lightning, so, you you have both there. So the so the other kind of all have just l and d, so, that's easy to kind of get over because those ones is,
[03:35:12] Unknown:
you know, just even migrating the main chain data, not just having to do the IBD again and download 450 gigs of blockchain. Right. You know, it's great to be able to switch between nodes and just, you know, you already have your blockchain data and yeah. I think it's we all have an incentive to help the users switch between easily. Mhmm. So, I mean, out of
[03:35:33] Unknown:
out of all 4 node projects here, star 9 is the only one that offers users the ability to run non Bitcoin apps on the node. And, like, jumping off of what Rusol was mentioning about, obviously, not being able to migrate from apps that don't exist on Raspberry Pi Blitz. Do you how do you think about that in terms of both, you know, lock in or, like, a soft lock in where they they already have their files set up? They already have you know, maybe they're using their self hosted photo sharing and then also having that as their main Bitcoin node. Like, is that is that a concern? Or I guess they could just move to just a new Bitcoin node and keep the star 9 for everything else. I'm just answering my own question. There is absolutely nothing,
[03:36:24] Unknown:
that stops people from using multiple versions of these sorts of things, to manage different parts of their lives. We our mission is a little bit more broad than Bitcoin in general. I think we see a lot of these, freedom infringements in other parts of our lives. I think the one that might resonate with a lot of people in this room is, like, Twitter banning people who happen to be having the the incorrect view of the day, which may shift by the day. And so you might have, like, competing projects like Mastodon, which are have been around for a while, but they just haven't experienced wide deployments because, you know, we have not put the effort into having a peer to peer deployment, that that is made easy for people. And so we we wanna be able to bring that to as many aspects of people's digital lives as possible and Bitcoin is one section of it.
But, you know, there's nothing there's absolutely nothing that stops someone from, like, running, you know, 2 different node implementations and, you know, the star 9, embassy 1 being for their non bitcoin stuff and, you know, their whatever other implementation that they're using for their bitcoin stuff. Right. So I wouldn't necessarily say that it's, like, soft lock in on a, like, cross app basis. Right. You might have some soft lock in in the sense that if, you know, you are running an app that one of the other implementations doesn't have, then, you know, that's that is a locking of sorts. But we we generally take the position that any application that is on our, on our node has to be open source. Right? It doesn't necessarily have to be fast, but it needs to have the source absolutely available. And that is what helps people be able to actually break those lock ins. Right? Because they know the data formats. They can be like, okay. I want me to go scrape this out and move it over. Would you even would you even frame start 9 as a Bitcoin node, or is it it's like a
[03:38:15] Unknown:
a self hosting everything
[03:38:19] Unknown:
with Bitcoin? It's a personal private server, and we named it the embassy not on a whim. We kinda think about it as sovereign territory and foreign land. Right? Where the Internet is this kind of like wild west and this is kind of like your your, you know, castle, your your embassy, your your location that you have sovereign control over even though sort of outside of the walls, it may not be as safe.
[03:38:45] Unknown:
So, I mean, part of, part of the reason why this idea of lock in with nodes, I think most of you would agree with me, is a concern that maybe one of the node projects becomes malicious or nonaligned with users or, you know, starts releasing you know, like like the fork wars we had, right, where they maybe you know, we didn't have these node projects at the time. Most people were just running Bitcoin Core on their computer themselves. If one of if one of the major node implementations was pro Segwit 2x and they sent out an update to everybody and switched them towards that, that could obviously become a major issue.
But at the same time, because of lightning so there was this ethos in Bitcoin that it was like, don't update right away. First of all, no auto updates, period. Because if you have auto updates, someone can,
[03:39:44] Unknown:
issue you an auto update, and that auto update could be malicious. Yeah. Like, I to to briefly add on to that. If you self host your stuff but the operating systems or the apps have the ability to force updates on you, you your self hosting isn't doing a lot. Right. Self hosting is supposed to afford you a sense of control, and forced updates undermine that. Right. It's a it's an attack vector. It's a centralized attack vector. So then
[03:40:09] Unknown:
but at the and and there was this the ethos went farther than that. It was like and I I still think it's that way today, at least on base chain, which is, you know, there's no rush to update. You can be a couple versions behind. In a lot of ways, that could be more prudent, while while review is happening on on on new nodes or new, you know, new node versions, or at least, you know, maybe have some people that are still running older versions. You know, people run really old versions of Bitcoin and still backwards compatible. But then on the lightning side, you know, there's situations where it's like, if you don't update right now, there's major fund loss risk. Like, I remember I was here in Miami for the HRF event, and I was on stage.
And I got off the state I got off stage, and Stefan came up to me, and he was like I I think it was 2 lightning implementations. I don't I definitely, LND was one of them because I was running LND, and it was, like, update immediately, you know, attack in the wild. You can lose funds right now. And I was on stage, and my node wasn't accessible to me. And just for, like, a week, I just obviously didn't update because I couldn't. And then I got home and didn't lose any money, so it worked out. But is there an argument to be made that on the lightning side, because it's so new that there should be auto updates? Like, how do you guys think about it? Like, Jonas, what do you think about that?
[03:41:40] Unknown:
No. Auto auto updates are are, are not a good thing, of course, for beta software, perhaps like Lightning or experimental in some sense, you need to use frequent updates, you need to take care of your funds, of course. Running a node isn't easy today. It will take some time until it will be easy. And one of the parts that make it hard is that you need to keep up to date with updating your software as well. And back to the Bitcoin code even in that case I wouldn't be so sure whether it makes sense to run old Bitcoin versions because you never know if a new Bitcoin version has some kind of hidden bug fix.
So, one of the things that some people do for example is to have like 2 Bitcoin nodes that are connected to each other and like, you have one one of them facing the outer world that is an updated node, updated to the most recent version, and then you have another node that is just connected to this gateway node and running an older version. And this is for example something that you could do, with, Nix Bitcoin.
[03:42:57] Unknown:
Oh, that's interesting. So it's, like, built in that way intentionally, or is there is it just
[03:43:03] Unknown:
users can can do that? It's just built customized enough so that you could, that you could build that. Got it. As long as the user has a choice, I think it's you know, that's really important. And, also, if you're in beta or, you know, lightning and doing experimental things, you should put proper warnings and let people know that, you know, don't don't put more on there than you're willing to lose.
[03:43:25] Unknown:
But isn't that kind of bullshit warning?
[03:43:27] Unknown:
It is. But if you're in beta, you just you need to do your users justice and let them know and properly educate them that they need to pay attention to every update and be aware. Fair enough. And this is you know, anytime you're developing something like this, you go through long periods of you know, the users need to be aware of all these changes that are being made. Rutzel, how do you feel about this?
[03:43:51] Unknown:
I think if you the question is always the of the the of centralization. Right? Because this is one point the update is coming from. So if if you can put in another service provider that, that built makes a build for you, somebody, a group that you trust, something like this. This could it could be something a little bit more easy for the user. Maybe pushing hard into into your node is always critical. This is why Rescooblets always has to make a USB card, and it goes through the update, basically. But I think when you go into this convenient thing, because in the end, that's what a lot of users want is the easy update, then you at least have to think about making it possible to that you can choose your source of updating and you can choose your kind of trust group, and you're not, not everything is targeted to this one company. But so you have, like, multiple update sources? It's like a toggle or something? Yeah. Not exactly. We have to see what system, but, basically, just you can choose, like, oh, I always get my build image from there or something. So yeah. So that you really can
[03:44:49] Unknown:
can can have not this one company that can just do this. Yeah. I mean, like, in the newest copy of MCOS in the 0 three o, we actually did introduce preliminary support for alternate marketplaces for precisely this reason, which is that we are aware there's a certain amount of trade offs that we have to make and, like, certain amount of, like, imperfection we have to accept in the short term, which is that, you know, we're providing most if not every, update that people are gonna be absorbing. But we're, like, intimately aware of the fact that, like, we could be co opted either, you know, through just, like, leadership changes or, you know, you know, various unfriendly organizations that can put us under duress. Like we're aware that that can put our users at risk. And so like I think having these this sort of multi sourced package model similar to the way that, like, app on Ubuntu works or the way that, like, Linux package management works but kind of, like, dressed up in a way that makes that can give better intuition to to users about, like, what it actually is. Because, like, you know, people have experiences of buying the same product from different stores.
Right? And so to the degree that that could be conveyed, I think users can actually take responsibility for those sorts of things. Right.
[03:46:01] Unknown:
I mean, I think it'd be kinda cool if you just, like, thinking out loud if there was, like, a new, you know, new Bitcoin core version comes out, new Bitcoin d comes out, and you have, like, 3 different sources that you pulled from, and you can tell that that all the hashes are the same. Like, they're the same file for all 3 just at the bare minimum. But, like, there is there I feel like there's a, we want as many people to use their own note as possible. Right? We want it to be as accessible as possible. But it kinda it does go up against this idea that you have personal responsibility will never be the easiest one.
And, like, even without I'm I know I'm sticking on this auto update thing, but even without auto updates, like, Umbrel pops up, like, update, and they just press the button. Right? Like, it's still manual at least. That's still a benefit. But is there a concern is there is do you guys have a concern? And, I mean, I'll direct this to Jonas because, I mean, I think your users are more experienced. But do you do you have a concern with users of these more convenient node packages that they kind of just, like, blindly follow that they're not necessarily educated users in that regard? Is that a real concern?
[03:47:22] Unknown:
I think that's a concern, but that's very hard to prevent, I suppose, because you not everyone can read the code and see what what happens in between. You need some kind of oracles that will tell you whether this is good code or not. In the end, you need to trust someone. No one of us reads all the code, that they're running. So this problem will never go away. You can, I think, reduce some of the, some of the attack vectors that are there if you, for example, have your releases signed by multiple people or even built by multiple people, like Bitcoin Core does, for example? And this already reduces the attack surface quite a bit, but you will never get rid of this problem entirely.
[03:48:12] Unknown:
Yeah. The price of freedom is personal responsibility. I think our job as the implementations is to provide users ever increasing leverage on the knowledge that they have. Right? So they still have to be the one in the driver's seat. They still have to be the one making decisions. But there are a lot of bullshit decisions when you're trying to set up nodes. Right? There's things that don't really matter to your ability to to to work on it. And to the degree that we can eliminate those and make it such that the only decisions they have to make are the ones that materially affect their outcome and what they're what kind of software they're running, like, that at least reduces the cognitive load enough that they can actually take an active role in that process. And, like, that's that is an ever improving thing. It's not like any of us has, like, the holy grail of that today. But I think that's the ultimate mission of, like, everybody sitting on this panel right now is, like, can we provide higher leverage to users?
[03:49:04] Unknown:
I think that's really well put. I mean, because everything will always have trade offs. So you can eliminate trade offs. It's just different trade off balances that you come to come to terms with. And every once in a while, you can push the frontier further. Right? It's like not every trade off is, like, neutral with with respect to value. Right. But,
[03:49:21] Unknown:
like, you know, you wanna give them the entire trade off curve if you can. And then, you know, when you can get these sort of free wins and push that frontier forward, just you fucking do it.
[03:49:33] Unknown:
So, I mean, we still have a little bit of time left. I kinda I'm curious. I mean, you guys are just heads heads down, really focused on on this. I guess I'll start with Rutsal. Like, Rutsal, when you think about the evolving node space because I feel like if if if you're a relatively new Bitcoin user, you might be under this impression that there's always been all of these independent node teams trying to take different trade off balances and make using your own node more convenient, but it's a relatively recent phenomenon. It's like the last 3 years has really blossomed, and I for this panel, I tried to get as many of the node teams as possible.
And when you start to think about it, it's like maybe there's, like, 7 or 8, like, major ones. But, fortunately, we got these 4 these 4 legends over here. So, Rizal, when you think about, like, this evolving node space, what do you like, what's the what's your biggest concern? Like, what keeps you up at night?
[03:50:33] Unknown:
Yeah. So you can see we have this one very dominant, node distribution out there, and it would not be, again, it would not be the problem if, if it would be free and open source because then if if it comes to dominant and people don't like it, they can always talk often, then you we can you can have multiple competing projects and you choose which one you you go. So a little bit, this this this is a concern, but just a concern, when it comes to, how to say, as long as migration is there, I'm I can sleep good. So that that's fine. It's good to for onboarding, I think it's perfect thing to have the solutions out there. So
[03:51:16] Unknown:
Jonas, what's your biggest concern?
[03:51:20] Unknown:
I don't think I have very big concerns in in the node space right now. It's cool that people run nodes. It's cool that people run a lot of nodes. More people should run nodes, run their own nodes, run their own software, use more CoinJoin, use more lightning, etcetera. And these node projects, help doing that, which is much better than not doing any of those things. So I think, I'm rather happy, and, I'm looking forward to the future,
[03:51:49] Unknown:
than the opposite. I love it. Jonas isn't concerned now. Now I feel better about it. Keegan, biggest concern?
[03:51:57] Unknown:
See, I am concerned but it's my job to be concerned. I the thing that keeps me up is really whether or not we can make our product easy enough to use to onboard the next people. Because here's the thing, like, with a dollar collapse happening whether it's in slow or fast motion, like, people are gonna be looking for alternatives. And if people jump to Bitcoin and Bitcoin doesn't have a beefy enough infrastructure in terms of central decentralization, then Bitcoin's own properties are kind of at risk. And so more people running nodes is and and not just running nodes, but, like, running them in a, like, self sovereign way where they're really exercising their own agency is, like, paramount to the survival of Bitcoin.
And the if you don't if we don't find a way to make it easy enough, or if we find or in the effort to make it easy enough, we rob users of too many important choices, then, like, the whole this whole movement doesn't really work the way it is supposed to. So, like, I am every day when I wake up, I'm, like, okay. What is too hard? And how can we make it easier that doesn't, like, fundamentally remove the user from the driver's seat.
[03:53:11] Unknown:
That's too biggest concern. I mean, I would basically bounce off of that. You know, I'm just concerned that convenience, there's gonna be too many sacrifices made.
[03:53:20] Unknown:
And, you know, while we want it to be easy and abstract things away, we also want to make sure that users are properly educated and have you know, know that the choices that they're making have certain consequences. And so I think, you know, education is very important. There's not enough good node education out there. There needs to be, you know, a lot more videos, guides. It needs to be made easier, but people still need to understand the basics of how this stuff functions. So I think, you know, education definitely needs to increase and we don't like he was saying, we gotta be careful the sacrifices that we make in the name of convenience.
[03:53:58] Unknown:
So all of your projects, essentially, in practice, what you're looking at is you're looking at having a a little server, a little computer running at home or your office, and that you're oftentimes connecting back to. Like, if you use it on a phone, you're connecting back to it. A lot of projects are using Tor to do that. But you have this central server, essentially, that you're running in in a physical location that you control. Now everyone has a phone in their pocket. Like, the next thing that everyone always says is nodes running on the phone, nodes on the phone. Now is that the future, or is that a pipe dream?
Full nodes? Yeah. So using using your own Bitcoin node on your phone. Right? Just it's it's just baked into the phone. Is that actually
[03:54:44] Unknown:
a thing that we could look forward to in, you know, 5 to 10 years, or is that a pipe dream? Yeah. I think I really like this idea because as you can see, Raspberry Pis are very hard to get, and and and not very affordable for a lot of people. And if you look at countries that that have operate on on low, income, a used smartphone is very easy to get because everybody has it. And and if you could if you can turn this one into into a full node, I think just just basically, you have the automatic battery in there so it's already a little bit more secured. So Sync Media, basically, it's it's a good device. I'm not exactly sure who's working on this. So there was a friend of mine at a heck day that was kind of looking into this, but decided at that point, no. It doesn't make sense here.
But I think we may might come more and more closer into the area where where this gets feasible. I mean, with a big SD card, I don't know. Still, they they some years maybe, but I think it would be great to to have this in the future. Jonas, you gave me the pipe dream look. Do you think it's a pipe dream?
[03:55:46] Unknown:
No. No? You think that's that's the future?
[03:55:49] Unknown:
I'm not sure if it's the future. So on next Bitcoin, we're also thinking about a lot about, Bitcoin infrastructure, not just having single nodes because a single node, if it goes down, if it explodes, you've lost your funds. And, in the Bitcoin on chain case, you might have a backup, but in the Lightning case, you're SOL. So, we're thinking about, deploying more things at once, a backup server and perhaps a gateway node that, has a VPN such that you can easily connect to your node at home that has monitoring. So even if your node at home goes down, you will be able to notice and, which is also important in in the lightning case.
So I guess there are just so many ways for how to use notes but for for the the the phone future
[03:56:44] Unknown:
for, Bitcoin nodes I think is still an interesting interesting way to to look at. I think I think phones for layer 1 type stuff is significantly more viable than it is for layer 2. And the reason for that is that when you go offline for significant periods of time, you can catch up with the rest of the network. But the way that pretty much every layer 2 protocol is designed requires a certain liveness to it. In fact, when we were originally trying to put the first version of the Embassy together, we were trying to narrow down what the essential characteristics were that were needed.
And for, for lightning in particular, and a lot of the layer twos will behave this way, just due to the nature of, like, computer science itself, is that these servers need to be addressable, and they need to be alive generally, as much of the time as possible. And because if they're not you are at risk of losing funds. If, because your your counterparties might try to cheat you and you have to be able to remain vigilant during times. And phones just aren't necessarily designed with the use case in mind that they're gonna be on 247. They're designed to be portable. That and that's tremendously useful for everything that we use phones for. But servers are designed to be alive 100% of the time. They're designed to be addressable 100% of the time. And those are properties that you absolutely need for a lot of these layer twos. Layer ones,
[03:58:06] Unknown:
different story. But Awesome. Yeah. For layer 2 phones, definitely a bit of a pipe dream,
[03:58:12] Unknown:
or at least there'd be needs to be a lot of work done, and it it need to be a very special setup. Or you could have, like, watch towers or some Yeah.
[03:58:20] Unknown:
It it, like, plus minimize third party service or running out of VPS or something like that. You could. Yeah. Awesome. Well, we're out of time, guys. This has been great. I wanna thank our our fantastic panelists. I wanna encourage all participants, everyone in the audience here, everyone watching at home, consider using your own node, consider running your own node. I know it sounds overwhelming, but it's it's really not that overwhelming. Get your feet wet. It's relatively cheap to do. At the end of the day, you're you're essentially taking a computer and plugging in an Ethernet and a power cord. So thank you guys. Thank you, and, take care for the keynote.
[03:59:02] Unknown:
Makes it easier in a way. You can't see anyone, you don't know what to think. Oh, our mics are on. I guess we're going. What is up freaks?
[03:59:08] Unknown:
What is up Miami?
[03:59:15] Unknown:
I wanna start because I'm a proud cohost. Let's give it up for Matt O'Dell for organizing this room here.
[03:59:21] Unknown:
Yeah. Thank you, brother. Truly special.
[03:59:26] Unknown:
Yeah. Incredible job, dude.
[03:59:27] Unknown:
This is the largest in person rabbit hole recap we've ever done. Yeah. Woo hoo. Congrats on the history. Somebody note the block, and, we'll write that down somewhere.
[03:59:38] Unknown:
We're joined by Craig Rall, nWizz. Steve Barber's supposed to be up here, but he's not here. So if he wanders in, send him to get a mic. But this is our HR. We have 40 minutes. When we do these live shows, we usually do a different format where we have a few topics that we wanna talk about. Matt and I haven't even talked about topics, and then we'll open it up to q and a. Wait. Raise your hand if you have no idea what rabbit hole recap is.
[04:00:05] Unknown:
Awesome. Oh. Welcome. Okay. So rabbit hole recap is our weekly news show, weekly Bitcoin news show. We've been doing it for over 3 years now. 4 years, September, I believe. Yeah. So if you like Bitcoin, you should check that. If you like this, you know, go check it out. Maybe consider it. But, yeah, as Marty said, we're just kind of gonna we're gonna shoot the shit and then we're gonna do a q and a. Yeah.
[04:00:28] Unknown:
Let's give another shout out to Wiz for doing a pirate livestream in this room today.
[04:00:35] Unknown:
Yeah. Thanks, thanks to Jack for retweeting my, pirate livestream at open source stage. I think it was an idea I had about 2 in the morning last night. I'm like, why is there no livestream? Let's just go to Target and Best Buy, buy a camera, and plug it in and set it up, and so we did it. Yeah. You
[04:00:53] Unknown:
you
[04:00:54] Unknown:
could spin up your own ISP. I think you can figure out a live stream in 12 hours. It's very impressive. Where's this 2 ISPs now? Boom.
[04:01:01] Unknown:
Well, technically, mempool.space is, its own ISP now. Yeah. Okay. So we kinda spun that off into its own
[04:01:08] Unknown:
sub ISP in a way. Why don't we talk about that? You you recently added a mining page to mempool.space.
[04:01:13] Unknown:
Yeah. We went down to Nashville, last week with Matt and Rod, organizing the Nashville meetup down there. And, we had a really nice crowd about, what, 100 people, maybe more? Yeah. There was a tornado warning. We didn't So a 100 was a good showing. Yeah. It was pouring outside. Yeah. And, but it was a great show. I mean, it was just me, Rod, Matt on stage, and we were just trolling each other. We actually forgot there was, like, an audience there, and he was having so much fun. I don't know how many hours we were talking, but it was a great show. But, yeah, he announced the so Wiz is the lead maintain one one of the cofounders of mempool.space
[04:01:49] Unknown:
and one of the co maintainers of the open source mempool project, where you can and he has she rented a TV and put it up over there with a live look at,
[04:01:59] Unknown:
his mempool. Yeah. We don't have a booth in the conference this year, so, we just rented a TV and stuck it in the corner over there.
[04:02:06] Unknown:
And we have we have Craig Raw here, who is, the lead maintainer and the the man behind Sparrow Wallet, which is one of the best desktop wallets on the market, fully open stores. This is his first public appearance ever in the Bitcoin scene. Thank you, sir. It is an absolute fucking honor that you are up here with us. Thank you. Well,
[04:02:31] Unknown:
thank you. Thank you. Craig Craig and I were talking backstage. You're comfortable talking about what we were discussing? Sure. Go ahead. So there's there's a path to scripters and wallets and simplifying that?
[04:02:42] Unknown:
Yeah. So well, we were just having a quick chat. Currently, Bitcoin Core requires if you wanna input your output descriptor into a Bitcoin core wallet, you got to get a receive chain output descriptor and a change chain output descriptor. They're different. Andrew Chow has actually put forward a multipath version of that, which allows you to have one descriptor and that's useful because if you're going to stamp it into a steel plate, for example, you've got 99% of them are the the actual data is the same for the received chain chain. So you might as well just have one descriptor which specifies both both chains. So that's a PR that's in Bitcoin Core right right now.
Sparrow implements it that way and I'm kind of hoping that Sparrow leads the way on that, to try and maybe get things to move in that direction. But it is as yet an unmerged PR. So hopefully it goes that way. So what does that mean to the end user? It means easier backups essentially? Yeah. So I mean, if you have a multistay, you need to back up all of the public keys. Right? You can't just have the seeds and, output descriptor is really the most standard way to do that. So, you know, just having one which is easier to put into steel plate, for example, which is is, I I think, an important thing.
[04:03:59] Unknown:
Awesome.
[04:04:00] Unknown:
Yeah. That's true. If you even if you have all your seed plate backups, if you don't have those, public keys, I guess, you couldn't recover the funds. Right? Correct. So, I mean, you know, people often think multisig. If I lose one of my seeds Right. I'm okay. But, actually, you do need the Other public keys. Other keys. Yeah. And then to reconstruct that script. So for that, you know, the output of the script is kind of our standard way to do it.
[04:04:24] Unknown:
Awesome.
[04:04:25] Unknown:
So I'll give this PR a thumbs up.
[04:04:27] Unknown:
I hope so. Let's get some review too. What do you wanna talk about? Is there any you wanna talk about tokens on Lightning? Yeah.
[04:04:37] Unknown:
Yeah. Matt was making fun of me earlier saying I'm a I'm a attention whore. No. I called you a cheerleader is what I called you. Why am I a cheerleader?
[04:04:46] Unknown:
I don't know. You just you you just made it seem extremely bullish, and I just don't I think it's very bullish. I think it's cool.
[04:04:53] Unknown:
I think what we're talking about is There's a lot of, layer 2, like, ways to do tokens on top of Bitcoin. Right? Like, even back in the day, you had, like, what's it called? Omni protocol. Yeah. Omni protocol. You had, something party. Counterparty. Counterparty. There's colored Bitcoin,
[04:05:09] Unknown:
then there's, like, liquid. Now there's lightning. You can issue shitcoins on top of Bitcoin in lots of different ways now. Right? Yeah. I mean, you can also just issue shitcoins on top of shitcoins and let that be. Like, if people wanna use Tether, why does it matter if they use Tron? Like, does anyone really care? Like, at the end of the day, you're still trusting the Tether Corporation in the back end. It doesn't really matter what chain it's running on. So why do we care if it's just running on a centralized
[04:05:33] Unknown:
Personally, I think the move was on Bitcoin
[04:05:35] Unknown:
rather than a shitcoin. That's why I got excited about it. Like, you can create these tokens within a Taproot transaction and then push it up to the 2nd layer and transact via lightning. But you brought up something earlier when we're discussing this when it became apparent that Matt was gonna, shit on me on stage. I was there. We should talk about it. Does it? I did. Does it, does it create this weird MEV like incentive mechanism on the Lightning Network? Where you you have these different assets going through lightning nodes, and does that mess with the incentives of the node topology?
[04:06:08] Unknown:
Yeah. I mean, I don't I don't really I mean, I just recently launched. We had we had the fortune of having Laalu on stage here yesterday to present on it. And what? It hit the it hit the dev mailing list the day before that, I believe. So it's really fresh. So I I expect people will, you know, look into it, but, you know, as someone who does run a routing node, run a lightning routing node, and I see that we have a lot of you know, Lightning's great. I've Lightning's one of those things where I just go through, like, 4 month cycles where I'm bullish and bearish on Lightning. But I've run a Lightning routing node the whole time, and I continue to use Lightning. But there are things that need to be refined on Lightning. It's an unfinished spec. Right?
And I don't know if NFTs on lightning are the thing
[04:06:58] Unknown:
that I get excited about. Like, I think stable coins are interesting. I'm interested in hash rate derivatives. Could they be tokenized? Stable coin. Yeah.
[04:07:08] Unknown:
Yeah. There's a lot of, assets issued on the Liquid network too, and there's this huge divide internally within the liquid federation. Should liquid become this thing that, like, eats Ethereum and all these other, shitcoin blockchains or should Liquid be a system for cheap and fast Bitcoin payments on a layer 2 blockchain? Right? Mhmm. And and it's it's really interesting to see how these layer 2 networks and and communities will evolve over time. I mean, the I guess the con rough consensus is, like, why not both? But it can be a distraction, and you get lots of scams.
It's it's it's really got its trade offs. Right? Yeah. So, I mean, Marty had a specific,
[04:07:51] Unknown:
when he when he was cheerleading Taro, he had a specific, framing, which is that it obsolete shitcoins. It makes every shitcoin obsolete. Yeah. Does it? It could potentially. I don't know. It could potentially. Maybe I wasn't. That wouldn't have made the tweet as fire. Right? It could potentially get the shit going obsolete.
[04:08:11] Unknown:
Craig, do you have any thoughts on this, or is this signal? Yeah. I mean, obviously, I haven't really had a chance to look into it, in any great detail, but, obviously the one of the bounding qualities of the Lightning Network is the amount of liquidity that's locked up into it. So if this brings additional liquidity that is a good thing. You know, are there going to be other second order effects? Hard to say at this point. You know, I think that it's it's we're just starting as a community to kind of look at what's being being being done. I think, you know, it's it's it's interesting, but it's not it's not super interesting in the long term. We obviously have a long term vision of a Bitcoin only future.
[04:08:48] Unknown:
But it may be sort of an interesting diversion on on that path. I know they do. Help us to get there. Who knows? It's a cool part of the of their vision. I will say that as opposed to, like, Synonym's proposal where Synonym's proposal essentially has you have to have dedicated Lightning channels for whatever shit coin you're transferring. Mhmm. So then that's completely separate liquidity. Like, they it's called the Lightning Network, but it's it's not really interoperable with the Greater Lightning Network. In this proposal, it is pretty cool that, you know, you could just be running a routing node that only sees Sats and doesn't even know that that any token is involved, and only the ed edges have to know. So, essentially, like, if Tether was successful on Lightning, it could create an incentive where there is way more liquidity on the Lightning Network because Tether is not on Tron or Solana or whatever bullshit.
And those routing nodes in between could end up making way more in fees as a result. Right? Yeah. So I I definitely agree that that is that is definitely a a very cool aspect of it. Yeah. It sounds like you're becoming bullish on Terra live on stage. I mean, you're right. I'm just trying to be fair. I'm just trying to be fair. I don't think it's gonna obsolete shitcoins, though. Yeah. We, we were, also reminiscing earlier
[04:10:05] Unknown:
of Bitcoin 2019 when we did the first Yeah. Live RHR. On a picnic table. On a picnic table. Bitcoin. Had a fresh face. He looked about 15 years younger wearing the same shoes. Mhmm. And it's just crazy to think of how big this pair but How how big this, how big this conference has gotten over the last 3 years specifically. Obviously, due to the fact that Bitcoin's a very big theme in the world right now. Bitcoin 2019,
[04:10:33] Unknown:
we're on a picnic table. There was 25 100 people at the conference, maybe even less, like 23100 people at the conference. The main stage for that event was probably around this size, maybe a little bit bigger. Definitely, the actual stage was bigger, but seat wise was probably
[04:10:50] Unknown:
maybe, like, 60% larger than this. Yeah. Like, this used to be the whole Bitcoin conference. Just this room. And then Bitcoin 2020
[04:10:58] Unknown:
was canceled, because it was happening in California as COVID hit. And then Bitcoin 2021, we were outside in the scorching heat. Yeah. They put O'Leary inside of it. In front of about 400 people with 13,000 people at the event. And now we're on this nice beautiful open source stage and air conditioning with probably,
[04:11:19] Unknown:
like, 900 to a 1000 people in here. I'll take it. And we've got a we've got a live 3 years. After too. Yeah. Love you. We love you, freaks. We do love you, freaks. Yeah. It's crazy. It's the thing. I mean, you had Odell Beckham, Serena Williams, and Aaron Rodgers opening the day. Do you know,
[04:11:39] Unknown:
did I tell you that, CNBC reached out to do an interview with me here, and they kept asking for my PR person? I was like, I'm just a humble big winner. Like, I don't have a PR person. He, like, planned the whole thing out, and they thought they were booking Odell Beckham Junior.
[04:11:55] Unknown:
And then, like,
[04:11:58] Unknown:
secondary Odell in Bitcoin. It's made me how quick that happens. That's incredible.
[04:12:04] Unknown:
Number 1 in our hearts.
[04:12:06] Unknown:
Let's fucking go.
[04:12:08] Unknown:
So with all this attention coming to Bitcoin, obviously, this conference, 25,000 people here, I'd like to hear your thoughts, Wiz and Craig, like, in term at the protocol level and the the network level in terms of decentralization and usability? How what do you guys think the state of Bitcoin is as a network right now?
[04:12:27] Unknown:
State of Bitcoin? Good question. That's a good question. I don't know. I mean, the community is very strong, but there's there's also, like, this, mix. It's it's like a Venn diagram or something where you've got the Bitcoin, the hardcore Bitcoiners, which are probably in this room, and then you've got the crypto people, and then you've got just the total shit shitcoin scams. Right? And it's it's like, obviously, those circles are not the same size, right, as you just described by the size of the comparing the different size of the stages or whatever. And even around this, conference, there's, like, satellite conference, like, shitcoin or something. I think Solana's doing something here. Yeah. It's it's just, yeah, it's the community is is evolving, I guess. It's very mainstream. But the real Bitcoin community, the core hardcore Bitcoin, they're all here. Like, in this room, I feel. Right? I mean
[04:13:22] Unknown:
Yeah. I have to agree with Wiz. I wander around and I feel that the Bitcoin conference is here in this hall. It's kind of not really happening out there. I mean, that's not may maybe fair because I haven't spent that much much time out there, and I'm sure there are interesting talks. But certainly what we've had here,
[04:13:41] Unknown:
thanks to Max, has been some really great talks. It was definitely not just me. There was a massive team that helped me. Sure. I hadn't done it without them. I mean, I behoove all of you an hour after this. I think it's 4 PM to go to the main stage because Mahler's has got a fucking insane announcement. So
[04:14:01] Unknown:
Matt hasn't even told me yet, so it must be pretty big.
[04:14:05] Unknown:
Lip sealed. Yeah. The
[04:14:08] Unknown:
Yeah. I just came back the mining stage, Steve Barber, Whit from Compass, Bob, and a gentleman, Ryan, I believe, from Titan with AJ, have, like,
[04:14:20] Unknown:
a further decentralizing mining talk. The mining stage is awesome. Right? I mean, I I've been stuck here, and I love it. But I I mean, I've I've looked all over that agenda, the agenda for the mining stage for today and tomorrow. I mean, like, historically, like, industry days always very suit heavy. Mhmm. You know? And this year was the exception because we did highly technical open source conversations here. So that was the rarity in terms of how they set up this conference usually. But the GA days on the mining stage are pretty pretty awesome. What was your how many talks did you watch there? What was your favorite?
[04:15:00] Unknown:
I must admit this is my second talk. So the the last one I saw was my favorite. But it I think it's an important discussion like decentralizing mining, obviously, in the mining industry it's always top of mind. You're seeing this massive migration of hash rates to the US and even more specifically to Texas. A lot of massive on grid, operations that are just inherently centralized. You have people building 500 megawatt facilities that that are very out in the open. And I think what Steve is doing with upstream and the black box to get more individuals mining and his framing with the black box is it may not be as profitable, but people really want it because they want privacy. There's this there's this push for privacy downstream in the energy sector,
[04:15:46] Unknown:
from from individual Bitcoin miners. Upstream 100%. Gets much more efficient, obviously, because they're closer to the lowest cost power. But downstream is being hardened because people want KYC free Bitcoin. I think that's a really cool move. That's an interesting, comparison between, like, the mining stage and open source stage. Open source can just be like a few shadowy super coders, you know, hacking away on GitHub. You don't you have no idea what their real name is. But to do mining, especially these days, it's extremely capital intensive and, you know, you need to wear a suit to raise that kind of capital. Right?
[04:16:19] Unknown:
I don't wear suits. Oh, no. So we have so I guess both me and Marty are gonna be on the mining stage tomorrow separately. I can wear a suit? And so Marty's Marty's talk is titled, is ESG an attack on Bitcoin? Obviously, Marty doesn't think ESG is an attack on Bitcoin. So it should be a very interesting conversation. Yeah. I will we'll talk about that tomorrow. And and I'm doing a KYC free home mining with Econo Alchemist and Diverter. So there's a lot of good conversations this year, that I'm excited about. And I I mean, I look. At the end of the day, there's just so much there's so much content that you you have to watch them after the fact Yeah.
[04:16:58] Unknown:
Till you, like, catch them all. Yeah. I did catch a clip of Dave Portnoy talking shit on me. That was fun. But Portnoy, could you Portnoy, he was talking shit about you? Yeah. Funny, though. I actually texted him after, trying to convince him to get Barstool's podcast on podcasting 2.0. I mean, that seems obvious. Yeah. I think that would be massive not only for podcasting 2.0, but, like, having somebody like Barstool. What did Portnoy say about you? He's,
[04:17:23] Unknown:
was he on stage? Shady when I worked at Barstool. While he was on I was sneaking into the studios late at night. While he was on stage? But the first time I recorded with Marty was in Barstool's merch closet with, T shirts all around us. Yeah. We literally did. A bottle of Macallan. The first what was that? That was, like, episode 29 of the interview series. Yeah. Marty was like, oh, come over to the bar stool studio. Like, this is where our court I was like, I was gonna be the most baller podcast studio ever. I'm just, like, sitting in a fucking glass box and fucking
[04:17:54] Unknown:
t shirts all around me. Hey. Humble beginnings, man. Had a lot of t shirts. Yeah. So we have yeah. We we'll keep 15 minutes.
[04:18:04] Unknown:
That's fine then. 15 minutes for q and a.
[04:18:08] Unknown:
What is, I got something. If you can't think of anything, you look like you're digging for something in there. Well, that's why I was looking at my phone earlier. Like, is there anything interesting? But if you have something Well, I wasn't able to dig too far into it, but Blockstream and Breeze
[04:18:22] Unknown:
announced Oh, that's cool. The green light integration?
[04:18:25] Unknown:
What, you seem to know more about it than I
[04:18:29] Unknown:
I do. What's going on? So I was talking to Roy about it. Roy's here from Breeze. He's absolutely awesome. So first of all, it's like a it's just an announcement of their plans to do it. Mhmm. But right now with Breeze, you essentially are running a lightning note on your phone directly on your phone. And if anyone's used Breeze for podcasting 2.0, like, your phone gets really hot Really hot. Because it's like it's legitimately running a a lightning note on your phone. And it also means that all of their different apps within Breeze, whether that's the actual wallet or whether that's podcasting or whether that's their point of sale, and he wants to add video streaming, and he wants to add all these different things, they all need to be in the same app because they need a lightning node.
Now Greenlight is cool because it's an on demand cloud node that Blockstream it's a it's a service that Blockstream runs, and it's trust minimized because the actual keys are on your phone. They're not on the server. Now there's obviously some trust still in Blockstream. Obvious the main one is that they actually are up, but, also, they provide a watchtower service for you because when your node's offline, someone can try and broadcast a bad state and steal your Lightning funds. Right? So there's a little bit of trust in Blockstream, but if they're not like your channel partner, they shouldn't be able to take your funds. And all these Lightning wallets on your phone, they're they're not trustless. There's always first of all, it's very hard for anything to be trustless, but they're all, like, trust minimized, taking different trade off balances. Like, even with Breeze. With Breeze, your phone goes offline.
You're now your main channel's open with Breeze. You know, they're the only liquidity provider. There's some trust there in Breeze. Now in this setup, it's it's really interesting because you, yeah, you have the keys on your phone, green light is the node, and then he can have all these different Breeze apps that can all connect back to that node and separate them out. So you don't have one big bloated app, that does all the things. That's modular. Yeah. And I guess, like, this is the first major partner with Greenlight that I know of. That's pretty cool. And it also means more c lightning usage like, core lightning usage. Do wanna talk about that? Did we talk about that last week? Talk about it last week. It was an April fools joke. Yeah. Cool. I mean We had Kristen Decker up here, and he kept he kept calling it c lightning by accident.
[04:20:51] Unknown:
We, I mean, we talked about it last week. Yeah. We did. We already talked about it. Yeah. I mean, there's a lot of people in the room here. The lightning flame wars are interesting, the implementation wars. What are do do you have any thoughts? Yeah. The the the green light logo is yellow. What's up with that?
[04:21:06] Unknown:
That just that just, irks me so hard. That's confusing. Right? Yeah.
[04:21:11] Unknown:
Well, I guess everyone's scared of, you know, making a green bee because of bee cache. There's one right behind your head over there.
[04:21:21] Unknown:
That's a square. That's a square. So it's, like,
[04:21:26] Unknown:
a little bit different. Yeah. A 100%. Yeah. I think b cache is who was here when b cache happened? When the fork happened? It's good about Yeah. See, for a lot of people, Bcache just does not even exist. Good. There's no reason to so you think they should call it yellow light, or should they change the color of the logo? I'm not the marketing person. I don't know.
[04:21:51] Unknown:
Yeah. Yeah. I was actually reminiscing with Harry Suttig about that too. Like, when we first met in 2017, like, all the topic was about the 4 cores. And it's crazy again to think how far we've come from that.
[04:22:05] Unknown:
It was an important part of Bitcoin history, though. Right? Kinda like, Mt. Gox going bankrupt or or the block size wars, whatever you wanna call it. It proved that Bitcoin is resilient, and it just got stronger afterwards. So
[04:22:18] Unknown:
yeah. It sort of needed to happen at some point, right, to prove that Bitcoin could overcome that. That's true.
[04:22:25] Unknown:
Yeah. Like, even 5, 6 years ago, it wasn't, maybe this is something we take for granted now. Now we kind of accept that Bitcoin works extremely reliably. But back then, it was much more, maybe experimental or we didn't have as much confidence maybe. It was it was more of something to play around with. Mhmm. Now, you know, you've got billionaires just going all in. Yeah. And then you have other billionaires who want to change the code.
[04:22:51] Unknown:
Hashtag change the code. Mhmm. They're gonna change the code. Anybody can change the code. Just getting people to run it, that's gonna be hard.
[04:22:59] Unknown:
Well, Greenpeace can go fuck themselves. They love it.
[04:23:07] Unknown:
Real Bitcoiners in
[04:23:13] Unknown:
here. What else do you wanna talk about?
[04:23:17] Unknown:
Well, echo I had I I lost the thought that just came back to me piggybacking on this. Fork wars were over how to, scale Bitcoin, particularly at the block size level. BCash went into arbitrarily just double the block size, and other people thought Segwit would be a more, advantageous way to to increase the block weight and making some more transactions.
[04:23:42] Unknown:
There he is. I was told to wander up. Okay. Do you have a handheld? Sorry. I'm dressed like Fiat today. So Steve, do you have a handheld mic? Steve, go get a mic. No. I got nothing. Stick your head in there and ask them for a handout. Tell them I can.
[04:23:53] Unknown:
The Bends are here. And We're not
[04:23:58] Unknown:
But The Bends are here. That's,
[04:24:00] Unknown:
I got in a bit of a discussion this week about attack. How's the Bends?
[04:24:04] Unknown:
Is there,
[04:24:07] Unknown:
Bends?
[04:24:08] Unknown:
Look at that. Benz always oh, no. I can't see it. They brought a gaggle. There's a gaggle of Benz.
[04:24:18] Unknown:
Get out of here.
[04:24:24] Unknown:
Get out of here.
[04:24:26] Unknown:
There we go. Steve, don't bring that sign up here.
[04:24:29] Unknown:
No.
[04:24:30] Unknown:
My my little boy is 6 months. His name is Ben. Oh, got it. Fair enough. I stand with Ben's baby. Did you get, did you get mobbed after your mining panel? That's what I assumed. I did. Yeah. A lot of, lot of noobs came up to me, so I'd explain Bitcoin from scratch. So
[04:24:49] Unknown:
What, what are your thoughts of this event? How's it going for you? I think it's been great. I, came in a bit late, but,
[04:24:57] Unknown:
a few NFT shields came up to me, but they're, you know, they're nice people. Marty loves NFTs, though, and he just wants to buy them. I have no opinion on them. Like, I'm sort of neutral, but mining is good. This year is nice to see like, excitement around mining. So I think, the conference guys have done an amazing job with that. So I love them loving what I'm seeing out there in the booth section. Do Do you wanna tell the freaks about our special offer? Yeah. I'm, I'm shilling our black boxes. If you guys haven't seen them, they're, mining out in the conference with a couple of s nines. So, yeah,
[04:25:36] Unknown:
You wanna tell them what a black box is?
[04:25:39] Unknown:
Yeah. Black box, it converts your KYC Bitcoin to non KYC Bitcoin, in the comfort of your home. It turns you into your own personal non KYC exchange. It burns your fiat and makes beautiful Bitcoins. So every single one of you every single one of you should get one. Although, I know it's expensive, so I I put out the plan on how to build your own. So you can just take a single sheet of plywood, cut it in the sections that I drew up, and build 1, and run an s 9 off 120 volt in your garage or wherever. And you'll get the sound kill. You'll get all the, you get you get to be on the black market, like a true Bitcoiner. So go do that. That's why it's called the black box.
[04:26:30] Unknown:
Oh, yeah.
[04:26:33] Unknown:
Oh, and oh, sorry. And and and I there is a promo, if you go to our web store, type in freaks, as a coupon code, you get a further discount off bundle. So so a little bit extra off. It's a promo on right now. So Freaks.
[04:26:49] Unknown:
Steve was in Texas last week. Big recruiting trip. When are you moving?
[04:26:54] Unknown:
It was a bit of a exploratory trip. Yeah. There's a lot of action in Texas. I'm stuck up in Canada. I don't know how I got here. I guess it's a different story, but, Canada is, not great for business right now. So we were checking out Texas for the oil and gas Bitcoin mining stuff.
[04:27:14] Unknown:
What about Nashville?
[04:27:16] Unknown:
So, I wanna go to Nashville. I met Peter McCormack last night, and he invited me there. So I might go in August. And actually, I heard Nashville is rocking. You guys do a good job at your meetups. Yeah. They're awesome. And Thomas, one of my favorite guys at Bitcoin, Marty's a good boy. Fucking awesome. He's from tenant he lives in Tennessee now. And from what I see, it's just a glorious place. Yeah. It's a glorious place. Yeah.
[04:27:43] Unknown:
Well, lots of people are moving there. Right? I mean, you got already, like, the Bitcoin Magazine offices headquartered there. Mhmm. And, not to talk to anybody else who's living there, but a lot of cool Bitcoiners, apparently are moving there.
[04:27:57] Unknown:
Yeah. But all the cooler Bitcoiners in Austin. So
[04:28:01] Unknown:
I'm kidding. People think this conference is bad. Wait for your WEF conference that's coming to town. Is that a WEF plus CoinDesk consensus? Yeah. Talk about being tone deaf. WEF and CoinDesk? Yeah. World World Economic Forum. Have you heard of them? Who is Klaus Schwab? Who is Klaus Schwab? Nobody knows.
[04:28:22] Unknown:
He's got he's a he's a shady character. Is he the emperor, or is he the is he the sith, or the is he the That's the he's the public. Like, we don't know. That's the that's the only question. We don't have to get into that though. We've got 10 minutes and 30 seconds left. We usually open it up to q and a at the end here. There's a lot of people. If any of you guys have any questions, do we have any mic stand out, or are we just standing up and screaming that?
[04:28:45] Unknown:
Do the shout outs.
[04:28:49] Unknown:
No wonder the vents are here. We That's it. I don't have them on. Why don't you just read the shout out you put in there? Yeah. Ben Yeah.
[04:28:59] Unknown:
I Actually, yeah, I had to reach out to 2 freaks and tell they DM me after. We usually don't do the shout outs at the live show. It's just it's not, not enough time.
[04:29:07] Unknown:
What's the most underestimated announcement this week?
[04:29:10] Unknown:
Underestimated announcement this week. The moment. What is the most underestimated announcement? It hasn't been made yet.
[04:29:20] Unknown:
Are you announcing the announcement now?
[04:29:22] Unknown:
Matt just did. The, What? What is the most underrated announcement? I don't know. Maulers. That's hinting here.
[04:29:31] Unknown:
Did you guys talk about the Cash App? I thought that was pretty cool. A lot of easier onboarding, easier user experience. Seemed like some good stuff. And lightning deposits. Right? Yeah. The dual, like, make it easier to to pay. I mean, we're we've been talking about this a lot, but I actually had a conversation with Danny. He's working on the Cash App wallet, and it's
[04:29:50] Unknown:
it's really cool just how much they've simplified the UX of pointing, your your camera at a QR code. It doesn't know if it's a Fiat QR code, an on chain or a lightning code, it just works. It picks up whatever it is and sends what it needs to. Let's give a shout out to to Cash App for really pushing the UX barriers
[04:30:10] Unknown:
around Bitcoin usage. Yeah. I mean, Miles was great up there. He fucking killed it. Yeah. With with absolute legend.
[04:30:17] Unknown:
Disclaimer.
[04:30:18] Unknown:
They used to be a sponsor. They're a sponsor of the stage. And the stage.
[04:30:21] Unknown:
Yeah.
[04:30:24] Unknown:
Underestimate. Yeah. I mean, I always hope maybe
[04:30:28] Unknown:
Aaron Rodgers in StackSats. That's boss. How's that make you feel? It's 2 years since stacks stacks ads first came out. Now it's just whatever.
[04:30:39] Unknown:
Just everyone's stacks that We're gonna move to bits, though, dude. We're move yeah. Right. Yeah. Are obsolete, and we're moving to bits. I was expecting I was expecting another nation state to announce here, so maybe not an underestimate. Well, Sampson had, like, an overestimated
[04:30:53] Unknown:
announcement. What was it? I I mean, it was just, it's like an island, like a little island off of Honduras.
[04:31:05] Unknown:
Prospera. Prospera.
[04:31:06] Unknown:
Right. Prospera.
[04:31:07] Unknown:
They're like everyone thought that was gonna be a whole country. I think we need more whole countries. I think El Salvador is out on a proverbial island. We're used to whole countries now. You know? It starts with islands, man. It starts with islands. Islands. Gross from there. Fair enough. Fair enough. I mean, I would love for, like, the US or Canada to just come out and be like, we're not gonna do anything. Run free with Bitcoin. Use it as you please. Which is who was I talking about this with? I was Mark Moss. I was talking about it with Mark Moss yesterday. Like, that's the way it should be. Like, we shouldn't have to wait for permission from the government to use Bitcoin the way we want to. Like, it's the way America the ideals it was founded on, I think, we should just be able to do it freely. It doesn't strike me as organic to expect countries to, like, states, like, governments to adopt it.
Doesn't seem Yeah. The incentives and game theory is not exactly Yeah. Exactly. You don't, yeah, you don't want whole nation states adopting. You just want their citizens to be feel comfortable adopting it and use it as they they want to.
[04:32:09] Unknown:
Especially if they have a money pre machine. I guess it was kind of a no brainer for El Salvador, though. Right? Because they were using the US dollar. They didn't even have their own currency. Yeah. And then the Federal Reserve is just printing out that 1,000,000,000,000 of dollars of money, and they're getting inflated and no benefits at all. So it's got, like, a very easy decision for them. Right? But most other countries that are printing their own currency, it's against their interest to They're slaughtering their own golden goose in a way. Right. So I guess for El Salvador, they already that that their golden goose already, got slaughtered internally before that,
[04:32:41] Unknown:
so it was a lot easier for them. Do you have any thoughts on this, Greg? Yeah. I mean, I think,
[04:32:46] Unknown:
you know, I think they're certainly early for their time. I don't think we expect any other countries to announce, certainly in the next few days. And there are a lot of downsides when a country does this. Right? There's a lot of custodial wallets. There's a lot of, you know, kind of implementation issues of trying to build dissent on a wider societal level. So as you were saying, Marty, it's almost better in a way that we have this kind of organic growth where it takes time, yes. But by the time that a government eventually says, you know, we're gonna use this thing, well, a lot of people are already using it, but using it in the right way or at least able to tell their friends and family, this is how you should do it. Don't just use the government's wallet, but, you know, use your own own wallet. And I think that that's, you know, so that's gonna happen anyway. So I'm I'm I'm not too fussed at the rate of country adoption because as you say, I think it's happening anyway. Yeah. Raise your hands if you've been to the Bitcoin bazaar in,
[04:33:41] Unknown:
in the conference. Okay? Raise your hand if you spent Bitcoin in the Miami area. That's pretty awesome. Like, I love that we have both the circular economy here. I love that we have every everywhere around this conference, you can pay with Lightning. And a bunch of different companies and groups of people have been onboarding businesses in the in the surrounding area. I mean, we were at a bar last night that was onboarded that accepted Bitcoin. Dude, it's crazy.
[04:34:08] Unknown:
My flight from Austin yesterday came in, and there's a few of the On Chain guys on the flight as well. And Tyler, who created the intro to our podcast, was going to a hotel right down the street. So we hopped in an Uber. We shared an Uber. And then somebody, coming to the prior? Prince, like, was, like, are you guys going to South Beach? This is probably not what you should do if you're a Bitcoiner. He was, like, can I hop in the Uber with you? We're, like, yeah, hop in. And he like, we like split the, he was like, I'll pay you over strike. I was like, yeah. Here's a lightning invoice, and then he paid me in the Uber. It's like as soon as I landed, ran into a Bitcoin or was willing to, like, pay me in sats to split an Uber. It was pretty cool. I think, like, the I have the opposite strategy. When the Uber driver asks me if I'm the Bitcoin, I'm, like, what's that?
[04:34:50] Unknown:
Bytecoin?
[04:34:51] Unknown:
That's why you show them a shitcoin just so you for good offset purposes. I I don't own any of that. Tron is the future. He just doesn't do anything to you.
[04:35:01] Unknown:
Yeah. It's it's really cool to superliver. Shout out to, like, Ibex and Oshii who've been going Oshii's
[04:35:06] Unknown:
Michael from Oshii just fucking never stops. Yeah. He never stops. Ibex has onboarded 40 merchants. I mean, IBEX and Oshi also work together. So it's very complimentary. I mean, one of the most bullish fundamentals of this year period is I really feel like there's starting to be real momentum on a proper Bitcoin circular economy. And I'm being cautious about it because there were false starts in the past. I mean, yeah, it was a big meme in, like, 2013, 2014. Hey. What about BitPay adding lightning? Do we care? No. Too late.
[04:35:40] Unknown:
Nicholas and the BTC paid server team obsoleted them, so it's so funny.
[04:35:45] Unknown:
Do you have to do KYC before you send them lightning stuff? Do you is it is it, like, a threshold? I've never spent to a BitPay merchant.
[04:35:53] Unknown:
Well, they don't even give you, like, a QR code, do they? They make you I mean, they don't give you, like, a Bitcoin address to pay. Do they give you, like, a lightning? I don't know. I have no idea. Yeah. Who cares? Is anybody using BitPay?
[04:36:04] Unknown:
I think a lot of people are. Right? Use BTC Pacer. Raise your hand if you use BitPay at your business.
[04:36:10] Unknown:
Zero. Zero hand. Somebody's pointing at somebody over there. It's like a pretty
[04:36:12] Unknown:
Somebody's pointing at somebody over there. It's like a pretty day it's a pretty day to day to day. Shame. It's kind of a mean it's kind of a mean question. Raise your hand if you've have you spent at a BitPay merchant in the last year?
[04:36:25] Unknown:
It's a few hands.
[04:36:28] Unknown:
Did they just give you an invoice? PIP 90? What yeah. Got it. So he's saying it's it depends on the merchant. So Some just give you a Bitcoin address. Yeah.
[04:36:46] Unknown:
They'll still catch it up. But there's other merchants that just use, BTC pay server, like, you know, to book your your flights or hotel. There's so many places you can go now.
[04:36:55] Unknown:
100%. So, guys, I mean, we have 2 minutes left. I think we should probably end it with final thoughts. But before we do before you all, like, jump out of your seats and stuff, we have a ride or dive freak here who's going to perform for us, captain youth, in 2 minutes after we do our final thoughts. So, I'm very excited about that and, looking forward to that. So, Craig, you wanna start with final thoughts?
[04:37:20] Unknown:
Sure. So, I mean, great to be here. And I just really am inspired by the number of people that I've met and feedback that I've got. It's great to see in person the kind of passion that people have. I'm living in one corner of continents in the world where bitcoin is not a general topic, let's say. And coming out here, you can really experience the kind of passion and enthusiasm that people have in the space, and that gives me energy to do what I do. So, yeah, it's been great to be here so far.
[04:37:57] Unknown:
Thanks, Craig. Wes, final thoughts.
[04:38:00] Unknown:
Yeah. I mean, it's been, Miami's been great so far. We started off with the beef steak, and that was amazing. Beefsteak's always special. Who who went to the beefsteak?
[04:38:08] Unknown:
Yeah. Marty, why is your hand up? Yeah. That's that's the best that's the best bet. Pregnant wife. I've had I tweeted, I have beef steak FOMO. I have poor FOMO. Yeah. But you were missed. Everyone that was asking me about you, I had to answer that question, like, a 100 times.
[04:38:23] Unknown:
Thank you for missing me, Franks. Yeah. Yeah. Beefsteak was awesome, and, you know, this open source stage was awesome. Like, every talk is these are this is the signal. Right? These are the people that I wanna, listen to and hang out with. I don't know what's going on in the other rooms. I'm not paying attention. But
[04:38:40] Unknown:
Yeah. Steve?
[04:38:42] Unknown:
Well, I'm happy to be up here. I I listen to you guys. I do a lot of driving in Canada from Calgary to Lloyd to oil wells, whatnot. I listen to you guys all the time. So appreciate having me up here. Me and Marty were shooting guns on a Texas ranch the other day. It was epic. Steve illegal guns that we wouldn't build, not US illegal, but Canadian illegal. So it was a special experience.
[04:39:04] Unknown:
Steve had a cathartic experience on the gun range on Sunday. I've got picture of him. He's got the biggest shit eating grin on his face.
[04:39:10] Unknown:
FN scar, man. Oh my god. There's a Guns and Bitcoin conference coming up. I don't know. Are you guys going to that? Guns and Bitcoin? Oh, yeah. I'm like, I want to. Yeah. I'm speaking at that, in a few days. Oh, awesome.
[04:39:23] Unknown:
It's down here in Miami. Right? I mean, they're great dudes over there. Yeah. Do you have any oh, yes. That's it. Virginia. Why don't you go first with final thought? And what what are you hoping? I wasn't gonna do final thoughts, but we've been working with the Bitcoin company, and we've turned that honey badger they've turned that honey badger that we used to have on our T shirts before Marty nuked the store because he was scared we were gonna be ledger hacked. And proceeds are going to Open Sats, them and us. It's a it's a three way split. Yeah. Shout out to my So it's pretty dope. This is the first time I've ever seen it in person. Shout out to my roommate, Braden, out of college who made that design. And shout out to Max who made this 3 d print. It's it came out great, dude. I know you just walked up on stage and I had a hot mic, but it came out fantastic. Final thoughts?
We're gonna win. We're gonna win. Let's fucking go. Thank you, freaks. Here comes captain youth.
The power of open source and the importance of supporting open source projects and contributors
The role of maintainers in the Bitcoin Core code base
Different components of Bitcoin Core, such as consensus engine, p2p, mempool, wallet, and GUI
The need for more engineering-driven processes in Bitcoin Core development
The benefits of having multiple implementations of Bitcoin, such as Bitcoin knots
The potential evolution of the Bitcoin Core repository, including separating the wallet into a separate repository
Ways to grow the developer ecosystem in Bitcoin Core, such as PR Review Club and providing more resources and funding
The bottleneck in Bitcoin Core
Introduction of panelists
Explanation of TBDex
Censorship resistance in Bisc
Censorship resistance in Bisk
Privacy concerns in Bisk
Importance of decentralized exchanges
Decentralized identity and DEX
Improving Bitcoin development experience
Accommodating different programming languages
Bitcoin design community
Difference between UI and UX
Collaboration between developers and designers
Applications built with BDK and LDK
Soft forks and unanticipated consequences
The promise of software and the impact of incompatible changes
The challenges of introducing hard forks and the importance of buy-in from the Bitcoin investor group
Trust in multiple entities in DLCs
Payment for oracles
Compensation for oracles
Use of oracles in derivatives contracts
Different ways to find each other in a decentralized fashion
The mission of the project
The ability to run multiple node implementations
The concept of the embassy as a personal private server
Texting Barstool to get podcast on podcasting 2.0
Blockstream and Breeze announcement
Bitcoin's resilience and adoption