path: root/transcripts/stephan-livera-podcast/2020-07-26-nix-bitcoin.mdwn

Name: nixbitcoindev

Topic: nix-bitcoin

Location: Stephan Livera Podcast

Date: July 26th 2020

Audio: https://stephanlivera.com/episode/195/

nix-bitcoin on GitHub: https://github.com/fort-nix/nix-bitcoin

Transcript completed by: Stephan Livera Edited by: Michael Folkson

# Intro

Stephan Livera (SL): nixbitcoindev welcome to the show.

nixbitcoindev (NBD): Hello. Thank you for having me.

SL: Obviously as you’re under a pseudonym don’t dox anything about yourself but can you just tell us what you’re interested in about Bitcoin and is it the computer science aspects or what aspects of it interest you?

NBD: I came into Bitcoin pretty much from the privacy angle because I’ve always pretty much since I touched a computer, I’ve thought it’s really like an extension of the human brain. So it deserves the same protection security wise as the content in your brain, which is absolute. That’s really the angle I came into Bitcoin from where I saw this is this kind of money that if we use it properly, it can guarantee that level of privacy in our financial transactions. Obviously a great part of privacy on Bitcoin is running your own node and having your own hardware. I’ve been really primed always for something like nix-bitcoin. When I saw Jonas Nick working on it, I immediately saw the power in this platform. We’ll get into that later with NixOS and that’s kind of where I started to program with him. It’s been a really interesting trip from there.

# What is nix-bitcoin?

SL: Great. So let’s start with what is nix-bitcoin?

NBD: What is nix-bitcoin? It uses NixOS which is this novel approach to a Linux distribution to ship a deterministic and reproducible Bitcoin node to users. NixOS is a purely functional operating system. What that means is that it builds the entire operating system from the source code of every application of the Linux kernel and turns that into a gigantic formula, which will result in the same system every single time it’s deployed.

SL: One of the interesting things when I was looking into NixOS is one of the ways Nix distinguishes itself is around its package management, how a new configuration cannot overwrite a previous one. Can you expand a little bit on that? Why is that important? Why does that matter?

NBD: Starting from being purely functional, what that means is instead of doing package management in the way that traditional Linux operating systems do it, where they download binaries, it takes this approach where it links different kinds of program source code together and then builds those on top of each other. How that pertains to what you said about versions is that you can always roll back to that previous version where the formula resulted in that source code building on top of each other. You can always go back to that and you can always start from that again. That’s where the atomic nature of NixOS comes from and we use that. That’s one of the greatest features that makes nix-bitcoin so special is that if you had a sane configuration at some point that works, you can always go back to that. You can’t really mess up your system. You can always roll back to the last previous functional state.

SL: I suppose this helps us in the way that we have more surety that we’re running the right code? That’s tying back to the reproducible aspect you were touching on earlier?

NBD: Exactly, that’s one aspect and security is at the heart of nix-bitcoin but security doesn’t really help you when your node is broken or it’s not working. So from the very start that’s the number one priority and NixOS is strong in both aspects. That allows us to make nix-bitcoin strong in both aspects.

SL: Then I presume the idea is that you would install NixOS and then you would install nix-bitcoin. Is it a scripted set of packages that all install together? Can you tell us how it works?

NBD: That’s how we’re different from the other node projects in that it’s not a bunch of scripts on top of each other. The way it works is you don’t need NixOS installed on your local system, on your workstation where you’re deploying from. You only need NixOS installed on the hardware or cloud, wherever you want to deploy to. So that machine runs NixOS and from your Linux computer, even Mac works, you can just download the GitHub repo, execute Nix shell that puts you inside of a command line environment with everything you need. Then all you need to really do is do some settings and configuration.nix and then deploy. Every time you deploy with that configuration and that state of the repository you’ll get the exact same node.

SL: Is it kind of like a VM in some ways. You’re kind of running this little VM on your machine and that is its own little contained…

NBD: That’s possible. That’s not the way I use it but it is possible to deploy to a VM on your own machine. Where I think it really makes sense to deploy it to is a standalone device in the cloud or physically that is always running. That’s how I use it. But it’s possible if you want to play around with it to deploy it to a virtual machine. It is difficult to explain. I didn’t understand for so long, even while I was working on it, how the magic of it is that it’s this new approach, this functional programming approach to systems management, where it builds an entire system, basically mathematically to deploy to any machine that’s running NixOS.

