Have you wondered how to recover bitcoins from a seed? Maybe your friend doesn’t remember which wallet they used? In this episode with Luke Childs, we talk about how to recover them into Electrum with his newly written tool. 

We also talk about Umbrel, a new node package promising very easy set up. 

We also chat about security, development and bitcoin coding.

Links:

• Twitter: @lukechilds
• Github: https://github.com/sponsors/lukechilds#sponsors
• Site: https://lukechilds.co/ 
• Umbrel: https://getumbrel.com/

Sponsors:

• Swan Bitcoin
• Knox Custody
• Unchained Capital (code LIVERA)

Stephan Livera links:

• Show notes and website 
• Follow me on twitter @stephanlivera
• Subscribe to the podcast 
• Patreon @stephanlivera

Podcast Transcript:

Stephan Livera:

Luke, welcome to the show.

Luke Childs:

Hey, thanks. Great to be here.

Stephan Livera:

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 good time to get you on the show. So Luke, just for listeners, can you tell us a little bit about yourself? Who are you and why are you working on Bitcoin open source?

Luke Childs:

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 of two or three years.

Stephan Livera:

Right. And so it seems like you’ve done a range of things in the Bitcoin world that 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?

Luke Childs:

Yeah, sure. So I was working on a BitcoinJS, which is a JavaScript library. So it’s not a wallet, but a lot of wallets which are implemented in JavaScript use this library. So, so that’s not a wallet itself, but most of us are using this code. So BitcoinJS is something that I’ve done some contributions towards. I worked on the PSBT functionality on BitcoinJS and also recently adding PayJoin functionality. To BitcoinJS also Electrum so the BIP39 recovery pull request that just recently got merged and I’ve added a few smaller features to Electrum like a SSL fingerprint verification. And I also worked on the adding PayJoin functionality into Blue Wallet as well.

Stephan Livera:

Yeah, that’s awesome, man. That’s really some really well known wallets in the space and the library as well. I thought it would 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?

Luke Childs:

Yeah, so the thing is when you have your, like a BIP 39 seed phrase, technically that’s not actually enough to recover all of your funds. So the way it works is that this BIP39 seed phrase sort of derives a tree of different multiple wallets and you also need the derivation path, which tells them exactly which branch on this tree it needs to look to find your addresses. So if you just have your seed phrase alone, the wallet needs to, it needs you to either tell it the derivation path, or it needs to sort of brute force all of the possible derivation paths until it finds the wallet with funds on. So this is what that pull request does. It brute forces all of the different possible paths until finds some with funds on and then ask the user, like we found some funds here. We found some funds here, which ones do you want to restore?

Stephan Livera:

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 12 or 24 words. And in that scenario, why is it that, you know, you can’t just necessarily you know, just recover that into Electrum?

Luke Childs:

So in many ways you can do this. So although there are all these different derivation paths, there are some agreed upon standards that most wallets follow. So it’s not too bad. There’s 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 derivation paths differ for different script types. So this is like if you have a SegWit wallet or a non SegWit wallet they have different derivation paths for that. And then also there is a slightly different seeds formats. So BIP39 is sort of the standard that most wallets used, but Electrum has its own seed format that is incompatible. So Electrum, by default, when you create an Electrum wallet, you don’t actually have a BIP39 seed.

Luke Childs:

You have a custom Electrum seed. You can recover a BIP39 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, aloing with your seed that separate in BIP39 in BIP39 seed words, seed phrases but Electrum seed phrases actually encode this version information into the seed itself. So within Electrum seed, 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.

Stephan Livera:

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. If we just want them to be able to write down these 12 words or 24 words, whatever, and that’s enough, whereas basically all the common or well known hardware, wallets, and other wallets are using BIP39. So that’s kind of where your tool is really handy. So maybe do you want to 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.org and the information there. I’m sure you’re familiar with it.

Luke Childs:

Yeah, so walletsrecovery is a great website. 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 these standard derivation paths that I mentioned before, but there were 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 wallets recovery is just a great resource where it lists pretty much every single wallet and it listed our ration path that it uses. So that’s what we’re using our tool in the Electrum 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 information there.

Stephan Livera:

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 will just scan through all of the common ones. Right?

Luke Childs:

Yeah, exactly. It’s quite interesting actually, what you, what you said before about the different arguments between 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 comes down to what you think a seed is. And 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 a wallet. And like, what I mean by that is, do you think every wallet that you create should have its own seed or do you want to have one seed phrase and be able to create like infinite wallets with that seed phrase? Because that’s the way the BIP39 works. If you have a BIP39 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.

Luke Childs:

And if that’s the way that you think it 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 SegWit wallet, and then 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 I mean, my personal opinion is that actually, I think BIP39 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 really sensitive information.

Luke Childs:

