Citadel Dispatch

Share on social media:

EPISODE: 42

BLOCK: 707898

PRICE: 1577 sats per dollar

TOPICS: security focused bitcoin nodes

 

@nixbitcoinorg: https://twitter.com/nixbitcoinorg

@n1ckler: https://twitter.com/n1ckler

@seardsalmon: https://twitter.com/seardsalmon

streamed live every tuesday:  

https://citadeldispatch.com

twitch: https://twitch.tv/citadeldispatch​

bitcointv: https://bitcointv.com/video-channels/citadeldispatch/videos

podcast: https://anchor.fm/citadeldispatch​  

telegram: https://t.me/citadeldispatch​ 

support the show: https://tippin.me/@odell

stream sats to the show: https://www.fountain.fm/

join the chat: http://citadel.chat/

[00:00:00] Unknown:

When you look at at when we're we've got a screen up, you probably can't see. We got Bitcoin. We have ether. We have Dogecoin at bond. There's another Shiba Inu there. The 2 of those are worth 80,000,000,000.   I I mean,   I I know that you you probably think that that Bitcoin is is here to stay. Do you think all of these,   different,   crypto assets   are real and here to stay, or or is there something to be concerned with? And and do we   need oversight so that that people aren't left holding the bag for some of these things, whether they do or not? I'm not not predicting one way or another.  

[00:00:35] Unknown:

I do think that Bitcoin is here to stay, and I think a lot of the others are not.   The fact that Bitcoin is fully decentralized   and that some of these others were issued by a person or an entity   that kept a large block of the coin for themselves   and then issued others to participate   means they look more like a security than a commodity.   Bitcoin is clearly a commodity.   It is digital gold.   So I do think that having a regulatory   framework,   within which this can   exist and innovate, meaning this entire space   of digital assets,   but, that protects consumers   at the same time is extremely valuable.  

And that's why we in the Financial Innovation Caucus,   are, even as we speak, putting together,   and reviewing the legislation we have crafted,   to,   address these and other issues.   Bitcoin is the standard.   Everything else,   is has to be monitored differently,   because they are created differently.  

[00:02:20] Unknown:

Happy Bitcoin Tuesday, freaks. It's your boy, Matt Odell, here for another Citadel dispatch.   I know it's been a while since our last proper Bitcoin Tuesday, but I have not forgotten about y'all.   We have a great conversation lined up for today, and, I have great conversations lined up for the next 4 weeks in a row.   Bitcoin Tuesdays are coming back   strong. Next week, we're gonna have Bitcoin q and a for a nice tight Bitcoin beginner focused conversation.   Then we're gonna have raw avocado and waxwing   on. Waxwing will be joining us for a second time.   Then we're gonna have Eric Sirian on,   with the Simple Bitcoin Wallet Maintainer and Fiat JAF,   discuss, Fedimint and,   Federated Lightning Wallets.  

Pretty excited about that with Tommy and Ecash.   This is Sidelle Dispatch, the interactive live show about Bitcoin distributed systems privacy and open source software.   Specifically, this is Citadel dispatch 40 2. We're gonna be focused on security focused Bitcoin nodes, specifically,   Nick's Bitcoin,   who's currently having some issues. So he is not with us right now, but he should be joining shortly, the lead maintainer of Nix Bitcoin.   Shout out to the ride or dive freaks who continue to support the show,   even though I've been traveling.  

You guys keep it   ad free and sponsor free,   so we can just focus on actionable Bitcoin discussion.   The easiest way to support the show is to go to new podcast apps.com,   pick a podcasting app, search Citadel dispatch,   press the subscribe button, load it up with sats, and stream sats directly to my node.   You can also,   donate via [email protected].   My paynim's Odell, very easy to remember,   or through tip and dot me, if you wanna just do a regular lightning payment.   As you know, I appreciate you guys. You guys you guys make it what it is. Awesome. Nix Bitcoin just joined us   just in time for me to finish up my intro.  

Today, we have,   Jonas joining us, Nickler on Twitter.   He works with Blockstream for research, and he's been a contributor to Nix Bitcoin.   We have Vivek here, good friend,   who helped set up this conversation. Always appreciate him. I just saw him in Austin.   He is business development at Blockstream,   and we have the lead maintainer of Nix Bitcoin himself,   that goes by Nix Bitcoin Dev. So I'm just gonna be calling him Nix for the remainder of the show. How's it going, guys?   Great. Great.  

[00:05:04] Unknown:

Great to be here.  

[00:05:06] Unknown:

Hopefully,  

[00:05:07] Unknown:

Yeah.  

[00:05:09] Unknown:

Nicks,   you wanna   you wanna say hi to the freaks? Let's see if your audio is horrible still.  

[00:05:16] Unknown:

So optimistic.   Hi, freaks. Hi, everybody.  

[00:05:20] Unknown:

You sound way better. Did you,  

[00:05:23] Unknown:

did you set up audio drivers on Nicks? Is that what was happening? No. No. It's the usual Linux thing with pulse audio and also interfering. It's super   complicated. I just   figured it out how out on GrapheneOS.  

[00:05:37] Unknown:

Awesome. Well, Phryx, he did it he did it for you guys, so everyone should appreciate that.   So, I mean, we're gonna focus here   to start with, we're gonna focus on NYX and NYX Bitcoin.   And then the conversation is we're gonna take it, you know, we're gonna go wider with it.   This will be a more technical conversation,   but that's how we like it here on dispatch. Just a reminder that,   this conversation builds on the conversation we had with Andrew Chow and Craig Raw on reproducible builds and building from software, which was still dispatch 37. So if you haven't listened to that, consider,   listening to that after this live show. Don't leave us.  

So I think a a good place to start here is is what is Nix OS, and, you know, why should we care as Bitcoiners that it exists?  

[00:06:26] Unknown:

Jonas, you wanna take this one?  

[00:06:28] Unknown:

I think it's a good place to start. But, before we do that, I would just like to make this correction   that I know it's super confusing, but Nix Bitcoin Dev is not the lead maintainer of Nix Bitcoin.  

[00:06:43] Unknown:

Oh,  

[00:06:44] Unknown:

damn. But that's me. And I'm not saying this Brutal.   Brutal. I'm just saying this so the responsibilities  

[00:06:51] Unknown:

are clear. If someone merges bullshit, then that's my fault and not Nix Bitcoin dev's fault. Wow. Well, I'm I'm Yeah. I'm sorry about that, and I appreciate the correction, but that is, pretty confusing.  

[00:07:02] Unknown:

Yeah. This would be  

[00:07:03] Unknown:

I took the Why did why did you choose the NIM?  

[00:07:06] Unknown:

Yeah. I choose the NIM because,   NYX Bitcoin was actually   how I started to really get into programming with Jonas back in the day, so I didn't have any better ideas. And   I just picked the purpose built nickname, I guess.   Also, back then, I was into samurai, and one of the devs there is samurai devs, so I just thought I'd go with  

[00:07:32] Unknown:

it. Yeah. Okay. So I I hope that's that's cleared up now. That was a good clarification. We appreciate that.   Perhaps it's   I guess,   it goes a bit too deep if we already start with NextOS.   Perhaps we should first talk about Nix Bitcoin because if you use Nix   Bitcoin   in   the way that is documented in the repository,   you don't have to deal that much with NextOS.   You earn all the benefits, but   you don't have to to learn everything about NixOS. So Nix Bitcoin is a node project, you could call it. Perhaps,   people know what that is from,   raspiblitzes   and Umbrell   and,   Noble and whatever else is there. And,   I started this project,   in November   2018,   because I guess as many people,   I just set up too many Bitcoin notes in my life   already at that point.  

And now I would at that time, I wanted to set up a new one just for lightning.   And then I thought, man, there must be a more   systematic way to do this. Like, how can we do this? We could write shell scripts or whatever,   but   I don't like this. I want I wanted to have a systematic way   that's,   also easily extensible   in the future. And then I remembered my colleague,   Russell O'Connor,   who's working on simplicity at Blockstream.   He gave a presentation at a a Blockstream off-site on NixOS.   And, I thought, well, maybe NixOS   is is a thing that we could build this on.  

And I started doing that mostly just published my own node configuration,   basically.   And, then Nick's Bitcoin dev started contributing,   started running it on his note, and then   more people started contributing. So we have, like, 3 regular contributors now, I would say, with with Eric Arstead and a couple of drive by contributors   and a few users that even use that for for their infrastructure.   Okay. So now to get to the question, what is NixOS?   When I started this project, I said I I just shared my own configuration.   What that means is that I basically I had this Nixo system,   an operating system, and I was able to share this whole configuration   in a GitHub repository   so people could clone this repository   and   rebuild the exact same operating system   that I was running.  

And   this is the power of Nixos, basically,   or or perhaps to to to go into this a bit more   systematically,   NixOS is a declarative   operating system.   K?   Regularly I guess, regular users when they work with their operating system,   either they have a MacBook or whatever.   And if they want to change some setting,   they go into their system,   settings and change their setting and click apply,   and then the setting is changed.   Similarly, if you work on a server, you SSH into the server, you change your   HTTPD   configuration,   and, restart the service,   and then,   your   change   takes effect.  

NextOS is different. In NextOS,   you have a configuration file that specifies the whole system.   It   tells   Nix   OS how the system is supposed to look like in the end, and Nix OS is responsible for building the system. So you write the configuration file,   and then you say   okay. The the the command, sounds a bit weird, but it's called NixOS rebuild switch.   And then your system, your operating system, will be built based on this configuration file.   Yeah.   So this is, like, the basic   next stuff.   It has a few other advantages.   But, what next Bitcoin now adds is   you have simple options   for,   Bitcoin related things. So in your configuration, you can say,   bitcoin d dot enable equals true   or bitcoin d dot port equals 8336   or c lightning enable equals true and,   a lot of other modules that that we maintain.  

And,   you don't have to SSH into your system or whatever, download certain things. You only have to add this option.   And,   that way, you can you can build that system.  

[00:12:45] Unknown:

So, Jonas, are you saying this is like a bitcoin dot conf file, but for, like,   multiple nodes and services   all in   one,   I guess,   software?  

[00:12:57] Unknown:

To a certain extent,   yes, because it's also a text file.   But   if you've looked at a Bitcoin configuration file,   it has a very simple structure. Right? It just says,   prune equals 550   or listen equals 1.   But the configuration files   in NextOS   are written in the Nix language.   So that means that you write your configuration   in a programming language,   which means that you have   a lot of advantages in writing your configuration because you can write your configuration in a very powerful way. You can for example, you can define variables.   Yeah. You can reuse code.  

You can   you can do all these things. You have types, so you don't mess up ports with strings, etcetera.   So that is really one of the main advantages,   for me why why I think next Nixo is really is the systematic way to build infrastructure.  

[00:14:05] Unknown:

But so you don't ask what you just said. I don't want it to scare off new users   in the, configuration dot mix right now. It's all nicely documented. So most of what a new user would be doing   is,   commenting out single lines, just removing the hashtag sign from that line. So it's definitely on par with usability of a bitcoin.com   file, if not even easier, I'd say.  

[00:14:31] Unknown:

But but for the freaks, understanding, Jonas, what is, I guess, the next   functional programming language? Like, how does it differ from,   object oriented programming? Like, what is, functional?  

[00:14:48] Unknown:

Functional means that you don't have mutation.   So you generally don't have   variables that could change,   their values.   You basically just have constants. You have an input, and then you have functions operating on that input to produce an output.   So in the case of,   NextOS,   your input is a configuration file. Your output is a running system.  

[00:15:19] Unknown:

Got it. And then, I guess,   because it's functional,   it's re reproducible as well, and then every dependency also has a shawesome,   and you can   all rebuild the exact same packages. Is this correct?  

[00:15:34] Unknown:

I wouldn't say that this is a consequence of being functional, but that's certainly also, one of the advantages.   I mean, the functional aspect   mainly helps you deal with complexity   because you're not going to write spaghetti code because you're not able to, basically. You can only write functions,   which should be relatively,   simple.   But as you said, what Nix also provides you,   k, perhaps it's a good time now to talk about,  

[00:16:07] Unknown:

we're already getting really deep into Yeah. We got we got deep right now.  

[00:16:11] Unknown:

Before we go deeper that I'd say that next Bitcoin is the most anti spaghetti code project   of all time because we have Eric Arstead   in our team who goes through every pull request meticulously,   fixes every point,   refactors   the whole code base at least monthly.   So  

[00:16:34] Unknown:

it's really Shout out to Eric. He's a Yeah. Nick's, black belt.  

[00:16:39] Unknown:

So it's   first of all,   to the freaks, as always, I mean, feel free to put questions in the live chat. We will get to your questions.   I will also probably be asking questions that you're thinking of without necessarily   verbalizing them because a lot of this is over my head, and I'm learning as well,   which are my favorite types of conversation.   To   to to start here, if if you're just an average freak and you're running let's say, you're running a Raspberry Pi blitz   on a Raspberry Pi,   and you want to you want to try nix Bitcoin out,   It doesn't run on a Raspberry Pi. Correct? You need you need different hardware, and, like, how how does that start pro like, how does that let walk us through setting up your your Nix Bitcoin node.  



[00:17:30] Unknown:

First of all, the Nix Bitcoin does run on Raspberry Pis. I think,   Jonas' brother has it running on Raspberry Pi. Yeah.   And, also,   it's very easy to start working with Nix Bitcoin because of,   the container and the M code that Eric in large part wrote, which allows you to basically start up   a a Nix Bitcoin node on your own laptop to start playing with it. And once you wanna go   build a 247 running node,   you just get   a off the shelf, stand alone,   either single board computer or a real, you know, beefy server, and   follow the install dotmd,   and you should be running a Bitcoin node without any major issues.  