SL: The idea is that people could take an old laptop and run nix-bitcoin on it. That’s their way of running the whole stack of Bitcoin software, not just Bitcoin Core but also Electrum Rust Server and so on. Or they could put it onto a dedicated PC box that they keep in their house or on a VPS, an external virtual private server?

NBD: That’s right now how we use it. I use it myself, Jonas Nick uses it, Jonas’ brother with Donner Lab, their entire backend is built with nix-bitcoin. I don’t know if you know about his project but they’re doing gaming on Lightning. It works in a range of setups and we’ve had a lot of drive-by contributors deploying to virtual machines, or even NixOS containers on their own machine just to play around with it. So this is why when Jonas saw NixOS he saw it was a perfect opportunity for a Bitcoin node because it gives you the structure that you can deploy onto a range of devices with.

# NixOS versus other operating systems

SL: What’s the benefit of nix-bitcoin, over using Qubes OS or using Debian or Ubuntu?

NBD: When you install a Debian system, you have so many packages and that’s one of the more minimal distributions. You have Python, you sometimes even have a print server, stuff that you’ll never need with a Bitcoin node. You deploy onto that machine that has so much attack surface that is completely unnecessary. What NixOS does is it just deploys a system that has a Bitcoin node and through that functional approach that NixOS has it will just deploy with the dependencies you absolutely need based on your exact setup. That’s benefit number one, that security. Benefit number two is that you can always deploy back to old states, new states disable features that go really deep into the system. For example, we’ve been working on this huge project for the last two months that builds this Linux kernel feature called network namespaces deep into nix-bitcoin. Every service that runs on your machine runs inside its own Linux network namespace. With another distribution it would be extremely difficult to switch between that kind of a setup and a setup without network namespaces. You’d have to have very complicated shell scripts, very complicated logic to roll back and forth. With NixOS it is just switching one option and that’s it. You can always go back and forth, experiment and always return to a working state.

SL: In order to install nix-bitcoin, does the user have to be using some flavor of Linux or can they use it on Mac or Windows? How would that work?

NBD: I think Mac is possible, Mac works. Windows I’ve not tried it. We have had no interest in doing that. But I think that where this project is going is definitely making it accessible to everybody on a wide range of platforms and putting all that logic, all the NixOS stuff inside the box itself. Then you’ll never have to worry about having another laptop where Nix is properly installed, running and that you’ve properly secured. It would also build on the machine. So you’d never have an issue with compiling Linux software on Windows for example.

# Target Audience

SL: Let’s talk about the target market or the target audience. Who is nix-bitcoin for?

NBD: Right now it’s for Nix Bitcoin developers who are using it to deploy their own nodes and for the startup that’s using it. It is really in the beginning steps. We’ve done so much at the foundation level. We’ve done so much work really going in depth on all these Linux options. You can do this with systemd, you can do this security feature, you can use a hardened kernel. All this stuff that nobody else worries about. We’ve spent all the time worrying about that. That’s why it’s really useful for us at the moment. I think that as we build out the foundation, which is very strong, we can focus on making it available and you’ll see that in the next year it being able to be used by people familiar with the Linux command line. I hope if we get more attention then we can also have the resources to make this graphical so that everybody can use it. I hope that you also will be able to use it and I’m actually very confident that we’ll get there.

SL: To characterize this we would say this is very early stage and you need to be highly technically proficient before it gets down to the tech savvy Bitcoiner level. The next level beyond that, the average tech savvy person who is maybe not that into Bitcoin but they can figure it out. We’re nowhere near that level yet.