If you have one seed phrase that like seeds everything you can, you can store it super securely. So you can like load onto a hardware wallet. So you have something to actually 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 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 is gets destroyed or something happens and you need to recover your funds, then you can bury up that safe, but you can continue to create more like more and more wallets in the future without needing to access the phrase just from a hardware wallet. So the fact that you don’t have to keep on accessing that storage frequently, it means that it’s sort of much more secure.

Luke Childs:

You can, you can make it much harder to get access to it 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 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 maybe you can’t be bothered to keep on digging up safes. 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 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 actually a better approach to take the BIP39 approach where you just have this one piece of super secure entropy that you keep secure.

Luke Childs:

You don’t have to worry about it again, you can derive more wallets from it. And then I guess it’s a valid concern that yeah, then users need to need to keep track of their derivation paths and any other metadata, they need to recover the different wallets. But the thing is this information on its own is not really that sensitive, as long as you know, when it’s not paired with the seed phrase, with the entropy that’s in the wallets, these derivation paths are not particularly sensitive. So you could like, you know, stick it on Dropbox and like encrypt it, stick it on Dropbox. It’s, you know, that’s up backed up and replicated. Like you could even tweet it publicly if you want it? 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 opsec. I wouldn’t recommend it, 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 can understand the Electrum 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.

Stephan Livera:

Right. Yeah. And the other thing, I guess, from, if I were to try and steelman the Electrum and Thomas view, it might be something more about actually it’s not about the sensitivity of that information. It’s more about the user knowing that they need to back that up. And I think, you know, 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 Bitcoin. Obviously I went forget that, but a more casual Bitcoin person might not. And I guess that’s part of the argument, right?

Luke Childs:

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 backs that up. Like if there was some sort of standard protocols that all the wallets supported to do that could be one solution. Also like at the moment there are 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 10 different derivation paths and it that in like less than a second.

Luke Childs:

So, you know, because I like the way Electrum works, it has the entire UTXO set indexed. It doesn’t have to do a full rescanned like with Bitcoin call when you’re recovering funds, the Electrum server has everything indexed. So it’s super quick to query. So like, yeah, I could scan 10 different derivation paths in 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 pretty feasible.

Stephan Livera:

I guess just one, a few other little technicality points. So which paths we’re looking here only at the non multisig schemes, correct?

Luke Childs:

Yeah, so it can recover every single non multisig path recorded on walletsrecovery.org apart from Bitcoin core without going into too much technical details, there’s basically the concept of hardened derivation and unhardened derivation. And Electrum only works with unhardened sub keys at the account level, and that’s not what Bitcoin core uses. So although I could have implemented scanning for the Bitcoin core derivation path is not actually compatible with electrum. It wouldn’t be able to be imported into Electrum. So I didn’t implement that, but every single other wallet, single signature wallet on walletsrecovery.org is supported by the Electrum feature.

Stephan Livera:

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 chain and the change chain. Could you just outline a little bit about that? What are those and what’s going on with those?

Luke Childs:

Yeah. So if you think of like, as I mentioned before, like the seed phrase basically generates like a tree with different branches. So like generally, like the first level is the script type, which could be SegWit and non-SegWit. Then each of those branches have their own branches for the account level, which comes like the first account. It’s like an account with a third account. And then each of those accounts have branches that we call internal and external. So the external branch is for addresses that you receive. So, if I want to send you some Bitcoin, you have to give me an external and address on the external branch and the internal branch is for changing addresses. So if you were paying me and you had some change to send back to yourself, that would always get back to a, change address on the internal branch.

Luke Childs:

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 rescanning functionality, because normally when you’re scanning a chain, you would scan like the internal chain and the external chain and recover the final balance. But because I was only trying to count, like trying to figure out how’s this account ever been used. I wasn’t trying to say 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 ever been used. All I needed to do with scan the gap limit on the external chain, which is the first 20 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. Cause they never would’ve sent a transaction.

Stephan Livera:

Clever. I like that. And so we should also jump into gap limits. So what is a gap limit?

Luke Childs:

So a gap limit is the, the gap, the empty gap that you can have between addresses that are unused. So the reason we have this is because the like a BIP44 like, wallets are deterministic. So when you have the seed phrase, it can, it can generate like infinite addresses, basically we need to set some sort of same limit of like how far ahead your wallet’s going to be scanning. It can’t just scan. It can’t be looking ahead for infinite addresses, because like, you know, that’d be impossible. So we have to set some sensible limit for how far we look ahead. And 20 is like the sort of widely agreed upon limit. So say if you want to donate to me and I generate an address for you, and then somebody else wants to donate for me and I generate an address for them.

Luke Childs:

I don’t know that you’re actually gonna spend to that address, but I should still give everyone else the new address because I don’t want to give someone the same address. That’s address reuse and that’s bad for privacy, but if I gave out 20 addresses that were unused, and then I gave out the 21st address to somebody else, if those first 20 people didn’t ever spend, didn’t ever send back onto those addresses. And the 21st person did when when I was recovering that seed into a wallet, it would actually just stop scanning when it’s, here’s a gap of 20, it was stopped scanning and say, this address isn’t used anymore, and it wouldn’t be able to recover it. So it was very important that wallets respect this limit, because if some wallet decided to say set a gap limit of 25, and then that situation happens, if you import it, that seed phrase to a different wallet, it would just stop scanning when it, when it got to that gap of 25 and would never continue to scan down the chain. So we’d have this awful fragmentation where like certain seeds won’t work when they’re imported to certain wallets, which would be a really bad situation.

Stephan Livera:

Got it. So let me just replay that, I guess. So we can think of it. Like our wallets have been coded in a way to sort of check the first 20 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 29th address or whatever, but because you know, you’ve only set the wallet to scan to the first 20. 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 29th address. Would you say that’s a good summary?

Luke Childs:

Yeah, yeah, yeah. That’s exactly right. So yeah, so, so in that scenario, you would just need to start reusing. What were, you have two choices. You either start reusing the addresses after you get to 20. So you start. So if you, if you’re on the zeroth address, so you give out the first 20, if somebody, if the 20, none of them have been donated to, and somebody asks you for their 21st one, you have to reuse the first address. Alternatively, you can give them the 21st address, but you need to note down somewhere, my gap limit is now 21, and you need to use that the next time you restore your wallet. So like sometimes you have to do that. Like for example, like a merchant solutions, like BTCPay, 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 10,000 or something crazy like that.

Luke Childs:

And like, they need to do that for their use case because obviously if you have a store and you’re giving out a unique address to each customer, and you’re tracking that address for that specific payment, if you have 20 people in your checkout you can’t just like wait for the first person to pay until you can issue out a new, like invoice to somebody else. So in that 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 BTCPay store, you should be aware that there were these, you know, if you have a 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 they respect the standard 20.

Stephan Livera:

Yep. And I guess for a listener or for a user who is not so familiar with how Bitcoin works, they might try to recover a wallet and then think, 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?

Luke Childs:

Yeah. So not very many wallets support this. But Electrum is one of the few that does this. It’s not yeah, it’s not natively exposed in the GUI for good reasons because then 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 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.

Stephan Livera:

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’d just use the default 20 gap limit, but I guess the tradeoff 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 could be like a DOS thing. Like 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 lot of load on that server. Right?

Luke Childs:

Yeah. That’s right. So, yeah, we use 20, which is the S which is like the recommended standard in BIP44, which is what pretty much every wallet uses, but like somebody has recommended on the issue, like, Oh, maybe we should increase it. So like 10,000 or something, so we can support BTC pay. But Thomas and ghost, the electric developers were 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 of 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.

Stephan Livera:

And Luke, I know you run one yourself. Can you tell us a little bit about how and why you do that?

Luke Childs:

Yeah. I mean, I just run it for myself personally and I just thought I may as well expose it for anyone else. So yeah, mine is available at bitcoin.lukechilds.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’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 by the way, I just, the reason I make it public is just so I know, like if I’m ever doing some sort of random scripty stuff, I can just quickly ping a Bitcoin.lukechilds.co. When I know I’ve got Electrum service, there’s going to be up and running.

Stephan Livera:

That’s great. And so in terms of running that, is that just a VPS? Is that expensive to run? What goes into it?

Luke Childs:

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 the VPS on DigitalOcean. So obviously I can’t be sure that digital ocean aren’t monitoring it in any way. Like, I don’t think they would be, but I can’t be sure they’re not. And yeah, it’s like a $5, it’s like a $5 VPS, but I have like a, an external volume with the blockchain storage on with like a Bitcoin full nodes. And then that’s the way the costs are involved with, I think it’s like maybe 30 or $40 a month for the actual storage for the blockchain and then $5 for the actual server. If you wanna run your own on a cloud server. Yeah. It’s about it’s around like $30 to $40 a month, or, but personally I would definitely recommend running your own locally on a Raspberry Pi with something like Umbrel.

Stephan Livera:

So for most people, yeah, they would just have, you know, they’d be running one of these node packages and obviously we’re going to 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 a the Electrum server or Electrum X, probably in this case on a VPs, then you might be more comfortable kind of exposing that on clearnet right?

Luke Childs:

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 going to be faster to just want a local server. You can run the rust Electrum server or also the, these like BWT Bitcoin wallet tracker, I think it’s called. Yeah. Yeah. That’s a really great implementation as well. So this is for you to use personally, that’s the easiest solution also probably going to be quicker than running a remote server, but the other benefit of running a remote server is you can also share it with like family members and friends. So, you know, you can have like a trust minimized 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.