[00:18:21] Unknown:

But perhaps more in detail, what,   the Nix Bitcoin tutorial would tell you to do essentially is   to install Nix OS on your target platform, which could be Raspberry Pi, Intel NUC,   or   some people run it on an APUC   4, I think it's called. And,   we have a list of of hardware in the in the Readme. So, So basically you install NextOS there,   and then you can, from your personal computer,   you can deploy then the next Bitcoin   system   on this blank Nix OS,   machine.  

[00:19:04] Unknown:

And it also works on, like, virtual boxes and, other things. Correct? So if they just wanna experiment with it, the freak scan.  

[00:19:11] Unknown:

Yep. And they don't have to really install VirtualBox for that. They could just go into the example folder and run   one of the examples, which would automatically   run-in a VM or in a container. The only requirement there is that you have,   the NIX package manager installed   on, on this machine where you're running this. And perhaps I should mention that   before you deploy Next Bitcoin,   you go into the example folder, and there you have a configuration dot nix. And that's the example configuration dot nix, which has documentation   and, like, has a lot of, options,   commented out.  

So you can just remove the   the pound symbol   and, activate things like   lightning c lightning or lnd,   or whatever.  

[00:20:05] Unknown:

Join market, pool,  

[00:20:07] Unknown:

everything. Right? Yep. So if you look at the if you want a real life Yep. If you want a real life example, which always helps me when I start learning something, you can go to our GitHub,   organization.   And the second repo there is nixbitcoin.org,   which actually gives you the full server configuration of our own,   internal project node,   and that will give you a really nice,   quick example of how a basic setup would look like.  

[00:20:40] Unknown:

Awesome.   Okay. So before we get deeper,   I I'm running raspi blitz. Right? A lot of the freaks are running raspi blitz.   The main advantages   of switching to Nix Bitcoin, or at least testing it out and considering a switch,   is that   it is more transparent   what you are running,   and   it is ideally a more secure setup all said and done. Would you agree with those two comments?  

[00:21:14] Unknown:

Matt, I can, expand on, like, I guess, my whole node journey because Yeah. Do that. Yeah. So In short, I would agree. In short, I would also.   Yeah. So, I mean, I started off just,   you know, in 2017,   just like a lot of the freaks, a complete pleb.   It it's only because of UASF, I finally ran a node, but it was pitiful because I didn't know how to verify   my own transactions because, you know, I was still in the trying to decentralize the network mentality or whatever.   For fast forward to 2018 where,   you know, I was fortunate enough to attend Ellen Hackday,   Rutsal,   Jonas's younger brother, Constantine,   Murch, Renee,   and,   Jeff, also, you know, FOMO.  

They were   very kind to, like, have patience and explain to me how to run a raspy blitz,   storing the seed, everything like that. And that's where I finally learned,   simultaneously, this is around the time that, Pierre Richard put out his node launcher.   So all this was fantastic.   It's really cool.   But,   going forward, I wanted to,   have a node just like Jonas mentioned that   I don't have to,   figure out,   like, necessarily   what broke if something did break in, my package manager.   This recently happened to me as something as simple as, like, with Homebrew   PIP and trying to get a Jupyter Notebook to work for a Jimmy Song's book on a MacBook.  

So,   that that mentality kinda stuck with me where I want something that I figure out once that's a config file that I could kinda keep handy somewhere,   and I could just, use that same config   to almost rebuild the exact node.   And, that's when, you know, Jonas helped me through this a bit more.   And, it was intriguing because,   there's also,   quote, unquote, atomic rollbacks in this,   where if something were to break, then I could just go back to the last build that worked.   So for these certain reasons,   I thought, you know, it was worth the steep learning curve to proceed down this path.  

[00:23:31] Unknown:

I actually   my   note journey was   pretty much the exact same, only that it was paired with my,   paranoia, which made me use Deviant from the get go.   But I always had a huge issue also with maintaining such a node because you constantly have to SSH in and and change things. And   yeah. So   at some point and I was always using Electrum,   with it, and at some point, the Electrum server project went all b cache,   and I decided to trash that node and start working with Jonas. And, my first thing was the Electrum Rust server.   And from there we just kept on improving it and,   from my side, I think I brought a lot of the security conscious   thinking into it, and we have some security features   right now and NEX Bitcoin will get into it probably in-depth later that I haven't seen anywhere else, and especially not with other Bitcoin nodes.  

So that's a major advantage.  

[00:24:37] Unknown:

Yeah. I also think,   everything is kind of moving in that trajectory. Right? Even with Bitcoin Core   and, having bootstrappable   builds as Carl Dong,   has brought up with Geeks, you know, everyone's trying to figure out a much more methodical approach to these sort of things.   But  

[00:25:00] Unknown:

So Awesome. I think that was I think that was very helpful to both me and the rest of the freaks.   I would say I'm on a similar journey, but I just haven't discovered NYX Bitcoin yet, so   my journey stops there.  

[00:25:14] Unknown:

If security is what you're looking for, which I'm pretty sure most people who run a node are, because,   first of all, they're they want freedom and also they want their funds to stay secure.   I think the learning curve is more than worth,   taking up because,   I can get into very in detail the advantages, but I've looked at some of the other code. And this is not to,   talk badly about the other node projects.   But I've I've looked at the code and none of the security features we we and the work we put in, I see in the other node. Plus it's more spaghetti code which always yields insecurity.   So what Jonas also said with shell scripting,   it and what you also said, Matt, about, you know,   transparency and system configuration,   I think that's already half of security there is knowing exactly what runs on your node and having just really what you absolutely need running there. No unnecessary   ports, no unnecessary   print servers whatsoever.  

And I think you can't get that with a shell script in the same way that you can with MixOS. I like to give the example that when I started working with Vivian, I tried to install de install every single package before I set up my Bitcoin node, which   every single time broke the entire system.   So   I I can say from experience that Nix OS   offers   security conscious users   something that no other node project does. Also privacy wise, we have everything,   locked behind Tor on multiple levels on the   individual application level, on the system d service level, and,   even on a network namespace level. We'll get into that later. Sure. But from a privacy perspective also, you don't want some mistake to leak your personal information out to the world and   this financial stuff is very sensitive,   personal information. So   I'm very I feel very safe with mixed Bitcoin because   everything has multiple layers of security,   which are all very transparently laid out and reviewed constantly.  



[00:27:24] Unknown:

So, I mean, from my point of view,   historically speaking,   Bitcoin node security   was mostly focused on the privacy level, like you said,   because when we use a traditional Bitcoin node,   with   on chain Bitcoin, your keys aren't held on the node.   So you you have privacy risk, but if someone compromises your node, it's, you know, not the end of the world in terms of actually losing funds. But now that lightning is in play and we have these hot wallets with the growing amount of money in them,   that are always connected to the Internet,   you know, security has become way more important,   from from my perspective and I assume from from most Bitcoiners' perspectives.  

And, also, on top of that, the fact that with Lightning, there's no really easy way to back up.   You have   this situation where reliability becomes really important,   where where you you need to be able to count on your node.   You wanna have as much uptime as possible, and you don't want anything to get corrupted or have any kind of issues in that regard. So I mean That's also a unique advantage of mixed Bitcoin  

[00:28:38] Unknown:

is that one system   goes all the way down from a Raspberry Pi to a ZFS   enabled,   redundant   power supply enterprise server.   And the same review work we put into the Raspberry Pi and the same knowledge we get back from users of the Raspberry Pi goes into the enterprise,   no, node and vice versa. And I think this having this approach,   maximizes the improvements you make on the node and that's what it's really about. It's learning from mistakes and reviewing and having transparent code that you can fix easily and constantly.  

[00:29:16] Unknown:

Yep. I think that's that's a very,   important point. I think   nix Bitcoin can only focus on security   because,   NixOS   is the methodical way to set up a system. Because the the goal   of next Bitcoin is to manage complexity,   essentially.   And if you add things up to a running system, it will get   exponentially   comp more complex   very quickly.   So how do you add security to such a system? You will have holes.   You   it's unavoidable.   So   what we really try to do is keep this   as simple as possible, and we do that,   which I tried to explain earlier   by   basically using the concepts   of abstraction   and reusability   of code because you treat your infrastructure   as code. You treat your server   as code.  

And,   because it is code, it can be reviewed   on GitHub, for example.   I think this is what because otherwise,   we wouldn't be able to set up a such a sophisticated,   system as Nix Bitcoin   with the three spare time contributors,   basically.  

[00:30:45] Unknown:

So,   Nick's Bitcoin dev kept saying you guys have additional security features in place that aren't in place in other node projects, and I said we could talk about it later. I feel like now is a great time to talk about it. What do you guys think? Okay.  

[00:30:59] Unknown:

I'm I'm so ready.  

[00:31:02] Unknown:

So I think that's great.   I think   the the thing that sold me even more on Nick's Bitcoin or Nick's OS was,   the whole pseudo vulnerability that happened and how they,   you know, they had duas. So they didn't necessarily   go through that issue. I'd love to   hear both of them elaborate on that.  

[00:31:23] Unknown:

So that's actually I would be flowing into it naturally.   First of all, Jonas,   the reason why it took him such a long time to set up Bitcoin nodes,   manually, I think, is because he always did it the right way, which means having one user per service,   etcetera, etcetera.   And,   other mix   other node projects don't have that. They run everything under one user, which makes it simple.   But we don't do that, and we have every single   service   running under a different user with fine grained permissions between services   when lightning loop needs to read certain things from LND,   the service gets that permission but nothing more. So that's the very first step is using Linux properly.  

Then we go on to,   system d which,   you know, people have different opinions about it but in our use case, it made   so many things easier that you have a long list of security features   and even an   tool, system d internal, which you can run over a service configuration.   And it will tell you exactly what kind of hardening options still can enable, which are which ones are already enabled. And we just basically went through that list and turned on everything   until something broke.   And right now, that's the status we're still holding at, which is   everything possible that system d offers in terms of hardening is enabled that goes from private route private temporary directories,   firewalling   on a service level,   on and on. Just,   privilege escalation   protections which wouldn't exist.  

Normally, UNAS, probably can think of a lot, it's up around 30 or 40   hardening settings. And then we go even further   to the actual packages that are being used.   Again, we have a extremely minimal foot footprint, whatever you enable in configuration.nix,   only that and its dependencies are ever deployed to the node.   And   every package we maintain ourselves   is GPG verified if possible,   and, we're slowly bringing that into upstream as well,   and,   which is supply basically, taking care of supply chain vulnerabilities,   but that's definitely the biggest construction site we still have.  

And,   what else am I forgetting, Jonas, security wise?  

[00:33:53] Unknown:

Jonas, can you go over, like, how the,   I guess, atomic rollbacks are possible with,   the way it's designed, essentially, with the next store versus the traditional, like,   file system,   hierarchical standard?  

[00:34:09] Unknown:

Okay. That's, I think, a a good question.   So what this rollback means is that,   let's say you have your configuration.   You make a change. You deploy it. You notice that your system doesn't work anymore.   What can you do? Well, one thing is to just boot up. And in the boot screen of NextOS, just say, I don't wanna run the current revision. I want to,   use an earlier deployment.   And that way, you can make a rollback.   How does that work?   That goes into into the reproducibility   aspect of, the Nix package manager and Nix OS,   the system.  

And when   when you read anything about reproducibility   in the NextOS   world, that's a different it's important to understand that that's a different definition of reproducibility   that we usually use in Bitcoin.   Reproducibility   in,   in,   in the NICS world means that   given   some package, you know exactly what its dependencies are. You know the hash of the sources, let's say, the source code the hash of the source code itself   and how,   these various dependencies   play together. That's all, like, everything is hashed, etcetera.   Like, you could imagine, like, a big Merkle tree or something of of dependencies.  

But, that doesn't necessarily mean that the output   is if if if I built the same package on 2 different system, that the output of this build, like a binary,   has exactly the same bytes. Right?   It has exactly the same dependency. It had its exactly the same source,   but there may be differences on this system. For example, the current time or whatever   that makes,   the binary binaries different.   There may be, like, a different byte at position x y z or or whatever.   So that's, I think, important to understand. However,   at least for the minimal   NixOS system,   the binaries   are actually reproducible in the sense that we mean in in the Bitcoin world. So that that's, I think, also an important aspect.  

So this reproducibility   allows you also to roll back because,   packages have dependencies,   but also your current system   consists of packages which have dependencies. So you can just,   store what your current system is. And   if you go back to a previous system, you know exactly   the packages that were used to build the system.   And you don't when I say exactly,   you don't I don't mean that you know the location where these things are. I mean, you know exactly the hash   of this specific   package. Right?   And,   so this gives you this kind of reproducibility   aspect, which I think in the security context makes sense because that way,   you know exactly   what you are running on the   system. You know exactly you you have one hash, and that's your system, basically. And from that hash, you know,   exactly   how your system is set up and what packages were used. So if some package is bad, you know, if you're running it, if if you're using it, and you know   also, hopefully, how to get rid of it.  



[00:37:53] Unknown:

Also, the   kind of reproducibility   that Jonas   mentioned   allows us to,   make   very deep changes in the operating system,   but   and make them,   make you able to roll back from them. So I like to use as an example   something I think which is unique   to nix bitcoin probably in all operating system   configurations, which is something called network namespaces.   Usually on Linux,   you have a local host and every service running   opens a port on local host and every other service can just talk to that. Sometimes services have authentication   like macaroons or passwords,   but sometimes you can also just call up the service and start talking to it. And we really didn't like that in nixed Bitcoin,   so we invented something   using standard,   Linux   kernel,   functionality called network namespaces, which   allows you to put every service into its own little box   and,   and fire and gives you very fine grain firewall control over which box is allowed to talk with which other box. So for example,   your,   ride the lightning or spark wallet won't be able to talk to Electrum running on the same system.  