NBD: The level we’re on is what’s really important. What’s been important to me is that the software works, the software is secure to the greatest extent that we’ve been able to make it. I use it every day with [Spark](https://github.com/shesek/spark-wallet) wallet which is a front end for….

SL: c-lightning.

NBD: c-lightning. I make all my Lightning payments like that. It is a living piece of software but that magic, that beauty will take its time to spread because there is a hurdle. When people hear NixOS they think “I’ve never used that. It’s really complicated.” At this moment you really just need to drop into a Nix shell with one command and then edit your configuration file, which is a text file, uncomment a few things that you want, what kind of services you want and then just deploy. That’s it. I think it’s at a good point. It’s not super finicky, it’s functional and now we’re taking it one step at a time to make it available.

# nix-bitcoin versus other nodes

SL: Where is nix-bitcoin situated? Could you help us understand the difference between nix-bitcoin and some of the popular well-known plug and play Bitcoin nodes such as myNode, nodl, RaspiBlitz, RoninDojo? How would you distinguish nix-bitcoin from those? Is it mainly the security, reproducibility aspects of it? Or is there anything else?

NBD: I think security and reproducibility are two aspects that we can’t talk enough about because that’s really what you want if you want to enter your node every day and see that your money is still there. You want to never have a broken node with your funds gone. Reproducibility also means that we can implement all these really cool features that users need and especially startups, merchants need. At this point, what makes us different is really the security aspect and the fact that we’re building on NixOS which allows us to do many more things in the future. I’ve taken a look at a bunch of these other node projects like myNode. I’ve seen a lot of really quick programming like setting every service to run under the same user. I think it is justifiably focused on quickly making it usable for the consumer market. But that’s not what we’re about. We’re not about cutting corners and running every service under the same user with no hardening options, without our hardened kernel. That’s just non-optional because again I came at this from the privacy angle, from the security angle. For a Bitcoiner, for enterprises, that’s something that is a nonstarter to not have that. RoninDojo, I listened to your [episode](https://stephanlivera.com/episode/160/) with the Samourai cofounder and it seems to me that it’s only focused on being a backend for your Samourai wallet. Whereas we can be a backend for Electrum, for c-lightning, for lnd, for JoinMarket, for Samourai, for Wasabi. That’s where we’re going as it says in the [Twitter bio](https://twitter.com/nixbitcoinorg), being a purely functional Bitcoin ecosystem which uses this foundation to offer any kind of functionality that needs a backend that you want to preserve your privacy and security with.

SL: I guess it depends on what kind of user you are. For instance, you might be a user who is using a plug and play node mainly for the Electrum Rust Server aspect. It is not necessarily holding your keys, it’s just doing the Electrum Server aspect. You might hold the keys on a hardware wallet or you might have some multisignature, a different model to think about your security. There’s still risks with that anyway.

NBD: The Electrum Server knows a bunch of your addresses for example. That’s something privacy related. Also the Electrum Server, you want it to be running at all times. Even a simple setup like that benefits from what we’ve built into nix-bitcoin.

SL: If you are running Lightning or if you are using JoinMarket CoinJoins or even Samourai Whirlpool, CLI CoinJoining, the keys are hot. You have to think about security for that too.

NBD: JoinMarket is a great piece of software. It is the best example for something that you want to be on a secure hot machine. We have a [PR](https://github.com/fort-nix/nix-bitcoin/pull/164) up right now that’s we’re reviewing at the moment. I’ve been running it on my node for the last couple of weeks without any issues. Every time I open up the node I’m really satisfied with the way that nix-bitcoin secures my funds. If you go into the JoinMarket order books, some people have a thousand Bitcoins on there, that’s really a huge risk they’re taking security wise. I think there’s definitely a place for a security and minimalist node like ours.

# Security of nix-bitcoin

SL: On the security hardening that’s available with nix-bitcoin. I’ve noticed on the Twitter feed you were chatting about access through a SSH key.

NBD: That’s a bit of a joke at the moment because the management interface right now is the command line. SSH is the way into that command line on a remote machine. SSH really is a great piece of software that offers a lot of security. So it’s kind of a meme that my SSH keys are on a Trezor hardware wallet. That’s really a strong level of security to enter your node remotely with. I think that as the project continues we’ll have some kind of management interface that’s not the command line exactly for the reason that we want to deliver this kind of security. Every single option and every single setting that’s possible with nix-Bitcoin, we want that power available to a wide range of people. That security feature is great for developers like myself but I think we can deliver the same security even in a web interface with something like U2F which also works with the Trezor hardware wallet. Regarding the general security principles of nix-bitcoin, I think it really starts with minimalism that you have a node that only has the software you really need. That’s not possible with a general Linux distribution. At least not in a way where you’re not going to break it at some point when you start de-installing a bunch of packages. That’s what I used to do with Debian, try to install everything that I could. At some point that would result in a completely broken system. So I’ve been around Debian, I’ve been around normal Linux distributions, and there’s nothing that comes close to NixOS on the minimalism aspect. It really has a kind of formula where it goes through and calculates what you need and builds only that. Nothing will ever come close to NixOS int hat aspect. When you don’t have something, if something isn’t there, then you can’t attack that. That’s number one, is the minimalism.

Number two, is the reproducibility of the code. Not only all the higher level stuff like Bitcoin, c-lightning, lnd, we have these scripts where we verify the hash with the developers’ GPG key. We’re really focused on not getting bad Bitcoin software into our project but then even the entire stack, the Linux kernel, everything under that is also reproducible with NixOS. You know you have the exact same system that everybody else has. Reproducibility has been a topic that people have been talking about recently because it’s so important for Bitcoin that completely relies on the security of the individual machines where Bitcoin is installed.

Number three, it’s close between defense in depth and the compartmentalization. I’ll start with the compartmentalization that we built into nix-bitcoin. Every service that we have runs in its own little box. That’s what we do with systemd. We put every service in its own little box under its own user. It can only see its own directory and now with network namespaces it can’t even scope out your entire network. It can only scope out its own network and its little Linux namespace and the ones that we’ve allowed it to see. Outside processes outside of that network namespace also can’t look inside. That’s where we spend a lot of time, taking these services apart, putting them in different boxes and then saying “Where do they need to connect? What do they actually need to see?” Only that is allowed. That offers a great deal of security because now the programs like Spark wallet that connect to your c-lightning, they’ll never see JoinMarket, they’ll never see Electrum, they’ll never see bitcoind. Every time I open my box I’m really happy about. Finally defense in depth, which means putting up multiple walls. We have users, we isolate by users. We isolate with systemd, we isolate on the network level. We try to have multiple lines of defense. Right now we’re reviewing something that Jonas and I think could be security relevant. We realized that because of the compartmentalization we’ve built in, it’s actually not that big of a security issue because we’ve spent all this time putting up multiple defenses. It’s being caught we think by one line of our defense. So we’ll be putting out a fix for that in the next few days and probably talking to other projects about this.

# Qubes OS

SL: It kind of reminds me of when people talk about Qubes OS. Each application is like its own little VM and that way it’s firewalled off from the rest of the system.

NBD: I think Qubes is really interesting to start off on because that’s a perfect explanation of where NixOS is great. Qubes, I use personally on my laptop, I love it. It offers so much. I recommend every developer who is working on security critical stuff to install it because you don’t want to have something malicious on your system which is able to compromise your signing keys or put in some bad code into your repositories. But it could never be used for a Bitcoin node because if you’ve ever set it up, you need to spend a lot of time setting up the individual VM,  making sure that you allow all these firewall rules. You have to do that all manually and doing that every time is unfeasible. What we’ve done with nix-bitcoin is written these text files, these code files, where you just deploy from those and you’ll get the same system with all those settings pre-installed every time you deploy it. Even on multiple machines that you’ve deployed on you’ll get the exact same state. So Qubes is a perfect example of how security can get in the way of functionality. We can have both with nix-bitcoin.

# Communicating with nix-bitcoin

SL: You’ve got Tor, clearnet, and WireGuard. Can you outline the ways that nix-bitcoin talks to the outside world?

NBD: That’s been a huge kind of construction site at the moment. It’s really something that we’ve been thinking about deeply. How do we want to expose these individual services to the bad outside internet world? Right now we’re Tor by default. It’s really the only perfectly supported way, Tor at the moment. It’s what I use and before we come up with a really good solution that is where we want to steer users towards. I know that in an enterprise setting like with Donner Lab, it’s not that easy to use Tor because of the latency. They’ve built their own WireGuard systems stuff with nix-bitcoin. WireGuard is this new VPN client server, this tunnel that’s built right into the Linux kernel. It is a completely different level of simplicity compared to OpenVPN which allows you to have these tunnels across the internet that are in effect authenticated with a public, private keypair. You can make this tunnel from any box to any other box and pass network traffic. That’s something really interesting for nix-bitcoin. Clearnet is, as we all know, the base layer and it’s really usable and we want to make that accessible. The plan at the moment is to take the network namespaces that we’ve built and on top of that for every network namespace, give these three, four options for how you want people to be able to connect into. We want them by default be accessible through Tor v3 services and we want them to be easily accessible through a WireGuard tunnel where it just shows you the QR code. You can enter that on your phone or whatever device you’re connecting from. We want to make it accessible through clearnet with an automatic transport layer security like with that green lock in your browser that has secured the entire internet so beautifully in the last few years.

SL: There’s probably two main areas that a Bitcoin person is thinking about. One might be they are out and about and they’re on their mobile phone. Let’s say they’re running Spark wallet or Zeus wallet. They want to connect back to their own c-lightning. Right now a lot of people would just do that through Tor because it might be simpler and they don’t want to expose their home IP.

NBD: You don’t want to worry about all that NAT stuff. Tor just completely gets rid of all that NAT translation networking stuff. That is really hard to understand to be honest. Tor has a wide range of benefits in the consumer space.

SL: The downside is that it can be a bit slower and sometimes it is not as reliable. If you’re out and about and you want to check your Lightning channels it takes a bit of time to load up. Sometimes it is a little buggy because things are early. It is not as smooth a customer experience. What some other people are doing is a VPN style set up and I suppose this is where the WireGuard set up might be a little bit more amenable to that. I’ve also noticed some of the Nodl users like to use ZeroTier, which is more like a VPN style set up. Is WireGuard going to be easier to manage for the typical Bitcoin HODLer who wants to manage his Lightning channels?

NBD: WireGuard and ZeroTier are both VPN solutions. WireGuard has gotten a lot of positive attention recently and has been put right in the Linux kernel which means that it’s really well vetted and a great piece of software. ZeroTier and WireGuard have the same functionality but I think that WireGuard is much better in terms of the pure technology. In terms of the HODLer he would just see the QR code in his interface, install the WireGuard app and just scan that. That would make it so that he can connect to his own address at home with almost no latency without worrying about networking stuff and actually providing a reasonable degree of privacy as well in the process. The great benefit VPNs have is that they have such wide support on all different kinds of devices. Android, iOS, everything has WireGuard in their app store which you can’t say about Tor. Apple puts up a lot of barriers to to cross app communication. You don’t have a Tor daemon in the Apple App Store. This means that every app needs to package Tor itself and a lot of apps haven’t done that. So VPNs are something we need to have and we will have quite soon. We’ve chosen WireGuard. ZeroTier I’m not so hot about.

SL: If I recall correctly, Zap the iPhone version has Tor built into it.

NBD: We were actually involved in that discussion from the very beginning. When we tried to implement lnd on our node, that’s something we thought about it in the very beginning. It turns out that now beautifully Tor does work and it works with nix-bitcoin.

SL: What about in the case where someone is a merchant and they want to expose their BTCPay Server and they don’t want to necessarily open up security risk there? How does a nix-bitcoin user handle that?

NBD: For the user it’s really great to be running with Tor or WireGuard. He or she limits the exposure of their node to a bunch of these privacy risks and makes it easier to deploy across NAT. They get access to this really refined project where you have continuous integration, a bunch of automated tests that make sure it’s working at every point with every configuration and when something doesn’t work they file a bug report and it gets fixed. The merchant that uses the same platform benefits from that too because now they’re using something that’s been tested in such a wide range of setups for a bunch of different users that have all tried a bunch of different stuff. It has been fixed, refined and they benefit from this. The user benefits also from the enterprise that has resources to make everything better. I think it’s really powerful to put these two projects together, merchant and consumer like we’re doing. When it comes to a merchant, the way they would be able to use nix-bitcoin is to put it on a secure server in a secure data center somewhere and use a WireGuard tunnel to expose just their BTCPay Server to their main e-commerce shop and voila. Now they have a secure backend for all their Bitcoin circular economy transactions.

SL: They have not exposed their nix-bitcoin directly, it’s going via their public website?

NBD: Yeah it is going via their public website. I don’t think it’s a good idea to put a big website on a web server that has so many different people coming in on the same server as a Bitcoin node with potentially hot funds when it comes to Lightning. Either the merchant would have a separate BTCPay Server instance which uses WireGuard to communicate with the individual services like bitcoind and the Lightning Network daemon On the network level, just a WireGuard tunnel, taking that connection on their local machine to the connection on their secure server. Or they also run a BTCPay Server inside nix-bitcoin and just expose that port 443 or 80, the HTTP port, to the outside world with the WireGuard tunnel to a WireGuard server that’s publicly reachable. They can forward traffic to that from their website.

# Ease of use

SL: Speaking about nix-bitcoin more broadly and generally around the question of difficulty of use. So how do you see that improving over time?

NBD: That’s the central piece here for getting it into the hands of users. I think it’s going to improve but we want to improve it without compromising these fundamentals we’ve built in. We want users to build their own software from source code. We want it to stay reproducible. We want it to remain so that compromising a password, which is commonplace at this point, is not going to lose you your funds. All this stuff we want to maintain whilst making nix-bitcoin more usable. That’s a real challenge but I think that we’ll find an elegant way to do that. One facet of that is moving everything to the node itself. It builds the software and deploys to itself. That’s something we’re working on. It’s actually not that difficult to do with NixOS. The second aspect would be to expose some kind of management interface potentially through a standalone app that authenticates itself with a locally stored key or a web interface. We would definitely use something like U2F which is in my opinion the best two factor solution because it uses this hardware token that you physically have to depress. That hardware token also verifies that it’s communicating with the proper website so you can’t really be phished anymore. That would be one option. Or we make the web interface behind the WireGuard tunnel need to authenticate to the WireGuard tunnel with a key first before you’re allowed to communicate even with the web interface. So those are the avenues with which we can work. I think that once we start moving out of the UNIX familiar command line stage we’ll pick a final path. But it’s much more difficult to get the fundamentals right, to go into depth on all these manuals, the c-lightning manual, the lnd manual, the Bitcoin manual, find all the different options that work together, how they work together and packaging that all for the user to be able to use easily. That’s what we’re focusing on at the moment. The graphical stuff is one more step from there but getting the foundation right is what allows you to make it easy to use for everybody. I’m really excited by getting software into it, like CoinJoin software, Wasabi, Samourai, so people can use this wallet while they’re walking around. They can connect to their own little nix-bitcoin node that’s hosted on their own server at home and just enjoy the kind of privacy and security that they are entitled to. This is how the world was meant to be. Private information is supposed to be private and secure funds are supposed to be secure against anyone. That’s the kind of world we’re moving towards by making everybody have an easy way to deploy a node in their home.

SL: There are lots of different node options and people have varying levels of technical ability to read code and verify for themselves. Is there anything that you guys could do or the project could do to mitigate users having to trust the developers? Hypothetically, if there were some malicious code and the user just clicks Update without knowing… This is a risk across many things in the Bitcoin world. Do you have any thoughts on mitigating that risk?

NBD: First of all, the risk is less with nix-bitcoin. Because of NixOS every nix-bitcoin node out there is running the same software and that’s verifiable because of the reproducibility. That’s a really strong defense against us inserting malicious code or stuff upstream getting compromised. Once we’ve pinned the hash, once we’ve verified that the software is good ourselves, within the hash it’s going to be the same software that everybody’s using. That’s number one, how we’re defending against this right now. When it comes to trusting us, we have a completely open development process. Unlike some other node projects which are closed source at the moment and want to publish their source code once it’s ready, namely nodl. That’s not the approach we’re taking. If it’s not good enough to be out in the open it’s definitely not good enough for people to risk their privacy and their security with, things that are so precious. I don’t think you should ever risk those with proprietary software. Our development process is completely open, everything is happening on GitHub. People can see our discussions, our different approaches, everything is on GitHub. The stuff that isn’t on GitHub is in our public IRC channel. Going further than that something I’m really excited about is we want to release software with some kind of multisig setup where Jonas, I and some other developers have to sign every single release. The user verifies that client side. Or and I have not really communicated this with the other developers yet, I’m looking into Frank Brown’s code chain approach which makes it impossible to target a backdoor to one person even if you have the signing keys. You need to backdoor everybody with the same source code if you’re compromised. That’s a much better security assumption because people are going to realize when it’s deployed to everybody. I think you’re based in Australia? They have this bill there which can force developers to put in targeted backdoors. I think we’re going to see that rolled out across the Western world. I’m not looking forward to it but I think it’s slowly creeping in. That’s where something like code chain comes in where we can’t target a backdoor to one user. We have to target a backdoor to every user. That’s going to get noticed very quickly because we have technical users who are going to notice that.

# Technical user interest

SL: There is a natural kind of dichotomy where sometimes certain projects appeal more to a very technical user but then once a lot of newbie users turn up the more technical ones lose interest. Is that something you might foresee here? Or is it more you see this as going to be part of the underlying infrastructure and therefore there are going to be a lot of people who maintain interest?

NBD: I don’t think that’s ever going to happen because the technical users benefit from normal users in the same exact way that normal users benefit from technical users. Normal users are using Android 5.0 and they’re doing weird stuff, actually using this in the world. They’re going to find a bunch of bugs that technical users are never going to find. I’m really looking forward to the influx of newbies because they’re going to use this project in a bunch of different ways and are going to make it really start to live. That’s something I wasn’t impressed with the Samourai co-founder [interview](https://stephanlivera.com/episode/160/), where he kept on focusing on the user. That’s who we’re building software for, a user. You can build the most beautiful piece of software like nix-bitcoin but if nobody is using it it’s really not alive. I’m looking forward to users of all different backgrounds coming towards nix-bitcoin. I think that everybody’s going to benefit from it and we’re going to have a really well tested, refined node set up. Whether it’s an enterprise, a startup like Donner Lab or normal users or developers themselves, we’re all going to benefit from this one tested and refined project.

SL: A small correction, you’re referring to Zelko, he’s not actually a Samourai co-founder. He’s actually more like a community member. That’s a small thing. But to the broader point about nix-bitcoin having a range of users I certainly take that point. I’m sure you’ve seen the famous xkcd comic about how there’s 14 standards and people say “What we need is one standard to unify them all.” Then the next panel is “Now there’s 15 standards.”

NBD: That’s always the risk. But with NixOS we’re building on an infrastructure that’s being used already so we’re not really going out there and reinventing the wheel. We’re using the wheel how it’s meant to be used. I think this standard is going to be the one because it’s usable for all use cases. So underlying infrastructure has the potential but we’re also happy about every user that finds benefits be it an enterprise or a developer or whoever. We don’t need to take over everything to make a difference and to be really happy about building good software.

# nix-bitcoin community

SL: It just needs to hit a certain level of users so that it kind of sustains. How many people are running nodes? If it’s one of the ones that people think of commonly, then that’s a good sign that there’s a bunch of users who are on this particular software stack. Let’s talk about the development and the community aspects of it. Obviously it’s quite small right now. What are the main ways of collaboration? You’ve got a [GitHub](https://github.com/fort-nix/nix-bitcoin), you mentioned an IRC. Are those the main ways you’d like people who want to contribute to come and chat with you and to participate?

NBD: Yeah. Github is really great because it’s become this focal point for development. I personally like IRC but I think that to be realistic not a lot of regular people are on IRC. I’m open to expanding our communication infrastructure and I’m also planning to release a bunch of YouTube videos and easy tutorials. It’s communication, it’s one way but it’s going to make it a lot easier for people to start it up. They’re going to see that it’s actually not as difficult as they probably expect. It’s just basically three or four commands and you’re there. GitHub is probably the best way of communication around software development when it comes to support. We have limited resources because we don’t really have a business model yet but when there is a business model or if there is a business model then we’ll find a way for users to get in touch with us easily.

SL: If somebody wants to do nix-bitcoin on a Raspberry Pi or on one of those single board computer style things that’s something that the project works with or supports?

NBD: Yeah. That’s how we use it right now. It is on single board computers, not Raspberry Pi right now but I’m pretty sure it works. We should try that too. The APU PC engines, single board machines, they’re really fun because they are more powerful, they can take an SSD without using a USB cable. When people have asked what kind of hardware to use I’ve always recommended that but it works on a Raspberry Pi and it works in the cloud also which is how Donner Lab is using it.

# Open source hardware

SL: The last topic is around hardware and where we’re going with that. There is a little more chatter about the idea of moving towards open hardware. Some of the things you might hear people talk about are RISC-V, reduced instruction set computer, Raptor computing and things like that. The idea is trying to move towards more open hardware for security reasons. So do you have any thoughts on what sort of hardware should people be looking to run nix-bitcoin on?

NBD: The APU is already pretty good because it has a core boot open source firmware. You already have a good level of hardware security with that. Different kinds of architectures, like OpenPower POWER9 which Talos uses and Raptor uses RISC-V. They’re really in the beginning right now so I don’t know if a normal user is going to be really happy with that yet. You’re going to run into a lot of issues with compiling software, stuff that you don’t want to deal with and enterprise also. It’s probably best for developers at the moment but that’s something that’s getting better every day. Right now I’d recommend to get a APU or some kind of other core booted device, and then follow the install manual. We have some tips on how to further harden your hardware on a firmware level, deactivating some features that have recently been used to do exploits. But with the hardening we built in you always have to think about how is somebody going to attack you. They don’t have a lot of attack surface with us. There’s no browser running that you’re browsing different websites with, there’s really no way to deliver an exploit properly. Even where there would be you have different kind of walls and security around that which make it even more difficult. So chaining a bunch of exploits. Using a hardware vulnerability at the moment is outside of our threat model because the people who have that threat model, you’ve really done a lot of work to get yourself there.

# Business model for nix-bitcoin

NBD: Another topic before we close is business model. That’s something that every good project that wants to survive at some point it needs to have. I think we’re still on that front looking for something that is as elegant as the CoinJoin model which is one of the best business models probably out there. Making money on a service on a feed that also serves a security function as a denial of service protection inside the service. It’s really extremely elegant and that would be something interesting for nix-bitcoin. If we can offer some kind of service like managing a Lightning node, something complicated and you often have to make decisions about. Who are you going to open a channel with? How are you going to balance that? Are you going to establish yourself as a really good routing node? Maybe we could have some kind of API with logic running on a backend where people who call it are submitting some data and asking for the best possible decision. We charge them on on the Lightning Network on every request. That’s something that came to mind recently but that would be a business model that could sustain nix-bitcoin. Or just selling pre-installed hardware. But that comes with a bunch of security risks which we we would want to mitigate before we start shipping hardware with pre-installed software on it.

SL: You could either sell the pre-installed box or you might try to do something like a Red Hat model where you are the consultant and the software is free but if they want additional technical support, that’s where they would pay for it.

NBD: Or something like Nextcloud which is a great example. It’s open to every user but as soon as an enterprise wants it and they have a lot of specific needs they need to charge. They need to pay for consulting and for subscription and stuff like that. That’s a way to monetize software but I think right now it’s really going good as an open source free software project. We’ve never compromised security or our values in order to make this a super profitable project because it can succeed in its limited way even as a free software project.

SL: Excellent I think that’s all the questions I had. So nixbitcoindev do you want to let the listeners know where they can find you?

NBD: nix-bitcoin was a name that I adapted specifically for this project so there might be a bunch of confused people around that. That’s why recently I’ve changed the name to nixbitcoindev. Reaching me is not that important. The project has its own [Twitter](https://twitter.com/nixbitcoinorg) and [GitHub](https://github.com/fort-nix/nix-bitcoin). Fort Nix is the organization. The nix-bitcoin repo is always a good place to submit stuff. IRC is at the moment our communication and Twitter is also a communication, both sided, through messages or posts. We’d be happy to have you at this point. Maybe it’s a bit too early if you’re not super interested in figuring out a bunch of low level stuff but you’ll see a bunch of YouTube videos and guides coming out that are going to make it really accessible. And communication will scale with them.

SL: Excellent. Thanks very much for joining me.

NBD: Thank you for having me. It was a pleasure and I look forward to hearing the podcast and other podcasts.