Stephan Livera:

Yep. And the privacy aspects as well, that you’re doxing only to your uncle Jim, the proverbial uncle Jim. So this might be an example for listeners who want to 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?

Luke Childs:

Yeah. Blue Wallet is based on Electrum protocol and also Phoenix, the lightning wallet, you can find that by your own Electrum server too.

Stephan Livera:

Yes. That’s a really cool one as well. So I guess, turning to wallets, what are you mostly interested in wallet wise and, you know, kind of, where are you currently on that?

Luke Childs:

I’m really interested in a coinjoin 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. 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 postmix 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 really your, you know, you’re really exposing your privacy by not by just sort of letting your wallet blindly choose UTXOs, merged together. So I’m very interested to see what emerges from that space.

Stephan Livera:

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 of that chunk or that UTXO as do not spend, then you can inadvertently docs your privacy by spending it together with some other UTXO, right?

Luke Childs:

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. Is 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 a well 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 the transaction that I have no idea I received it from. And it’s a really small amount I would say, a bit suspect this not used at UTXO. Just labeling the transactions to make sure you keep track of where your coins came from is because I think are a very simple and very effective way that you can kind of mitigate some of these attacks and reduce the privacy loss you get.

Stephan Livera:

Cool. And so you mentioned that you’ve done some blue wallet contributions as well. Can you tell us a little bit about what you’ve done on that side?

Luke Childs:

Yeah, so that was so I worked on the PayJoin client library and BitcoinJS and that was a joint work between me and Kukks from BTCPay. And Jonathan Underwood’s, who’s like the main, the main developer on BitcoinJS. 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’s wallet to add PayJoin and functionality. And then we we’ve got that to a point where it was almost ready, but the actual PayJoin BIP wasn’t standardized at this point. So we just kind of implemented it up to the point where the BIP was at knowing that we would have to make some changes in the future then just to kind of test that implementation.

Luke Childs:

I went ahead and started to integrate it into a Blue Wallet. So this was a few months ago now and it was basically integrated. So it was like 99% done. But the, yeah, the BIP has changed quite a bit since then and like me and Kukks and John kind of had other things that we were focusing on. So I haven’t had time to go back and update that since the BIP has been finalized I think Kukks has been doing some work on the PayJoin client finishing that up, just get it in the state that it’s aligned with the BIP and Overtorment, which is, I think the lead developer of.

Stephan Livera:

Igor, yeah.

Luke Childs:

yeah, you had him on recently actually. Yeah. I think he’s taking over the implementation that I did and is finishing that up and getting that ready. So yeah, that was a while ago that I did that, but it was cause the BIP wasn’t standardized it wasn’t ready to be merged and the BIP has been standardized now, so that should land soon, but some other people have taken over finishing that off for me.

Stephan Livera:

With PayJoin there as well. I guess one interesting thing there is, it actually does change the QR code that you scan. So for example, if you scan the BTCPay 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. Yeah.

Luke Childs:

I don’t think it will. It’s likely that that would break compatibility because I can’t remember the BIP number is now that Bit40 something, but there’s like a, there’s a specific 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 PayJoin information is added as one of these extra query parameters. So any, any wallet that is able to scan like a Bitcoin URI, if it sees any of these extra query parameters, that it doesn’t understand it just ignores them. So I think the chances of it breaking the existing Wallets is pretty low.

Stephan Livera:

I was funnily enough, I was actually testing it out just with Phoenix Wallet on my own BTCPay. And I think that was the reason why it couldn’t scan the Bitcoin address. Yeah. So I’ve mentioned that with the Phoenix guys, so 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 PayJoins the better it is for the overall network in terms of breaking that common input ownership heuristic. So I want to also chat 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 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?

Luke Childs:

Yeah, so I think I’ve published a lot of JavaScript modules on NPM like where most of my work has been, I’ve done similar things, but mostly JavaScript modules on NPM.

Stephan Livera:

So listeners who aren’t familiar, can you just spell out what is NPM?

Luke Childs:

NPM is node package manager. So NodeJS is like a JavaScript implementation. And NPM node package manager is like a package registry. So if say, if I’m writing like a Bitcoin library, like say BitcoinJS, I publish Bitcoin JS to NPM. And then if anybody else is writing, writing a Bitcoin wallet in JavaScripts, they just do NPM install BitcoinJS and it’ll pull it down and they have it ready in their project. So it’s just a way for people to share like code libraries, modules and stuff like that. So I published a lot of modules to MPM I think maybe like about 80 modules that I’ve written myself. And then there’s probably like maybe about 10 that I just help contribute towards. And yeah, it’s really crazy. Like they’ve became really popular. Some of them, like, I think I’ve had about a 7 billion downloads total over all of them now which is just absolutely insane.