And this is something that goes really deep into the operating system,   but because everything is reproducible   in the way   Jonas Jonas explained,   you can switch back and forth from that and one day when you   want this extra complexity, you can have it enabled, and the next day when you feel comfortable with running in local host, with running everything in local host, you can go back to that. And these kinds of deep changes   wouldn't be possible with shell scripts.  

[00:39:45] Unknown:

Perhaps they are, but they are very complex. And just to be clear,   I don't know much about these other node projects.   From my perspective, they could also have that.   I just can talk about what what Nix Bitcoin is doing.   And and perhaps to to rephrase this, what NixBitcoin dev said about,   about the network namespaces   and since we're also on the topic of security features.   So what you can you use Next Bitcoin, you enable Bitcoin d, c lightning, and Spark wallet, let's say. And Spark wallet is like a front end for for CLitening.   So   and your threat model is kind of that Spark Wallet is compromised. Okay?  

That's a problem because Spark Wallet has access to your c lightning   node. Right? So it can spend your coins.   That's bad.   But,   also bad is if if Spark somehow is able to access   your Bitcoin node as well.   Like, let's say there's some kind of supply chain attack on,   on Spark Wallet. It's not   it it doesn't seem too unlikely that something like this happens, then you really don't want Spark Wallet to access your Bitcoin.   You don't even want Spark Wallet to see,   your transactions, your Bitcoin transactions. That will be a privacy leak.   You also don't want Spark Wallet to even know that there is a Bitcoin d running on the system,   and that's why we have this,   NetNS   feature. Net, what you could you can imagine that this is like a network   on the Nix Bitcoin system itself.  

So you give each service a different IP address, and then we have a router   and a firewall   inside Nix Bitcoin that makes sure   that only services   that are supposed to talk to each other even see each other. Right? Because they cannot just ping any arbitrary IP address. They can only ping the IP addresses they're supposed to talk to. So CLightning has an IP address, Bitcoin has an IP address, and Spark Wallet can only   ping and connect to,   clightening.  

[00:41:56] Unknown:

And, also, we use that opportunity to add an extra,   protection from IP address leaks because,   if you have a certain option enabled, which is enabled by default,   services are only allowed to connect out of their network namespace out of their box to the Tor, Rooter.   So all connections,   you can be sure from that service   will either go through Tor or not go to the Internet at all.  

[00:42:26] Unknown:

And there's multiple options. Right? I recall,   there's Tor,   also a way through WireGuard, and then now, I2p recently?  

[00:42:35] Unknown:

The I2p   is, Bitcoin specific, but what was amazing about the whole I2p,   feature   is that   enabling,   I2p with Bitcoin   was a 4 line diff in our code,   which is amazing if you think about it that you can enable   such a complex   feature with   just   a couple line differences. It was just services dot I two p dot enable, which pulled something from NextOS,   and then the appropriate options in bitcon deed, and it was just able to start running immediately. And   so that was something where I was again very happy that   I was running Nix Bitcoin and that I'm developing on Nix Bitcoin because doing something like that on   Deepgram or whatever else,   would take much longer and be much more difficult to maintain.  



[00:43:30] Unknown:

So let's say, you know, something was compromised in, next Bitcoin.   Because of the way it's designed, do you feel that it would be easier to identify   where it was and,   you know, pinpoint it much faster than maybe   the other, potential   node boxes that are have taken more of a scripting approach.  

[00:43:53] Unknown:

I think, mostly, the advantage   is that,   something,   that is compromised won't necessarily   compromise other things that it doesn't have access to already.   So,   in Jonas's example, a Spark wallet   vulnerability,   which is very likely because it runs on   Node. Js,   that wouldn't   would never affect,   Bitcoin d because it's so sectioned off on multiple levels, soaring from users   to system d options and so on and so on. So I think maybe, Jonas, you can say more to what Matt said. But in my opinion, the biggest advantage is,   basically, flames from one service won't catch all over immediately   onto other services.  



[00:44:46] Unknown:

I mean, there are multiple   threat models that that we protect against. And   one is that the package is compromised   deep in your system. A library is compromised, and you might be   since   your whole system is pinned to certain dependencies,   you know,   if you are running this bad   dependency or not.   And there's also the thing where Spark, the service itself is is compromised in some way and now tries to break out and,   really to damage to,   the whole system in various ways.   So   perhaps another security feature, it's more trivial, but I wonder in in respi bullets,   when I guess you also SSH into the system,   Do you usually   do you do that at as root, or how does that work?  

Question to Vivek or or Matt. Yeah. I I think so.  

[00:45:51] Unknown:

Yes. You do.  

[00:45:54] Unknown:

K. So in in X Bitcoin, for example,   we   try to pay really good attention on having, like, a user that has restricted abilities   but is still able to interact with all these services,   although the services themselves are separated by running under different,   Linux users. So that user is usually called the operator, and the operator can run all the important commands but is not root, for example. And this is, like, a simple,   way, I guess, to to get quite a bit more security from your   from your node.  

[00:46:33] Unknown:

This is the And and this, for example, is also only possible. This additional complexity,   is is really possible to maintain   because of the way the ease of of the Nix OS approach.   So,   yeah, it's, it's something that,   the the principle of least privilege, which is something a basic   security tenant that   everything should only have access to what it absolutely needs, every user, every program,   is a nice theory, but people usually   breaks down when people start having to maintain such a system and all of a sudden something breaks so they just   disable the extra security feature and give more access than they need to.  

And with Mixed Bitcoin, we do the whole thing once. We do it properly, and every change that we make through the software gets run through our   automated testing suite.   And,   and if there's any issue, we,   we, the developers, fix it before it ever gets to the users, and we know that what is what we are testing is exactly what is gonna arrive at the user.   So,   we talk about security often   in in an abstract way, but here it's very clear how   the,   the way NextOS works helps us   to maintain and yeah. To create and maintain a secure system.  

[00:47:58] Unknown:

Next Bitcoin dev. Since Vivek asked, can you can you go into the, pseudo versus duas   story?  

[00:48:05] Unknown:

Oh, yeah. Exactly. I I forgot that.   So the pseudo duas story was something that was also personal to me because halfway through   developing   Nix Bitcoin, I stumbled upon OpenBSD,   which is kind of the OG operating system for security conscious people, especially on servers.   And I started to think about maybe this effort we put into developing the next Bitcoin is misplaced. Maybe we should do OpenBCD minus Bitcoin.   But I quickly discovered that just because a system is relatively secure when you boot it up, doesn't mean it stays secure over time   and doesn't mean that you can respond to security vulnerabilities   quickly.  

And one of those security vulnerabilities that popped up was the sudo bug   which first of all is because   sudo is written in c and sudo is an extremely   complex program,   unnecessarily   so. And it was only a question of time until such a terrible security vulnerability popped up, which basically allowed any user to gain root on the system where sudo was installed.   So,   from my background with OpenBSD,   I knew that they do a couple things right, which is write really minimal,   good programs. Like, for example, open SSH, which is in use   everywhere   in the industry   and is the only thing I would feel comfortable,   running   Internet facing, which gives people access to my server because it's so well reviewed and so well secured.  

The same authors that wrote s s OpenSSH   also wrote a tool called Duas, which has since been ported to Linux,   and we decide as a project to, from now on,   use Duas as our,   tool to get have you allow users to gain root access when they need to.   In our system, it's more used for root to become user, but that's going to into detail. The main   point here is that   Duas is is a much more minimal alternative to sudo,   and changing that in Nix OS again because it's so transparent and it's   it's code. It's not a abstract system where you input   lines into a into a command line,   every couple weeks, and you forget what you used to what you did before. It's a clearly laid out code which gets reviewed on GitHub by multiple people on every change.  

And,   Duets making that switch was very simple, and we still, by the way,   enable people to keep continue using sudo. It's just that we try to lean towards security in our default.   So,  

[00:50:53] Unknown:

I mean, we have 2 comments in the chat, and I just wanna make sure that I didn't speak incorrectly.   With Raspberry Pi Blitz,   you use an admin user, but it has pseudo access, which to me, that means it's root. Right?  

[00:51:10] Unknown:

That's the same. Password protected?  

[00:51:13] Unknown:

Yeah. Yes. But it's always password protected, isn't it?   Like, you type in   you type in   so, usually, when you're using Linux, right, and you wanna have root access, you type in sudo   then whatever command you're gonna do.   And then   once you do that, it asks for a password, and then you have root access. Right?  

[00:51:35] Unknown:

Well, I mean, I guess, there there's a difference between the admin   versus the root, but,   I don't know necessarily   where their   privileges end on whatever OS.  

[00:51:46] Unknown:

So there is a difference.  

[00:51:48] Unknown:

For for there is a definitely difference because by us, the operator   user has no way of   gaining new privileges.   There he doesn't have access to,   to do as in that way where he can go up to root. So   I guess that's a slight difference, but I'm glad to hear that   this security step is   existent.   Unlike   Jonas, I'm not so diplomatic, and I I will say that something like Umbrell, for example, has terrible security practices.   And,   yeah. So I'm very happy to hear that GraphiteBlitz   is   is is,   has that in place.  

[00:52:31] Unknown:

Perhaps just just to clarify again, we use this duos thing and also, like, as a replacement for sudo and mainly for the operator user to become the c lightning user or the Bitcoin user. And it's not possible to get root.  

[00:52:45] Unknown:

Gotcha.  

[00:52:46] Unknown:

And then, Saturi, he also just added Ronan Dojo has SSH   key auth.   So,   or offers it. But, any any person with, with half a brain should be using SSH key auth.   Passwords are not   not   2021.   Well,   Matt, do you think, we could jump into maybe, like,   cool features about Next Bitcoin? You know,   they recently had a release.   There's a bunch of stuff on there that I'm fascinated with.   I think it's a good Yes. Let's rip it.   Cool. Cool. So,   I guess the stuff that intrigues me most about Nick's Bitcoin is that it's kind of agnostic.   You know, there's   a liquid node on there that you can enable through the module.  

You can have LND node. You can have a CLining node.   There's pool on there.   So I,   you know, frankly, in these times where,   there is, like, all sorts of   protocol standardization,   sharp elbows going on. I I find this as, like, the way forward in a sense.   The other things that I'm fascinated with is, they also have JoinMarket,   Elect RS, BTC pay server.   So, I wanted to give Jonas and,   Nix Bitcoin to have a chance to talk about maybe what they use or find,   cool.   And then, I think Satrinity   had a question a while back about BTC pay server and,   Ellen URL, which we can jump into afterwards. But, yeah, Jonas Definitely.  



[00:54:28] Unknown:

Definitely. So,   first of all,   because you said c lightning and lnd   and Nix Bitcoin being agnostic,   I think   nix Bitcoin is probably the only node project that allows you to run clighting and lnd at the same time easily.  

[00:54:44] Unknown:

I believe RaspiGlitz   just added that, but, yeah. Nyx is the 1st.  

[00:54:50] Unknown:

So it's it's actually very simple, but I get very fascinated by this.   But for some of the development nodes, I actually have that running, which makes it easy because I have can test both on one node.   But,   you mentioned join market, and I like using that. And it's really difficult to maintain because it's Python   code, and a lot of work goes into this joint market thing. So I hope I'm not the only user.   But if  

[00:55:21] Unknown:

You're the only maker of making those, Fidelity bonds.   Yeah.  

[00:55:26] Unknown:

No comment, but   join market is something I like to use. I like to use c lightning and l and d.   I haven't gotten into really the,   lightning   stuff like pool and loop, but I love this thing called CLboss,   which Jonas turned us onto. It's the coolest thing ever. You have a CLightening node, you put funds on it to on it, you enable CL Boss and it has such complex logic that it just figures out,   what are the best possible routes and channels for you, and just does with your funds. Really, everything automatically   and tests   stuff periodically,   chain rebalances and even,   eve, it even   uses low low fee times to do a lot of these,   on chain operations.  

So it's it's something like set and and forget and you always root. You always have a root.   And,   that's something I really like to use and on our Even sets your channel fees.   Yeah. Exactly.   It's so cool.  

[00:56:31] Unknown:

It is so just to clarify for the freaks, this is a c lightning plug in that I believe Z Man made.  

[00:56:37] Unknown:

And Yeah.  

[00:56:38] Unknown:

This isn't the first time I've heard this, and I keep hearing it from different people. You know,   Francis from Bull Bitcoin, you know, he was a pessimist about lightning, then he got intrigued by it. Then he had some liquidity issues, and then he tweeted later about c l's CL boss fixing all of it. So,   very bullish on this particular plug in.  

[00:56:58] Unknown:

It fixed my my issues too, really. And,   and it it it somehow picks notes I like.   It it, picks cool nodes.   And, something else with nixbitcoinorg,   because somebody mentioned BTC pay server,   We have that running in a in a professional way. So if anybody wants to see how to deploy BTC pay server public facing   and and have it really be very stable and reliable,   go check out the next bitcoin.org   repo.   And, we have we have,   Bitcoin enabled, we have Lightning enabled, and the coolest thing is we also have Liquid enabled. So you could make liquid payments to us,   which so far one person has done, but   I'm really into it.  

What else? I'll get the  

[00:57:50] Unknown:

you You got the only liquid user to donate, so that's good.  

[00:57:54] Unknown:

Yeah.  

[00:57:57] Unknown:

That's fired, man. So  

[00:58:00] Unknown:

last last thing I like to use is,   Spark Wallet, but I think that's on the way out   because I'm maintained, and we're gonna   today, we   or today, I finished the Arrive the lightning module, which is gonna go through very intensive   graphical user interface for making payments with either LND or c plus lightning   and also managing your node.  

[00:58:30] Unknown:

So The RTL the RTL,   package or module is going to be awesome because I remember,   you guys didn't like gooey people, and, we were somewhat of peasants in your eyes. But,   it's it's glad I'm I'm very glad to know that, we now.  

[00:58:48] Unknown:

No. You do. And and look. It's it's one thing if you have a note with a couple   $1,000 worth of Bitcoin on it. I'm sorry I still use the dollar as a unit of account. I know I'm not a great toxic maximalist,   but still,   so if you have a node with a couple $1,000 on it, I would feel comfortable to have a GUI. But once you start getting into the tens and 100 of 1,000,   I would stick with,   see lightning only or l and d only.  

[00:59:15] Unknown:

That's a fair   point.   The question specifically that Sat Trinity asked were, are there plans for next Bitcoin to make it easy to expose a BTC pay server   to the outside world to take advantage of the new lnurl   slash lightning address functionality   in a safe and secure way?  

[00:59:34] Unknown:

So,   I don't know if it's so easy, but public facing again,   usually we only work with,   onion services,   in the Nix Bitcoin repo itself and kind of say that if you wanna do anything more complex,   we want you to know what you're doing and you should be doing that, as because Nix Bitcoin is super extensible, you should be extending that yourself. And if you want an example for how we extended NEX Bitcoin to work with Clearnet,   and,   Clearnet and Tor at the same time for nixbitcoin.org.   Check out the nixbitcoin.orgrepo.   And as far as Allan URL goes,   we are working on that. Eric   Arstead thinks that's a super cool feature, and I'm sure that'll be a very,   thorough and,   and good,   PR coming up very soon.  

So, Jonas,   I took up a lot of time about the features, but,   I'm also interested to hear how you use your Bitcoin.  

[01:00:37] Unknown:

That was a was a good summary.   I'm also a fan of the CL boss.   I think more people should look into it. It's also not   it's also kind of extensible, and not many people are really looking at this right now, and is only updating it from time to time.   So,   I think there this could be improved quite a bit.  

[01:01:01] Unknown:

Someone it again? What what language?  

[01:01:05] Unknown:

It's in c plus plus. Oh, c plus plus. Got it. Okay.   So just because,   as   I need to answer this question so I don't forget, someone asked, how do you get a NYX white belt?   And you usually get a white belt by showing up at the gym.   So in this case, it would be to check out,   the next Bitcoin repository   and read   what is there and perhaps also delve into the   Nix OS documentation.  

[01:01:37] Unknown:

The white belt hole stuff reminds me that,   about I just wanna say something quickly about the   project culture at Next Bitcoin,   which is   very   software oriented in the terms of Cypherpunks   right code.   And,   yeah, I I know that other projects have some kind of belt   system and then and community managers and everything and we're you can rest assured that the 3   spare time   mixed Bitcoin   developers waste all their time on on such stuff and focus all their time on improving   the software for your node.  

[01:02:17] Unknown:

And you guys are politically agnostic. Right? Like, you know, I'm a California   communist, so,   very happy that I'm embraced in your community.  

[01:02:26] Unknown:

So I guess we we all have kind of our own political opinions.   Some stronger, some   less strong,   but, we try to keep NEX Bitcoin or we do keep NEX Bitcoin. Also, the reason why I picked a NIM and a project specific NIM.   I and I think also the other developers are in this to write good code,   and good code automatically produces freedom,   I think.   At yeah. So we're   we're not in it to fight with anybody.   We're in it to make   good software, that a beautiful software,   non spaghetti software,   and,   we kind of keep our political opinions   to the   to other other parts of the world.  



[01:03:14] Unknown:

No sec with who acts.  

[01:03:16] Unknown:

That that's not political. That's technical, I think. But   definitely no two x. We don't we also had   a a discussion, I remember Jonas,   when when   Taproot   stuff came up and we took a very clear line and decided a little bit for   our users,   I guess, something that we decide the defaults and we're definitely   we definitely take a   a block stream position on things. No yield   us.  

[01:03:48] Unknown:

But, I mean, compared to other projects, if, like, in the future and and this was a conversation so I had   pretty much all the other maintainers   all the other node project maintainers on   for, like, a roundtable discussion except for Umbrel,   who refused to participate. And,   you know, one of the main top that that was around,   when when the whole Tappr thing was going on with speedy trial and whatnot.   And so in the future, I mean, there could be a situation where we have, you know, contentious clients, where we have multiple clients, and, you know, Taproot was kind of obvious,   but where we have a situation where we have, you know, multiple   clients that are in contention with each other.  

And these node projects, you know, are kinda going to   there's no clear answer there on how they will proceed,   in that type of situation. And people can say one thing or say the other, but, like, when push comes to shove,   we'll see how that all plays out. But am I correct in my understanding that with something like Nix Bitcoin, it would be easier for me to basically   choose which Bitcoin d client I'm running?  

[01:05:03] Unknown:

I   I'm not necessarily.   I I think that because it's it's kind of a   something where we take a lot of the technical complexity out of your hands,   we also make   decisions that we think are in the best interest.   But I think if something really contentious came up where we wouldn't see a clear,   clear answer,   where most of the time I think with Bitcoin because it's so   hard to make changes. If there are changes, they are only they're very clear,   for the better   or, only with pretty much only upsides.   But,   yeah, if there was something really contentious where you could fall on either side, I think we would make an easy option for people to choose. But,   going in the idea of us trying to protect our users and also ourselves because we use it ourselves,   we make sensible default decisions on a on a technical level. And also one quick thing about Deepak, I think you said you're a California communist. Who who said you're a Yes.  

No. I think that's something also very important by us that we we   accept and love and accept everybody, I guess.   But definitely,   everybody's welcome and it's   about running good code and   and using Bitcoin the way it's supposed to be used,   on sovereign hardware,   privacy by default, security by default,   and,   not about   anything else. And then But am I am I wrong am I wrong in  

[01:06:40] Unknown:

am I wrong that, like, to to run a different version of Bitcoin, all I have to do is change a line item on in the config file?  

[01:06:50] Unknown:

Jonas, what do you think? I mean, these are future things. I mean, if it's if it's contentious, then it's already too late, so there's no safe option. Yes. Then we would have   some option. I mean, would make it optional to the user, but I don't probably other node projects would make similar choices and would make it easy for the user, whether that's,   like, changing a a config file or  

[01:07:11] Unknown:

changing something in the GUI, I guess. So so a couple of things here. First off, you know, I'm being facetious about the whole   California communist thing. You know, skills are what matters most, so I echo, Nick's Bitcoin dev sentiments.   It seems like specifically for this instance of Taproot   speedy trial,   Nix Bitcoin   is not   as, you know, inclined to take the lot true approach,   maybe rightfully so,   you know, given that,   UASF did reveal   that the nodes the full nodes   are, like, the validators in the network, and the miners are   kind of the appenders who need to follow the full nodes, say,   of course, you know, with contention of economic nodes and all the other variables thrown into the mix.  

But with that said, there was no reason to   drive things to that right away.   If it was,   you know, contentious in that sense where   minors were adversarial,   then, of course, we can do it. But in this specific instance,   it didn't feel as if that was the right way to do things and further set precedent.   Not to say that's not a valid opinion. I do very much respect   Luke Dasher as well as others that would run the code and have expressed   that opinion like MBK. You know? So   I think it varies. And,   if it did come down to that contentious moment again like UASF,   I think, like, there would   be, like, multiple,   I guess,   configs   for this,   and maybe all the   distributions or node boxes of whatever client software.  



[01:08:57] Unknown:

The whole that a lot of truth thing also goes with our general philosophy, which is safety, stability,   first.   And,   we like to   do things easy and not, you know, go all the way all of a sudden. We're very   thoughtful in our decisions. Everything   in our code base has a lot of thought echoes into it. And, once we fix one thing, it stays like that for and we like it. It stays like that forever.   So we   are very careful using our code and also with these kinds of things. And,   so I think that gives a little bit of the background why we didn't choose to go with the radical approach   initially.  

Another thing This is people's money. You know? It's it's people's Bitcoin, and once it's gone, it's never coming back. No. I mean, I I appreciate the conservative nature for sure. I think most Bitcoiners do.  

[01:09:57] Unknown:

It's, like, become part of our ethos in general.   Another another   line of of conversation that came from that conversation   was   the ability to, like, easily migrate between node projects. If,   let's say, you're running, an Umbral or a RAS pi blitz, and they decide to go a route that you don't want them to go and you want to easily migrate without closing out all your channels.   Is that something you guys have considered? Is it, like, how how how difficult is the migration process if if someone already has a   if they're already running Raspberry Pi Blitz and they have a bunch of channels open or vice versa, if they're they're running next Bitcoin and they have a bunch of channels open, and they wanna move to Raspi Bliss. Is that something that you guys have considered?  



[01:10:45] Unknown:

So I guess, in theory,   you know, more than even a NIX Bitcoin question, this is, I   guess, how easily can you,   port your channel DB and wallet dot dat and actually, like, the   the different derivation standards, like, the AZ with the birthday and other stuff.   Would you say that's fair, Jonas? And how does Nix Bitcoin   do this,   and maybe whether it's different or similar to others?  

[01:11:17] Unknown:

I think this is   quite difficult to do in a general way. I know both who did this, who didn't lose their funds, but   I think there are many things that can go wrong. Just imagine that,   like, the the LND or c lightning versions are different on the next Bitcoin node you're porting to to the   to the node you're porting from, and somehow your data directory isn't compatible anymore, and it expects something else somewhere else. So I think that gets   difficult really quickly. I think it's a good question,   because could be expensive to close your channels to set up a a node.   I am in principle, if you had 2 Nix Bitcoin or NixOS based projects, I guess it would be simple to make this   switch because then you could do it,   basically programmatically   because you know what versions are running there.  

But for, like to migrate from   a general   like, any kind of,   Bitcoin node, I guess, that requires some custom   thinking.  

[01:12:26] Unknown:

So,   Jonas,   you just made a PR that I'm gonna review in the next   days of, of the backup plugin for CLightening.   Wouldn't you just be able to restore from your backups,   from 1 CLightening backup,   1 CLightening backup you made to your new next Bitcoin node or vice versa?  

[01:12:50] Unknown:

I guess that's kinda what I was alluding to in the clarifications   for this question. Are we talking, like, between implementations? Because that might be more of a lightning problem. Are we talking between, like, nodes?   And then also,   essentially,   don't wanna docs a person, but we did necessarily   see someone   who was able to migrate from   l and d recently, correct,   in our elements chat?  

[01:13:22] Unknown:

I guess if it's about   changing between different, lightning implementations, of course, that's that's not not our problem.   But, yeah, I guess it's too easy to lose funds. And to Nick's Bitcoin dev's question, we have this backup plugin. Actually, that's a good question. I'm not quite sure. What the backup plug in does, it simply writes down,   the SQL   statements that would usually go to your database,   and it writes this the simply the SQL statements into a file appended, and,   I'm not sure how   portable it is between versions, but that's a really good question.  

[01:14:03] Unknown:

We need to we need to figure this kind of stuff out   because,   I have this dream.   I I I haven't articulated   in some private conversations, but   my kind of long term vision, which is just mine and   no one.   As Jonas pointed out in the very beginning, very clearly, I have not deleted   my payer, but my vision is to,   we have a couple things that we really need to get done, which is 1, ride the lightning and,   really good backups,   solutions,   and a couple of other things.   And after we finish those things, I wanna   make a,   v 0.1   or 1.0 whatever in our naming scheme release,   and from that point on,   just make functional improvements   or,   deprecate one feature in favor of another, but not keep expanding the complexity of of mixed Bitcoin adding new features,   but instead make that   more   part of secondary projects for people's   private,   big module extensions. But I kinda wanna   wanna finish make a finish line for next Bitcoin and start only making   improvements and and and functional and then and speed, secure all these kinds of underlying stuff, which which we pride ourselves in. I think we wanna get better and better in that.  

And,   and backups is one thing that is, I think, a question for all of lightning, but specifically for us because we wanna be the most safe   and and conservative nodes for people and backup a good backup strategy is is an integral part of that. So,   I I wanna get into that in the coming that's part of that's one of the   most highest priority things that we wanna get done also for our own interest, not just because we think it's a good idea but I also   would appreciate have you know, having clarity about how safe my lightning funds are in case of hardware failure. And because that mentioned matrix   and l or element chat, I wanna give a quick plug that I think that Bitcoin users should slowly migrate onto matrix, which is shaping up to be a very robust   decentralized   federated chat solution.  

And, I think this is more in the ethos of of Bitcoin than people using,   centralized things like   even Keybase or   whatever, which can all have a political lean, and and it's just a question a matter of time until people start getting banned, until people start getting shadow banned,   whatever.   So,   I think that quick thing just about matrix and our project is is pro matrix. We have a matrix server, which also interacts with IRC over libera.chat,   and we're   really I I feel very comfortable with this, and I think   every Bitcoiner should have his   own square, his own little   house in the digital realm, his own property.  

Like, he has his money, he should also have property over his his, communications.   Just a side note, and we'll get back on topic.  

[01:17:22] Unknown:

Hey, Matt. My, autism is kicking in because of this fear, but, I wanted to dive even deeper, like, for backups, essentially.   With the channel DB, you know, the main issue is, like, the state   and, like, storing all those revocation points or the transactions. Right, Jonas?   Like, with the commitments,   does any plug out,   will that reduce the amount of state required and reduce, like, the channel DB size?  

[01:17:54] Unknown:

In principle,   yes.   You should only have to store the latest state.   And   if you store an earlier state because you,   you have an older backup,   an updated backup, essentially, instead of losing your fund your funds, you should be able to recover   trustlessly kind of modular fees with your,   with your channel partner.   Awesome. But before we move away from this whole feature discussion, I want to answer a few questions from the chat. So,   let me find this. Radix rat asked   if there's   a   if I want a new version of Bitcoin Core that's not supported yet via the Nix Bitcoin update scripts, what should I do?   That's a good question.  

So I can tell you that if I wanted to do that, that would take me   2 minutes or something to do that.   But for someone who hasn't worked with Nix, it would easily take a couple of hours. And the the reason is just that we have to be honest, the Nix and NixOS documentation   is really terrible, and it's a lot of custom things that need to be done. I could show you easily in 2 minutes how to do it if you show up in our matrix channel. For example, I guess it would be, the right answer to this question.   But, usually, we try to update relatively quickly. I think our Bitcoin d updates, they landed within,   2 weeks 1 or 2 weeks within the the release.  



[01:19:32] Unknown:

Yeah.   Something that also,   I think that,   on top of the security features and everything,   Mixed Bitcoin is one of the   node projects, I think, that updates the quickest,   and you don't have to wait on on on stuff with us. We usually have things   running in days or and or maximum one.   Crazy times, 2 weeks. But, usually, we're snappy with maintaining stuff, except join market, which usually takes a long time to figure out,   how to how to do it.  

[01:20:07] Unknown:

And and just to clarify my earlier point,   using NYX Bitcoin the way it's intended to be used should be relatively   straightforward   for a technical user who's familiar with command line.   But   if you want to do custom stuff, then it gets   quite difficult   quickly. And that's why we say   it's the lowest   time preference,   note project because   you it makes sense to invest into learning these things because then in the long run, you hopefully have, fewer problems.  

[01:20:43] Unknown:

So, Jonas, I read in the chat a lot of stuff about making it easier for   new users or or not so technical people. I even read the dirty word Windows   and other things. So what do you think about   us   making Nix Bitcoin   plan friendly and lowering the bar of entry.  

[01:21:05] Unknown:

Can I take this?   Yes. So, I mean,   I've been telling Jonas for a while that I'm going to build a tutorial.   You know,   Matt had, like, the PlevNet folks on before, Raj Winder and Pete.   Many others I've discussed with also, like, another guy named Richard, Miguel,   Rafael.   So they are interested in this, and, they are fairly technical.   So I think it's,   very much possible as long as there is, like, a good tutorial. So working on that with some Intel NUC hardware   that Jonas has suggested.   Specifically to the Windows question you mentioned, is from VidGamer   14.  

He says the bar to entry seems extremely high. Like, can you even run this on a old Windows laptop? And to that, I say, you know, I have run Nix OS   on old MacBook Pro from 2010, and,   it worked. I got big Nix Bitcoin running as well.   I tried recently   on a 2017   Surface Pro,   The   the what's it called? The resolution was a little screwed up. But if I plugged in an HDMI, I was able to see upon another   monitor.   And,   I think it   for the most part, Nix does run pretty well on multiple things. But, the main issue I've encountered is   whether, you know, to use,   the UEFI   booting   or,   I guess, the legacy BIOS boot option, like, in the Nix OS install instructions.  

But once again, like Jonas and Nix, Bitcoin Dev mentioned, just hop in the matrix and ask some questions, and, people are more than willing to help you.  

[01:22:47] Unknown:

Matrix or we better chat if you're into IRC more. Maybe we bridge out to other things in the future, but right now, that's really   what we, what we use for communication. I read 2   questions here that are related   from Setrinity   and SovereignHodler.   Can you talk more about the BTC pay server implementation and how you're exposing it to the outside world? Does Nix Bitcoin use Tor?   Great question. So first of all, Nix Bitcoin by default always uses Tor and only Tor. So if you are running on a home node and you wanna start up a BTC pay server, if you go into the config and,   uncomment the line BTC pay server enable,   what will happen is that on once you deploy that to a node,   it will set everything up and generate a Tor Onion service for your use.  

Once you wanna leave the Tor world   and,   once you want to,   endanger your own privacy   and and start dealing with NAT and all those things,   you're kind of on your own,   which I think is something   we want to make a little bit difficult.   But,   I wouldn't recommend it for home use, especially,   exposing your IP address and dealing with NAT.   Usually better if you want to have a BTC pay server just for interacting   with people privately,   just to use for.   And,   if you wanna know then Sovereign Huddler, can you elaborate on public facing BTC pay? Does it expose your home IP? No.   Public facing with an onion service won't, and if you start, going out of that secure space,   like we did with nixbitcoin.org,   it does expose your IP, obviously, because you're using ClearNet.  

And,   that's,  

[01:24:47] Unknown:

that's something we did manually there. Are you aware of, the IP tutor   support that Raspberry Blitz has integrated?  

[01:24:55] Unknown:

I am aware   of it   its name, but I never how does it, make it clear that IP? The name is, like, pretty self explanatory.  

[01:25:07] Unknown:

So so, like, the the issue is right? So, like, if you're if you're a merchant and you wanna run BTC pay server   and you wanna run on your own hardware,   doing Onion only, doing Tor only is kind of a nonstarter. Like, all your customers need to, you know, open up Tor Browser and and go to your onion link. They can't Depends what kind of merchant you are.   That's true. It depend it depends on the type of merchant you are. But if you're just like a a standard,   I'm selling coffee. Yeah. You're selling coffee and,   you you you you wanna use BTC pay server,   it's it's pretty much a nonstarter to do Tor only. But the other issue is that if you're   if you're running it at home, you're running out of your office,   exposing your IP to the whole world,   is obviously horrible for your privacy and security.  

So   they're they have this IP to Tor service integrated where you pay them SATs, and it basically does a tunnel   through Tor   to a VPS that they run, and then   they provide you, like, a clear net,   IP.   So you can That sounds a little centralized to me. Yeah. It's extremely centralized, and it's not very reliable, to be honest, but it's a cool feature.   I've kind of come to the conclusion, and I'm curious of your opinion is, like, if if you're a merchant in that kind of situation I mean, the perfect example is,   my other podcast, rabbit hole recap, where we accept donations via BTC pay server,   is to just run a dedicated BTC pay server instance on some server somewhere that's, you know, virtual private server, and you just,   you just expose that IP address, and you keep it contained, and you just have a separate node for yourself.  



[01:26:55] Unknown:

Right? And and then you would take a look at next bitcoin.org   or,   in at how we did it there, and that gives you a pretty straightforward way to also,   expose BTC pay server publicly and also safely, because what we did   with our,   with our next bitcoin.org   is that in nginx, in the web server,   we, disallow access to a lot of   the admin API   and API admin stuff that people don't need   publicly,   which I think is a mistake in BTC pay server kind of that,   the same way you   administrate the node is also the way you   access it as a customer. I we have certain issues with v t c pay server, but not to get into it.   We we block all that stuff, so I think it's really worthwhile to take a look there. But probably   something we we should make easier in the future.  

But as far as how I would do it if I was a merchant,   trying to,   expose not expose my   public   IP address,   but at the same time,   be available over Clearnet with, high reliability   is I would use WireGuard,   to run a very simple   public VPS server or something that really   only takes,   you know, a couple 1 CPU core and maybe 1   a half a gigabyte of memory to have a a public facing WireGuard server   that tunnels from from that public IP address to your local machine.   But, I think that that's something that's,   yeah,   that's that's something that isn't isn't straightforward   as just setting an option and it makes Bitcoin.  

So,   Jonas, do you think that's something that in the project's   future to to make easier, or  

[01:28:56] Unknown:

are we still looking to to to be honest?   To be honest,   it should not be too difficult to set this up yourself. I've   done that a couple of times. There probably ways for Nix Bitcoin to make this simpler for you   to use.   Perhaps one thing to mention is that   if you you you can use NextOS on one machine   and deploy your configuration to 1 machine,   But you could also run your whole infrastructure,   on NextOS, which means that you have one configuration file per server, and you can deploy them all with one command. And they can interact with each other's share, their variables,   etcetera.  

And once you're doing that, you're definitely not a pleb anymore. So if pleb means anything,   you're not a pleb anymore. So I I thought about this a lot today. Like, if if you're doing that, you're not a pleb.   So people should be aware of that.  

[01:30:03] Unknown:

You're not a pleb. You're a freak now.  

[01:30:05] Unknown:

Yeah. Oops.   But, Jonas, how would you go about it? Would you be would you put the BTC pay server on a VPS and have it connect to your Bitcoin node over   over Wireguard, or would you put the BTC pay server   on the on the on your own hardware and then just put the public facing Wireguard server on the VPS?  

[01:30:31] Unknown:

I guess that, depends   on on your situation and how powerful your VPS is. For example,   sometimes these VPSs that you can get privately are pretty underpowered. So perhaps you don't want you only want to run BTC pay server there, especially if it should be performed. So it all depends, and this is really   like, when   if we want to add support for it in next Bitcoin,   then the question is exactly in what way because people are different and have different,   requirements.   And that's why it makes sense to learn how to use NextOS because then you can build these systems,   by yourself relatively easily. But I think something like IP two Tor is is pretty elegant solution to this problem.  



[01:31:17] Unknown:

What I think that what's different also about Raspberry Pi Blitz and and and mixed Bitcoin, which is a disadvantage and an advantage at the same time for Raspberry Pi Blitz is that Raspberry Pi Blitz,   thinks about a very specific kind of user   and makes it easy for that guy. So,   it thinks about a user who has a b who has a Raspberry Pi 4   with this and this amount of gigabytes and this and this kind of HD or SSD,   and who's running it at home and wants to do things that somebody at home does.   But what makes Bitcoin takes more the root is that we give a basic   kind of function   and then and,   some some really streamlined stuff. And once you wanna do something   more,   you start extending it yourself, which is much easier than you think probably.  

And,   and and once more people start using it and sharing their configurations   and and writing tutorials,   it will become as easy as just following a tutorial for your use case. I'm not sure if those are things that we should really,   determine for people in Nix Bitcoin because Nix Bitcoin tries to take the   agnostic approach   and not presume   a way you're using it.  

[01:32:40] Unknown:

Yeah. I think,   just, just one aspect of that. I'd be in favor of removing features from NixBidco and actually Make it as simple as possible but   extensible.   So, that's one of the things that we're investing quite a bit of time on. How can we make NEX Bitcoin extensible? So we have one core NEX Bitcoin system that perhaps has Bitcoin d and perhaps the Lightning implementation   and sidechains or whatever has a module for,   having a Tor interface   and the password interface.   But everything else would be kind of separate repositories that can be that can have a separate governance   and would be able to easily integrate   with this,   NIX,   with the,   like, upstream   NIX Bitcoin system.  



[01:33:34] Unknown:

Yeah. And also for if anything,   once we reach that certain point where we have more features,   these couple features that we've laid out that we need, like,   a graphical node manager and other stuff,   we're not gonna keep on adding to the next Bitcoin, but we're gonna start chiseling away at it and making it more   robust.   And,   and,   yeah.  

[01:34:01] Unknown:

I mean, this this kind of already works. So people are using Nix Bitcoin and built modules on top of that without integrating them into the upstream Nix Bitcoin repo.   I don't I'm not sure if I I'm not going to dox him who's doing that anyway.   So it's already possible, but it's just not very ergonomic at the moment and not documented at all.  

[01:34:29] Unknown:

If anybody still has a burning question, I would suggest,   putting reposting it again because I'm reading through questions now, and I'm not sure what really got answered in the context. So   somebody's still listening   and then hasn't had their question properly answered.   Please,   write it again maybe if you can because I think when someone's Yeah.  

[01:34:52] Unknown:

I,   I I saw it wasn't a question, but Winsome Hacks was saying, you know, my   he was commenting on my question, which was   was the twofold question, which was migration and the ability to choose which Bitcoin version you run.   And he was saying,   I think rightfully so, that it's important that we have standardization   and and these things are easier to use,   rather than focusing on edge cases.   The reason I   brought it up is because   to me,   to my monkey brain over here, you know, I see we never had, like, these node projects before. Right? Like, this is like a relatively new phenomenon. If you've been in Bitcoin for a while,   we used to just, you know, run Bitcoin d or run Bitcoin Core.  

Now you have all these, like, managed node projects. And   one of the things, like, Umbrel has been making noise about lately is is,   you know, whether the validity of their claim is correct or not,   they're taking credit for a lot of the growth in lightning and a lot of the growth in node count and saying that it's it's their users that are running these nodes.   So in my mind,   I immediately go to   this theoretical situation in the future where   whatever the leading node project is decides to,   you know,   push their users towards some kind of contentious,   version of Bitcoin. So so I'm, like, I think that's, like, a real fear. Like, I think that's something that could happen in the future, and I'd prefer   if I'd prefer if we weren't trying to figure it out, you know, as it was going down.  



[01:36:27] Unknown:

I mean, Matt, like, you're you're spot on. Like, this is basically, like, a redo of,   or deja vu of   of BitPay   and, like Yeah. Just, you know. And I think this problem will always be there, where,   you know, the noob users will come in to, like, whatever, like a MyNode or an Umbrel, and then they'll brag about adding, like, onboarding 9 of 10 nodes of, like, the last year.   But, I think it's our duty to make sure, like, they go further down the funnel. Right? Like,   maybe, like, they just get pissed off because, like,   their channel state just keeps crashing,   and then they're it just corrupts.  

Other things, like,   maybe,   they get jacked because there's just too much attack surface.   You know, things like that. Like,   I think no matter what, it'll be whack a mole with whatever is, at the top of that funnel, and,   it's pretty fucked.  

