{ "episodeId": "SLP206", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "luke_childs": { "name": "Luke Childs", "role": "guest", "tag": "LUKE" } }, "segments": [ { "speaker": "stephan", "time": "00:09", "start": 9.27, "text": "Hi, you're listening to the Stephan Livera podcast, a show about Bitcoin and Austrian economics. Today for episode two hundred and six with Luke Childs. Have you ever wondered how to recover bitcoins from a seed? Maybe your friend doesn't know which wallet they used. Well, in this episode with Luke Childs, we talk about how to recover them into Electrum with his newly written tool, and we also talk about Umbrel, a new node package. Package promising very easy setup. This show brought to you by swanbitcoin dot com, the best place to order stack your Bitcoin in the US with incredibly easy setup and low fees. I personally appreciate that Swan is Bitcoin only and is dedicated to Bitcoin education. Go to swanbitcoin dot com slash livera to get ten dollars of free Bitcoin when you start stacking with Swan. And Swan has some news to share. They've had massive demand for daily buys since the day they launched the service. One of the big positives of regular recurring payments Buys is smoothing out price volatility, so buying daily will catch those dips even better than buying weekly. There are a limited number of spots in the Swan Daily Buys beta, so head over to swanbitcoin dot com slash dailybuys to get into the beta. That's swanbitcoin dot com slash dailybuys. Announcing a new sponsor of the show, Knox Custody. Knox is the only Bitcoin custodian with insurance covering the full value of holdings. So, for example, suppose a fiduciary wants to hold two hundred and fifty million dollars Of Bitcoin with Knox. Knox will obtain two hundred fifty million dollars of insurance dedicated exclusively to that account and adjustable to volatility, no fractional coverage or narrower scope. Insurance for what it's worth, a tool to transfer risk. Knox is backed by investors such as Fidelity Investments Canada, Initialized Capital, and Inovia. If you are a Bitcoin company, investment fund, trust, or family office, check out Knox for your insured custody. Knoxcustody dot com. Lastly, Unchained Capital, Bitcoin native Financial services, Unchained are doing a lot of work to make multi-signature accessible, and they're doing Bitcoin in a way that respects the \"not your keys, not your coins\" ethos of Bitcoin. So if you're thinking about your Bitcoin security, if you're sitting on a single signature, or if you wanna go zero to multi-signature, do it with Unchained. They're offering a Vault Concierge onboarding package where you can get a guided setup call and have hardware devices mailed out to you. So the packages range from fifteen hundred dollars down to one thousand dollars, for setup And this includes a thousand dollars in the vault and potentially if you want the hardware wallets with that. So use code Livera for a discount and go and get set up with them today. And don't forget to read Parker Lewis' series, Gradually, Then Suddenly, available on the website at Unchained Dash Capital dot com. Luke, welcome to the show. Hey, thanks. Great to be here. So Luke, I've been following you for some time. I've seen you've done some great work, in terms of contributions in open source Bitcoin development, and I thought it would be a Luke, just for, listeners, can you tell us a little bit about yourself? Who, who are you, and why are you working on Bitcoin open source?" }, { "speaker": "luke_childs", "time": "03:07", "start": 187.19, "text": "Yeah, so, I've been working full time on open source for about four years now, so- in 2016, I quit my job, and started working full time on open source, so for the last four years, I've been doing a lot of open source stuff, not just on Bitcoin, but just open source in general, and it's been sort of the last two or three years I've really focused on, Bitcoin specifically. I've been involved with Bitcoin for a lot longer than that, but I've only sort of been active, actively contributing, for the last sort" }, { "speaker": "stephan", "time": "03:38", "start": 217.89, "text": "of two or three years. Right. And so, I've seen at least in terms of contributions with various different wallets and things, so could you just maybe hit a few highlights there in terms of what are some of the things that you've been contributing to, in recent years?" }, { "speaker": "luke_childs", "time": "03:54", "start": 234.18, "text": "Yeah, sure. So, I was working on, Bitcoin JS, which is a JavaScript library. so it's not a wallet, but, a lot of wallets which are implemented in, in JavaScripts, use this library. So, so that's not a wallet itself, but most wallets are using this code" }, { "speaker": "luke_childs", "time": "04:14", "start": 254.06, "text": "I worked on, the PSBT functionality on Bitcoin.js, and also recently adding, Payjoin functionality to Bitcoin.js. Also Electrum, so the bit thirty-nine recovery, pull request that just recently got merged, and I've, I've added a few smaller features to Electrum, like, SSL fingerprint verification, and I also worked on the, adding Payjoin functionality, into Blue Wallet as well." }, { "speaker": "stephan", "time": "04:40", "start": 279.91, "text": "Yeah, that's awesome, man. That's really, some really well-known, wallets in The space and, the library as well. I, I thought it'd be good to talk about your recovery tool as well, because I think that's a really interesting tool set, and it's kind of funny how we've gotten into this scenario why this tool is needed. So maybe tell us why would someone need this tool and why did you write this tool?" }, { "speaker": "luke_childs", "time": "05:03", "start": 303.25, "text": "Yeah, so, so the thing is, when you have your like Bitcoin seed phrase, technically that's not actually enough to recover all your funds. so the way it works is that- this, this bit thirty-nine seed phrase sort of derives a tree of different multiple wallets, and you also need the derivation path, which, which tells the wallet exactly which branch on this tree, it needs to look to find your addresses. So you-- so if you just have your seed phrase alone, the wallet needs to-- needs you to either tell it the derivation path or it needs to sort of brute-for-- brute-force all of the possible, derivation paths until it finds the wallet with the funds on. So this is what that, Pool request does it, it brute forces all of the different possible paths until it finds some with, with funds on, and then asks the user, \"Like, we found some funds here, we found some funds here, which one do you wanna, restore?\"" }, { "speaker": "stephan", "time": "05:52", "start": 351.97, "text": "Yeah, that's really cool. So I guess just to break that down for listeners who might not be familiar, you might be trying to help your friend, and your friend may not know which wallet they had used, but they might just have these twelve or twenty-four words. And in that scenario, why is it that, you know, you They, you know, just r-recover that into Electrum." }, { "speaker": "luke_childs", "time": "06:16", "start": 376.19, "text": "So, in many wallets you can do this. So, although there are all these different deriv-derivation paths, there are some agreed upon standards that most wallets follow. So it's not too bad. There's, there is a lot of interoperability where if you create a seed in one wallet, you can just import that seed into the other wallet and it will just derive it. But there are some, the, the derivation paths differ for different script types. So this is like if you have a SegWit wallet" }, { "speaker": "luke_childs", "time": "06:41", "start": 401.04, "text": "For that. and then also there is a slightly different seed formats. So bit thirty nine is sort of the standard, that most wallets use, but Electrum has its own seed format that is incompatible so Electrum by default, when you create an Electrum wallet, you, you don't actually have a bit thirty nine seed, you have a custom Electrum seed. you can recover a bit thirty nine seed into Electrum, but you can't recover an Electrum seed into most other wallets. and the reason for this is that, so the derivation path, the extra piece of information you need along with your seed, that's separate in bit thirty nine, in bit thirty nine seed words, seed phrases, but Electrum seed phrases actually encode You don't need that derivation path as well. When you just import that seed into Electrum, it can actually, it actually understands what your derivation path is just from the seed phrase alone." }, { "speaker": "stephan", "time": "07:34", "start": 454.37, "text": "And so that's, one of those, perennial, long standing debates, around which sort of seeds should people use. And, I think the point of view from people like Thomas and the Electrum team is more like, we don't want the users to have to be technical enough to know to write down the derivation path and so on, we just want them to be able To write down these twelve words or twenty-four words, whatever, and that's enough. Whereas basically all the common or well-known hardware wallets and other wallets are using Bip thirty-nine, so that's kind of where your tool is really, handy. So, maybe do you wanna just tell us a little bit about-- I know it's not your website, but if you could just tell us a little bit about walletsrecovery dot org and the information there, I'm sure you're familiar with it." }, { "speaker": "luke_childs", "time": "08:18", "start": 498.37, "text": "Yeah, so Wallets Recovery, was a great website that I, it was actually really useful for me implementing this feature. and it lists all of the, derivation paths commonly used for wallets. So there are the standard derivation paths that I mentioned before, but there are some wallets that, they don't use a standard derivation path, but, but like it's known, it's published of what their derivation path is, so we can specifically check for that. So Wallet Recovery is just a great re-resource where it lists, pretty much every single wallet and it lists the" }, { "speaker": "luke_childs", "time": "08:48", "start": 528.09, "text": "So, that's what we use in our tool, i-in the election tool, to recover, and if anybody needs to recover funds and they know what wallet they've used, they can go to this website and they can see the, the information that they need to pair with their seed phrase." }, { "speaker": "stephan", "time": "09:00", "start": 540.16, "text": "One of the cool things with your tool is if you, let's say the listener and they've got, they're trying to help their friend with Bitcoin and their friend has written down these words and they forgot which wallet it was, well, that's where this tool actually is quite handy because now it" }, { "speaker": "luke_childs", "time": "09:18", "start": 558.15, "text": "It's quite interesting actually, what you, what you said before about, the different arguments between the, the different seed phrases. Yeah, like I can kind of, I can see both sides of the argument, I can sympathize with both sides of the argument, but I think it, it comes down to what you think a seed is and what, what relationship you think a seed has to a wallet. It comes down to whether you think, a seed has a one-to-one relationship with a wallet or a one-to-many relationship with, with a wallet. And like what I mean by that" }, { "speaker": "luke_childs", "time": "09:48", "start": 588.13, "text": "own seed, or do you wanna have one seed phrase and be able to create, like infinite wallets, with that seed phrase? Because that's the way the bit thirty nine works. If you have a bit thirty nine seed phrase that works with these hardware wallets, you can derive multiple completely different, completely isolated wallets using different derivation paths from that one seed. and if that's the way that you think seeds should work, then adding versioning information to a seed is actually not a useful thing, because if you have versioning information in your seed that says, \"This is a SegW You create a SegWit and a non-SegWit wallet from that, well then your seed is misleading when you try and recover. so yeah, or like if you take it from the Electrum point of view where you think every, every single seed, every single wallet should have its own seed, then it does make sense to encode the data. But the re- I mean, my personal opinion is that actually I think Bitcoin 39 does it right. I think it's good to not have versioning in the seed, and the reason I think this is a better approach is because it makes it much easier to securely store the seed phrase, which is really the, the really sensitive information. If you have one seed phrase that like seeds everything, you can, you can store this super securely so you can like, load it onto a hardware wallet so you have something to actually, you know, access the seed from. But then you write this down, you can put that in a safe, you can bury that safe in your garden, like you, you never need to access that again, it's super secure, you never need to touch it. Only in the event that, like, your hardware wallet gets destroyed or something happens and you need to recover your funds, then you can bury" }, { "speaker": "luke_childs", "time": "11:24", "start": 683.51, "text": "Not needing to access the phrase just from a, just from a hardware wallet. so the fact that you don't have to keep on accessing that storage frequently, means that it's sort of much more secure. You, you can, you can make it much harder to get access to because you don't need to access it regularly. If you have to generate a new seed every time you create a wallet You need to keep digging up your safe every time you do that and store that seed, and then you end up with loads of seeds, and how do you keep track of which ones are for which wallets and, and maybe you can't be bothered to keep on digging up that safe, so you have some in your house and some in different places, and how do you keep track of them all? I think it's, a lot harder to keep the, the seed, which is the entropy, which is the real private information safe, when you have When you keep on generating it each time you create a wallet. so yeah, I think it's, it's actually a better approach to take the bit thirty-nine approach where you just have this one piece of super secure entropy that you keep secure, you don't have to worry about it again, you can derive more wallets from it, and then, like, it's a valid concern that, yeah, then users need to- Need, need to, need to keep track of their derivation paths and any other metadata they need to recover different wallets. But the thing is, this information on its own isn't really that sensitive, as long as, you know, when it's not paired with the, with the seed phrase, with, with the, the entropy that's seeding the wallets, this, these derivation paths, aren't particularly sensitive. So you could, like, you know, stick it on Dropbox, like, encrypt it, stick it on Dropbox, It's, you know, that's backed up, backed up and replicated like all over the place. Like you could even tweet it publicly if you wanted, I wouldn't recommend it, but like you could just tweet all of your derivation paths every time you create a wallet. Like people can't really do much with that information without the seed phrase. Not great for your ops sec, I wouldn't recommend it, but, but it's not particularly sensitive data. It's just important that you don't lose it. so I personally think that this is a better approach, Yeah, but like, I, there are, yeah, there are different perspectives on it, and I, I can understand the electron perspective too. I just think it makes it harder when you have, you end up with like, loads of different seeds for all these different wallets to keep track of." }, { "speaker": "stephan", "time": "13:23", "start": 803.46, "text": "Right, yeah. And the other thing, I guess, from if I were to try and steal, man, the Elektra and Thomas view, it might be something more about, actually, it's about-- it's not about the se-- the sensitivity of that information, it's more about the user knowing that they need to back that up. And I think, yeah, you know, for, for those of us who are more like someone like yourself, you're a developer, you're much more technical, you would never not know that. And someone like me, I'm more hardcore into Might not, and I guess that's part of the argument, right?" }, { "speaker": "luke_childs", "time": "13:55", "start": 835.38, "text": "Yeah, that's definitely a valid concern, but I think there are ways we can make that not such an issue. So like one would be maybe some kind of like standardized backup procedure where like it could be built into wallets, where like each time you create a wallet, it saves your derivation path on like a file somewhere, or maybe you can even hook it into like Dropbox or even your own self-hosted storage or something that automatically, automatically backs that up. like if there was some sort of standard protocol that all the wallets Do that, that could be one solution. Also, like at the moment, there aren't that many different derivation paths to scan, so the Electrum functionality works really quickly. Like, when I was testing it out, I think I tested it on like maybe scanning ten different derivation paths, and it, it completed that in like less than a second. So, you know, because Elect- the way Electrum works, it has the entire UTXO set indexed, it doesn't have to do a full re-scan like with Bitcoin Core when you're recovering funds. the Elect Scan ten different derivation paths in like under a second. So right now today, even if you don't know your derivation path, as long as it's a well-documented one, you can brute-force all of the combinations pretty quickly today. It doesn't matter, you don't actually need to remember that data. Like going forwards in the future, you know, it's, yeah, it's a valid concern that maybe when we, in the future, when we have loads of different, derivation types and stuff, maybe that might not be feasible anymore. But for now at least, it's," }, { "speaker": "stephan", "time": "15:20", "start": 920.14, "text": "it So which paths? We're looking here only at the non multisig schemes, correct?" }, { "speaker": "luke_childs", "time": "15:29", "start": 929.04, "text": "Yeah, so it, it, it can recover every single non multisig path, recorded on walletrecovery dot org, apart from, Bitcoin Core, without going into too much technical details, it's basically the concept of hardened derivation and unhardened derivation, and, Electrum only works with, unhardened subkeys at the account level. That's not what Bitcoin Core uses, so, although I could have implemented scanning for the Bitcoin Core, derivation path, it's not actually compatible with Electrum, it wouldn't be able to be imported into Electrum, so I, I didn't implement that. But every single other wallet, single signature wallet on walletrecovery dot org is, is supported by the Electrum feature." }, { "speaker": "stephan", "time": "16:11", "start": 970.83, "text": "Great. I'm also interested to just chat a little bit about, because we were chatting about this, offline before, is also just like that difference between the, I guess, the receive Change chain, could you just outline a little bit about that? What are those and what's, what's going on with those?" }, { "speaker": "luke_childs", "time": "16:29", "start": 988.68, "text": "Yeah, so, so if you think of, like as I mentioned before, like the seed, the seed phrase basically generates like a tree with different branches. So like the, generally like the first level is the script type, which could be SegWit or non-SegWit. Then each of those branches have their own branches for the account level, which can be like the first account, the second account, the third account. And then each of those accounts have" }, { "speaker": "luke_childs", "time": "16:53", "start": 1013.18, "text": "is for addresses that you, receive. So if you, if you, if, if I wanna send you some Bitcoin, you would give me an external, an address on the external branch. And the internal branch is for change addresses. so if you were paying me and you had some change to send back to yourself, that would always go back to, a, a change address on the internal branch. and this is like, we actually make use of this. I made use of, use of this to get kind of a shortcut in the rescan functionality" }, { "speaker": "luke_childs", "time": "17:24", "start": 1043.52, "text": "Like the internal chain and the external chain and, and recover the final balance. But, because I was only trying to count-- like trying to figure out, has this account ever been used? I wasn't trying to say, \"Let's, let's figure out the final balance of this account,\" because Electrum handles that on its own. I was just trying to figure out, has this account ever been used? All I needed to do was scan the gap limit on the, external chain, which is the first twenty addresses that they're gonna receive from. There's no need to worry about scanning the change addresses because if they haven't received, if they've never received, a transaction, then they'll never have any change because they never would have spent that transaction." }, { "speaker": "stephan", "time": "17:57", "start": 1077.16, "text": "Clever, I like that. And so we should also jump into gap limits. So what is a gap limit?" }, { "speaker": "luke_childs", "time": "18:03", "start": 1083.38, "text": "So a gap limit is, the, the gap, the empty gap that you can have between addresses that Unused. So the reason we have this is, because the, like, bit 44, like, while it's, deterministic, so when you have the seed phrase, it can, it can generate, Like infinite addresses, basically, we need to set some sort of sane limit of like how far ahead your wallet is gonna be scanning. It can't just scan-- it can't just be looking ahead for infinite addresses because, like, you know, that would be impossible. so we have to set some sensible limit for how far we look ahead, and twenty is like the sort of widely agreed upon limit. So say, if you, if you, if you, if say if I, you wanted to donate to me and I generate an address for you, and then somebody else wants to" }, { "speaker": "luke_childs", "time": "18:53", "start": 1132.56, "text": "I don't know that you're actually gonna spend to that address, but I should still give everyone else a new address, because I don't wanna give someone the same address, that's address reuse, that's, that's bad for privacy. But if I gave out twenty addresses that were unused, and then I gave out the twenty-first address to somebody else, if those first twenty people didn't ever spend, didn't ever, send Bitcoin to those addresses, and the twenty-first person did, when, when I was like re-recovering that seed into a wallet, it" }, { "speaker": "luke_childs", "time": "19:22", "start": 1161.92, "text": "And it wouldn't be able to recover it. so it's very important that wallets respect this limit, because if some wallet decided to, say, set a gap limit of twenty-five, and then that situation happens, if you imported that seed phrase into a different wallet, it would just stop scanning when it, when it got to that gap of twenty-five and wouldn't ever continue to scan the rest of the chain. So we'd have this awful fragmentation where like certain seeds only work when they're imported into certain wallets, which would be a really bad situation." }, { "speaker": "stephan", "time": "19:47", "start": 1186.84, "text": "Got it. So let me just replay that" }, { "speaker": "stephan", "time": "19:52", "start": 1191.7, "text": "Our wallets have been coded in a way to sort of check the first twenty addresses, let's say, and so the problem might arise in some scenarios where, let's say, it's a donation scenario or something else, and people just haven't been paying those addresses. So then in reality, let's say somebody donated to the twenty-ninth address or whatever, but because, you know, you've only set the wallet to scan to the first twenty, it might think, \"Oh no, I don't have any money,\" when in reality it does have its money, it just didn't scan to that twenty That's a good summary?" }, { "speaker": "luke_childs", "time": "20:23", "start": 1222.92, "text": "Yeah, yeah, yeah, that's exactly right. so yeah, like, so, so in that scenario, you would just need to start reusing, well, you have two choices. You either start reusing the addresses after you get to twenty, so you start, say, if you're, if you're on the zero address, so you give out the first twenty, if somebody, if the twenty, none of them have been donated to, and somebody asks you for the twenty-first one, you have to reuse the first address. Alternatively, you can give them" }, { "speaker": "luke_childs", "time": "20:51", "start": 1251.44, "text": "Like s-sometimes you have to do that. Like, for example, like, merchant solutions like BTC Pay, I think they use a really high gap limit. Like, I'm not sure what it is, but I think it might even be like a thousand or ten thousand or something crazy like that, and like they need to do that for their use case because obviously if you have a store, and you're giving a unique address to each customer and you're tracking that address for that specific payment, if you have twenty people in your checkout, you can't just like wait Like invoice to somebody else, so in their scenario, they have to just go way beyond the gap limit. But like, that's fine for that specific scenario because if you're running a BTC pay store, you should be aware that there are these, you know, that if you ever need to recover your funds, you need to use a specific gap limit and stuff. So it's fine for like specific use cases if you need to go beyond this gap limit. It's just very important for general use, for general wallets, that, that they respect the, the standard twenty." }, { "speaker": "stephan", "time": "21:47", "start": 1306.78, "text": "Yeah, and I guess Bitcoin works, they might try to recover a wallet and then think, \"Oh, oh shit, I've lost all my money, I can't see it, where is it?\" And in reality, it's just that you need to tell Electrum, \"Hey, go and scan those extra addresses.\" And so that's where there's like a command to go and do, like to manually go and search those additional addresses, right?" }, { "speaker": "luke_childs", "time": "22:12", "start": 1331.81, "text": "Yeah. So not very many wallet, wallets support this, but Electrum is one of the few that does this. It's, it's not, People would end up like losing money probably, but yeah, if you go to the console, you can just enter a couple of simple commands that will increase the gap limit. So if you, if you know your derivation path, you know your gap limit, and you're not sure how to recover them, you can do that fairly easily with Electrum." }, { "speaker": "stephan", "time": "22:37", "start": 1356.76, "text": "Yeah, and so I guess one thing to think about then with this kind of tool that you've written, the Electrum, recovery tool, we have to also think about how far should they, how far should it scan, until it can't find an address? And I suppose you're saying, you just use the default, twenty gap limit. But I guess the trade-off is really that whoever, whichever server you're using, like the Electrum server, so it could be Electrum Rust server or probably Electrum X, that That could be like a DOS thing, right? If you set that really high to scan, then that means like if lots of people are all trying to rescan, then that's like a, a lot of load on that server, right?" }, { "speaker": "luke_childs", "time": "23:17", "start": 1397.31, "text": "Yeah, that's right. So, yeah, we use twenty, which is the, which is like the, the recommended standard in Bitcoind 44, which is what pretty much every wallet's use. then like somebody did recommend on the GitHub issue, like, \"Oh, maybe you should increase it to like ten thousand or something so Because we're both like, no, I really don't feel comfortable with that. It would be, yeah, it'd be putting a lot of load on the Electrum servers. And, and there's no, like, there's no, monetization in running an Electrum server. It's just like, people just do it to benefit the community. So, yeah, it's nice to sort of not put them under too much unnecessary stress." }, { "speaker": "stephan", "time": "23:53", "start": 1432.99, "text": "And Luke, I know you run one yourself, can you tell us a little bit about, how and why you do that?" }, { "speaker": "luke_childs", "time": "24:01", "start": 1441.1, "text": "Yeah" }, { "speaker": "luke_childs", "time": "24:07", "start": 1446.74, "text": "bitcoin dot lukechilds dot co, and I also run it under a Tor hidden service, which I can't remember off the top of my head, but yeah, I just do it just because I needed it, and I thought I might as well expose it publicly and, also, I, I, I've, I've publicly said like, if any developers want to like interface with an Electrum server, you're free to use mine and just like stress test it as much as you want and just sort of battery. I just, the reason I I can just quickly ping, bitcoin, bitcoin dot lukechilds dot co and I know I've got an electric server that's, that's gonna be up and running." }, { "speaker": "stephan", "time": "24:41", "start": 1481.38, "text": "That's great. And so in terms of running that, is that just a VPS? Is that expensive to run? What, what, what goes into it?" }, { "speaker": "luke_childs", "time": "24:49", "start": 1489.39, "text": "it's just a VPS, yeah. It's just, so what I actually personally use for my stuff is a local Raspberry Pi node. but then I also run this secondary for like less important things. It's a V I don't think they would be, but I can't be sure they're not. and yeah, it's like a five dollar, it's like a five dollar VPS, but I have like a, an external volume with the blockchain storage on, with like a Bitcoin full node, and then that's the, the where the costs are involved. I think it's like maybe thirty or forty dollars a month for the actual storage for the blockchain, and then five dollars for the actual server. If you wanna run your own, on, on, on a cloud server, yeah, it's about, Recover Bitcoins with something like Umbrel." }, { "speaker": "stephan", "time": "25:38", "start": 1537.94, "text": "So for most people, yeah, they would just have, you know, they'd be running one of these node packages, and obviously we're gonna get into Umbrel later. But, I suppose for most people, they would only be using it on their local network, and it might be a little bit more difficult to kind of connect back, from outside, unless they're doing it through Tor. But I suppose, maybe if you were to run, the Electrum server or Electrum X, it probably in this case" }, { "speaker": "stephan", "time": "26:06", "start": 1565.8, "text": "On Clarent right?" }, { "speaker": "luke_childs", "time": "26:08", "start": 1567.58, "text": "Yeah, and the other thing is, so if it's just for you personally to use on one machine, absolutely local is the way to go. It's gonna be faster to just run a local server. you can run the, the Rust Electrum server or also the, these like, BWT Bitcoin Wallet Tracker, I think it's called. Yeah, yeah, that's a, that's a really great, implementation as well. So if it's just for you to use personally, that's, that's the easiest solution" }, { "speaker": "luke_childs", "time": "26:36", "start": 1595.64, "text": "Server is, you can also share it with like family members and friends. So, you know, you can have like a trust minimize setup where people who aren't technical enough to maybe do this stuff themselves, but also understand that they shouldn't be just trusting random third parties, could choose to have a trusted individual, like, you know, an uncle or a friend or whatever, where they connect to their Electrum server, and, you know, they're trusting, they have somebody that they trust to not lie to them instead of just trusting a random stranger not to lie to them." }, { "speaker": "stephan", "time": "27:06", "start": 1625.56, "text": "Well, that you're doxing only to your Uncle Jim, the proverbial Uncle Jim node. Yeah, exactly. So this might be an example for listeners who, who wanna set up for their community, this might be a good idea as well, because then they can point, and there's lots of different wallets that can point to Electrum. So I know obviously the Electrum phone wallet can point to it, and even, I think Blue Wallet can. Yeah, Blue" }, { "speaker": "luke_childs", "time": "27:27", "start": 1646.67, "text": "Wallet's based on Electrum, protocol, and also Phoenix, the," }, { "speaker": "stephan", "time": "27:33", "start": 1653.34, "text": "the Lightning wallet, you can back Turning to wallets, what are you, you know, mostly interested in wallet-wise and, you know, kind of where are you currently, on that?" }, { "speaker": "luke_childs", "time": "27:43", "start": 1662.83, "text": "I'm really interested in, coinjoin, like, and, and wallets that are implementing coinjoin functionality, so I'm keeping my eyes on that, I think there are pros and cons with all of the current implementations, so I try not to get too political about that. Sure, sure, yeah. There's a lot of stuff going on with that at the moment. But, yeah, I'm really interested in that space. I think like that is so important, and things like post mix tools and, not even post mix tools, but just UTXO, like just how to manage your UTXOs properly is something that a lot of wallets miss out on, and, and really you're, you know, you Choose UTXOs and move them together. So I'm very interested to see what emerges from that space," }, { "speaker": "stephan", "time": "28:29", "start": 1709.08, "text": "Yeah. So speaking of that, even with this recent dust attack, now it seems that it was basically some, BSV type person who just wanted to do, like, spam some recently used addresses. But you can see as well, to your point about not having post-mix tools or not being able to, for example, mark that piece or that chunk or that UTXO as \"don't spend,\" then you can inadvertently- Doxx your privacy by spending it together with some other UTXO, right?" }, { "speaker": "luke_childs", "time": "28:58", "start": 1737.58, "text": "Yeah, exactly. And like one of the simplest things you can do to mitigate stuff like this is label all of your transactions. So, Wasabi has good support for this, and also, Electrum allows you to do this. It's just label every-- label every single transaction that you send out, label every single transaction that you receive, and then when you go to spend coins in the future You can be aware, like, oh, okay, I received this payment from this guy, and now I'm paying this thing. Like, do I potentially want this person to find out I've made this, I paid this bill? Or here's a transaction that I have no idea who I received it from, and it's a really small amount, that looks a bit suspect, let's not use that UTXO. So just labeling your transactions to make sure you keep track of where your coins came from is, is, I think, a very simple and, and very effective way that you can kind" }, { "speaker": "stephan", "time": "29:44", "start": 1783.62, "text": "of" }, { "speaker": "stephan", "time": "29:48", "start": 1788.48, "text": "About what you've done on that side?" }, { "speaker": "luke_childs", "time": "29:51", "start": 1790.51, "text": "Yeah, so that was, so I worked on the Payjoin client library in Bitcoin JS, and that was, that was joint work between me and Cooks from BTC Pay and Jonathan Underwood, who's like the main, the main developer on, Bitcoin JS. So I worked together with those guys for the, for the Bitcoin, for the, Payjoin client library, which is just a sort of generic library that can be integrated into any JavaScript wallet to add, Payjoin functionality. And then, we, we got that to a point where it was almost ready, but the, the actual Payjoin bit wasn't standardized at this point, so we just kinda implemented it up to the point that the bit was at, knowing that we'd have to make some changes in the future. Then, just to kinda test that implementation," }, { "speaker": "luke_childs", "time": "30:38", "start": 1837.52, "text": "So this was a few months ago now, and it was basically integrated, so it's like ninety-nine percent done. But, the, yeah, the BIP has changed quite a bit since then, and like me and Cook and Cooks and, and John kind of had other things that we were focusing on, so I haven't had time to go back and, and update that, since the BIP has been finalized. I think Cooks has been doing some work on the PageOne client, finishing that up, to get it in the state that it's, that The Torment, which is, I think, the lead developer of, yep, yeah, yeah, yeah, you had him on recently, actually. yeah, I think he's taken over the, the implementation that I did and is, is, is finishing that up and getting that ready. So, so yeah, that was a while ago that I did that, but it was, 'cause the bit wasn't standardized, it wasn't ready to be merged, and the bit has been standardized now, so that should land soon, but, some other people" }, { "speaker": "stephan", "time": "31:32", "start": 1891.72, "text": "have, have taken For example, if you scan the BTC pay, with Payjoin enabled, it actually has a different, obviously, 'cause that's how it's done, but, then that might even break, compatibility with other wallets, because they might not be used to reading or like coded to be able to read a Payjoin enabled invoice, right? that's a funny thing there." }, { "speaker": "luke_childs", "time": "31:57", "start": 1916.54, "text": "I don't think it will, it's likely that that would break compatibility, compatibility because, I can't rem- I can't remember what the bit Bitcoin URI, which like starts with the word Bitcoin, then it has a Bitcoin address, and then it can have these optional query parameters that you can sort of add extra metadata to it. and the, the Payjoin information is added as one of these extra query, query parameters. So any, any wallet that is able to scan, like a, a, a Bitcoin URI, if it sees any of these extra query parameters that it doesn't understand, it should just ignore them. So, I, I think the chances of, of it breaking existing wallets is, is pretty" }, { "speaker": "stephan", "time": "32:37", "start": 1956.62, "text": "Clever enough, I was actually testing it out just with Phoenix Wallet on my own BTC Pay, and, I think that was the reason why it couldn't scan the Bitcoin address. Yeah. So I, I, I've, I've mentioned that with the, Phoenix, Phoenix guys, I'm sure they'll patch that up and so on, but, but yeah, it's just a funny little thing where, but, I mean, at the same time, it's a good thing to have, and obviously, the more, people doing pay joins, the" }, { "speaker": "stephan", "time": "33:07", "start": 1986.64, "text": "A little bit about your open source contributions just generally. So I know you, just from reading your page and just from seeing some of the stuff you do, you actually maintain a, a bun-- a different, a bunch of different things as well. Can you tell us a little bit about those, the ones that aren't necessarily directly in the Bitcoin world?" }, { "speaker": "luke_childs", "time": "33:23", "start": 2002.69, "text": "Yeah, so, I think I've-- so I published a lot of JavaScript modules on npm. that's like where most of my work has been. I've done some other things, but mostly JavaScript modules on, on npm" }, { "speaker": "stephan", "time": "33:37", "start": 2016.62, "text": "What is NPM?" }, { "speaker": "luke_childs", "time": "33:38", "start": 2017.66, "text": "NPM is Node Package Manager. So, Node JS is like, like a JavaScript implementation. and NPM, Node Package Manager, is like a, a package registry. So, if, say, if I'm writing, like a Bitcoin library, like say, Bitcoin JS, I publish Bitcoin JS to NPM, and then if anybody else is writing, wants to write a Bitcoin wallet in JavaScript, they just do NPM install Bitcoin JS, and it'll pull it down, and they have it ready in their project. So it's Share like code libraries, modules and stuff like that. So I've published a lot of modules to npm, I think maybe like about eighty modules that I've written myself, and then there's probably like maybe about ten that I just help contribute towards, and yeah, it's really crazy, like they've, they've- They've, they've become really popular, some of them. Like, I think I've had, had about, seven billion downloads total over all of them now, which is just absolutely insane. Like, it kind of terrifies me a little bit that people put this much trust in my code. but yeah, the, yeah, some of them are used, quite a lot. And like, if you're, if you're building something, 'cause, 'cause a lot of the modules are like kind of low level, so I've done like I've done some work on like, like Bitcoin JS obviously, which is used, depended on by a lot of other Bitcoin projects, Browserify, which is a project that allows code written in Node JS to work in the browser, which a lot of projects make use of that under the hood. so like, actually, if you're, if you have like a JavaScript project, there's a good chance there's some of my code in there somewhere, just very low down, hidden around." }, { "speaker": "stephan", "time": "35:17", "start": 2116.94, "text": "I see. And so it's one of those things where, when you talk to some more technical people" }, { "speaker": "stephan", "time": "35:25", "start": 2125.18, "text": "Different projects all cobbled together, and some of them are maintained by some random guy that you've never, you've never met before, and, in some sense, you're one of those guys maintaining." }, { "speaker": "luke_childs", "time": "35:35", "start": 2135.29, "text": "Yeah, honestly, that's probably more true than most people realize." }, { "speaker": "stephan", "time": "35:39", "start": 2139.19, "text": "So it's kind of like, people, I guess, if you're not as technical, you might just, you know, interact with your phone on the web browser or whatever, and it all kind of works very slick and smooth, and you think it's all-- You might think naively, you might think it" }, { "speaker": "stephan", "time": "35:55", "start": 2155.24, "text": "All these possible upstream, dependencies and potential vulnerabilities there also, right?" }, { "speaker": "luke_childs", "time": "36:02", "start": 2161.73, "text": "Yeah, well, this is actually a very huge issue with, no, JS is, and JavaScript, there's, there's like this mentality, in the JavaScript ecosystem of everything should be a small reusable, composable module, which is a really productive mantra. It's, it's like, it's, it allows you to be incredibly productive, and I love JavaScript for this. If I have like an idea in my head, I can just smash out some code really quickly because there's all these Pre-made third-party modules that I can just pull down from npm to just sort of use as building blocks to build this functionality together. So it's great for productivity, and it's great if you're not doing like security-critical stuff, like if you're just building a, you know, a brochure website or something. But when you start trying to build really security-critical applications in JavaScript, you have this real auditability nightmare because Let's say you're writing some software and you include five modules that help you implement that functionality, and then each of those five modules are implementing five other modules, and each of those five modules, are including five other modules. Before you know it, you have this dependency tree of like hundreds of different third-party modules written by random people on the internet, and you don't know who they are, and it's impossible for you to go through and audit every single line of this code. so yeah, this is kind of an issue, in the JavaScript ecosystem, and it's something we Well, we try and mitigate against i-in Bitcoin JS, so we don't really use any third-party libraries in Bitcoin JS, and the few that we do, like Browserify, most of the Bitcoin JS contributors are also Browserify contributors, so we're kind of involved in those projects. But a lot of, a lot of JavaScript projects don't take this approach, they just blindly include, third-party dependencies, and yeah, like it, it's just blind trust, you're just blindly trusting every single person in your dependency tree to not push a malicious update." }, { "speaker": "stephan", "time": "37:45", "start": 2265.3, "text": "Right. And so it's It's like the programmer equivalent of copying someone's homework, and you don't know what, what's inside it because you haven't had the time to go and look at everything, and part of it is just because it's such a huge tree that it wouldn't be feasible to go and check everything for yourself," }, { "speaker": "luke_childs", "time": "38:04", "start": 2283.59, "text": "right? Yeah, exactly. I mean, honestly, like some of the, some, some of the projects that I've seen, like sometimes they have literally multiple thousands of lines that it's just listing the dependencies. So that's not code, that's just thousands of lines listing the dependencies that then Of code each. So, yeah, when you have something like that, it would actually probably be significantly less effort to just write everything from scratch than it would be to actually read through all of that third party code and understand it. You know, it's not always easy to understand somebody else's code, even not necessarily 'cause it's bad, because they've just had a different way of thinking about a problem than, than you would have yourself. It's, it's very difficult to go through that amount of code and audit it, really understand how it's working, and, and be sure that there's" }, { "speaker": "stephan", "time": "38:47", "start": 2327.34, "text": "Subtle error, or it could be that a bug or a, or a malicious co-- a piece of malicious code was hidden in a subtle way and you, you, you-- unless you really know how to find it or you spend the time, you might not see it. but one other point there, that sort of conflicts a little bit with what I've heard of like the, the kind of Unix development philosophy, this idea that everything should be modularized. How would you kind of counter that idea? Do you think it's like, it's only true up to a point?" }, { "speaker": "luke_childs", "time": "39:14", "start": 2354.0, "text": "No, no Small focused programs. The issue is with, so in Unix, like most of these, like, like all of these small, focused binaries, like cat to, to list a file or like ls to list the files in a directory, they just do one small tiny thing. That's fine, but that code's been like audited by a lot of people, and the people who wrote that were probably quite reputable and probably like, when they were building these, they were probably discussing this, these ideas on a mailing list, and, and everyone in like, like Linux or POSIX or That kind of agrees, yeah, this is a useful utility. The, the difference between that and the, what we have on NPM is that these modules are written by like somebody who, who has no accountability, they have no reputation, they have nothing, like, it could be an anonymous account, they have nothing to lose by pushing, a, and, and yeah, this is the main issue, it's, it's, it's that they can push a malicious update. So like, let's say, like the, with the, like Unix philosophy, if the author of ls, right That, scanned the user's hard drive for a Bitcoin wallet and then posted it to their server. No Linux distribution in the world is gonna include that change because they're gonna have lots of people carefully auditing the changes, and that would be very obvious to spot. Nobody's gonna include that. On npm, people just blindly do npm install, they don't even check the code, they just, they read the README on GitHub, they're like, \"Oh, this looks cool, npm install, pull that shit down, publish it.\" Nobody actually audits any of this stuff. And even if you do audit Like you would really need to be going through every single line of change, every single line of, every single line that's changed in all these thousands of dependencies to make sure somebody didn't push a genuine module and then slip in malicious update later. Like, is this sort of the auditing that doesn't really happen? in the NPM ecosystem, and isn't really feasible to do because of the size of the dependency trees, whereas, the sort of Unix philosophy, I don't think that same attack would-- I just don't think you would be able to get away with it. So it's, it's not, it's not necessarily the small focused part, it's the, it's the huge, it's the huge dependency tree part." }, { "speaker": "stephan", "time": "41:21", "start": 2481.39, "text": "Yeah, yeah, definitely. And, I mean, it's, it's very interesting to try and understand, and I know even in the Bitcoin world some of the Bitcoin Core developers are trying to look for ways to try to minimize those dependencies, or to try to get a better knowledge through that whole upstream chain so that we at least know what we're trusting, kind of thing." }, { "speaker": "luke_childs", "time": "41:45", "start": 2504.62, "text": "Yeah, absolutely, and I think that's a great thing to do. Like, I think, I'm not 100% sure about this, but I think at some point, Bitcoin Core depended on OpenSSL, which is known as being kind of like a crazily complicated code base, and I, and then I think, Last year or two, that was actually removed and that like all of the stuff that we were depending on OpenSSL was implemented directly in Bitcoin, so we could remove the OpenSSL dependency. So things like that, I think are great and, and make it much, make-- they make the code base much more audit-able, much easier to audit and much, much easier to be able to trust that the code is actually doing what you think it's doing." }, { "speaker": "stephan", "time": "42:18", "start": 2538.23, "text": "and just out of curiosity, as you mentioned Bitcoin JS, do you know just some example wallets or other Bitcoin software that actually depend on Bitcoin JS, just Listeners who are curious." }, { "speaker": "luke_childs", "time": "42:29", "start": 2549.11, "text": "Yeah, so, Bitcoin, so, BlueWallet uses Bitcoin JS, Exodus, which is, it's like a closed-source multi-asset wallet, but they're using Bitcoin JS, and they actually sponsored me to work on Bitcoin JS for a, for a while, which is really nice of them. Pretty much any web wallet is most likely using Bitcoin JS. There are some alternatives, like, BitPay have their own, library called like Bitcoin JS, I think, but, but it's not that popular. Web wallet is pretty much always using Bitcoin JS, and yeah, I'm sure there are a lot more, but, off the top of my head, those are the, the ones that I can think of." }, { "speaker": "stephan", "time": "43:09", "start": 2588.6, "text": "I guess while we were, we were just recently chatting on some of those ideas around security, I know you also do a little bit around security and vulnerability disclosures as well. So what sort of, what goes into that process? Is that something you do out of interest or is it something that maybe you, you, you go and find like bug bounties and get income from that" }, { "speaker": "luke_childs", "time": "43:28", "start": 2608.49, "text": "Yes, so it's purely something I actually do out of interest. I, I enjoy it, it's fun. and it was something that kind of, subsidized my open source work a little bit, because m-although like I'm very lucky recently, I've had some sponsors on GitHub sponsorship, and in the past I've had occasional, sponsorships from companies. Most of the time I've been working on open source, it's been entirely self-funded, so I've had to do occasional, freelance work or paid work, to, to fund it Flaws and then getting awarded bounties for that has been like one way that I've earned money and been able to, to fund that. So yeah, like, I can't talk about it too much, but, I found some vulnerabilities in like some, some, altcoin wallets, a decentralized exchange, a password manager, and then normally, normally, like, the process is I would just contact them, explain, the issue, work with them to, like, on how to resolve it, and often With a bounty for doing that. but yeah, it's not, it's not something that I ever like sit down and think, right, today I'm gonna try and find, a vulnerability in something. It's normally just, when I've been using some software or when I've seen some code on GitHub or I've heard that somebody's doing something and I've just kind of thought, oh, I wonder if, like, I wonder if there's a way you could break that. I just sort of genuinely find it quite fun to download the software and try and break it," }, { "speaker": "stephan", "time": "44:58", "start": 2697.79, "text": "No, also in the Bitcoin world, people are-- because this is all open source, right? People work on, it's kind of like, you scratch your own itch, right? And so sometimes it's about different Bitcoin wallets or projects in the space that want contributors, and they want people looking at, you know, 'cause we-- the, the saying you hear is \"eyes on the code.\" And so I, I suppose one of the ways that happens is, if someone is building things on top of your code, well, then there's more people looking at it, and then they might I mean, your experience also." }, { "speaker": "luke_childs", "time": "45:30", "start": 2729.61, "text": "Yeah, I mean, absolutely. The more, like, it really makes so much more sense when we have, especially with like mission-critical code, to have it open so that people don't have to reinvent the wheel, people don't have to solve the same problems, everyone can, can sort of centralize around a, a single solution. But also, if it's this really critical code where," }, { "speaker": "luke_childs", "time": "45:50", "start": 2749.76, "text": "It's just crucial that it doesn't fail in any way. the fact that loads of other people are using that same code, and that when any, and whenever anybody finds an issue in it, they can fix it, and everyone benefits from that, it's just mutually beneficial to everyone. It's just, it's just a way more efficient way of working, and yeah, just so much, so much better for everyone involved." }, { "speaker": "stephan", "time": "46:09", "start": 2768.83, "text": "Great. so also wanted to chat about Umbrel, which is a new project. So for listeners of my show, you probably already know that there are a range packages that are available, things like Minode and Nodle and Raspiblitz and Ronin Dojo and so on, but I've seen, some chatter and I've seen some, screenshots and my friend Katana's also played around with Umbrel also, so can you tell us a little bit about it? What is Umbrel?" }, { "speaker": "luke_childs", "time": "46:35", "start": 2795.12, "text": "Yeah, so it's like, It's like a sort of like a, a Bitcoin and Lightning, application stack. So, it's a way, it's, it's, it's a, it's a, it's a simple way for people to run a Bitcoin and Lightning node on their own hardware. we're really trying to focus on like user experience, and making it as simple and easy to use as possible. Like, you know, there's been a lot of chatter about, how easy it is to run a full node recently, and it's like people seem to be We can't expect people to be able to do this, and other people will say like, \"Oh, it's easy, like, you just download Bitcoin Core and that's it.\" And like, they're kind of both right. Like, just downloading Bitcoin Core, and double clicking an EXE, like, that's not hard, anybody can do that. But there's, like, there's a lot more to, to that than, there's a lot more to running a full node than just that. It's like, you know, maybe you wanna install an Electrum server, without doing that insecurely, like there's a, there's a lot more involved to running a full node and connecting it to modern wallets and stuff than just simply downloading Bitcoin Core, and that's the part that I think a lot of people get overwhelmed with and struggle with. So Umbrel is trying to, take the pain out of that and, and, and have everything set up and pre-configured in a way that's super secure and private by default, making like good privacy decisions by default so the user doesn't need to understand the trade-offs and doesn't- Need to understand how to set that up, it's configured for them, and yeah, and just be easy, just be easy to use, so, so anyone can do it. It should be a full node that's so easy even Pete McCormack can use it. That's, that's the end goal, I think." }, { "speaker": "stephan", "time": "48:21", "start": 2901.19, "text": "I, as I said, it's, it's intended as like a Raspberry Pi style Bitcoin node, right?" }, { "speaker": "luke_childs", "time": "48:26", "start": 2906.18, "text": "Yeah. So it's like, yeah, so it, it can run on anything. At the moment, the target that we're And we need to just sort of focus on one thing to be able to iterate faster and, and, and put stuff out quicker. We're focusing on the Raspberry Pi, so that's the recommended way of installing it. We, we publish an operating system image that you can download, flash to an SD card, and then just whack that in a Pi, boot up, and then, you just sort of set it up for your web browser from there. so yeah, Pi is the supported, hardware target at the moment." }, { "speaker": "stephan", "time": "48:59", "start": 2938.96, "text": "Do, do you get any difficulty there with having" }, { "speaker": "stephan", "time": "49:04", "start": 2944.12, "text": "to" }, { "speaker": "luke_childs", "time": "49:07", "start": 2947.36, "text": "We're using, like Docker to handle the orchestration, and we are using like, multi-architecture, Docker images, so, everything just works. And if we-- if you wanted to run, like, so it runs on ARM, but if you wanted to run it on x86, like, like a normal desktop CPU or server CPU, that will also just work without us really having to change anything. and so obviously like Bitcoin Core and LND are already cross-platform, and then the sort of, glue code The sort of the, the way that we're orchestrating everything is mostly done using Docker and scripting languages, which also work cross-platform. So the actual like hardware architecture isn't something that we need to worry about, that's kind of all abstracted away for us." }, { "speaker": "stephan", "time": "49:50", "start": 2989.99, "text": "And, I mean, from what I've seen in terms of screenshots and, the videos and things, it looks really, really slick. So, well done with that, I think it looks really nice and, Yeah, like it's a bit more, it's a bit more appealing, for perhaps the, the person who's a little bit newer to Bitcoin and running a Bitcoin node and things like that. so I guess in terms of cost to run one of these, if they were to go with the recommended setup, what kind of cost range are we looking at here?" }, { "speaker": "luke_childs", "time": "50:19", "start": 3018.78, "text": "Oh, to be honest, yeah, I'm not actually sure off the top of my head. but I mean, a Raspberry, a Raspberry Pi is like $50, so we recommend the four gigabyte, the Raspberry Pi four, four gigabyte, which I think is about $50. And then we also recommend, a one terabyte SSD, which is, you know, probably around a hundred dollars or something like that. Not sure off the top of my head, but that's the sort of rough. Ballpark figure that you'd be looking at." }, { "speaker": "stephan", "time": "50:47", "start": 3046.74, "text": "One other interesting thing I noted with, Umbrel is that you guys are actually using the compact block filters approach. So tell us a little bit about that and how you're able to just start straight away without actually having to download the full blockchain to start." }, { "speaker": "luke_childs", "time": "51:01", "start": 3061.4, "text": "Yeah, so the way, so, so the thing with that is, obviously it's like most people right now are using, well, a lot of like sort of average users are using like SPV wallets, which is pretty bad because that puts a lot of trust in the miners, but like there's a reason people are doing that. It's because it's just easy. It's just you download a, an app, you open it, and it just works. Like it's instantly on, it just works straight away. so it's hard to convince people to run" }, { "speaker": "luke_childs", "time": "51:31", "start": 3090.92, "text": "One app and, and it would be working instantly. You know, it's hard to like convince them that that's something they need to do. so with Umbrel, we kind of achieve the best of both worlds by, when you set up your Umbrel, we start syncing Bitcoin Core in the background instantly, a full-- So we start syncing a full node instantly, but it's instantly accessible, the on-chain wallet and the lightning wallet is instantly accessible, but it's backed by Neutrino, so it's backed by an SPV node. so this, and Pretty good, it improves upon like previous SPV technology, so it gives you almost as good privacy as a full node, it's just the, the trust element in the miners, which is the negative. so it uses, it uses, Neutrino, so everything is instantly available, and then as soon as your full node is synced, like however long that takes, maybe a couple of days, it just instantly switches over to using the full node, so it's just a temporary issue. So as long as you trust the miners to not pull off some huge coordinated attack Days, then there's basically no downside whatsoever, and all of the upsides, you just get an instantly accessible node that's eventually backed by a full node." }, { "speaker": "stephan", "time": "52:38", "start": 3158.07, "text": "Yeah, it's a really clever approach, and I think that would be great to see, because basically it means the user can just get started, up and going right away, and so they don't have to premeditate it as much in terms of setting it up and then waiting for a few days and then getting started with doing whatever they want to do with it." }, { "speaker": "luke_childs", "time": "52:59", "start": 3178.7, "text": "The approach that we're taking With a lot of the, the features that we wanna add to Umbrel is that the user doesn't need to be aware of them. So the user doesn't need to understand like what SPV is, what a full node is, like they don't even need to know that. They know that they don't need to know when to switch over or anything. As far as they're concerned, they just plugged a b-a box in, they set it up, and then they can just use Bitcoin, like they are completely unaware of what's going on behind the scenes." }, { "speaker": "stephan", "time": "53:19", "start": 3199.47, "text": "Yeah, that's a clever approach," }, { "speaker": "stephan", "time": "53:30", "start": 3209.98, "text": "users, but, for, you know, people who are, you know, we're trying to teach our family, we're trying to teach our friends, this is, probably the way to go. So, in terms of, what we've got currently on Umbrel, as I understand, you've got Bitcoin Core and Lightning, are you looking to do any of the whole Electrum server thing or have a way to hook up your mobile phone wallet with your Bitcoin node and things like that?" }, { "speaker": "luke_childs", "time": "53:52", "start": 3231.94, "text": "absolutely. So we, we don't have any like hard-coded plans for like we're gonna add this up, we're gonna add that up. We're just kind of waiting to see what the community ask us for, and what there's demand for, and we're just gonna, you know, we're just gonna implement what people are asking for really. But yeah, we've already had people ask for Electrum servers, we've already had people ask for a block explorer, we've already had people ask, for mixing apps that run on the Umbrel device. so We're gonna add those and, and anything else, you know, if there's things that people want, we just, we want them to tell us and we'll implement what people want. And, who else is working on the project, by the way? so there is, Mayank Chabra, who is-- He is like really the brains behind everything. he, he designed everything, so all of the, all of the, compliments on the design, should all go to him. and then we also have another developer called No Limit, who's been helping us out, and there are a few other people, who have, who sort of loosely are involved in a like, it's just sort of we talk ideas over a lot. me, Damien's been really help yeah, but it's, yeah, it's mainly, me and my Ank and No Limit who have been, building it." }, { "speaker": "stephan", "time": "55:07", "start": 3307.1, "text": "With the seed as well, I was chatting with Katan, he was telling me it is the LND AEZ, which is another type of seed from what we spoke about at the start, right? Because you got BIP thirty-nine, you got Electrum style, and then you've got AEZ, right, which is the LND style. Yeah." }, { "speaker": "luke_childs", "time": "55:23", "start": 3322.67, "text": "Yeah, so, w-we don't really have a choice there." }, { "speaker": "luke_childs", "time": "55:31", "start": 3331.44, "text": "Interface with LND, and then we can do things with like Lightning, we can do things with on-chain Bitcoin, and we, we can configure LND to use, to be backed by Bitcoin Core or to be backed by Neutrino. So using LND gives us a, a common interface to just interact with for all of that, regardless of what backend is being used, and LND uses xPub, so we didn't really have a choice in that." }, { "speaker": "stephan", "time": "55:54", "start": 3353.79, "text": "Yeah. Right, but I, I think it's a clever approach, because in some ways it's quite, it's a bit of a simplification of, of what's going on, and so that way it's a bit more, I can, I can understand why, that makes a lot of sense. Yeah. And the seed is" }, { "speaker": "luke_childs", "time": "56:06", "start": 3366.3, "text": "also pretty cool in that it encodes the birthdate of the wallet. so, I mean, also it goes back to what I was saying before about whether a seed is one to one or one to many. In the case of So in this case, it makes sense to encode version data or it makes sense to encode a birthday, because it's specifically for that Lightning wallet. if you like, so like, you got, you gotta think of Umbrel as, as a server, not a client. So it's not really a wallet, it's like an application stack. And if you wanted to use a wallet, like Electrum or whatever, you would connect that to your Umbrel, and that would have its own seed that you would deal with. So yeah, Azid has its, has the birthdate of the wallet encoded into it, which means that when you recover it, it can really efficiently re-scan the blockchain to recover your funds because, it has the birthdate, so it doesn't need to scan from the genesis block. It knows, you know, this wallet was created on this date, so there's no point scanning on blocks before that. We only need to scan on blocks after that." }, { "speaker": "stephan", "time": "57:06", "start": 3425.53, "text": "and in terms of the model for Umbrel, is it gonna be like, like, is it a pay, paid product or how, how's that part going to work?" }, { "speaker": "luke_childs", "time": "57:14", "start": 3433.94, "text": "So the idea is that Umbrel is gonna be a for-profit open-source project. So, we wanna be self-sustainable, right? We don't wanna have to rely on donations or just spending our own time on building it. We want it to be self-sustainable and have some sort of sustainable funding model. we really don't know what that's gonna look like yet. Yeah, we're not really worried about that at the moment. We're trying to just get validation on the idea, we're trying to get something out there, get feedback on it, see if people are actually interested in it, see if people like what we're building, and then if people like it, then we're confident that we will be able to find some sort of way to monetize that and, and turn it into a, something that can, you know, fund itself. but, to be clear, Umbrel itself, like, Umbrel is always gonna" }, { "speaker": "luke_childs", "time": "58:05", "start": 3485.25, "text": "There will be some kind of paid additional services that would complement it, hopefully that we could come up with, to monetize it. That would be the idea in the future. But yeah, as of now, we, we don't know exactly what that would look like." }, { "speaker": "stephan", "time": "58:16", "start": 3496.14, "text": "It could be something like you might, sell the pre-made version of the, you know, of the box or have like a premium version that you pay for or things like that." }, { "speaker": "luke_childs", "time": "58:26", "start": 3505.79, "text": "Yeah, something like that. Really like, it's just, yeah, you know, if, if we're building Umbrel and people" }, { "speaker": "luke_childs", "time": "58:35", "start": 3515.09, "text": "Solving for free because it would, there would be cost behind it, but there's-- but we could be like, \"Oh, we could solve this problem, but it's gonna cost us money,\" then that could be something we'll sell, you know? Like, yeah, just whatever, whatever, whatever we come up with along the way really." }, { "speaker": "stephan", "time": "58:47", "start": 3526.51, "text": "Gotcha. and I guess just in terms of determining which features to actually implement, I mean, you mentioned based on, community feedback, but I guess how, how are you going to figure out which one? Are you just gonna have to like pick which based on popularity of what the community's asking for, or just kind of maybe think in your mind what sort of user, like, have a target user in mind that you're trying to build for?" }, { "speaker": "luke_childs", "time": "59:10", "start": 3550.27, "text": "so I think yeah, a big part of it is just gonna be what most people, are requesting, but also there Features that like people might not really request because they don't really know that they need it, but that, that we think are important to add. So for example, automated channel backups is something that we are almost ready to release, which nobody's requested that, but, we think that's pretty important. and also like I, I'm really happy with the way that we implemented this, 'cause we were discussing on how to do this for a really long time, and I wasn't really satisfied with any of the solutions, but I think we've came up with a really good approach But, I was kind of worried about a potential privacy leak, because if we, basically, we wanna, we wanna back up the channel data every time it changes, because, you know, you, you need an up-to-date channel backup. But there is kind of like, we need to, link it to some unique ID, which is deterministically derived from the seed. So, it, basically, the recovery process is completely transparent. your ba-- your channel states are backed up with a unique ID that's deterministically derived from your seed. So, let's say Umbrel. You can set up a new Umbrel, and when you put in your seed phrase, that obviously recovers your on-chain funds, but it can't recover your, your Lightning funds from the sta-static channel backups. But what it will do, Umbrel will deterministically derive the same backup ID from your seed. It will then ping our servers and say, \"Hey, do you have any, do you have any channel backups from this, from this ID?\" We respond and say, \"Yeah,\" we send back a channel backup which is encrypted, from a encryption key that's also" }, { "speaker": "luke_childs", "time": "01:00:44", "start": 3644.85, "text": "Backup files, but, Umbrel will automatically just decrypt that, import it into LND. So from the user's perspective, they've just whacked in a seed phrase, and then Umbrel is back up and restored and has all the channel, channel balance, balances available. They weren't aware that any like channel backup stuff even existed, like it's just everything is just linked to that one seed, But yeah, we were, we were kind of worried about like, how can we do this in a, in a privacy-respecting way, right? Because if we're pinging our update server with a, with an ID, each time your channel state changes, there are poten-- I mean, it'd be quite difficult to pull off, but there are potential attack, like, deanonymizing attack vectors there, like, if we were doing like a timing analysis attack, like if we, if we were monitoring the Lightning Network and seeing how the state changes on the Lightning Network" }, { "speaker": "luke_childs", "time": "01:01:35", "start": 3695.13, "text": "fifty-seven times that day, and then this channel changed its state fifty-seven times that day, we could make a correlation there. So the way we do the backups, we backup every time the channel state changes, but then we also just randomly backup on random intervals, even if nothing's changed, to kind of throw off this analysis that we would be able to do. And we also pad the backups with like a random amount of, of random data. so you could backup three times in a row, even though nothing's changed on your device, and one time the backup could be bigger It could be smaller in size. Nothing in your backup has changed size, but we add this random padding, so we can't tell when it's a genuine backup, when it's like a decoy backup. Whether your backup's increased, reduced, changed, changed in size, we can't monitor any of this data. and I think that's really important because we don't want our users to trust us. Like, obviously, I trust myself not to deanonymize our users, but I don't want our users to have to trust us not to do that. I don't wanna put myself in" }, { "speaker": "luke_childs", "time": "01:02:34", "start": 3754.85, "text": "Enforcement to, to share some data with them, like we'd have to make a decision between, like, do I fuck over my users or do I go to prison? Like, neither of those are particularly appealing options to me, so I wanna, like, we wanna make sure that we don't ever put ourselves in that position and we don't even have access to that data in the first place." }, { "speaker": "stephan", "time": "01:02:52", "start": 3772.64, "text": "Right. And this can be a bit of a difficult question, I know, in the case of not all they use like a USB key to do the backups, and then, yeah, User and so on. I, and I don't know, in the Nodal case, they've, they've done things to try and make that a bit easier, but certainly I appreciate, that's, a, a bit of a tricky one to handle there. and I guess the other point really is just that if people are using, Umbrel, it depends really how they're going to use it, and if many people are just gonna be hodling, well, they're probably just gonna be on a hardware wallet, in which case they just want Electrum server In this case, because they don't wanna leave too many, too many bitcoins or too much fun, too many funds on the device hot, they just want only the amount that they're doing for the lightning channel component, and then all the savings hodling stuff is in the hardware wallet part, right?" }, { "speaker": "luke_childs", "time": "01:03:51", "start": 3831.2, "text": "Absolutely, and that's the way we would recommend people use it, and also, the way you said about how like some people only care about, like Bitcoin or Electrum or whatever. So the idea that we wanna work towards with Umbrel is like each application That we add to Umbrel is like isolated, it's like, there are very strict like, like permission, permissioning system and, and isolations between these apps and how they can interact with each other. and you will be able to, choose which apps you run on Umbrel. So, like, it's up to you to choose what you want on your Umbrel. We're, we're not, we're not gonna be like pushing our decisions on other people and saying, \"Oh, now everyone has to run this, now everyone has" }, { "speaker": "stephan", "time": "01:04:31", "start": 3871.79, "text": "to run So it's kind of like in a beta test, kind of, small number of users who are just playing around with it and more technical users who are giving feedback. So what stage would you say you're at, in terms of like going to a, to the next, I guess, next phase or next release?" }, { "speaker": "luke_childs", "time": "01:04:52", "start": 3892.59, "text": "Yeah, so I, I should probably be clear about this. Umbrel in its current state is like, it, we're not saying that it's like stable, we're not saying it's safe for large amounts of money, it absolutely isn't. we've, we've taken reasonable lengths to like try and protect people from fund loss and stuff, but like absolutely, it's early, it's in beta, there will be bugs. we encourage people to test it out, we want people to test it out on mainnet, but to, like, with small amounts You know, yeah, it is new and, you know, I don't know when we're gonna be at a stage where we say it's stable and it is safe for, for funds, but there are like, there are, there are multiple things that we're aware of that, that aren't-- that we're not comfortable recommending people put large amounts of- Funds on while it's in that state, and we will rectify that before we say it's, it's stable, but yeah, I'm not sure exactly how long that will be yet. There's also, if you're interested to know more about that, if you go on our GitHub, we link to like a security dot MD file that, that specifically lists the things that we have like some sort of shortcuts that we've taken for now to be, to make it easy for people to test and debug and stuff that aren't ideal for security and that we will fix, but we've documented" }, { "speaker": "stephan", "time": "01:06:08", "start": 3968.38, "text": "And Lightning, is there anything that you are particularly excited about over the next year or so? Are there any particular developments you're looking forward to, or is there anything in particular that you think, you know, Bitcoin and Lightning wallets or applications need?" }, { "speaker": "luke_childs", "time": "01:06:23", "start": 3983.29, "text": "yeah, so really, just improved, privacy, so CoinJoin and post-mix CoinJoin tools, I'm really, really just keen to see where that goes. also interested to see, Taproot and Schnorr be deployed. Yeah. mainly privacy for me, privacy is the main thing that motivates me, and, and a big part of also why I started working on Umbrel was because, before I was working on Umbrel, I had a lot of privacy tools I wanted to build, but I was-- a lot of When you get a large amount of people to use them, if it's only a minority of people using them, you don't have a good like anonymity set, you don't have a good crowd to hide in. And then when I saw what my uncle was doing with, with Umbrel, I kind of thought, this is like really lowering the barrier of like- Technical knowledge for people to get into Bitcoin. So if I can help with this project and then try and focus on adding like privacy tools to it, that could not only be building useful privacy tools, but also building useful privacy tools that are much more accessible to users of a w-a wide range of skills, which ultimately just, you know, really benefits everybody." }, { "speaker": "stephan", "time": "01:07:24", "start": 4044.13, "text": "Excellent. Well, look, I think the, they're the key points I was interested to hit. Luke, before we let you go, where can listeners find you? And also if they would like to sponsor your development on GitHub, where can" }, { "speaker": "luke_childs", "time": "01:07:37", "start": 4057.02, "text": "So, lukechilds.co has links to all of my like social profiles and stuff. I'm at luke childs on Twitter. and also github.com/forwardslash/lukechilds is my GitHub, profile." }, { "speaker": "stephan", "time": "01:07:49", "start": 4069.15, "text": "Fantastic. Well, thank you very much, Luke. Yeah, thanks a lot, Stephan. It's been great. Subscribe to the show, share it with your friends, and get the show notes at stephanilivera dot com slash two o six. That's it from me. I'll see you in the citadels." } ] }