Luke Childs:

Like it kind of terrifies me a little bit, but people put this much trust in my code. But yeah there’s, some of them are used quite a lot. And it if you’re building something that could cause a lot of the modules or like kind of low level, so I’ve done like a really low level key value store that’s used this depended on by a lot of other modules. I’ve done some work on like BitcoinJS obviously, which is used depended on by a lot of other Bitcoin projects for Browserify, which is a project that allows code written in NodeJS to work in the browser, which a lot of projects make use of that under the hood. So like actually if you have like a JavaScript project, there’s a good chance that some of my code in there somewhere just very low down, hidden around.

Stephan Livera:

I see. And so it’s one of those things where when you talk to some more technical people and they talk about how the internet is like this patchwork of various projects all cobbled together, and some of them are maintained by some random guy that you’ve never met before. And in some sense, you’re one of those guys.

Luke Childs:

Yeah. Honestly, that’s probably more true than most people realize.

Stephan Livera:

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’s secure and so on, but actually underneath there’s kind of all these possible upstream dependencies and potential vulnerabilities there also, Right?

Luke Childs:

Yeah. Well, this is actually a very huge issue with NodeJS and JavaScript. 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 like, 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 premade 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 it’s a building a, you know, a brochure website or something, but when you stop 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.

Luke Childs:

And then each of those five modules are implemented in five other modules. And each of those five modules are included in 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 his code. So yeah, this is kind of an issue in the JavaScript ecosystem. It’s something we prevent, well, we try and mitigate against it in BitcoinJS. So we don’t really use any third party libraries in BitcoinJS. And the few that we do like Browserify most of the BitcoinJS, yes, contributors are also Browserify contributors. So we’re kind of involved in those projects, but a lot of other JavaScript projects don’t take this approach. They just blindly include third party dependencies and yeah, like there’s just blind trust. You’re just blindly trusting every single person in your dependency tree to not push another update there.

Stephan Livera:

Right. And so it’s sort of like, it’s like the programmer or equivalent of copying someone’s homework and you don’t know 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. Right?

Luke Childs:

Yeah, exactly. I mean, honestly, like some of the some of the projects that I’ve seen, like sometimes they have literally multiple thousands of lines, but it’s just listing the dependencies. So that’s not code, that’s just thousands of lines listing the dependencies that then contain hundreds of lines 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 problems than you would have yourself. It’s very difficult to go through that amount of code and audit, really understand how it’s working and be sure that there’s no vulnerabilities or intentional backdoors in it.

Stephan Livera:

I say, because it could be that there was like a very subtle error or it could be that a bug or a, or a malicious code, a piece of malicious code was hidden in a subtle way. And 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 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 it?

Luke Childs:

No, no. So I, a hundred percent agree with like the Unix philosophy of like small focused programs. The issue is with so with Unix, like most of these, like all of these small focused binarys like cat to list a file or like LS to list the files in the directory where they just do one small, tiny thing. That’s fine. But that code has 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, these ideas on a mailing list and everyone in like like Linux or politics or whatever kind of agrees. Yeah. This is a useful utility. The difference between that and the, what we have on NPM is that these modules are written by like somebody who has no accountability.

Luke Childs:

They have no reputation, they have enough, like it could be an anonymous account. They have nothing to lose by pushing yeah, this is the main issue is, is that they can push a malicious update. So like, let’s say like the Unix philosophy, if the author of LS the command, that you use to list the directory pushed a malicious update that scans the user’s hard drive for a Bitcoin wallet and then post it to their server. No Linux distribution in the world is going to include that change because they’re going to have lots of people carefully auditing the changes. And that would be very obvious to spot. Nobody’s going to include that on NPM people just blame the do NPM install. They don’t even check the code. They just read read me, on github. And like, Oh, this is cool.

Luke Childs:

NPM install, pull that shit down, publish it. Nobody actually audits any of that stuff. And even if you do audit it, the next time you do NPM update and update all your dependencies, 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, I’m gonna something later. Like, it’s this sort of the ordering that doesn’t really happen in the NPM ecosystem 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’d be able to get away with it. So it’s not necessarily the small focused part. It’s the, it’s the huge, it’s the huge dependency tree part.

Stephan Livera:

Yeah. Yeah, definitely.I mean, 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.

Luke Childs:

Yeah, absolutely. And I think that’s a great thing to do. Like I think I’m not a hundred percent 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 then I think within like the last year or two that was actually removed and that like all of this stuff that we were depending on openSSL for was implemented directly in Bitcoin. So we could remove the openSSL dependency. So things like that I think are great and make it much, they made the code base much more auditable, much easier to audit and much easier to be able to trust that the code is actually doing what you think it’s doing.

Stephan Livera:

And just out of curiosity, as you mentioned, BitcoinJS, do you know just some example, wallets or other Bitcoin software that actually depend on BitcoinJS just for listeners who are curious?

Luke Childs:

Yeah. So Bitcoin so BlueWallet you just BitcoinJS Exodus, which is, it’s like a closed source multi-asset wallet, but they’re using BitcoinJS. They actually sponsored me to work on Bitcoin Jasper for awhile which was really nice of them. Pretty much any web wallet is most likely using BitcoinJS. There are some alternatives like BitPay have their own library called like Bitcore, I think, but it’s not that popular, big congested, the most popular. So is there any web wallet is pretty much always using BitcoinJS. And yeah, I’m sure there are a lot more, but off the top of my head, those are the ones that I can think of.

Stephan Livera:

I guess, while 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 go and find like bug bounties and get income from that, or what’s kind of your process around that?

Luke Childs:

Yeah, so it was purely something I actually do out of interest. I enjoy it. It’s fun. And it was something that kind of subsidized my opensource work a little bit because although like I’m very lucky recently, I’ve had some sponsors on getting 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 fund it. And like reporting security flaws and then getting awarded bounties for that has been like one way that I’ve earned money and been able 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 I normally like the process is I would just them explain the issue work with them to like on how to resolve it. And often they will reward you with a bounty for doing that. But yeah, it’s not something that I ever like sit down and think right today, I’m going to 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 kinda 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. And then if I can find a way to break it and report it, then it’s like a pretty big benefit that I can, earn money from that.

Stephan Livera:

Right. Yeah. And so I know also in the Bitcoin world, people are because this is all open source, right. People work on, it’s kind of like a, 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 saying you hear is ‘eyes on the code’. And so I suppose one of the ways that happens is someone is building things on top of your code. Well then there’s more people looking at it and then they might catch these vulnerabilities. Has that been your experience also?

Luke Childs:

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 sort of centralize around a single solution, but also if it’s this really critical code 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, a way more efficient way of working and yeah, just so much, so much better for everyone involved.

Stephan Livera:

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 of node packages that are available. Things like myNode and nodl Raspiblitz and Ronindojo and so on. But I’ve seen some chatter and I’ve seen some screenshots and my friend Ketan has also played around with Umbrel also. So can you tell us a little bit about it? What is Umbrel?

Luke Childs:

Yeah, so it’s like a, sort of like a Bitcoin and lightning application stack. So it’s a way, it’s a simple way for people to run a Bitcoin 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 there’s like, people seem to be pretty split on this. Like some people will say, Oh, it’s too complicated. It’s really hard. People. Like people can’t expect people to be able to do this. And other people 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 downloaded Bitcoin core and double-clicking the exe, like, that’s not hard.

Luke Childs:

Anybody can do that, but there’s like, there’s a lot more to that then. There’s a lot more to running a full node than just that it’s like, you know, maybe you want to set up an Electrum server, and add that to your wallet. Maybe you want to set up lightning. How do you set these up in a way that they can communicate between each other? How do you expose them publicly or expose them so you can access them remotely? 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 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 anyone can do it. It should be a full node. That’s so easy. Even Peter McCormack can use it. That’s the end goal. I think

Stephan Livera:

As I see it, it’s intended as like a Raspberry Pi style Bitcoin node, right?

Luke Childs:

Yeah. So it’s like yeah, so it can run on anything at the moment. The target that we’re supporting is Raspiblitz Pi. So just because it’s early now and we need to just sort of focus on one thing to be able to iterate faster and, and put stuff up quicker. We’re focusing on the Raspberry pi part. So that’s the recommended way of installing yet. We publish an operating system image that you can download and flash an SD card and then just wipe that in a pie do 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.

Stephan Livera:

Do you get any difficulty there with having to code for, like, is it the ARM processor versus other processes?

Luke Childs:

No, not really. So 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 want it to run, like say it runs on ARM, but if you wanted to run it on x86, like, like a normal desktop CPU or service, if you, 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 this sort of glue code, there’s sort of the, the way that we’re orchestrating everything is mostly done using Docker and scripting languages, which also works cross platform. So the actual like hardware architecture is not something that we need to worry about. That’s kind of all abstracted away for us.

Stephan Livera:

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 a, 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 costs to run one of these, if they were to go with the recommended setup, what kind of cost range are we looking at here?

Luke Childs:

To be honest here, I’m not actually sure. Off the top of my head. But I mean, a Raspberry Pi is like $50. So we recommend the four gigabyte Raspberry Pi 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. I’m not sure off the top of my head, but that’s the sort of rough ballpark figure that you’d be looking at.

Stephan Livera:

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.

Luke Childs:

Yeah. So the way, the thing about that is obviously it’s like most people right now, we’re using 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 at doing that is because it’s just easy. It’s just, you download an app, you open it and it just works that it’s instantly, it just works straight away. It’s hard to convince people to run a full node and wait like three days for the blockchain to sync when they could just install an app 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 achieved the best of both worlds by when you set up your Umbrel.