[01:37:23] Unknown:

So so I guess that   also with   with Node projects, now that you're add adding that layer layer of abstraction,   you also have to   kind of find who you align with philosophically.   And I I'm somewhat skeptical that Nix Bitcoin is gonna become   by itself,   Nix Bitcoin is gonna become the go to Bitcoin node for everybody,   maybe as an underlying,   as an underlying structure for a more user focused,   more user friendly,   thing built on top. But by itself, I don't think I don't see Mixed Bitcoin going that route of being the   mainstream,   node project, I guess. But it's something for people who,   align with our philosophy of of of conservatism,   stability, security,   and and taking things into your own hand a little bit,   technically, also.  

To to,   to, be be sovereign in that way, which I think is is   you don't have the option as as the somebody who wants to   remain sovereign,   digitally of of being a techno. You need to increase your skills over time   to because the other side is also increasing their skills   and and and building a a more   and more,   elaborate net of control   over,   over,   you know, companies and and and what whatever.   And and,   so   when you really wanna be sovereign, you need to also kind of understand the technological side. And and if you align with our philosophy of conservatism and security first, then,   it's it's worth investing the effort. And probably it's not gonna be everybody, but that we're gonna be that   that per that role in the market.  



[01:39:15] Unknown:

A 100%.   I guess not to beat a dead horse, but just reframe my perspective a little bit. I tend to agree with you that,   and with Vivek that, you know, next Bitcoin will be,   and and should be, I think rightfully so, geared to more technical users, who are farther down the funnel.   I guess my perspective is   and maybe this is just like a maybe this isn't even on the dev side. Maybe this is more on, like, a tutorial side.   But to make it easier for people to migrate from these top of the funnel node projects   down to Nix Bitcoin,   because,   you know, right now I mean, I I have pie on my face from earlier in this year when I was calling for a sustained high fee market, and as you can see from mempool.space   being streamed by now, it's just fees have been fucking low as hell. But   in a sustained high fee environment, all of a sudden, all those lightning channels you have open become real frictions, you know, sticking points where people, you know, might not like the direction a node project's going,   but they're hesitant to move because they have to close and then open. So each channel is is 2 on chain transactions.  

So it's just   you know, I I I think it's just something to consider   making it easier for   someone who's already on one of the other node projects to migrate over to Nix.   But maybe   Yeah.  

[01:40:46] Unknown:

I think you're you're hitting a couple things that are super interesting.   I I think start 9 is well positioned to be probably, like, the   most,   compelling   top of the funnel solution   that, you know, has   a multitude of these sort of offerings.   Ideally, they have some other competitors,   that are a bit more respectable, not just Umbrel.   And then with that then said, you highlighted on a great point of vendor lock in,   not only between, like, the node boxes, but maybe between the lightning implementations   themselves. You know?   And I don't necessarily know if, like,   we fix that. You know, it's more of, like, on   a on a standardized   standardization   or, like, a a spec level type of thing that needs to be ironed out about, like, the the backups and   channel DB, you know, like, it it, it gets hairy really fast.  



[01:41:48] Unknown:

I totally agree that standardization   would be nice.   Absolutely.   I don't exactly see the lock in problem. It would be a problem if it was a problem. But, for example, in respi blitz, if they would make decisions you don't agree with,   You at least if it's, like, a simple thing using Bitcoin   core version x versus version y, someone could fork it, and, hopefully, you'd be able to intercept   the update process   and, basically point to this forked   repository instead of the original one. At least with Nix Bitcoin, that would be possible. And it should be possible because, otherwise, you're not in control of your money.  

[01:42:30] Unknown:

Yeah. Yeah. I I think I guess that's where That's a good point. That's where some of the note boxes, you know, rightfully so,   have diverging opinions about   open source and, like, FOSS,  

[01:42:41] Unknown:

essentially. Yeah. That's that's something very important that   that open that   that free software isn't just something that you throw around   because it's a cool marketing term, but it's a a way of of thinking about the world.   That your computer is your property, an extension of your brain and your and you.   And,   and free software means being in control of   that. And,   Nix Bitcoin takes the maximum approach on that, and we're MIT licensed.   Somebody also, I think I read in the chat that it needs to be a business and and businesses are,   Mixed Bitcoin is, first and foremost, a free software project that people develop in their free time.  

People who   have don't have economic interests except that they wanna have a great node that works really well.   And there's a place in the market for that too. There isn't just place in the market for glossy,   glossy,   quote, unquote, open source   source available notes. There's also place in the market for a hardcore MIT project,   hobbyist,   made with love,   made carefully,   made for your own use project, and that's Nix Bitcoin.  

[01:43:57] Unknown:

And, not to really, you know, toot our horn or whatever, but,   this is, like, priceless. You know? It's it's not to say, like, this needs a business or whatever. Like, literally, Avionna Snyk, one of the Taproot   BIP authors working on this as, like, his pet project.   So, you know, it's something  

[01:44:17] Unknown:

fascinating. You know? And you have also Eric, who who is probably   one of the most knowledgeable first people in the world on the inner workings of NYX,   reviewing every PR meticulously.   And, also, not to toot my own horn, but   I'm more on the paranoid side of things as Jonas would probably confirm.   And, I'm also looking at things, and   and everything is always open for review.   And,   there's some very technical people using it. Again, not to talk to anybody,   but there's, there's people who know what they're doing who are using NICK's Bitcoin and also looking at code changes.   So, I think those are things that are a little that are really, as you said, priceless and   not a business case.  



[01:45:07] Unknown:

Hey, Matt.   I had a flash of autism again. You know, when we linked up, we were talking about   PTLCs   and, I guess, Taproot in a sense of, like,   do channels need to close, or how are they updated?   We have Jonas   on here with us too. So,  

[01:45:27] Unknown:

I recall just based on what you said about Jonas, do do I have to close all my channels to take advantage of PTLCs?  

[01:45:38] Unknown:

Not necessarily.   You will have to   I mean, you won't get the benefits of music, for example, immediately,   because your channel's already open. Right? So if you want to close it, you always have to provide 2 signatures to close it. So I guess that's But, PTLC should be separate from that.  

[01:46:02] Unknown:

Well, so so   you you can have, like, the output updated in the existing channel. Right? But, to take advantage of maybe the updates to bolt 7 and 23,   that's when you need to close it and reopen?  

[01:46:19] Unknown:

Why would you have to close and reopen?  

[01:46:26] Unknown:

I'm   I'm a simple pleb.   This is this is the impression I was under.  

[01:46:32] Unknown:

Close and reopen   for updating to music or for updating to pOTLCs?  

[01:46:38] Unknown:

Just,   like, I guess, p t l c's,   maybe,   a taproot address,   music ideally, like, you know, whatever is, like,  

[01:46:48] Unknown:

the There's this meme there's this meme going around that, like, we open channels   for our grandchildren. Right? Like, you you wanna have long lasting channels that are   there for   years   and have reputation and whatnot.   But is that is that just a meme? Like, are we gonna be constantly   closing our channels, opening them up for whatever   new goodies we have in line?  

[01:47:16] Unknown:

That's that's a good question. So it depends on what the upgrade is. I think the lightning community, which   I'm not really a deep part of the technical   light lightning community. They would like to   start with upgrading to,   music   first,   which would mean that instead of having 2 public keys and 2 signatures on the chain for an open and close of a channel, you would only have one public key and one signature.   But for doing that, of course,   since the public key is in the channel opening,   you would have to close and reopen.   But, perhaps doing that can be deferred to your grandchildren, so you will always have this open channel. I think for if you want to upgrade to l 2, you would have to make another,   Bitcoin transaction that doesn't have to be a closing transaction, but at least another Bitcoin transaction.  

On Bitcoin transaction.  

[01:48:18] Unknown:

Just wanna catch up on 2 questions I saw in the chat. If if if the   PTLC   conversation is,   is that a as a conclusion?  

[01:48:30] Unknown:

We can go back to that. I wanna totally nerd out with Jonas later about Okay. Signatures and other stuff.  

[01:48:36] Unknown:

Okay. So, just quickly, I suppose it WinsomeHacks   says, I suppose the question then is, who do you see using it? There are many more people not using it and using it and want to migrate.   So   right   now, I really see the technical   users   who are focused on mix   using it at the moment.   And   I think that because we're so focused on on improving stuff right now, I don't think   we even have the time of doing tutorials.   And and so if if anybody who listening   is   a good project, always needs somebody who's into documentation   and and somebody who's who's   making videos and   and, and   and showing people how to migrate and all this stuff. So   I think our project would very much benefit from you if you're like that.  

But until that really happens and gets and gets easier, I really see   the   technical people using it or people within companies   who want a good basis to build on,   just   using Nix Bitcoin as as their starting point.   Another question that I saw  

[01:49:55] Unknown:

also oh, Winston. Just to that question, how to contribute, I think, another way to contribute is just to suggest what,   we should do with NYX Bitcoin because   perhaps,   there was this impression earlier   that we are kind of building Nix Bitcoin for some   ideal   Bitcoin user, but that's not the case, at least not for me.   Whatever I do, I do mostly for myself. I do stuff that I want to use myself. So   sometimes it's difficult   to,   to know   what is currently on vogue in in the Bitcoin world, like whatever,   lightning node manager   or something like that. So I'm always happy to get suggestions in in that area.  



[01:50:40] Unknown:

That, again, that's nice about Nix, and I guess free software in general, that the knowledge and the use cases of of different people can come together in a in a homogeneous project.   And and that's we share all of the knowledge. We share the use cases, and the more people who   put in the effort to get into next Bitcoin, the better it's gonna become.   And another thing that I really wanna get into with Nix Bitcoin is is exploring the different   ways that Nix OS has, or in the Nix OS community of verifying   packages   in in the way that   reproducibility   is understood in the Bitcoin world.  

I think we that's something we really need to do, Jonas. And we talked about originally, there was something   trustics that came up   that build basically, packages get built on on a decentralized   network of of servers controlled by different people, and then hashes gets of the final binaries get compared,   and then only the ones where   they truly are the same for everybody get get put into the system for users to download from. And   we really need to   exploit more the   reproducibility   in the sense Bitcoin nature of of Nix OS.  

[01:52:01] Unknown:

That I think that's another point that's, worth getting into. So you were talking about,   like, you do a next Bitcoin upgrade and perhaps your Bitcoin d version upgrades, and usually you would go to the   Nexo as as cash and download the new,   Bitcoin d version.   But that's, of course, a problem if you do that, and the cash   that is maintained by the Nixo as people is compromised and would, provide a   backdoor to Bitcoin   deal. So, what we're actually suggesting in the tutorial is to build everything yourself.   So then when you do a next Bitcoin upgrade,   it actually takes a while for me on my system. Usually, it depends sometimes half a day or so. But, during that time,   the whole   system, everything that changed is rebuilt   from source. And I think that's also a really great, security feature.  



[01:53:04] Unknown:

And then you can also have something which   I have is, is in my network and build server   where every every NixOS computer every NixOS machine,   running in my network put hands off all the intensive build tasks to the to the, build server, which has   a lot of cores, high memory. It's obviously not something that everybody can use. But if you're going the maximum security way, you wanna build everything from source and don't wanna wait half a day,   that's something we should look into.   Jonas, that was just I quickly Jake, continue, please. I just quickly wanted to so not everybody thinks that it's the only option is wedding half a day. You have the option of  

[01:53:55] Unknown:

of going If you do that, again, you're you're not a pleb anymore. You're like Saruman and his tower commanding his Urok Hai.  

[01:54:05] Unknown:

Saruman and his watch tower. Yep.  

[01:54:11] Unknown:

Okay. I think before,   so there are at least 3 three points on non Nix Bitcoin that I would like to to make before we go on to this other nerd discussion.   So one is that,   a security feature that we haven't mentioned yet are,   which I think   are underappreciated   are, Bitcoin d,   RPC   white lists.   So what that is, that's a list   that a bitcoindrpcuser,   is allowed to it's a list of RPC commands that a Bitcoin DRPC   user is allowed to make.   So you could have a public,   Bitcoin RPC user, which we're doing in,   NYX Bitcoin,   and that public user   only has read access to your Bitcoin d note.  

So the white list would say, yeah, you can you can, read blocks   or you can,   check what the chain tip is or you can see the peers, but you cannot   use send to address   or you cannot interact with the wallet at all because the RPC command   is not,   allowed to be used.   And, where is this useful? For example, it's useful,   if c lightning is compromised because usually, c lightning has full access has RPC access to to Bitcoin d.   So it a compromised c lightning   could, easily,   just spend   all the coins in the Bitcoin wallet as well, which is something that, of course, you want to prevent. But if you use these, white lists,   which we do by default in in Bitcoin, then even a compromise c lightning   cannot steal your coins on Bitcoin d because it uses   these, white lists.  

So everyone who's maintain who's running their own, Bitcoin node should think about this and integrate it or switch to next Bitcoin to make use of,   Bitcoin DRPC wireless?  

[01:56:23] Unknown:

Just we also do the same thing with macaroons.   So, for BTC pace and for example, we don't just give it the admin macaroons.   We make a custom macaroons that only includes   the,   permissions that,   BTS and pay silver absolutely   needs for LND.  

[01:56:46] Unknown:

Hey. Going through my point, apparently,   second one   is that we have a relatively comprehensive test framework.   So that means that if you open a PR,   then,   basically, a next Bitcoin will be spun up on a VM,   and it will be checked,   whether all the services are running and whether they can interact   with each other. And this is really useful. It's also basically a feature of, NextOS. I mean, other people can reproduce it,   but it works quite well. And as a result, we have relatively frequent releases   because we don't really when we do updates, we don't have to do manual testing,   really, perhaps a bit. But, if these tests are running, then we know basically that we can,   release,   the software. That's really nice. And also what this test framework   allows you to do is,   to have   a   set up so it's okay.  

