Blocktime
Your go-to Bitcoin podcast hosted by Pierre Rochard, VP of Research at Riot. Tune in weekly for thought-provoking discussions, exclusive interviews, and a deep dive into the disruptive power of Bitcoin.
Instagram:https://bit.ly/BlocktimeIG
Facebook: https://bit.ly/BlocktimeFB
X: https://twitter.com/BlocktimebyRiot
YouTube: https://www.youtube.com/@RiotPlatforms/podcasts
Blocktime
Episode 30: Tobin Harding's Journey Through Open Source Software & Bitcoin's Core Challenges
Tobin Harding takes us behind the scenes of his coding journey in Episode 30. Tobin conveys the profound impact of this collaborative ethos on his approach to development. We also tackle the critical role of the kernel, the correlation between hardware and software, drawing attention to the necessity for durable, high-quality code.
Our conversation culminates in a thought-provoking exploration of Bitcoin's future, including its scalability and complexity. The million-dollar question arises: Can Bitcoin achieve widespread adoption without overwhelming users with its technicalities, akin to the seamless use of the internet? Pierre and Tobin debate the delicate balance between sophisticated features and maintainability, touching upon the importance of trust in Bitcoin's cryptographic fortitude and the potential for custodial services to cater to diverse user preferences.
Follow Blocktime on Twitter: https://twitter.com/BlocktimebyRiot
Follow Blocktime on YouTube: https://www.youtube.com/@RiotPlatforms/podcasts
Welcome to the Block Time podcast produced by Riot Platforms. My name is Piero Chard and we're joined today with a guest on the other side of the world, Tobin Harding. Welcome to the podcast, Tobin. How are you?
Speaker 2:Very well, thank you. Thanks for having me.
Speaker 1:So this podcast has been a long time coming. I've been wanting to record something with you since we met, probably a couple years ago.
Speaker 2:Awesome.
Speaker 1:So to give some context to the listeners, a long time ago I worked at Kraken, a large exchange, and sadly, someone we were recruiting ended up having terminal cancer and passing away and that we wanted to remember his memory by contributing to the open source ecosystem that he was contributing to.
Speaker 1:This was Tomas Bloomer and he was a great bitcoiner, contributed a lot to the space. So at Kraken, we created kind of a memorial open source grant and we had a very competitive process to identify who would receive it. I worked closely with Andrew Poulstra from Blockstream, who has contributed in the Rust Bitcoin ecosystem and kind of wider protocol research. So, tobin, you really stood out as kind of the perfect person that we wanted to fund with this grant and then eventually transitioned the grant from Kraken to Riot. So we're excited to be awarding you this grant for the coming year or this year, I guess, now that we're in 2024. So I can talk about why I thought that you were the perfect recipient, but I'd rather have you do the talking of kind of going through what your approach to software engineering has been and why you've been excited about contributing to the Rust and Bitcoin ecosystems.
Speaker 2:Cool big question. Well, I guess I should say that it was pretty surreal when I first got contacted by you guys, when Kraken first contacted me, and I was pinching myself right up until I got the email saying that I was accepted and that you gave it to me. So that was pretty crazy. I didn't understand why there wasn't someone else, like you know imposter syndrome. So then I guess later I heard that I was the most enthusiastic bloke, which is interesting, and so I guess I must say that I got started in Linux kernel programming and that's where I learnt all my lessons cultural lessons in software engineering, in free software.
Speaker 2:So really I owe a debt of gratitude to those guys, and any good work I do is because of what I learnt by those guys. So Greg KH in the staging directory of Linux kernel, taught me a lot how to do PRs, how to do the right thing, how to fail in public and that sort of thing. And that's the big thing write code and give it away. So yeah, that's why this is so meaningful to me. It's the hacker ethos write code and give it away, and that's what it's about.
Speaker 1:Yeah, do you want to talk about kind of the free and open source software movement from a philosophical perspective? Because I grew up listening to Richard Stamman lectures about this topic and I think that it's a really important one for kind of more of a mainstream audience to learn about, especially in the context of Bitcoin.
Speaker 2:Yeah, I was actually just thinking about this the other day, so a long time ago, I read a paper called so you Want to Be a Hacker. And just for anyone that doesn't know, hacker is a programmer. That was our term first, and then it got taken by the mainstream media for what we call crackers, for people that steal stuff, and a hacker is primarily someone who solves hard problems and gives away their solution. And, yeah, that idea came at least to me, came from that paper. So you Want to Be a Hacker, and he had a list of things how you become, how you can become one, and one of the things with this subculture is you can't really refer to yourself as one. You become one once someone else thinks you're one.
Speaker 2:So there was a list of things learn this language, learn this, do this, do some functional programming, all these things. But yeah, that paper really hit me and I was like I don't know how to get started on step zero. So that stayed with me for a long time. And then, yeah, I read the other, the Cathedral in the Bizarre Paper of Richard Storman, and then another book that was really instrumental for me was the Art of Unix Programming and yeah, that's really a cultful book and yeah, those things are deep and some of the new kids in Bitcoin don't really know about that stuff so much, but yeah, that philosophy is really deep.
Speaker 1:Well, it's astounding that in 2024, we are mostly still using the POSIX standard when we think about what the internet infrastructure is running on.
Speaker 2:Yeah, we're still using code written in the 70s. That's still bug free. It's like crazy.
Speaker 1:It just goes to show that if you put in some quality caratsmanship you've got the right approach to it, that it can withstand the test of time.
Speaker 2:Yeah, I don't know how they write that code In C line by line and without bugs. I don't know. It's crazy.
Speaker 1:Maybe it's that they had a lot more time to think about it, because it wasn't like today where you just throw open the word processor not the word processor, the IDE and you can just start running code, even in the cloud. You don't even have to set up any infrastructure. Back then it was probably more like punch cards.
Speaker 2:Yeah, but I can spend three hours on three lines of code and come back a month later and go. What was I doing? Why did I write that? That's ridiculous. And yet it's in a like. Rust is so much safer to use, our tooling is so much better, yet those guys were writing code. That was just amazing. I don't know why.
Speaker 1:I want to kind of dwell. You mentioned that you cut your chops on the Linux kernel. Do you want to kind of explain what a kernel is in an operating system and kind of what its functionality is and how important it is for that?
Speaker 2:Sure, so the kernel or the operating system is the bit of software that talks to the hardware. So the idea is it's about abstraction. If a user wants to print something, then you don't want the user to have to tell the printer how to put ink on the paper. The printer should know how to do that. And you don't want to tell your machine how to talk to the printer, so the machine should know how to do that and the operating system wraps up all that sort of thing and then, as well as peripheral devices, it does memory management and that sort of thing, so all the stuff that the user shouldn't know about. So the applications above can just talk to the user.
Speaker 1:And Linux in particular, has had a tremendous growth trajectory over the past several decades. So, starting out as really as a one man project right Linux, torvalds and now it's grown into kind of a multi large corporation project.
Speaker 2:Yeah, it took over the world. It was the test, right? Can we write better software open source? Can we write free software? That's better, and for some types of software the answer was yes.
Speaker 1:And he also wrote the version control system around it get get.
Speaker 2:Yeah, he started get. A lot of other people worked on it since, but yeah, he kicked that off too.
Speaker 1:That's like having two tremendous software engineering achievements, which is astonishing for for somebody to do yeah, definitely.
Speaker 2:There's a fun tongue-in-cheek Quote from him. Someone asked him why did you call it get? And he goes. I know more my projects after myself.
Speaker 1:And now everybody uses get right, get hub, get lab all of these Goosies are on top of this. Get functionality. That that came out of that.
Speaker 2:Yeah, definitely.
Speaker 1:And did it have to do with the size of the Linux kernel that he needed or that ecosystem needed a different version control system?
Speaker 2:The. When git came in it's a bit before my time, but there was some politics going on and there was the version control they were using was closed source and there was a bit of um kaphuffle about that. So he's like he just three sands up there and goes let's do this properly.
Speaker 1:Yeah, there's always Some incrementalism within the free and open-source ecosystem of okay, well, you have an open-source kernel, but this particular driver has a binary blob in it and we need to eliminate it. Right? They're always trying to find proprietary things to replace.
Speaker 1:And it'd be remiss of me not to mention that github is closed source and it's dominating the open-source software, which is not totally sad it is, but the architecture is nice in the sense that you still have your local git repository that you're, you know, pulling from the remote to, so I feel like it's on my hard drive. It might give me a false sense of security.
Speaker 2:Sure, but it feels like a lot of developers are relying on the tools myself included github actions as all CI now and Like people review in the web UI without pulling patches down onto their machine. Yeah.
Speaker 1:Yeah, so I'm sure that Somebody will be inspired to create a open-source clone. But then the challenge seems to be and I think this is something that Richard Stalman pointed to which is the network effects of once you have a server client model, then it becomes a lot more challenging for kind of the whole stack to be open source. The Linux kernel is written in C, correct? And my understanding is that your focus right now is on rust. Do you want to explain kind of why you went from C to rust in your approach?
Speaker 2:Sure, probably. Quite another friend I know who said writing C. If you write C, the problem has to be fun. If you're right, rust, just writing it is fun. So it's like it's a fun language to use and that attracts. I think that's important, it's not just a gimmick, it attracts developers that care about stuff. So you're not going to spend you know a multiple, you know three days working on three lines of code. If it's not fun, it just it doesn't happen. It's part of the free software thing where people are working on what they want to. They started off working on what they wanted to On the weekend, so it had to be fun.
Speaker 2:And it seems that in creative work we produce different things when we're enjoying doing it, and Now we all do it as a living. But still there's a fine line, like a lot of us, when we're not looking after our kids or at work. You'll find us at work like Like fiance constantly walks in, he goes what are you doing? And I go work and she goes. But it's like Saturday and I go. Well, it's kind of not how you, what you mean by work, but like I'm at the computer doing the stuff that I do for work. So yeah, so anyway, back to rust it's.
Speaker 2:It's an interesting language for that reason and it has a lot of technical merits. But everything has technical merits, so like geeks can argue about that all day. But I think it's really important that it is fun to write, so it produces a certain in a certain kind of work and it attracts certain developers. There's some really hard, really annoying things about it and it, like it takes a long time to learn and, yeah, there's a lot of it has, you know, some sharp edges still. So if you don't enjoy it, I don't see the reason to do it. It's quite slow. It can be quite slow to develop in.
Speaker 1:And what about? It makes it fun though.
Speaker 2:I might. It's just my personal opinion. I think they got the right mix of functional and imperative languages. So functional programming has always been excuse me, functional language has always been like this really cool, geeky thing that is just like massively interesting and very fun, especially if you like, like math, but Without offending anyone. We never got that much done. But rust, in my opinion, got the mix right. So, yeah, you can get a little bit functional, you can really have fun, but you can also write it totally imperative if you don't want to write functional at all, and Depending on how much work you need to get done right now, you can. You can change, but that's yet totally subjective.
Speaker 1:I see that makes sense. And for those who are Not familiar with imperative, do you want to explain kind of the difference between functional programming and imperative programming?
Speaker 2:Sure, imperative programming is more like a recipe for a cake do this, add this, move this over here. If you need to go back to step one, that's fine, you know, and then you're done. Functional is Like a whole mathematical thing. You've got this list and we'll do some crazy things to it. You can move it, you can start here and then do the next one, the next one, the next one, and when you're done, magic happens. And yeah, I can't really explain it, but there's like people that, yeah, there's been books written about it in like co and style, like it's a crap, it's amazing, but it's like pure geekness. You can get a lot done without ever learning functional languages.
Speaker 1:Well, every programming language has functions in it, right, and is it really about the chaining them together?
Speaker 2:So has functions, that's, if you take the word function out and call it a sub routine, then it's clear as those Imperative language has sub routines. Do this, call this sub routine in this sub routine, call this, do that. But a functional language is a mathematical concept, I believe. I'm a bit sloppy on the definition, but it's about. It's about lambda calculus, like it's a different style of math, it's not. Yeah, so that's not the best our description, but yeah, it's all right experience, learning and.
Speaker 1:As you can see, I haven't fully learned it. We like to explore the outer edges here on this podcast, get in depth, because the other part in my mind is about Whether it's stateless or not right, whether there's, it's a pure function or these are things I've read, but when I'm programming, I'm just trying to hack it together to make it work right.
Speaker 2:Yes, yeah, yeah, so you're right. A pure function doesn't do, just takes in inputs and returns outputs. It doesn't change any state. That's true, that is one of the reasons why functional languages are hard to get things done, because it's hard to get anything done if you can't change the world.
Speaker 1:Right, and my personal area of interest is in databases, so I actually like state a lot. It's just, I guess, a different way of looking at the world.
Speaker 2:Yeah, if I can program my whole life and not touch a database, I'm happy.
Speaker 1:I'm the opposite. I'm like how do I put all of my coding into like Postgres SQL queries? All right, how do I get more?
Speaker 2:That's why I think it's important we have different developers, because there's different tasks than they're doing and not every developer is suited to every task.
Speaker 1:That's right. That's right, it's different personalities create a composite.
Speaker 2:Yeah, yeah, I have found this last couple of years that, like, because Rust bitcoins are library writing, a library is very different, it's different to writing a kernel and it's different to writing an application, and there's you know, there's things that are specific to library writing.
Speaker 1:Yeah, so on that, I think that people sometimes view Bitcoin development as very monolithic and kind of they zero in on, specifically, the Bitcoin Core repository, kind of what is the descendant of Satoshi Nakamoto's code base. But if we look horizontally, there's lots of other software ecosystems that are focused on Bitcoin that are just not the C++ reference implementation. Do you want to kind of give us a lay of the land from your perspective?
Speaker 2:Sure, yeah, that's an interesting one. So there's like there's Bitcoin Core, the software that people run when they talk about running their node, and there's people that work on that, that are called core developers. But core is this thing that means like the center of the system. So the Bitcoin node is at the center of the system because you yeah, but there is libraries below it, like there's Libsec P, which does the cryptography, and that's written in C as opposed to C++, and then there's all. There's other people writing libraries like Rust, bitcoins in Rust, and there's all different.
Speaker 2:All the bunch of other languages have a library and that's for writing any application that wants to interact with Bitcoin in your specific language. You'll use that one of those libraries. Typically, you can write the whole thing from scratch if you want, but if you want to use a library, that's what they'll usually be one. So there's a bunch of application developers writing a bunch of in a bunch of languages, writing Bitcoin applications, and then there's a bunch of library developers creating libraries, and then there's Bitcoin Core and C++ and there's a few other people doing, you know something, some implementations to, but we tend to we seem to have focused on just one, and then there's some low libraries as well, yeah.
Speaker 1:That's really interesting Because earlier you mentioned, the kernel is abstracting from the hardware to essentially what the user can interact with. Now there's lots of middle where there's lots of applications in between. But if we, if we kind of look at the abstraction concept of, hey, let's take something that is very nitty gritty, detailed and let's step back and build an interface to it that is easier to interact with, that, essentially, is what a library is aspiring to do at the very least, which is OK, big Indian, little Indian, let's kind of hide that behind a wrapper so that you can create Bitcoin transactions. You can, you can develop a Bitcoin wallet without having to develop something that's interacting with the Bitcoin network or Bitcoin data structures in a very kind of detailed way.
Speaker 2:Yeah, most definitely that's. That applies to all. Like all libraries, right, their libraries are always trying to abstract thing. An interesting thing that I've discovered in the last year is, at least at Rust Bitcoin, what we're trying to do also is abstract away some of the prickly bits of Bitcoin. So the thing that comes to mind straight away is lock times, and if you read the, because we had locked time. We had one lock time, then we created the second lock time. There's a few edge cases and it's kind of hard to get it all worked together. And so at Rust Bitcoin, what we've tried to do is present to application developers a more sane surface area without them having to spend three days reading the bit and make sure they've got everything right, and that seems to us like it's a.
Speaker 2:It's useful to do for a couple of reasons. One, it saves a lot of people time. You know, if everyone has to read the bit for three days, that's a waste of everyone's time. But also, if you don't, you know you just want a quick thing that work, that is going to work and is not going to lose people's money quickly, you don't want to have to know every single edge case then the library should provide that. That's what. That's what we're hypothesizing. It's a little bit difficult because there's a, there's a line. You know, is this an application developer who's been running Bitcoin code for a year, or is this guy been going for 10 years and he really wants to be able to do everything? So yeah, it's a, it's a fine line and we're still finding it, but it seems to be a useful thing to provide.
Speaker 1:Do you want to explain what a lock time is for those not familiar with the I should have mentioned it.
Speaker 2:Sure, like a lock time is a way to encumber a UTXO in a. So you normally encumber coins with a key you give. You can sign with this key, then you can spend the coins. A lock time allows you to say if you have this key and it's after some amount of time, and then we have relative time for a number of blocks and we have absolute time after this block.
Speaker 1:So check sequence verify was the relative one. Is that right? Or check lock time verify, kind of highlighting the issue here.
Speaker 2:Yeah, yeah, yeah, that is, this is the exact issue. So, yeah, every time I mention them, I have a comment. This is CSV, sequence of CSV, because it has an S in it. The other one is CLTV because it has it's the absolute lock time and, yes, csv is relative lock time. But yeah, like I wrote these modules and a month later I looked at them and I still have to think about it, like to review code that touches those takes me ages because I have to go back and read over it all again. That's why it's a time drain and it's really hard to mention.
Speaker 1:What wasn't there also something about? It can either be a block height number or a date time stamp.
Speaker 2:Yeah, so humans used clock time, and that's silly when you're trying to be programming, because Bitcoin only has blocks, and so we have this 10 block window, 10, and we get 10 blocks, and then we average the time and it's called something medium time or something. It's just so humans can talk about time, but time doesn't exist. You know, time's an illusion, so, but we cater to this, even though we should only have blocks. But you know humans when you use computers too.
Speaker 1:Yes, and it's. I think it's second since 1970. Yeah.
Speaker 2:Unix epoch. That's like the most clear, non confusing thing of the whole. The whole system, yeah, but basically it's a conceptual problem. Right, people want to do, I want to do it in 15 minutes. That sounds like a sane request, but it's not a sane request. In Bitcoin, but we can do it, but it always causes problems, in my opinion.
Speaker 1:Yes, and for those not familiar with Bitcoin, block times have a high variance to them, so there might be an hour between two blocks or there might be seconds. It just depends on the luck of the draw for the Bitcoin miners hashing.
Speaker 2:And, amusingly, a block can arrive that claims to have been mined at one time and the one after it can claim to be a mine before it, even though it's a block after. Yep times an illusion.
Speaker 1:Now, what is not an illusion is the block height.
Speaker 2:Correct.
Speaker 1:Unless there's a reorg.
Speaker 2:Yeah, but if we go back a few blocks we can count from them.
Speaker 1:So that's really interesting. And now, before you were working on this issue, I mean just in general, do you wanna give a recap of kind of the improvements you've made to the Rust Bitcoin library and where it's at today and kind of what use cases it enables?
Speaker 2:Yeah, so what we're trying to do is create a library that's useful. We're trying to create a library that's like we just discussed, can be used by application developers, can be. Hopefully they can use it to write bug free software, because in this case bugs means you lose people's money and we don't wanna do that. So can we do that? And it's an open question, right? It's software has bugs in it. So one of the things is to make the abstractions clean. So we're doing that. And then to what else could I say yeah, so we're trying to make abstractions clean, make the abstractions useful, and then we want people to be able to use it.
Speaker 2:And so now we get into some technicalities where, if one project's using one version and another project's using another version, there becomes a little bit difficult. So in order for improvements to come in, there's a whole chain of events that has to happen and we're trying to make that easier. And so that's an airy-fairy way of saying we're doing a lot of engineering. That doesn't look like we're doing that much, but I like to think that we're doing a lot because we're solving these problems. That can bite people very hard If we write some software and no one can use it because of all these upgrade problems and things, and they're on software that we wrote three years ago. Then did the bugs that we fixed in the last three years matter? So, yeah, that's one of the problems we're trying to solve and some of this is related to the language. So we think the library's pretty much like 85% feature complete.
Speaker 2:You can do a lot of bunch of stuff. You can do most things with Bitcoin. You can do all the basics, but we're trying to make it easier to use. We're trying to make it better, faster, safer and we're trying to make it so that, yeah, different projects can use it over time and it not cause problems. That's kind of a hand-wavy answer.
Speaker 1:No, that's great, and I think that we should also talk about this library, as it's not just that you have to learn Rust in order to use the library right. There are bindings to other languages.
Speaker 2:So I hear I've not worked on it and yeah, that makes me very excited because it's cool that other people be able to use it. It's kind of nerve-wracking too, because there's constructs in Rust that other languages don't have and the language is really tied into the implementation, especially when we use type safety and things like that, and when it goes up to a different language it has different guarantees.
Speaker 1:That makes sense. And there's other libraries that build on top of a set of crates. I believe they're called.
Speaker 2:Yes, yeah, library crates, synonym in Rust.
Speaker 1:So I've seen lightning developers using it as well. So it's kind of a piece of infrastructure that is going to be underlying a tremendous amount of the ecosystem.
Speaker 2:Yeah, hopefully that's what gets us excited, but it also is a bit nerve-wracking, right? Yeah, BDK is a library for writing wallets. Ldk is a library for writing lightning applications. So there's these libraries stack up on top of each other, and Rust Bitcoin is lower down the stack.
Speaker 1:And below the stack on Rust Bitcoin. You mentioned LibSecP, which is for the signing and verification of what we traditionally think of sending Bitcoin. I think that at the user level, people kind of get confused of what a Bitcoin address is and how it's being used by the system. Do you want to explain, when you have a Bitcoin address and you are sending to it, what that means at a actual Bitcoin level?
Speaker 2:Sure, I was actually at a meetup on the weekend and I was trying to explain this. It's hard to explain when you talk to someone who doesn't look at data structures all day, because I look at these data structures all day and still, three years later, I quickly have to flick one open and go oh yeah, that's right, that has that in it, this has this in it. So one way I thought to explain it is when you have some coins Bitcoin, a UTXO, it's they use this word encumbered, those coins are locked by some rules. Now, typically the rule is can you sign? Can you sign? So do you have the secret key? So typically it's very simple do you have a key and if you have the key, it's locked and off you go.
Speaker 2:So for most people, you don't have to think about much else, but as soon as you want to add scripting capability and more interesting things, you have to. If you just think of this, you have some set of locking rules and so, yeah, that's what the lock times came in. That was another type of locking rule and you can have multiple keys, all the different locking rules, but conceptually you have some rule that locks this thing and if you can follow the rules. Prove that you can do the steps. Then you can send the Bitcoin.
Speaker 1:And how has that changed over time? I know that at one point it was like sent to an IP address or something like that that Satoshi was doing, and then we got to a hash of the contract of the encumbrance and now with Tapper. Has that changed a lot in the Rust library?
Speaker 2:It's definitely changed a lot. Taproot was a big deal. There was a lot of stuff to implement and I'd be lying if I said I was a taproot expert. So we changed a lot. We had paid a pub key and then we worked out we could just hash it and that was better, and we made these incremental improvements. But still, conceptually we had the encumbrance and normal people didn't need to know about it.
Speaker 2:But from a software engineering perspective it got more complicated and now you have multiple things. So the abstractions are much harder to deal with now. And then on top of that there's some things that we don't do much anymore. So we don't use uncompressed keys very much. We don't use paid a pub key anymore, really. Yet you still need to be able to do these. So one of the challenges we've had is how do we make a library that can do everything, but when someone comes to it they just can't see what to do because there's 3,000 things available and that's an unsolved problem.
Speaker 2:We're trying to simmer up things that are more useful, like SegWitB0 and TAProot, segwitb1. And how you do that, just from an engineering perspective, is reasonably difficult, because engineers are obsessed with doing things correctly and RustBit engineers are even more obsessed than normal and so, for example, we had this big problem which I just said. Then I misspoke a little bit. You might have heard but TAProot is SegWit, but it's SegWitB0 didn't get a proper name, it was just SegWit. So there's even confusion in naming things. Is it SegWit or is it SegWitB0? Is it TAProot? And when you have to debate all these things for a long time to get them right, it can get harder.
Speaker 2:And then is it wrapped, segwit, yeah yeah, it would be nice if that just went away. But it can't go away. Exchange will still use that constantly. Every time I send luck using exchange, I'm like why are you using that address for me? Oh, that's right, because you're still used wrapped. Yeah, it's crazy.
Speaker 1:But it's also, I think, a huge strength of the Bitcoin system, this approach of forward and backward compatibility, just to provide that developer experience where you're not having to constantly update your stack in order to stay on the Bitcoin network.
Speaker 2:Yeah, it's a strength and a weakness right. There's definite arguments for both sides. It kind of would be nice to chuck everything away and start again, but at some stage you can't keep doing that.
Speaker 1:No, not when you've matured, like Bitcoin has. But, that's an interesting challenge. I mean, I think that people want to have defaults. They don't want to face choices that are kind of over their heads in a sense. But yeah, I think that, or I hope that taproot adoption will continue and that'll be kind of the default at some point.
Speaker 2:Yeah, but for the simple use case like say would be zero is perfect, it's even a slightly smaller.
Speaker 1:It is. I think that when we look at it, it kind of has this negative externality on the privacy side of hey, it would be better if it all looked like taproot so that, but there's not an individual incentive for that.
Speaker 2:Yeah, that's one of the. That's one of the examples of it would be nice to chuck everything away If we just had taproot. We chuck, everything goes away. We could move, for everyone's, software would get so much more simple and it'll be job done. But we can't do that.
Speaker 1:Now maybe the incentive will be a positive one of hey, you've got cheap multi-sig with taproot and maybe multi-sig is more secure for a lot of users.
Speaker 2:Yeah, I'm not sure that normal people can do single-sig. Let's let multi.
Speaker 1:Well I tell people hey, you're already doing multi-sig. If you have two FAA right, you've got one signature coming from your phone, the other one from your password. But it's going to be quite a steep learning curve over the coming years as people on the board.
Speaker 2:Yeah, definitely, definitely.
Speaker 1:So what do you see on that note as some of the big challenges in terms of Bitcoin adoption from a developer perspective?
Speaker 2:Bitcoin adoption. From a developer perspective, the main problem with Bitcoin, in my not so humble opinion, is that you can't explain it to anyone without using a heap of words that they don't understand. It's almost impossible to open your mouth without just garbage coming out. There's so much stuff to learn. Yeah, when I came to Bitcoin, I didn't think it was very complicated. I was like, oh, I'd rather be a Kona developer. It's way more complicated. And then, after hitting enough a BIP's reading enough code, I was like, actually there is a fair bit of complexity here, and now I think there's too much. It's too much for the regular person.
Speaker 2:If you don't stare at this stuff all day long, there's just bits you won't know. There's bits of guys that have been doing this since like 10 years. There's bits they still can't remember or they don't know, which means it's complex enough for us engineers and too complex for users. Yeah, operating systems we manage to abstract them away. A lot of users don't even know that an operating system exists, and that's awesome. Yeah, I personally think that Bitcoin should be the same. Normal people shouldn't know it exists, and then that would be, and just let the engineers to do it and the people that really want to and then it's done. But yeah, it's too complex a system for everybody but that's probably an unpopular opinion.
Speaker 1:Perhaps because I've also heard the opposite opinion, that it doesn't have enough features. If we look at other cryptocurrencies that have way more complexity than Bitcoin does that, you know, those are what we should be striving towards. It's an interesting dichotomy.
Speaker 2:All right, I'm going to give another unpopular opinion that I'm way more comfortable saying those engineers should just totally go and work on other systems. Ours is already too complex. We want to cut things out, not add more things.
Speaker 1:That's fair Now, especially if there's a large amount of value relying on it, and also it's so. Do you think that the risk of the complexity is also shared at the cryptographic level, that there's too much cryptography going on? That was always when I was first learning about Bitcoin. I just knew that cryptography could be brute forced, and then I had a friend of mine correct me that no, there's strong cryptography that you know it would take far too long to brute force. Bitcoin is secure. Do you have any concerns in that area as well?
Speaker 2:I'm not a just carry out. I'm not a mathematician. I don't have concerns with using cryptography. That was invented in the 70s. I'm sad that we used a CDSA and didn't have snore from the start, but that's about the line, so about. There is good. It seems to be fine if Bitcoin breaks, like everything else breaks as well, and but yeah, I definitely don't think we should get tricky with it.
Speaker 1:Yeah, that makes sense and in terms of kind of the user experience, I think that there's a lot of folks who want to have the it's got the purest approach of each person has their UTXOs and they are holding their own keys, whether it's well both for mobile wallet and for cold storage, and the pushback on that is on the scalability side, that there's billions of people. We can't fit all those UTXOs and you know the transaction throughput and all of this. Where do you kind of see the scalability debate going for Bitcoin?
Speaker 2:That's. This is just thoughts just come to me now. I've been known to say that lightning lightning's no, not useful until people can use it without hearing the word channel. And perhaps you've just you've just raised him with this idea that maybe Bitcoin's not useful unless you can use it without hearing the word UTXO. So if we just go back five minutes to go, it's too complex for normal people. They shouldn't need to know what UTXOs are. The scaling problem should be an engineer's problem, not a user's problem, and, as far as I'm aware, it's unsolvable. There's eight billion people, there's not eight billion UTXOs. End of question.
Speaker 1:Yeah, it's like do people know about packets and TCPIP when they're using the Internet?
Speaker 2:And it's like silly to ask them to. It's like really interesting for people that are interested in it, right, it's not interesting for everyone else. I don't think everyone should be interested. They try to teach my kids programming. My daughter likes drawing pictures. She doesn't want to know how to program and like all the programming classes are not going to make her want to be a programmer.
Speaker 1:So is the outcome custodial.
Speaker 2:I don't know what the outcome is. I don't want to say what the outcome is. I think definitely a lot of people enjoy not having to take responsibility and, like I, enjoyed at times too. So we need to have both options. People should be able to choose. Yeah, there's got to be various, various solutions, various, you know. Different things for different people.
Speaker 1:Yeah, I think that's so. Key is that, if we look today, custodial is a solution for a lot of people, I mean, and with the issuance of ETFs here in the United States, I think that trend is going to continue, while simultaneously, we still are seeing new records of people using the Bitcoin network, and that there's still, you know, lots of people buying hardware wall. It's lots of people wanting to self-custody, being sovereign, run their own node, and so these two things are happening at the same time somehow.
Speaker 2:Yeah, interestingly, I was thinking the other day, when we say you should do XYZ with Bitcoin, we've already made an assumption that you should have savings. Some people don't even think you should have savings, like some people get their money unspended and that's the choice too right. So we've got this base assumption that you have savings. One thing we do that's interesting is try to explain to people that their house is savings, but it's savings because their money's broken. And, yeah, that's an interesting thing. That's not an engineering thing, it's a different aspect. One of the reasons I like Bitcoin is there's other aspects apart from just engineering.
Speaker 1:Yeah, the economic dimensions as they intersect with the engineering, I think, are unprecedented, in particular, when we think about the speculative aspect of Bitcoin. I don't think there's been a lot of people speculating on the value of a Wi-Fi router, right, oh you know. Or the value of an iPhone oh, it's increasing. So I'm going to buy 10 iPhones and then I'm going to sell them over the next five years and pay for my kids' college.
Speaker 2:Yeah, yeah, definitely.
Speaker 1:Yeah, this one.
Speaker 2:Sorry what I was going to say. That's one of the things We've invented, something that's scarce, or that's our plan, and so to me one of the interesting questions is can we not break it, can we not wreck it? And it seems how you wreck things is you get a bunch of people together and you let them argue forever and eventually the thing's broken. So it's like can we not do that as humans? It's an interesting experiment.
Speaker 1:Now, perhaps if everyone's busy arguing about it, then they won't change the code and Bitcoin will just continue to work.
Speaker 2:Hopefully, hopefully, I'm going to get so many bad comments to me.
Speaker 1:But I mean, it's like a miracle that it even works in the first place at all, that Satoshi Nakamoto launched this without any kind of. I know we've talked about some of the upgrades that have happened since Satoshi launched it, but I would argue that they're not systemically changing how Bitcoin works, and it's astonishing that it has operated for so long and has been able to upgrade the script.
Speaker 2:Yeah, it's no main fate, Definitely.
Speaker 1:And so on the Bitcoin node side, I'm curious do you think that the scaling limitations are there or that they're in the kind of more of the cryptography side, in the sense that we've gotten all the efficiency we can out of maintaining the UTXO set and processing a block and that anything that increases Bitcoin scalability is going to be about cryptographic magic?
Speaker 2:I think the solutions we haven't come up with yet. So, yeah, I try, I don't. It's just a personality thing. I like to think about what we've got working today as opposed to the future, and there's other people that only like to do research what's in the future, and I think those guys will come up with something that just other people haven't thought of yet. At the moment, the system works for the number of people that are using it and I don't know some number more. It works excellent and, yeah, sure, people can plan when the fees go up a little bit, but the whole system works. It's been working for 10 years and everything's great. So, from my perspective, everything's good. Just keep going, keep going along, like, keep New guys. Researchers will keep coming up with new ideas. People know about the problems and, yeah, if we just don't break it, we should be fine.
Speaker 1:Was it jarring, coming from Linux and seeing transaction fees. It was for me. I've never had to pay a fee to do app, to get install right Of. Hey, I'm using free software. Why Where's this money?
Speaker 2:going. Yeah, yeah, that's a fee is funny. And people talk about fees in their native currency and that's also weird and they're like fees are going up. Well, they're not really. There's some stats, you've got this data and you want to use it. So you know that guy gets some of the data, some of the gets some of the stats for that amount of data that you used. So from that perspective, it's not unusual. I find I'm often jarred in conversations when people talk about fees. That didn't really answer your question, but yeah.
Speaker 1:Well, we don't like to monetize in free and open source software, right, Like we're always trying to take down the paywall rather than put one up.
Speaker 2:Though strangely I'm less. I'm more comfortable paying fees than I was paying for cloud nodes, like I've paid $5 a month to have a cloud node sitting there and I'm like, but I can run that on my own machine. So, yeah, yeah, this, at least you see exactly You're paying for exactly what you get. You want to move this to here? There's a fee for that. So it's kind of cool like that.
Speaker 1:You mentioned the local currency. I like to remind people you know, if you look at it as sats per V-Bite, it's been a steady downward trend for the past decade.
Speaker 2:Yeah, thanks to engineers, exactly.
Speaker 1:Efficiency. Yeah, okay, so where do you kind of see the future for the library going and your hopes for the wider Bitcoin ecosystem?
Speaker 2:So I would hope I'd like to get to a place where people never no one mentions Rust, Bitcoin ever. It's just like there's a bunch of other interesting applications. Some people know they're written in Rust and then some people know those guys use a library and then below that library there's some other thing, but no one knows it always works. It's not annoying. You quickly look at the documentation, you can look at the source code and you just go yeah, that's sweet, Don't worry about that. Those guys have got that covered. And then they I'm in heaven then.
Speaker 1:And what would be your advice for somebody who wants to become a Bitcoin hacker and kind of follow your path?
Speaker 2:Well, I have to say, don't follow my path for your own. First, but read that paper so you want to be a hacker and then, if there's any new Bitcoin stuff to add, just work on something interesting. Find something you like and work hard at it.
Speaker 1:Excellent, Gabe. Did you have any questions? You don't know. I really sat back and enjoyed this high-level conversation of a lot of things that were quite over my head, but you guys seem to know what you're talking about, and that's awesome.
Speaker 2:So, yeah, just thanks. So much, tobin, for coming on. Thank you, cheers, it's been a pleasure.
Speaker 1:Yeah, it's a lot of fun getting to host a podcast that has electricians, economists, software engineers. We get to mix it up here on the block time.
Speaker 2:Nice, nice.
Speaker 1:Tobin, did you have any questions for us before we call it a rant?
Speaker 2:No, just like massive thanks. Like every morning, I get up and I get to come to the computer and I get to just work on something that's interesting and that's meaningful to me and hopefully useful. And that's all thanks to Riot Cheers. Thank you very much.
Speaker 1:Thank you, and I get to vicariously watch through GitHub notifications what's going on and it's very exciting to see kind of the thriving Rust Bitcoin ecosystem.
Speaker 2:Well, I'd love to say you filter sometime, because otherwise you'd be getting overwhelmed.
Speaker 1:I do. I'll admit I don't read every poll request, but I'd like to at least see, kind of where the focus areas are and what people are talking about at a glance. Awesome, awesome. Alright, thanks, tobin, and look forward to meeting you in person one day. Enjoy the rest of your day in Australia.
Speaker 2:Thanks, pierre, awesome Thanks for having me.
Speaker 1:Cheers.
Speaker 2:Bye.
.png)