Luke Childs:

We start syncing Bitcoin core in the background instantly. So we start thinking a full mode 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 neutrino SPV is actually 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 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 syncs like however long that takes maybe a couple of days it just instantly switches over to using the format. So it was just a temporary issue. So as long as you trust the miners to not pull off some huge coordinated attack in like the first couple of 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.

Stephan Livera:

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.

Luke Childs:

The approach that we’re taking with a lot of the features that we want to 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 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.

Stephan Livera:

That’s a clever approach. And I think that’s probably the right one for that next level of user. Right? So obviously listeners of my show tend to be the more advanced 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 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?

Luke Childs:

Yeah, absolutely. So we don’t have any like, hard coded plans for like, we’re going to add this up, we’re going to add that up. We’re just kind of waiting to see what the community asks 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 yeah, if we get demand for those absolutely we’re going to have those and anything else, you know, if there’s things that people want, we just want them to tell us and we’ll implement what people want

Stephan Livera:

And who else is working on the project by the way?

Luke Childs:

So there is Mayank who is, he is like the, 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 were a few other people who have, who sort of loosely are involved in it. Like it just sort of, we talk ideas over a lot. Yeah, but it’s, yeah, it’s made me and Mayank and no limit who have been building it.

Stephan Livera:

With the seed as well. I was chatting with Ketan. He was telling me it is the lnd aezeed, which is another type of seed from what we spoke about at the start. Right. Because you’ve got BIP39, you’ve got Electrum style and then you’ve got Aezeed right. Which is the lnd style.

Luke Childs:

Yeah. Yeah. So we don’t really have a choice there. We’re using lnd to kind of abstract away the differences. So, so we can just interface with lnd and then we can do things with like lightning to do things so blockchain, Bitcoin, and we can configure lnd to use to be backed by Bitcoin core or to backed by neutrino. So using lnd gives us a common interface to just interact with, for all of that, regardless of what backend is being used and lnd uses aezeed. So we didn’t really have a choice in that. Yeah.

Stephan Livera:

But I think it’s a clever approach because in some ways it’s quite, it’s a bit of a simplification of what’s going on. And so that way it’s a bit more I can understand why

Luke Childs:

Yeah aezeed is also pretty cool in that it encodes the birth date 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 Umbrel it’s one-to-one right. The lnd seed is for the seed that we gave you is for the lnd wallet. So in this case, it makes sense to encode version here, it make sense to, and go to birthday. Cause it’s specifically for that lightning wallet. If you like so like you got to think of Umbrel’s as a server and not client. So it’s not really a wallet, it’s like an application stack. And if you want it 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, aezeed has the birth date of the wallet encoded into it, which means that when you recover it, it can really efficiently rescan the blockchain to recover your funds because it has the birth date. 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 in scanning on blocks before that we only need to scan in blocks after that.

Stephan Livera:

And in terms of the model for Umbrel, is it going to be like, is it a paid product or how’s that part going to work?

Luke Childs:

So the idea is that Umbrel is going to be a for profit open source project. So we want to be self sustainable, right? We don’t want to 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. 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 turn it into something that can fund itself. But to be clear Umbrel itself, like Umbrel is always going to be a free and open source software project. We’re never gonna just be like, Oh, now you have to pay for Umbrel. There will be some kind of paid additional services that would compliment it. Hopefully that we could come up with a way to monetize it. That would be the idea in the future. But yeah, as of now, we don’t know exactly what that would look like.

Stephan Livera:

Maybe something like you might a sell the premade version of the, you know, of the box or have like a premium version that you pay for or things like that.

Luke Childs:

Yeah. Something like that really. Like, it’s just, yeah. You know, if we’re building Umbrel and people are saying, people are saying like, people have some sort of issue that we can’t really justify solving for free because there would be cost behind it, but we could be like, Oh, we can solve this problem, but it’s going to cost us money. Then that could be something we’ll sell, you know, like yeah. Just whatever we come up with along the way really.

Stephan Livera:

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 are you going to figure out which one are you just gonna have to like pick which based on popularity of what the community is 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?

Luke Childs:

I think, yeah, a big part of it’s just going to be what most people are requesting, but also there’s some features that like people might not really request because they don’t really know that they need it, but that we think are important to ask. So for example automated channel backups is something that we are almost ready to release, which there is requested that, but we think that’s pretty important. And also like a, 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 to this. But I was kind of worried about a potential privacy leak because if we basically, we want to, we want to back up the channel data every time it changes because you know, 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.

Luke Childs:

So basically the recovery process is completely transparent. Your channel States are backed up with a unique ID. That’s deterministically derived from your seed. So let’s say your house gets struck by lightning and it fries your 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 lightning funds from these 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 an encryption form which is also deterministically derived from your inaudible. So we can’t read those backup files, but Umbrel will automatically just decrypt that import it into lnd.

Luke Childs:

So from the use perspective, they’ve just walked in the seed phrase and then Umbrel is backed up and restored and has all the channel 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 kind of worried about like, how can we do this in a privacy respecting way, right? Because if we’re pinging our update server with an ID each time your channel state changes, there are.I mean, it would be quite difficult to pull off, but there are potential attack. Like deanonymizing attack rates is there. Like if we were doing like a timing analysis attack, that if we were monitoring the lightning network and seeing how the state changes on the lightning network of all the channels, and we saw that, right this ID backed up their channel state data 57 times that day.

Luke Childs:

And this channel change the state 57 times that day we could make a correlation there. So the way we do the backups we back up every time the channel state changes. But then we also just randomly back up 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 random data. So you could back up three times in a row, even if nothing’s changed on your device. And one time the backup could be bigger in size the next time it could be smaller in size the next time 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, wherever your backups increase, reduce, change in size.

Luke Childs:

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 want to put myself in a position where we have that information. And it’s not just about trusting us. Like if we got a request from law enforcement 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 want to, we want to 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.

Stephan Livera:

Right. And this can be a bit of a difficult question. I know in the case of nodl, they use like a USB key to do the backups and then yeah. But then it takes, but then the question is, is that easy for the user and so on? And I don’t know, in the nodl case, they’ve done things to try and make that a bit easier, but certainly I appreciate a, that’s a bit of a tricky one to handle there. And I guess the other point really is just that if people are using Umbrel that it depends really how they’re going to use it. And if many people are just going to be HODLing, well, they’re probably just going to be on a hardware wallet, in which case they just want, you know, Electrum server, or they want something like specter connecting to Bitcoin core on the Umbrel in this case. Because they don’t want to leave too many, too many Bitcoins or too many funds on the device, hot. They just want only the amount that they were doing for the lightning channel component. And then all the savings HODLing stuff is in the hardware wallet part. Right.

Luke Childs:

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 electrum or whatever. So the idea that we want to work towards with Umbrel’s, like each application that we add to Umbrel is like isolated it’s like there are very strict, like permissioning systems 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 don’t, we’re not going to be like pushing our decisions on other people and saying, Oh, now everyone has to run this. Now everyone has to run that, you know, it’s going to be up to you to choose, like, I want this, I want this, I want that.

Stephan Livera:

And obviously I understand with Umbrel, it is in an early stage at this point. So it’s kind of like in a beta test, kind of a small number of users who are just playing around with it and the more technical users who are giving feedback. So what stage would you say you’re at in terms of like going to the next, I guess next phase or next release?

Luke Childs:

Yeah. So I should probably be clear about this Umbrel in its current state is like 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 links to like try and protect people from fund loss and stuff, but like, absolutely it’s early, there will be bugs. We encourage people to test it out. We want people to test it out on main net, but just like with small amounts of money, you know, with like, don’t put any money on Umbrel. You’re not prepared to lose yet. Because you know, yeah, it is new. And you know, I don’t know when we’re going to be at a stage where we say it’s stable and it is safer for funds, but there are like there are multiple things that we’re aware of the aren’t, that we’re not comfortable recommending people put large amounts of funds on it in that state.

Luke Childs:

And we will rectify that before we say 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 github. We linked to like a security file that specifically lists the things that we have, like some sort of shortcuts that we’ve taken for now to be able to make it easy, to pick the test and debug and stuff that are not ideal for security and that we will fix, but we’ve documented some of these, if you want to read about them on our github.

Stephan Livera:

Awesome.And so just turning more broadly to Bitcoin 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, a bitcoin and lightning wallets or applications need?

Luke Childs:

Yeah, so really just improved privacy. So CoinJoin and postmix CoinJoin tools. I’m really, really just keen to see where that goes. I’m also interested to see taproot and Schnorr be deployed. Yeah. many privacy is the main thing that motivates me. And a big part of also why I started working on Umbrel because before I was working on Umbrel, I had a lot of privacy tools I wanted to build, but I was a lot of these privacy tools only really work when you get a large amount of people to use them. If it’s only a minority 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 Mayank was doing with Umbrel, a 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 wide range of skills, which ultimately just really benefits everybody.

Stephan Livera:

Excellent. Well, look, I think that 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 they find you?

Luke Childs:

So Lukechilds.co has links to all of my like social profiles and stuff. I’m @Lukechilds on Twitter and also Github.com for such the child’s is my Github profile.

Stephan Livera:

Fantastic. Well, thank you very much, Luke.

Luke Childs:

Yeah. Thanks a lot. Stephan, it’s been great.