It says this. Some of our back reports are scripts.   They are scripts that's built in Nix Bitcoin system and try to reproduce this bug.   And,   that works similar to the VM examples that we mentioned earlier. So you run the script. It can be just a few lines, sometimes 5, 6 lines,   and this will spin up a VM   and, with all the next Bitcoin services, and we'll try to do something weird that will exercise this bug. And this is a really nice feature,   because it allows you to quickly figure out what the problem is and how to solve it.  

[01:58:27] Unknown:

That's awesome.  

[01:58:31] Unknown:

Okay.   I think another point that next Bitcoin dev made earlier   was that,   next Bitcoin   is   for technical people,   but Nix Bitcoin is also a sandbox.   Nix Bitcoin is   modules,   Nixos modules.   And if you use the tutorial to set it up, you will use our preset   to,   which basically says how these services   interact with each other. We call this preset secure node, by the way, because it does all the Tor by default   stuff, etcetera.   But you don't have to use it that way. You can use it in any way you like if you understand NextOS. But what I think follows from that is that anyone since Next is also composable,   anyone could try to build something more user friendly on top. I mean, if you   let's let's say a graphical user interface, for example.  

So,   we have a user interface, but it's command line based. I think it's pretty good. It has versioning. It will tell you if you if there are incompatible changes in a new version, it will tell you what to do in such a case.   But it's,   just a command line interface. Other people may prefer graphical user interfaces.   And I think   because   NextOS is so composable,   it's relatively easy, if you know something about NextOS, to build stuff on top that's more user friendly.  

[02:00:07] Unknown:

Yeah. We had a question about that on Twitter   about you guys are never gonna implement graph,   GUIs yourself. Right?  

[02:00:15] Unknown:

There's a RTL that they're trying to merge. Right? I  

[02:00:19] Unknown:

I guess the question is if we're gonna have a GUI to to manage your node   and,   you know, your brother mentioned something,   some time ago about it was the next GUI thing, but   I also like the command line interface.   So I don't know. I'm I'm not I wouldn't be bullish on that. Yeah. I mean, Raspberry Blitz made the same decision.   Yeah. Great.   They they're much better than everything I'm hearing here. This is really good stuff about Raspberry Pi Blitz.  

[02:00:52] Unknown:

Bullish on RaspiBlitz   and, Ronin Dojo. But, man, I was gonna say these guys are,  

[02:00:58] Unknown:

clearly attack surface driven, so, adding a GUI doesn't necessarily warrant the benefits if Yeah. I feel that. It's it's cool that someone else could do it if they wanted to, though, very relatively easily, it sounds like.  

[02:01:10] Unknown:

Yep. But what you have to also know about GUIs nowadays is that the way people develop GUIs with,   Electron, which sucks, or,   Node, which   JS, which has   you know, we used to think that supply chain attacks are in theory and never happened, but now we know they do happen, and they happen almost exclusively through NPM and the Node.   Js,   ecosystem.   So   GUI thing to me, at least to be a huge problem. And also on,   on Linux, as long as you're not using Wayland, which is the newest,   kind of   graphical,   driver behind the scenes. If you do X Server, which is the standard on pretty much everything,   you have to know that each one of your GUIs can see   all other GUIs and can read all keystrokes from all other GUIs. So that's maybe something that reflects badly on Linux in general,   but that's the way it works and,   it's a terrible   thing. It's it's a huge security hole, and the only way to get around that,   while staying in the Linux world is by using Wayland, which is really good and,   is already being used, I think, in Fedora and Linux   Mint. I'm not sure, but definitely in Fedora.  

Or using something like cubes OS,   which goes the extreme route of running everything in its own virtual machine.   But,   yeah, it's it's gooeys bring a lot of problems. They're not just good.   If you want a hardcore security   node,   privacy node,   probably it's a good decision to stay away from GUIs in general.   And,   one off the topic thing I want to say before Jonas   makes his   third point,   right, about   next Bitcoin   is that   privacy   I tried to say this often,   and I also wanna say it here is that privacy is not something dark.   Privacy   is not something illicit or criminal. Privacy is the basic way that the world used to work and should return to working that   a human being has control over   who he exposes private information to and to what degree and   and and for how long and, you know, just   really the individual being in control and and they the way it works now with with regulation and all these things are toothless,   and we're moving   into a world that's that's not the way it's supposed to work. And privacy is not the issue. Privacy is actually   the the most important thing that we're losing and it's not it's not, you know, something that usually in the marketing things, privacy is portrayed as some, you know, somebody with dark goggles and a hoodie, and it's not that. It's and and bit makes Bitcoin is not a target project because we use Tor and privacy.  

It's a very bright project, so a positive project that we give the user control over who he exposes information to, and we always make the decision towards privacy,   for the user,   and and he needs to invest effort to   leave that secure space.   And and I think that's how it's supposed to be. If you wanna start risking stuff,   you should have the technical knowledge of how it works. But by default,   we wanna protect you as much as we can.   So, Jonas, please continue.   Just this is something important that I wanna say on every report that I have.  

[02:04:55] Unknown:

Thank you for reiterating that. That's super important, and,   I'm kind of a broken record on the show about it. So,   but the freaks can always use another reminder.  

[02:05:07] Unknown:

Absolutely.   I actually made my 3 points already. The only thing left on my list is, like, what what to do, where where to start if you want to use the next Bitcoin now.   Should should I go on with that? Or do we have more discussion topics? Where to start?  

[02:05:26] Unknown:

Yep.  

[02:05:27] Unknown:

Yeah. Let's that seems pretty important.  

[02:05:29] Unknown:

K. We've mentioned a couple of times we have this matrix server, so that would be a start. Just join. Or if you would prefer IRC, join IRC on,   Libera. It's   pound Nix   dash Bitcoin,  

[02:05:44] Unknown:

I hope, or Nix Bitcoin, I think. Nix minus or Nix dash Bitcoin.  

[02:05:49] Unknown:

K.   Then   we have this tutorial. So if you go on to GitHub /   GitHub.com/fortdashnix/   nixdashbitcoin,   then, you will find a read me, and there's a get started section, and that brings you to a tutorial,   kind of discuss what it what it does. But that should be a good start and should   basically   work if you have a target system. If you don't have a target system,   then you can just run the examples. We also discussed this this earlier.   As long as you have the next package manager, that should be also easily   installable, I guess, with regular package managers,   depends on your distro.  

But these examples,   they worked on macOS at one point, but I don't think they work anymore, unfortunately.   So for that, you would need a a Linux   machine.   What else? I think those those are the the most most important points how to get started if you want to use Next Bitcoin.   Yeah. Nixbitcon.org,   that's also another repository in the Fortnix   organization.   And there, you basically have a good example of how you could set up a system, for example, with a public BTC pay server,   etcetera.   And,   yeah, lastly, if you would just want to learn more about NYX, I'm not sure if I've, mentioned earlier, they are also the so called nicks pills,   and, this is a tutorial that,   basically explains   all the advantages of NIX and also gives you an introduction   into,   NIX as a programming language.  



[02:07:39] Unknown:

With the NIX pills, I'm I've gone through them many times, and I I have to say I never understood them.   I I went at it, I think, also,   like, other people using Nix Bitcoin, who I know of, from the hacker side where I just   used it until I figured out how to use it.   And,   that's also if you're more that kind, then   I I and also another person that I know who uses NixBitcoin can give testimony   that that also works. So,   you don't have to have a background in computer science to to with the right attitude, get get, you know, get this thing running.  

[02:08:20] Unknown:

Yeah. There's there's levels to this game.   Absolutely.  

[02:08:26] Unknown:

I love it.  

[02:08:27] Unknown:

What what is the orbit?  

[02:08:30] Unknown:

Yeah. Someone please give a definition of orbit.  

[02:08:34] Unknown:

You are.  

[02:08:36] Unknown:

I've had someone try to explain it to me for, like, an hour and a half, and I just can't.  

[02:08:40] Unknown:

I just think of it as, like, a whole new networking stack, like,   with its own language and everything, and,   yeah, I'll just get that.  

[02:08:51] Unknown:

They they have, like, shit coins integrated.   They, like, call them, like, planets, stars, and universes. And imagine if DNS  

[02:08:58] Unknown:

was, like, a shit coin,   and they also had, like, a language   to,   essentially provision,  

[02:09:07] Unknown:

different IPs and whatnot. And then I'm scared I'm gonna have nightmares from this.   My pure Bitcoin head has never heard of this.  

[02:09:18] Unknown:

I'm fine. But yeah. All the all the urban guys are gonna   to this tiny little mention of it, and, they're all gonna flood our mentions now. Next Bitcoin is gonna get this this is like the  

[02:09:31] Unknown:

the insider alpha, right, for Citadel dispatch. Like, there's now a Nick's Bitcoin and Urbit beef. We just started just now.  

[02:09:41] Unknown:

One question, if anybody knows, what is squeak mode?   Because somebody opened a PR, and they they can't I mean, something called squeak mode,   which doesn't have a description in its repo, and I have no idea what it does.   If anybody knows what it is, please tell us.   No. You ever you ever figured that out?  

[02:10:05] Unknown:

Squeak Note, I have no idea what it is.   But the PR gets updated.  

[02:10:10] Unknown:

Matt, Bitcoin sign guy is still there. Right?   At,  

[02:10:14] Unknown:

Erbit? Yeah. BSG is, like, product lead or something at Urbit. So when I said that I've been been chilled it for, like, an hour and a half, it's really just him personally, and it was way longer than an hour and a half. It was, like, multiple times.  

[02:10:28] Unknown:

I'm bullish on anyone that can get in front of Janet Yellen with the buy Bitcoin stuff.   I'll figure it out.   I guess, is this the time where now I can just, like, Yeah. Just you want you want your autism to run wild? Or Yes. You wanna wrap it up? Wait a sec. Wait a sec.   Go ahead.  

[02:10:50] Unknown:

There you go.  

[02:10:51] Unknown:

Yeah. Sipping on the good stuff. Nice. Nice. Alright. I'm a go grab a beer too one more.  

[02:10:57] Unknown:

Alright. I listened to a lot of, rabbit hole recaps and wanted to do that one day.  

[02:11:02] Unknown:

Oh, that means a lot. That means a lot.   Just trying my best out here.   I'll tell you, this conversation has been fantastic. I've learned a lot. So   and I look forward to trying Nick's out.  

[02:11:15] Unknown:

Same. I learned about RAS by Blitz being   being really cool and also Erbit.   I I'm kind of curious now. I wanna take a look at it, see if I if I can grok it.  

[02:11:31] Unknown:

Yeah. You you try and figure it out, and then I'll bring you on with BSG, and we can do an urban show.  

[02:11:38] Unknown:

No. Well, back to what Jonas is saying, it's been a pleasure being on that. You know,   just like   I I reminisced to the bear market times of 2018, and,   you guys, TFTC,   Stefan Lavera,   Block Digest pretty much got me through. Everything else was kinda shit corny. So,   it's amazing to see what,   these,   quote, unquote,   podcasts have blossomed to be as, like, communities now.  

[02:12:08] Unknown:

Yeah. The pleasure is all mine.  

[02:12:11] Unknown:

So let's let's jump into your autism. What do you got for us? Yeah. You know how me and p roll.   So, Jonas,   because, you know, you're into this Taproot stuff and, you happen to be one of these BIP authors,   I'm curious, you know, what's up with signatures these days? You know, I'll be in the DMs with Shinobi once in a while. They'll be floating some other random ring signature stuff.   I watched some half aggregation stuff that you posted   that may be used for, gossip, and then also music could be used for gossip. So,   we'd love to dive deep into the signature   rabbit hole   and, potentially   end at, like,   where threshold is at these days.  



[02:12:58] Unknown:

Wow. That's a whole another 2 hour   conversation.   Okay. Where are signatures these days?   According to my best estimate, Taproot will activate sometime November 14th.   So from then on, we will have, Schnorr signatures on Bitcoin main chain, which will be   really nice.   Will be interesting to see how people are going to use it.   Right now, I spend a lot of my time trying to,   make music usable.   I talked a bit early about about it, which,   basically, what it does is,   if you had previous if you have a multisig,   let's say a 2 of 2 in the lightning case,   then right now, you would have to write both public keys. And then if you close the channel,   both signatures on chain, which is both bad for privacy,   and, also, it costs more money using lightning,   that way   compared to having just a single public key and a single signature, which is what, music would allow you to do. And this is what I hinted at earlier that   the Lightning people are really interested in making this upgrade once,   Taproot   is,   or has landed on main chain. But, of course, this all needs to   be spec'd out how exactly this is going to look like. So,   the lightning people need to do that. But before they can do that,   we also need to, write a specification   how exactly music should look like. Like, how to how do the various signers interact to actually   aggregate their public keys and signatures into a single   signature. So I'm working on that. Implementing this,   in Libsec p z Libsec p z k p right now,   which is a a fork of Libsec p, the the library that Bitcoin Core   uses,   and also trying to to spec it out.  

And there are also, like, regular wallet authors who would like to use music.   There are some   like having this.   Some wallets,   wallets provide multisync functionality, and they want to use music as well because they see as it as a big advantage for their users,   if they have to pay less fees. And, also, if it isn't immediately obvious on chain that someone is using a multisig wallet, which I think is a really big benefit of these things.   So that's in the music world. But,   there are many different things that we we also want to do.   So,   you mentioned ring signatures.  

So interestingly,   in,   in SegWitv0,   our current,   most recent   address format. In order to spend it,   you need,   to reveal the public key   because in the output of this coin   or of this u UTXO, there's only is is   a hash of the public key. Right?   So that will change in Taproot where the, public key,   is barely written or is   is written into the output,   of this coin.   So that means there's no hashing involved.   And this makes it simple to,   create ring signatures over the UTX OSAT.   So how does that work? What does it mean?   What you can do, for example, is,   let's say you have the UTX offset   and you just filter the ones that are using   Taproot.  

And then you look at the public keys, which is now possible because they're not hashed anymore.   You have then you end up with a list of public keys,   and then you can create a ring. If one of the public keys is yours,   then you can you can create a ring signature.   And the ring signature,   over these public keys will prove that you own one of these public keys.   One of them, but you don't reveal which one.   And   this could be interesting   in various   spam prevention,   schemes,   because you don't have to reveal exactly which coin you own   anymore.  

So for example,   there were some discussions on joint market fidelity bonds where   you don't say exactly which output you own, but you say, I own this output.   I own one of these outputs, but you don't say,   specifically   which one you own. And that's something that's   possible   with Taproot. It was possible before, but, basically, computationally   and complexity wise, relatively infeasible.   So I think that's that's an interesting, research area to see how how that could,   improve the privacy of these fidelity bonds because these fidelity bonds, they are also suggested in suggested in the lightning world quite a bit.  

[02:18:24] Unknown:

So yeah. Okay. So if they're not hashes, essentially, are these points just like, I guess, that you're it's almost like the multi hop blocks or whatever I think I've seen you previously talk about. And then secondly,   this is what's, like, commonly referred to as, like, liquidity   pools or whatever. Right? Like, if you can,   prove that you own part of that Fidelity bond.  

[02:18:50] Unknown:

I haven't heard the words liquidity pool before.   Perhaps perhaps, liquidity   something liquidity,   but not pool.  

[02:19:01] Unknown:

Okay. May maybe,   mixing 2 concepts. But, They are liquidity ads.  

[02:19:07] Unknown:

Not not that, but, that people do. You mean like a non set. Right?  

[02:19:12] Unknown:

Well well, essentially,   because you're pooling you could still pool capital in a sense of, like, how he was mentioning the Fidelity bond,   where you just have one of the keys. Right?  

[02:19:24] Unknown:

Yep.   So this isn't something that would happen on on chain. It's totally off chain.   I mean, basically, Monero is kind of similar, but there, it's really on chain where you prove that you own one of these,   input coins, but you don't reveal which one, and you do that with a ring signature. But here, it would be just off chain to prove that you own some,   coin without revealing which one.   Okay. And,   another topic that you mentioned   was aggregation.   Yes.  

[02:20:03] Unknown:

About gossip. Yep.  

[02:20:06] Unknown:

Okay. So,   as I said, I'm not that deep into the technical   lightning community.   But,   it seems that,   one   kind of problem is that in the gossip network,   your channel announcements are relatively large,   and that's because the channel announcements   contain multiple signatures, multiple public keys   in order to prove, for example,   that you own a coin on chain to make this resistant this message resistant against spam because you don't want anyone to just send any message because that would,   bring down the gossip network very quickly. So you're only supposed to send a message if you can prove that you have a coin on chain, and that's basically your your spam prevention,   method.  

Now the current channel announcements, they are relatively big.   The question is, how can you reduce the size of these? And,   one thing that they   include is, for example, they include,   the public keys of both nodes   that open the channel and also signatures from both nodes. So you could use this music technique   I mentioned earlier to make,   both public keys into one public key   and also both signatures into one signature.   And, that way, you already save a lot of space,   but you can go further.   So music is   essentially a way to have multiple parties sign the same message,   but there's also the concept of   signature aggregation. And when we talk about that, we usually mean there are multiple people   signing a different message.  

So what could happen is that,   each of these channel there are channel announcements,   gossiped, and, each of these channel announcements has a signature.   But   and this signature signs the channel announcement itself.   But,   what if you could have a batch of channel announcements,   each having a signature, and aggregate these signatures together into   a smaller signature?   And that's something that would be possible with a concept of, half aggregation,   because half aggregation doesn't need   cooperation with the signers. So you can take a bunch of signatures   and just aggregate them into 1 half aggregated signature.  

It's, it's half as big as the individual signatures   combined,   and   this would already give you quite a lot. You could go even further than that using full aggregation.   And this is only on the Lightning gossip network. So perhaps one day, this could also be used   on the Bitcoin   consensus layer   to reduce the size of transactions   where you have one signature per transaction   as opposed to one signature per input.  

[02:23:21] Unknown:

Is that,   am I mixing concepts up, or is that a cross signature input aggregation?  

[02:23:28] Unknown:

That's cross input signature aggregation. Exactly.   C cell.  

[02:23:34] Unknown:

And that that would be particularly helpful for CoinJoin.  

[02:23:39] Unknown:

This would be helpful for CoinJoin,   because now it makes   sense   to create larger transactions and pool your inputs with other people,   because   then you   on like, if you imagine an infinitely large coin join, then your cost,   your fee that you pay for the signature   is essentially 0   because you don't have a signature anymore. It's aggregated into everyone else's,   signature.   But,   actually, the advantage that you get is   not that big. So that's something that,   that will be would be interesting to see in a world where we have signature aggregation   because the signature   is relatively large. Right? It's 64 bytes,   but it's also already in the witness. Right? So it's also 64 witness units   weight units.  

So,   in terms of weight units, your gain isn't that big in terms of bytes. Okay. Your transaction will get smaller. But in terms of weight units, I think in the infinite coin join example, you would get you would get, like,   18%   reduction   in weight for an average   transaction.   And weight would also translate into fees, so an 18% reduction in fees.  

[02:25:02] Unknown:

So, therefore, it effectively   make people,   want to do this,   as, like, a de facto or default versus doing it the other way,   in a sense where you opt into a CoinJoin. You'd essentially be of the mindset to opt out for some reason.  

[02:25:21] Unknown:

Right now, CoinJoin costs more than a regular transaction. In this world, CoinJoin would cost less than a naive Bitcoin transaction. Right?  

[02:25:30] Unknown:

Exactly. I mean, there are also downsides, of course, of doing a coin join with other people. So it's like a question of   what ex I mean, in terms of usability, right, it takes longer to create a coinjoin, for example, because people need to interact and need to send these, signatures around. That's the downside. So the question is, like, is the upside worth it?   But, yeah, it's also it just gives you a good reason to co and join because now it's not just   the, how do we call them earlier, the dark people anymore with the hoodies because now it's everyone. We just want to save, dark  

[02:26:05] Unknown:

people. Yeah. I mean, it could work well Because it specifically for, like, lightning opens. Right? Because they're more low time preference transactions where people are already online anyway.  

[02:26:16] Unknown:

So this is this goes back to, like I I I left that one podcast that also got me through the bear market, Matt. It was noted. And there is a glorious episode, well, you know, with Bittstein,   Pierre Richard, and, an actual watch streamer called Johnny Dilley. And he goes into this in-depth, essentially, where the holy grail is,   you know, some sort of,   batching in a sense where every channel open or channel close is also a coin joined because it's,   economically incentivized.  

[02:26:50] Unknown:

I mean, that's the meme. Right? Every transaction a coin join, I heard it on rabbit hole recap. I've been spreading it before,   that as well.   And,   even better is every channel, lightning channel open, should be a coin join   in in the ideal world where you have multiple channels, dual funding channels, and whatever. And if that's cheaper than not doing that, then that's that's even better. But, I mean,   even in terms of bytes, like, for for the network, it gets you a lot. It's like a 40% reduction   in the just size of transaction in in bytes.   So, that's our already a huge thing.  



[02:27:29] Unknown:

I just wanna say I misnoted.   What a good show.   Yeah. Yeah. I mean, we had we had, Johnny Dilley on   TFTC as well. That was an in person rip in New York. That was a fucking fire rip. Oh, yeah. That that was really good. That too.   So, I mean, guys, this has been   a absolutely fantastic conversation. We are hitting the 2 and a half hour mark.   You think we should just wrap up with some final thoughts?  

[02:28:01] Unknown:

Sure. Sure. I know it's probably   getting late for,   the other 2.  

[02:28:07] Unknown:

Yeah. Let's let's start with next Bitcoin dev. Final thoughts. Boom.  

[02:28:11] Unknown:

Wow. Okay. I was just thinking about metrics because somebody was,   writing about Telegram.   I think this is a chance to make a bigger point that,   next Bitcoin is the node for the digitally sovereign,   people who wanna have full control up down to the hardware,   and also wanna have an overview over how it works technically,   while at the same time not having to become expert system administrators   to have extremely secure,   configuration.   So,   with that in mind, it's it's also   probably right now not not for,   the super noobish people, but,   I hope that once we once we get the   project   to a certain finish line,   we can start or it's probably gonna be me because Jonas and, Eric are   more on the technical side,   start making   more documentation   for migration   and just in general,   different use cases and how to do it.  

And,   yeah, we're building on a on a good foundation, on a good technical foundation right now.   And,   rather than doing it vice versa, rather than getting users involved and then trying to improve the technical foundation.  

[02:29:40] Unknown:

Awesome. Thank you, Nix Bitcoin Dev.   Vivek, final thoughts.  

[02:29:48] Unknown:

Yeah. So,   I guess   nobody's   untouchable.   No plan is foolproof.   Software will break.   That's why we strive for FOSS. That's why we strive for agnostic   implementation.   You know, anything that we're interested in,   That's why I was drawn towards Nick's Bitcoin.   I will be,   not only releasing the tutorial for this after,   you know, submitting it with,   Jonas, Nick for   making sure I'm doing everything properly. I'll also be speaking about it at tabconf later this week. But, just really   find,   a FOSS project or something in this community that interests you and see if there's one way you can some way you can contribute to it   and,   just try to build I think I've heard Nick's Bitcoin say this before.  

Cyberpunks write code.   Twitter's fun, but, someone's actually gotta roll up their sleeves and,   walk the walk. So much love to everyone that does sit and walks the walk.  

[02:30:53] Unknown:

Fuck. Yeah. Enjoy tab conf. It looks fantastic.  

[02:30:56] Unknown:

I'm gonna miss you.  

[02:30:59] Unknown:

Thank you, Vivek.   Jonas, final thoughts.  

[02:31:03] Unknown:

I have a lot of fun developing Nix Bitcoin.   It's a great   side project.   The lows are very low too.   I would still recommend to,   would generally recommend to have a look at NextOS. I think it is a game changer in many ways. If you've   if you stepped over a certain point, you don't wanna get back into regular Linux or regular   system administration.   The community is the general Next OS community is really large and also great.   I'm going to continue doing this because I'm going to continue running a Bitcoin node, and somehow it needs to be, managed. And that's going to continue   to be through Bitcoin.  

If people want to join,   this project will be really cool to see you on GitHub or Matrix.  

[02:31:58] Unknown:

Awesome. Thank you, Jonas.   I wanna thank the Rider Die Freaks for being in the live chat   and hanging in here with us and   being a part of the show. You guys are what make it unique, and I wanna thank all of you who choose to support the show and keep it ad free and sponsor free so we can focus on actionable Bitcoin discussion.   It is truly special. As I said it in the beginning of the episode,   I know I've been traveling, and our Bitcoin Tuesday schedule has been in flux,   But we're going hard into the winter months, so expect a lot of more great discussions   on our Bitcoin Tuesdays.  

I wanna thank,   our guests, Nix Bitcoin Dev, Vivek, and Jonas for joining us. I really do appreciate all the work you guys do in the space. I hope you come back on,   in the future,   not only to follow-up on this project, but also for future,   autistic discussion.   Looking forward to that, and just thank you, guys.  

[02:32:58] Unknown:

Thank you very much for having us.  

[02:33:00] Unknown:

Yep. Thank you. It was fun.  

[02:33:05] Unknown:

Yeah. I'm like, oh, god.   Oh, oh my god. Bitch, I won the game. Y'all just come and take it from the side. I'm like, oh, god. Oh, oh my god.   Everything I do, you know I do it for the squad. I'm like, oh, god.   Oh, oh my god. Bitch, I won the game. Y'all just commentate from the   So I gave them this right here, now go get bloody   Check my last album, all y'all know I'm running   Flipping script just because I couldn't fucking stun it, this this this this this the type of shit my life was all about,   check the forms unless you know I'm falling down, they say Logic, you too humble boy just let it   I'm like, oh god. Oh. Oh my god. Everything I do, you know I do it for the squad. I'm like, oh god. Oh.  

Oh my god. Bitch, I run the game. Y'all just time to take from the side. I'm like, oh god.   Oh. Oh my god. Everything I do, you know I do it for the squad. I'm like, hold on. Let me bring it back. Everybody know I'm bringing a fax. And it went around. I got it like that. Because I put everything   Oh, my god. Bitch, I won the game. Y'all just commentate from the side. I'm like, oh, god.   Oh. Oh, my god.   Everything I do, you know I do a do a fool. I know. I know. I know.   I   know. I know. I know. I know. I know. It's been a hell of a ride.  

[02:36:19] Unknown:

That was our boy logic ride or die Bitcoiner. We'll be joining us at Bitcoin 2022   for the first Bitcoin infused music festival,   April 6th through 9th.   Ticket prices go up tomorrow.   You get a $100 off if you buy with Bitcoin. You get an additional 21% off if you use code open source.   I do not make any money from that code. That was not an ad read. I am helping them organize it.   Love you all, freaks. We'll be back for Bitcoin Tuesday next week,   with Bitcoin q and a, and I'll see you all for rabbit hole recap on Thursday.   Stay humble, Stack Sats.